1.6 实现云原生模式

云原生基础架构由应用程序来维护，而云原生应用则由基础架构来维护，两者密不可分。这就要求基础架构和应用程序设计必须是简单的。如果一个应用程序比较复杂，则应该采用微服务模式，将复杂功能拆分为细微的服务，然后通过集成这些细微服务来组装成一个应用系统。但由微服务构成的如此复杂的系统，势必无法通过人工管理，应该采用自动化管理，这也是云原生应用的一个基本特征。

在传统单体应用中，企业所用开发语言是单一的，例如Java体系或者.Net体系，但是在众多微服务进行开发时，语言限定得到了解放。负责某一个微服务的开发人员擅长使用.Net语言，负责另外一个微服务的开发人员擅长Node.js，这就出现了多元化。云原生应用并不限定语言，它只对诸如弹性、服务发现、配置、日志记录、健康检查和度量检查等模式有要求。针对两种不同情况，目前常用的做法主要有两类。

（1）单一语言情况下，可以通过导入标准库的形式在程序代码中声明云原生特征。例如Java语言系的Spring Cloud，可以通过类声明来实现配置、服务发现、熔断机制等功能。

（2）多语言情况下，则可以通过伴生（sidecar）模式来解决。该模式将实现各种功能的微服务应用通过容器化部属捆绑在一起。常见例子如Envoy proxy为服务增加弹性和指标，Registrator通过外部服务发现服务，Configuration监视配置更改并通知服务进程重新加载。Health endpoint提供用于检查应用程序健康状况的HTTP端点。这些都简化了云原生架构的开发难度并提高了组件复用率。

在云原生架构下，应用的生命周期也是由软件来进行控制的，普通用户无须关心应用的生命周期。应用程序的集成、测试和部署应该是自动化、自助式的，按照DevOps文化来进行。