云原生应用的概念和云原生应用的 15 个特征

微服务架构只是一种软件架构风格，并不限制所采用的实现技术，开发团队可以自由选择最合适的技术来实现。微服务架构实现最大的挑战是它的复杂度，这些复杂度是微服务架构本身天然所具备的，是每个微服务架构应用绕不开的难题。在实现微服务架构时，开发团队当然希望把全部的精力放在实现业务逻辑上，而不是应对微服务架构自身的复杂度，这就意味着，需要选择能够帮助应对这些复杂性的平台和工具。云原生（Cloud Native）应用就是微服务架构的最佳实现方式。

云原生应用的概念

顾名思义，云原生应用的概念由云和原生两个部分组成，云在这里指的是云平台，也就是平台即服务（Platform as a Service，PaaS）；原生应用指的是专门针对云平台而设计和实现的，充分利用了云平台的特性。应用的微服务可以专注于实现业务逻辑，而把微服务架构的复杂度交给云平台来解决。

起初CNCF(云原生计算基金会)认为云原生系统需包含的属性：

1. 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
2. 自动化管理：统一调度和管理中心，从根本上提高系统和资源利用率，同时降低运维成本。
3. 面向微服务：通过松耦合方式，提升应用程序的整体敏捷性和可维护性。

随着近几年来云原生生态的不断壮大，所有主流云计算供应商都加入了该基金会，且从 Cloud Native Landscape 中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF 基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF 为云原生进行了重新定位。
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

• 容器技术（container） ：容器技术真正核心的创新是容器镜像（docker image），镜像是一种新型的应用打包、分发和运行机制。容器镜像将应用运行环境，包括代码、依赖库、工具、资源文件和元信息等，打包成一种操作系统发行版无关的不可变更软件包。容器技术和云原生好比一对螺旋体，容器技术催生了云原生思潮，云原生生态推动了容器技术发展。容器镜像打包了整个容器运行依赖的环境，以避免依赖运行容器的服务器的操作系统，从而实现“build once， run anywhere”。容器镜像一旦构建完成，就变成read only，成为不可变基础设施的一份子。在容器技术的基础上，容器编排技术（主流方案：K8S）为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等功能，用户不需要再过度的关注资源的管理问题，降低操作的复杂度，提高了大规模容器集群管理的便捷性。
• 微服务（Microservices） ：微服务架构中，服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能，服务的API封装了其内部实现，与单体架构不同，开发人员无法绕过服务的API直接访问服务内部的方法和数据，因此，微服务架构强制实现了应用程序的模块化。微服务架构的最核心特性是服务之间的松耦合性。
• 服务网格 ：服务网格是用于处理服务间通信的专用基础设施层，负责在微服务间进行可靠地请求传递。服务网格通常通过一组轻量级网络代理来实现，这些代理与应用程序代码一起部署，而不需要感知应用程序本身。
• 不可变基础设施：一个工作负载（比如容器、虚拟机等）一旦部署以后就不会被修改。当需要更新，修复或修改某些内容的时候，只需要将新的、经过验证的工作负载替换旧的即可。
• 声明式API：声明式API是一种比命令式API更高级的接口设计方式，简单来说，命令式API提供给用户怎么做的能力，而声明式API给用户提供了做什么的能力。
• DevOps：DevOps就是基于敏捷开发将软件开发/测试人员/IT运维关联在一起，通过工具、组织等方式使开发、测试、发布流程自动化，软件发布频繁，高效。DevOps的核心是CICD。
  • 持续集成（CONTINUOUS INTEGRATION，CI）其核心是新提交的代码与原代码正确的集成。开发人员多次、频繁的将代码提交到代码仓库中，在合并到指定分支之前，对新提交上来的内容进行编译、自动化检测(如：代码格式检测)的验证，这样的过程既保证了代码的完整性、安全性，为后面的工作提供了质量保证。
  • 持续交付（CONTINUOUS DELIVERY，CD），其重点不在代码本身，而是可以交付的产品上。在发布到生产环境之前，对新增的代码进行测试(test) -> 模拟(staging) -> 生产(produciton)，即简化繁琐的发布流程，又保障新添加的代码在生产环境是可用的。
  • 持续部署（CONTINUOUS DEPLOYMENT）通过自动化部署的方式频繁的交付产品，关注的重点在于自动化部署。从开发人员提交代码到编译、测试、部署整个流程都是通过自动化执行，这种方式加快了交付的速度，同时在发现问题时也缩短修复的时间。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生应用的特征

与其他应用相比，总结起来，云原生应用有如下 15 个特征。

单一代码库

