什么是云原生

1 缘起

有一次在写K8S相关技术文档的过程中，有一部分是要介绍相关的技术，
于是，开始调研、收集材料，
其实，对于应用者而言，K8S能用、会用即可，可以不用关心K8S是在怎样的背景下产生的，
出于文档需要，就查了一下关于K8S的文章，
有一个必点的话题：云原生，
云原生是理念，而K8S是在这个理念下催生的工具。
本文做一个简单的搬运，帮助读者轻松应对知识交流。
原文如下：
https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/definition

2 云原生

云原生架构和技术是一种方案。这种方案充分利用云计算模型，在云端–设计、构建和运行工作负载。
云原生计算基金会的官方定义：
云原生技术允许相关机构在现代、动态环境中构建并运行可扩展的应用程序，如在公有云、私有云及混合云中。
容器、服务网格、微服务、不可变基础设施和声明式API就是云原生的案例。
这些技术使松耦合系统具有弹性、可管理性和可观察性。与强大的自动化相结合，允许工程师以最少的工作量频繁和可预测地进行变更。
云原生是关于速度和灵活性的。业务系统正在从支持业务能力发展转变为加速业务速度和增长的战略转型武器。必须立即将新想法推向市场。

与此同时，业务系统也变得越来越复杂，用户的要求也越来越高。他们希望业务系统可以快速响应、功能创新以及零停机。性能问题、重复出现的错误和无法快速移动已经无法容忍，他们可能因为这些问题而访问你的竞争对手。云原生旨在拥抱快速变化、大规模和弹性。

2.1 云原生的支柱

云原生的快速发展及云原生的灵活性有多种因素，其中，最重要的是云基础设施。
云原生的核心支柱如下图所示。
由图可知，云原生的核心支柱有：现代设计、微服务、容器化、后台服务、自动化。

3 云

云原生系统充分利用了云服务模型。
这些系统广泛使用PaaS（平台即服务）计算基础设施托管服务，在动态、虚拟化的云环境中蓬勃发展。
云原生服务将底层基础设施视为一次性基础设施，通过自动化在几分钟内按需配置资源（扩缩容、销毁）。
这里以大众熟知的宠物和牛的DevOps概念举例。
传统的数据中心，将服务器（物理机）比喻成宠物，赋予一个有特殊意义的名字，并且细心照看。
为了让服务器具有更多的功能，向服务器中添加需要的资源（各种软件）。当服务器出问题（生病）时，需要维修员（护士/医生）修复。
如果服务器不可用，所有应用程序都会感知到。
养牛服务模式则不同。为每个实例提供一个虚拟机或容器，供其运行，并未每个虚拟机或容器分配系统标识，如Service-01、Service-02等，以创建容器或虚拟机的方式扩展功能，即使某个容器或虚拟机不可用，其他的虚拟机或容器是无感知的。
牛模式包含不可变的基础设置。服务器是不可修复或变更的。如果一个虚拟机或容器出现故障或需要更新，直接销毁重新建即可，并且这些操作均是自动化方式完成的。
云原生采用了养牛模式。该模式不关心服务器的扩容或缩容，只关心自身实例在容器或虚拟机中的运行（资源满足运行条件）。

4 现代设计

如何设计云原生应用程序？
架构是怎样的？
遵循哪些设计原则、模式以及最佳实践？
需要关注哪些基础设施？

4.1 应用的12要素

构建云应用的共识是12要素。这12要素描述了开发人员在构建现代云环境应用应遵循的原则以及实践经验。
特别是跨环境的可移植性和声明式自动化。
虽然12要素适用于任何网络应用，但是，众多从业者将12要锁视为构建云原生应用的基石。
基于这些原则构建的应用可以快速部署、扩展及添加新功能以快速响应市场变化。

