你懂得吗？云原生应用的15个特征

Posted 2021-04-02 勾勾的Java宇宙

什么是云原生应用

顾名思义，云原生应用的概念由「云」和「原生」两个部分组成：

• 「云」在这里指的是云平台，也就是平台即服务（Platform as a Service，PaaS）

• 「原生」指的是专门针对云平台而设计和实现，充分利用了云平台的特性。

所以，「云原生」应用的微服务可以专注于实现业务逻辑，而把微服务架构的复杂度交给云平台来解决。

「原生」通常意味着高效和难以移植。

「原生」是针对特定的平台而设计，可以充分利用平台的特性，因此运行起来非常高效；同样，与特定平台的深度绑定导致很难移植到其他平台。

云原生应用同样具有这两个特征，但是对于云原生应用来说，难移植并不是一个问题，毕竟迁移到云平台之后，不会再想迁移回去。

云原生应用的特征

1. 单一代码库

云原生应用必须有单一的代码库，并在版本管理系统中进行追踪。

对于微服务架构的应用来说，每个应用由多个服务组成，这些服务应该由单一的代码库进行管理，这保证了构建版本的稳定性。

• 如果一个改动涉及到多个服务，则这个改动应该在一次代码提交中完成对所有相关服务的修改；
• 如果服务的代码分散在多个代码库中，则一个改动会被分成多个代码提交，每个代码提交都会触发一次持续集成流程，产生对应服务的构建版本，这些服务的构建版本只包含了部分改动，是不完整的。

2. API 优先

微服务架构的应用使用公开 API 来作为服务的对外接口，API 屏蔽了服务的内部实现细节。API 优先的设计策略指的是在设计阶段，应该首先设计 API 并确定相关细节。

• API 优先的策略保证了 API 的稳定性，同时可以减少不必要的后期修改；
• API 优先的另外一个好处是不同的团队可以并行工作，从而提高效率。

3. 依赖管理

云原生应用通常会包含全部所需的依赖，尤其是以容器形式运行的应用，典型的例子是微服务的 REST API。云原生应用会自带嵌入式的 Tomcat 这样的服务器来提供 HTTP 服务。

4. 设计、构建、发布和运行

云原生应用应该有完整的设计、构建、发布和运行流程，如下图所示。

5. 代码、配置和凭据

代码、配置和凭据是云原生应用开发中创建的三种不同类型的实体。

• 代码包括源代码和相关资源文件
• 配置是与部署环境相关的配置信息，通常以 XML、YAML、JSON 或属性文件的形式出现，配置中包含的信息包括第三方服务的连接方式、数据库连接信息和应用自身的配置属性等
• 凭据指的是密码、私钥和 API 密钥等敏感信息

6. 日志

与传统应用不同的是，云原生应用并不需要对日志的输出方式进行很多配置，只是简单地把日志写到标准输出流（stdout）和标准错误流（stderr）。

日志的收集和处理由云平台上的其他服务来提供，这把应用开发人员从日志管理相关的任务中解放出来。

云平台上的日志管理服务非常多，开源的典型实现包括 Elastic 技术栈（ElasticSearch + LogStash + Kibana）和 Fluentd。

7. 随时可丢弃

云原生应用的生命周期可能是短暂的，随时可能被终止。云平台可能会随时启动和停止应用的实例，这就要求云原生应用的启动和停止速度都要非常快。

8. 支撑服务

支撑服务是一个宽泛的概念，包括数据库、消息中间件、缓存、用户认证和授权、存储等，连接这些支撑服务的配置信息应该被抽离出来，在运行时根据部署环境提供实际值。

9. 环境等同

开发、测试和生产环境之间不应该有差异，每一个唯一版本的构建工件可以被依次部署到不同的环境，在测试环境上经过测试的版本，可以直接部署到生产环境。

10. 管理任务

云原生应用运行中可能会需要执行一些管理任务，比如生成报表或者执行一次性的数据查询等，这些任务通常并不属于业务流程的一部分，更多的是为了管理和运维的需要。对于这些任务，应该创建独立的应用，并在同样的云平台上运行。

对于定期执行的任务，可以充分利用云平台的支持，比如，Kubernetes 提供了对定时任务（CronJob）的支持。

11. 端口绑定

云原生应用在运行时并不负责管理实际的端口绑定，而是由云平台统一管理。

12. 无状态进程

云原生应用应该是无状态的。所有的状态信息都应该从应用中抽离出来，并保存在支撑服务中，比如数据库中。

正因为应用是无状态的，才可以由云平台快速的启动和停止，并进行垂直或水平扩展。

13. 并发性

云原生应用使用水平扩展来并发运行多个实例，使用负载均衡来把请求分配到某个实例进行处理。

14. 遥测数据

云原生应用需要收集一系列遥测数据，包括应用性能指标、运行状态和日志等，这些遥测数据，对于云平台和应用来说同等重要。

云平台可以用性能指标来进行自动水平扩展，比如，Kubernetes 支持 Pod 的自动水平扩展，当 CPU 的利用率超过预定的阈值时，会自动启动新的 Pod 来处理请求。

15. 认证和授权

云原生应用应该是安全的，安全应该在应用的设计阶段就充分考虑。在实现中，可以使用基于角色的访问控制（RBAC）来保护 API，已经有大量的开源框架来帮助实现认证和授权。

总结

在理想情况下，云原生应用应该具备上述全部 15 个特征，但是在实际的开发中，不一定能够做到。开发团队可以根据需要，选择对应用最重要的特征来实现。

有些比较好实现，有些则相对较难一些。在实际的开发中，应该尽可能让自己的云原生应用满足这些特征。