云原生应用必须有单一的代码库，并在版本管理系统中进行追踪。
对于微服务架构的应用来说，每个应用由多个服务组成，这些服务应该由单一的代码库进行管理，这保证了构建版本的稳定性。

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

API 优先

**云原生应用应该采用 API 优先的设计策略。**微服务架构的应用使用公开 API 来作为服务的对外接口，API 屏蔽了服务的内部实现细节。API 优先的设计策略指的是在设计阶段，应该首先设计 API 并确定 API 的细节。API 的设计过程需要多个团队的参与，包括 API 的实现者和可能的使用者，这些团队在充分讨论中最终完成 API 的定义。API 可以使用 OpenAPI 规范描述，从该规范中可以生成 API 文档和进行测试的模拟服务器。

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

依赖管理

云原生应用应该管理自己的依赖，Java 开发人员对依赖管理应该并不陌生，常用的 Java 构建工具 Maven 和 Gradle 都提供了依赖管理的支持。在开发过程中，只需要利用构建工具的支持即可；在管理依赖时，则需要区分应用自带的依赖和运行环境提供的依赖。云原生应用通常会包含全部所需的依赖，尤其是以容器形式运行的应用，典型的例子是微服务的 REST API。云原生应用会自带嵌入式的 Tomcat 这样的服务器来提供 HTTP 服务。

设计、构建、发布和运行

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

代码、配置和凭据

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

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

代码和配置的区别在于，代码不会随着部署环境而变化，而配置则相反。在实践中，应该尽可能把配置从应用中分离出来，进行外部化管理，构建出来的二进制工件中不包含任何配置信息，实际的配置值在部署时根据环境来确定。在运行时，一般使用环境变量来传递配置值，还可以使用类似 Spring Cloud Config 这样的专门配置服务器来管理配置值。凭据都应该从源代码仓库中删除。

日志

日志是应用开发中不可或缺的部分。与传统应用不同的是，云原生应用并不需要对日志的输出方式进行很多配置，只是简单地把日志写到标准输出流（stdout）和标准错误流（stderr）。
日志的收集和处理由云平台上的其他服务来提供，这把应用开发人员从日志管理相关的任务中解放出来。
云平台上的日志管理服务非常多，开源的典型实现包括 ELK 技术栈（ElasticSearch + LogStash + Kibana）和 Fluentd。

随时可丢弃

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

支撑服务

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

环境等同

**云原生应用的不同部署环境应该是等同的。**开发、测试和生产环境之间不应该有差异，环境的等同性保证了云原生应用可以快速的进行部署，这一特征与构建工件的不变性是相辅相成的，两者缺一不可。有了这两个特征之后，每一个唯一版本的构建工件可以被依次部署到不同的环境，在测试环境上经过测试的版本，可以直接部署到生产环境。我们可以确定应用在生产环境上的行为与测试环境中一样。

管理任务

云原生应用运行中可能会需要执行一些管理任务，比如生成报表或者执行一次性的数据查询等，这些任务通常并不属于业务流程的一部分，更多的是为了管理和运维的需要。这些任务在执行中会用到云原生应用所依赖的支撑服务，对于这些任务，应该创建独立的应用，并在同样的云平台上运行。对于定期执行的任务，可以充分利用云平台的支持，比如，Kubernetes 提供了对定时任务（CronJob）的支持。

端口绑定

云原生应用在运行时并不负责管理实际的端口绑定，而是由云平台统一管理。比如，一个基于 Spring Boot 的微服务应用通常在 8080 端口运行 HTTP 服务，当应用运行在云平台上时，这个端口只是虚拟机或容器内的端口，并不是外部用户或其他服务访问时的实际端口。云平台对网络进行统一管理，负责分配实际的端口，云平台同时提供了相应的机制来发现访问服务的实际地址和端口。

无状态进程

**云原生应用应该是无状态的。**所有的状态信息都应该从应用中抽离出来，并保存在支撑服务中，比如数据库中。正因为应用是无状态的，才可以由云平台快速的启动和停止，并进行垂直或水平扩展。

并发性

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

遥测数据

云原生应用需要收集一系列遥测数据，包括应用性能指标、运行状态和日志等，这些遥测数据，对于云平台和应用来说同等重要。
云平台可以用性能指标来进行自动水平扩展，比如，Kubernetes 支持 Pod 的自动水平扩展，当 CPU 的利用率超过预定的阈值时，会自动启动新的 Pod 来处理请求。

认证和授权

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

总结

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

参考：
https://lib.jimmysong.io/cloud-native-handbook/intro/what-is-cloud-native/
拉勾：《云原生微服务架构实战精讲-成富》

本文内容到此结束了，
如有收获欢迎点赞

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/IT小白/article/detail/484486