讲云原生应用个特征海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

本我将带你学习云原生应用。

微服务架构只是一种软件架构风格，并不限制所采用的实现技术，开发团队可以最合适的技术

来实现。在第01介绍微服务架构的时候，提到了微服务架构实现最大的是它的复杂度，这些

复杂度是微服务架构本身天然所具备的，是每个微服务架构应用绕不开的难题。在实现微服务架构时，

开发团队当然希望把全部的精力放在实现业务逻辑上，而不是应对微服务架构自身的复杂度，这就意味

着，需要选择能够帮助应对这些复杂性的平台和工具。云原生（Cloutive）应用就是微服务架构的

最佳实现方式。

顾名思义，云原生应用的概念由云和原生两个部分组成，云在这里指的是云平台，也就是平台即服务

（PlatformasaService，PaaS）；原生应用指的是专门针对云平台而设计的，充分利用了云平

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

原生这个词在软件开发中有它独特的含义。原生通常意味着高效和难以移植。原生意味着针对特定的平

台而设计，可以充分利用平台的特性，因此运行起来非常高效；同样意味着与特定平台的深度绑定，很

难移植到其他平台。云原生应用同样具有这两个特征，对于云原生应用来说，难移植并不是一个问题，

毕竟迁移到云平台，不会再想迁移回去。

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

单一代码库

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

可以是共享同一根的多个代码仓库，其重要性在于每一个代码提交（Commit）都会对应一个不可

变的构建版本。在每次代码提交，持续集成流程会被触发，最终产生一系列的应用容器镜像，这就

在代码提交和构建版本之间建立了一对``一的对应关系，这种一对一的关系保证了每个构建版本都是

可追踪的，可以比较不同版本之间的代码变化。

对于微服务架构的应用来说，每个应用由多个服务组成，这些服务应该由单一的代码库进行管理，这保

证了构建版本的稳定性。如果一个改动涉及到多个服务，则这个改动应该在一次代码提交中完成对所有

相关服务的修改；如果服务的代码分散在多个代码库中，则一个改动会被分成多个代码提交，每个代码

提交都会触发一次持续集成流程，产生对应服务的构建版本，这些服务的构建版本只包含了部分改动，

是的。在应用部署时，有的服务可能包含了部分改动，而有的服务则没有，这使得部署的应用实

际上是不能工作的。因此，微服务架构的应用应该使用单一代码库。

API优先

云原生应用应该采用API优先的设计策略。微服务架构的应用使用公开API来作为服务的对外接口，

API了服务的实现细节。API优先的设计策略指的是在设计阶段，应该首先设计API并确定

API的细节。API的设计过程需要多个团队的参与，包括API的实现者和可能的使用者，这些团队在充

分讨论中最终完成API的定义。API可以使用OpenAPI规范描述，从该规范中可以生成API文档和进

试的模拟服务器。

API优先的策略保证了API的稳定性，同时可以减少不必要的后期修改。因为API是服务之间的接口，

修改API就意味着相关的实现、测试用例和API的使用者都需要进行修改，如果在应用开发中出现

了必须修改API的情况，那造成的影响是很大的。API优先确保了尽可能减少在开发中对API进行修

改。

API优先的另外一个好处是可以提高开发效率。API确定，可以利用工具生成文档和模拟服务器，