云原生架构
目录
1 云原生的概念
云原生（Cloud Native）是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。（从OnCloud到InCloud）
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在讲云应用中的非业务代码部分进行最大化地剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、码部分进行最大化地剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
基于云原生架构的应用特点：
- 代码结构发生巨大变化：不再需要掌握文件及其分布式处理技术，不再需要掌握各种复杂的网络技术，简化让业务开发变得更敏捷、更快捷。
- 非功能特性大量委托给云原生架构来解决：比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
- 高度自动化的软件交付：基于云原生的自动化软件交付可以把应用自动化部署到成千上万的节点上。
2 云原生的原则
云原生具有以下原则：
- 服务化原则：通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代。
- 弹性原则：弹性是指系统的部署规模可以随着业务量的变化而自动伸缩。
- 可观测原则：通过日志、链路跟踪和度量等手段，使得多次服务调用的耗时、返回值和参数都清晰可见。
- 韧性原则：软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
- 所有过程自动化原则：让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
- 零信任原则：不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础。
- 架构持续演进原则：架构具备持续演进的能力。
3 云原生架构相关技术
3.1 容器技术
容器（Container）作为标准化软件基础单元，将应用及其所依赖项打包发布，由于依赖项齐备，应用不再受环境限制，可在不同计算环境间快读、可靠地运行。
容器部署模式与传统、虚拟化模式的比较如图所示：
3.2 容器编排技术
容器编排技术的作用包括资源调度、应用部署与管理、自动修复、服务发现与负载均衡、弹性伸缩、声明式API、可扩展性架构、提升可移植性。
3.3 微服务
详见SOA
3.4 无服务技术
无服务技术的特点：
- 全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；
- 通用性，结合云 BaaSAPI的能力，能够支撑云上所有重要类型的应用；
- 自动弹性伸缩，让用户无需为资源使用提前进行容量规划；
- 按量计费，让企业使用成本得有效降低，无需为闲置资源付费。
3.5 服务网络
服务网格 (Service Mesh) 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦 。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。换句话说，因为大量非功能性从业务进程剥离到另外进程中，服务网格以无侵入的方式实现了应用轻量化。
如图所示为服务网格的典型架构：
在该架构图中，服务A调用服务B的所有请求，都被其下的服务代理截获，代理服务A完成到服务B的服务发现、熔断、限流等策略，而这些策略的总控是在控制平面 (Control Plane) 上配置。
4 主要架构模式
4.1 服务化架构模式
服务化架构要求以应用模块为颗粒度划分一个应用软件，以接口契约（例如IDL）定义彼此业务关系，以标准协议（HTTP、gRPC等）确保彼此的互联互通，结合领域模型驱动（Domain Driven Design，DDD）、测试驱动开发（Test Driven Design，TDD）、容器化部署提升每个接口的代码质量和迭代速度。
4.2 Mesh化架构模式
Mesh化架构把中间件框架（如RPC、缓存、异步消息等）从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。
4.3 Serverless模式
业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发。开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等（即Serverless），将应用的整个运行都委托给云。Serverless模式适合事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。
4.4 存储计算分离模式
分布式环境中的CAP困难主要针对有状态应用：一致性（Consistency，C）、可用性（Available，A）、分区容错性（Partition Tolerance，P）三者无法同时满足，最多满足其中两个。
无状态应用不存在一致性这个维度，可以获得很好的可用性和分区容错性，因而获得更好的弹性。
4.5 分布式事务模式
由于业务需要访问多个微服务，所以会带来分布式事务问题，否则数据就会出现不一致。因此架构师需要根据不同的场景选择合适的分布式事务模式，常用的有：
- XA模式：由于XA规范是实现分布式事务处理的标准，通常采用两阶段提交（2 Prepare Commit，2PC）的方法，具有很强的一致性，但是由于需要两次网络交互，所以性能差。
- 基于消息的最终一致性（BASE）：在可用性和一致性相冲突的情况下，为了权衡二者，BASE提出只要满足基本可用（BA）和最终一致性（E），接受数据的软状态或未确定状态（S），来优先实现性能，所以这类系统通常具备很高的性能。但是由于应用的特点，选择可用性和一致性的妥协方案，导致通用性很差。
- TCC模式（Try-Confirm-Cancel二阶段模式）：该模式下事务隔离行可控、高效，但需要应用代码将业务模型拆成二阶段，所以对业务侵入性强，设计开发维护等成本很高。
- SAGA模式：每个正向事务都对应一个补偿事务，若正向事务执行失败，则会执行补偿事务进行回滚。所以开发维护成本高。
- 开源项目SEATA的AT模式：它将TCC模式中的二阶段委托给底层代码框架，并且取消了行锁，所以非常高性能且无代码开发工作量，且可以自动化执行回滚操作，但存在一些使用场景限制。
4.6 可观测架构
可观测架构包括Logging、Tracing、Metrics：
- Logging：提供多个级别跟踪，例如INFO/DEBUG/WARNING/ERROR
- Tracing：收集一个请求从前端到后端的访问日志聚合，形成完整调用链路跟踪
- Metrics：提供对系统量化的多维度度量，包括并发度、耗时、可用时长、容量等。
4.7 事件驱动架构
事件驱动架构（Event Driven Architecture，EDA）是一种应用/组件间的集成架构模式。适用于增强服务韧性、数据变化通知、构建开放式接口、事件流处理、命令查询的责任分离（Command Query Responsibility Segregation，CQRS）把服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的API接口等。
5 典型的云原生架构的反模式
架构设计有时候需要根据不同的业务场景选择不同的方式，常见的云原生反模式有：
- 庞大的单体应用：缺乏依赖隔离，代码耦合，责任和模块边界不清晰，模块间接口缺乏治理，变更影响扩散，不同模块间的开发进度和发布时间难以协调，一个子模块不稳定导致整个应用都变慢，扩容时只能整体扩容而不能达到瓶颈的模块单独扩容等。
- 单体应用“硬拆”为微服务：强行把耦合度高、代码质量少的模块进行服务化拆分；拆分后服务的数据是紧密耦合的；差分后成为分布式调用，严重影响性能。
- 缺乏自动化能力的微服务：人均负责模块数上升，人均工作量增大，也增加了软件开发成本。