序号	要素	描述
1	代码库	每个微服务都有一个单独的代码库，存储在自己的库中，通过版本控制进行跟踪，可以部署到多个环境（如QA/暂存/生产）
2	依赖	微服务间是隔离的并且打包自己的依赖，变更时不影响整个系统（某种程度上而言）
3	配置	配置信息从微服务中移除，通过代码外的配置管理工具进行管理，相同的部署可以共享配置文件
4	支持服务	辅助资源（数据存储/缓存/消息队列）应通过URL寻址，可以将资源与应用解耦，并灵活变更（替换/修改）
5	构建、发布、运行	每个版本都必须在构建、发布和运行阶段进行强制隔离，每个阶段都必须有唯一的ID，支持回滚，现代CI/CD系统遵循该原则设计
6	进程	每个微服务都应在自己的进程中执行，与其他微服务隔离，将需要的依赖服务外部化到支持服务中，如分布式缓存或数据存储
7	端口绑定	每个微服务都应该是独立的，接口和功能暴露在自己的端口上，这样可以和其他微服务隔离
8	并发	当需要扩容时，可以在多个相同进程（拷贝）上横向扩展服务，而不是在功能强大的单机上，将应用程序开发为并发应用有助于在云环境中无缝扩展
9	一次性	服务实例应该时一次性的，有助于快速启动增加可扩展性，以更优雅的方式保证系统处于正常状态，Docker容器遵循这种原则
10	开发/生产校验	尽量保持应用程序在整个声明周期中相同的运行环境，避免成本高昂的捷径，容器的引入可以极大程度地满足该要求
11	日志	将微服务生成的日志作为事件流。使用事件聚合器处理，将日志数据传输到数据挖掘/日志管理工具，如Azure Monitor，ELKF系统，最终完成日志落盘
12	管理流程	将管理任务作为一次性流程，如数据清洗/计算分析，使用独立的工具从生产环境中调用这些服务，但是要与应用程序分开

除了上面的12要素，作者Kevin Hoffman还讨论了反映当今现代云应用程序设计的三个额外因素：

序号	要素	描述
13	API优先	让一切都成为服务。假定代码会被前端、网关或其他服务使用
14	远程监控（遥测技术）	在工作站上，可以深入了解应用程序及其行为，而在云端，则无法充分了解。因此，要做好信息采集，如监控、域名和健康/系统数据
15	身份验证/授权	设计之初就实现身份认证，在公有云中采用RBAC（Role-Based Access Control，基于角色的访问控制）

5 微服务

云原生系统包含微服务，这是一种用于构建现代应用程序的架构风格。
微服务以分布式的方式构建小型且相互独立的一系列服务，服务间通过共享结构进行交互，
微服务具有如下特点：

• 每个服务在更大的域上下文内实现特定的业务功能；
• 每个服务都是自主开发且可以独立部署的；
• 每个服务都是自包含的，封装自己的数据存储技术、依赖和编程平台；
• 每个服务都运行在自己的进程中，并使用Http/Https、gRPC、WebSocket或AMQP等协议与其他进程进行通信；
• 这些服务组合在一起形成一个应用程序。

下图比较单体服务和微服务。
由图可知，单体服务的分层体系，该体系中逻辑在单个过程中进行，通常使用关系型数据库。
而，微服务将功能进行拆分，每个服务都有自己的逻辑、状态和数据，以及各自的数据存储。

5.1 为什么选择微服务？

微服务具有足够的灵活性。
通过上面的对比，可知，微服务两个优点：

• 每个微服务都有独立的生命周期。即独立开发部署，无需等待发布窗口来更新功能，并且，可以更新部分功能，而不影响整个系统，在不用重新部署全部应用的情况下更新服务。
• 每个微服务的扩缩容都是独立的。即可以单独对某个服务进行扩缩容，以达到性能要求，细粒度的扩缩容有助于对系统的控制，包括成本的控制。

5.2 开发微服务

可得。
（1）基建可得：可以在现有的操作系统上进行微服务开发，Windows、MacOS、Linux（CentOS、Ubuntu）；
（2）软件可得：“巨人”们已经研制了多种服务框架供开发者使用如Spring系列（Java）、.Net系列（C#）。

