机智云代码移植_我眼中的云原生应用

把发在知识星球的文章转过来，原文: https://t.zsxq.com/aiyzneq

软件系统经过漫长的发展时代，演进到了今天的云原生应用。究竟什么是云原生应用？我理解的云原生应用就是说一个应用程序的设计完全是为了云化而设计，为了优雅的跑在云上而设计。这并不是说『任何一个应用程序只要部署到一个云上（比如：阿里云、腾讯云、aws等），那它就是云原生应用』。在我眼中的云原生应用至少应该具备以下的一些特点：

1. 弹性好，能够随便 scale out，能够随便重启

一个应用程序要想具备水平扩展的能力，最简单有效的方式就是把应用程序设计成无状态（Stateless）服务，坚决避免持久化状态数据到本地文件系统。一切状态数据都需要存储到数据库或存储服务中，数据库和存储服务应该尽可能的使用云厂商提供的产品，而不是自建。

2. 不要使用本地配置文件

应用程序的配置项尽可能设计得简单，每个配置项都有一个明确的语义和行为，多个配置项之间最好不要有强相关性。

坚决避免采用本地配置文件的方式来管理配置项，不管配置文件是 yaml、json、toml 还是 ini，都不需要这样的一个配置文件，比如 nginx.conf 今天来看就不是一个好的方式。配置项的管理应该采用环境变量或则配置中心，最好的方式是配置中心，支持配置动态更新。

3. 不同环境要保持一致

应用程序不管是部署在开发环境、测试环境还是最后的生产环境，都需要可能的保持一致，这里的一致主要包括三个方面：一是代码要一致，不能因为环境的不同就要使用不同的代码；二是配置项要尽可能一致（日志 debug 开关、调试选项、使用的 DB 实例等除外），在不同的环境里不应该出现不同的代码逻辑控制开关之类的配置；三是依赖的数据库、中间件等基础软件要一致，不能开发环境要使用 MySQL，而生产却使用 Postgres。

4. 日志要能够被统一采集、存储、分析

现在的云平台几乎都提供了日志服务，一个云原生应用的日志应该符合日志服务标准的，是能够被日志服务采集、分析、存储的。不能够将日志随意写入到本地日志文件。

5. 应用程序的交付环境应该是稳态的、可移植的

云原生时代，应用开发者不再只是交付应用程序的代码和配置，而是要交付一个完整的应用程序运行环境，比如：你是一个 java 应用，那么你应该提供正确的 java 版本及运行环境；是一个 c/c++ 应用，那么你应该提供正确的所依赖的 so 库等。总之，开发者要交付的不仅仅是代码，而是整个运行态。交付出来的应用的整个运行态要是稳态的、可移植的。目前为此的主流做法就是采用 docker image 来打包这样的一个运行环境。

甚至可以说，应用程序应该采用 docker image 交付。

6. 充分使用云能力

计算、存储、网络，再往上的数据库、文件存储、中间件等基础设施应该尽可能的采用云服务，而不是自建。

7. 可监控

应用程序要能够被监控，被治理。甚至采用一些监控标准来提供白盒监控的能力。目前，prometheus 在云原生领域是比较主流的。

8. 对计算、存储、网络无特殊要求

对底层硬件环境有特殊要求的都不算云原生应用，比如要求物理机，要求裸金属服务，要求单实例cpu核数，要求网络类型，要求磁盘存储设备等。

这是目前，我站在应用软件角度所看待的云原生应用的模样。除了应用，其实还有云原生数据库，云原生中间件，元原生容器平台等等，这些服务的云原生条件就会有一些不一样的地方了。

文章优先发表到知识星球。