5.3 微服务的挑战

分布式云原生微服务具有非常大的灵活性，但是，仍面临一些挑战：

• 通信
  前端与后端微服务如何通信？
  是直接与后端通信还是通过网关进行通信，以保证服务的灵活性、可控性和安全性？
  后端服务之间如何通信？
  是直接进行HTTP调用（增加耦合并影响性能和灵活性）还是使用队列或Topic（解耦）传递消息？
• 弹性
  微服务架构将系统的通信从进程内转换到进程外，分布式体系中，当服务B没有响应服务A的请求时会发生什么？
  当服务C不可用时，调用服务C的服务被阻塞时发生什么？
• 分布式数据
  设计时，每个服务都有自己的数据，通过公共接口对外提供，如何实现分布式事务？
• 安全
  如何安全地存储和管理密钥以及敏感的配置数据？

6 容器

云原生的讨论中，容器被频繁提及。在《云原生模式》一书中，作者Cornelia Davis指出，容器是云原生软件的伟大推动者。
云原生基金会将微服务容器化作为云原生路线的第一步，这也是企业实施云原生的路标。
容器化微服务非常简单、直接。将代码、相关依赖和运行时打包到二进制文件中（称为镜像）。
镜像存储在容器注册表中，注册表作为镜像仓库。注册表可以在开发机器中、数据中心或共有云中。
Docker自身通过Docker Hub维护公共注册表。
服务（应用）启动或扩缩容时，可以将容器镜像转换为运行的容器实例，实例可以运行在任何安装了容器运行时引擎的机器中。
可以根据需要调整实例数量。

不同的服务有不同的镜像，运行时的实例在各自的容器中，示意图如下图所示，
由图可知，
三个不同的服务在各自容器中运行，三个容器在同一台物理主机中。
每个容器都会维护自己的依赖和运行时，不同版本的服务在同一台物理机上运行，如Product服务的1.0版和2.0版。
每个容器共享底层物理主机的资源：操作系统、内存和处理器，但是，服务彼此是隔离的。

6.1 为什么选择容器？

容器可移植并且保证了跨环境的一致性。
通过将所有内容封装到一个包中，可以将微服务及其依赖关系与底层基础设施相隔离。
可以在任何部署了Docker运行时引擎的机器中部署容器，容器化的工作负载同时消除了使用框架、软件库和运行时引擎预先配置每个环境的费用。
通过共享底层的操作系统和主机资源，容器占用的资源远比虚拟机少，这样可以增加主机可同时运行的微服务密度或容量。

6.2 容器编排

使用Docker等工具创建镜像和运行容器时，还需要一些工具管理镜像和容器。
容器管理是通过容器编排器的特殊软件来完成的，当使用许多独立运行的容器进行大规模操作时，编排是非常重要的。
容器编排器自动执行任务如下图所示。

任务描述如下：

• 定时
  自动配置容器实例
• 亲和性/反亲和性
  容器间相互提供服务，提高可用性和性能
• 监控监测
  自动检测和纠正故障
• 扩缩容
  自动添加或移除实例以满足需要
• 故障转移
  自动将失败的实例重新迁移到正常运行的机器中
• 网络
  为容器通信管理网络包
• 服务发现
  帮助容器相互定位，发现
• 滚动更新
  协调增量升级和零停机部署，自动回滚有问题的变更

虽然已经有多个容器编排工具，但是，K8S已然成为云原生世界的事实标准。
K8S是可移植、可扩展且开源的平台，用于管理容器化的工作负载。

7 后台服务

云原生系统依赖许多不同的辅助资源，如数据存储、消息代理、监控和身份认证服务。
这些服务统称为后台服务。
常见的后台服务如下图所示。

作为开发者，可以自行管理后台服务，但是，需要管理、配置这些资源。
而云服务商则提供了丰富的后台服务，与其自定构建、管理这些后台服务，不如简单地使用它（如果经费允许、人员不足）。
云供应商提供这些资源并负责服务性能、安全和维护。服务中具备监控、冗余资源和高可用，服务供应商保证服务性能，并完全支持服务管理，会及时解决相关问题。

云原生系统支持管理云供应商的后台服务。
节省时间和人力是非常重要的，如果自行运维可能会很费时、费力。
当然了，不同的开发者/公司需要根据当前及未来规划选择合适的方案，这里只是简单介绍云与服务商的易用性。

最佳实践是将后台服务作为附加资源，通过配置文件与微服务动态地绑定到一起（如URL）。
这种方式，可以在不修改代码的情况下将后台服务和微服务隔离，
当需要将微服务从QA环境提升到临时环境，只需更新微服务配置文件，通过环境变量将设置注入到容器中。

云服务商为专用的服务提供了API，这些API有专用的封装，如果直接与这些API通信则会使代码与后台服务耦合。
常用的设计方式是隔离供应商的API实现细节，引入中间层（中间件），将通用操作暴露给微服务，将供应商的代码封装起来。
这样松耦合设计，在更换后台服务时，无需更改微服务代码，直接在中间件中修改。

8 自动化

云原生采用微服务、容器和现代系统设计达到服务开发的灵活性和高效性。
但是，这只是一部分，如何将这些微服务在云端环境运行、快速部署应用（更新）？
接下来就是基础设施即代码的（Infrastructure as Code, IaC）时代。
使用IaC，可以自动化平台配置和应用部署，基本上将软件工程实践（如测试和版本控制）应用到DevOps实践中。
基础设施和部署是自动化、一致和可复用的。

8.1 自动化基础设施

资源管理器可以在脚本中动态配置资源名称、位置、容量和密钥。
脚本通过版本控制，并作为项目的一部分检入到源码中。
可以通过调用脚本为跨系统环境（如QA、暂存和生产环境）提供一致且可复用的基础设施。
这也是IaC核心理念的应用。
IaC是幂等的，意味着可以多次使用配置脚本而不会产生任何影响。
如果团队需要进行更改，重新运行后，只影响更新的资源。
在《基础设施即代码是什么》一文中，作者Sam Guckenheimer描述道：
实施IaC的团队可以快速、大规模地提供稳定的环境，并避免手动配置环境，
而是通过代码表示环境需要的状态来增强一致性。
使用IaC的基础设施是可复用的，可防止配置漂移或依赖缺失导致的运行时问题。
DevOps团队可以使用统一的实践和工具，快速、可靠、大规模地发布应用。

8.2 自动化部署

现代设计的要素5描述道：每个版本都必须在构建、发布和运行阶段强制执行严格的隔离。
每个版本都应该有唯一的ID进行标记，并支持回滚。
现代CI/CD系统有助于实现这一原则。它们提供了单独的构建和交付步骤，有助于确保用户可以随时获得一致且高质量的代码。
相互隔离的发布流程如下图所示。

• 1 代码开发、调试
• 2 提交代码到代码仓库（如GitHub、GitLab、BitBucket）
• 3 持续集成（Continuous Integration, CI），提交代码触发阶段：构建、测试、打包
• 4 持续发布（Continuous Delivery, CD），提交代码触发应用发布
• 5 程序运行，将服务运行在指定的服务器中

应用这些实践，相关组织已经从根本上改变了他们发布软件的方式。
许多公司已经按季度发布向按需发布转变，目标是在开发周期的早期发现问题，此时修复这些问题的成本较低。
集成之间持续的时间越长，解决问题的成本就越高。
有了集成过程的一致性，团队可以更频繁地提交代码变更，从而实现更好的写作，提高软件质量。

9 小结

（1）云原生是设计理念，为更好地应用计算机硬件资源，高效、灵活地开发、运维软件；
（2）云原生的基石是容器化，在容器化的基础上，进一步实现云原生的设计理念；
（3）设计理念：充分利用云服务器，结合现代设计、微服务、容器化、后台服务、自动化进行软件设计、开发、运维。