云原生架构

这是一篇关于云原生架构的思维导图，主要内容包括主要架构模式：服务化架构模式、Mesh 化架构模式、Serverless 模式、存储计算分离模式、分布式事务模式、可观测架构、事件驱动架构。相关技术：容器、VPC、微服务、服务网格等概念。

云原生架构

• 概念
  • 来自“Cloud Native”的直译
    • Cloud
      • 指应用软件是在云端而非传统的数据中心
      • 关注 IaaS
    • Native
      • 表示应用一开始就基于云环境、专为云端特性而设计，可充分利用和发挥云平台的弹性+分布式优势，最大化释放云计算生产力
      • 关注 PaaS
  • 解决的问题
    • 传统 IT 建设的“烟筒”模式，导致每个应用相对独立，管理与分配资源难
  • 云原生适合的开发模式
    • DevOps
      • 是 Development、Operations 的缩写
      • 是开发、技术运营和质量保障三者的交集，促进之间的沟通、协作与整合，从而提高开发周期和效率
    • 融合开源生态，通过技术的易用性和开放性实现快速增长的正循环
• 定义
  • 技术角度
    • 是基于云原生技术的一组架构原则和设计模式的集合
    • 将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点
  • 代码组成
    • 业务代码
      • 实现业务逻辑的代码
    • 三方软件
      • 业务代码依赖的第三方库
    • 处理非功能特性的代码
      • 实现高可用、安全、可观测等非功能性能力的代码
      • 从业务代码中剥离的大量非功能性特性到 IaaS 和 PaaS 中
• 架构原则
  • 服务化原则
    • 服务化拆分，拆为微服务架构、小服务（MiniService）架构
    • 把不同生命周期的模块分离出来，分别进行业务迭代
    • 面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度
    • 从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理
      • 分布式环境下的限流降级、、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量（而非网络流量）的控制策略
  • 弹性原则
    • 系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源
  • 可观测原则
    • 在云这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，使得一次点击背后的多次访问调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等
  • 韧性原则
    • 当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力
    • 核心目标
      • 提升软件的平均无故障时间（Mean Time Between Failure，MTBF）
    • 架构内容
      • 服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、可用区（Availability Zone, AZ）内的高可用、单元化、跨 region 容灾、异地多活容灾等
  • 所有过程自动化原则
    • 通过 IaC(Infrastructure as Code)、GitOps、OAM(Open Application Model)、Kubernetes Operator 和大量自动化交付工具在 CI/CD 流水线中的实践
      • IaC，即基础设施即代码（Infrastructure as Code），是一种通过代码来管理和配置IT基础设施的方法。这种方法允许开发者和系统管理员以编程方式自动化地部署、监控和管理数据中心的资源和服务，而无需手动设置和调整网络、存储、计算等物理或虚拟组件。
      • 标准化企业内部的软件交付
        • 标准化基础上的自动化
      • 通过配置数据自描述和面向终态的交付过程
        • 让自动化工具理解交付目标和环境差异
      • 实现整个软件交付和运维的自动化
  • 零信任原则
    • 核心思想
      • 默认情况下不应信任网络内部和外部的任何人 / 设备 / 系统，需要基于认证和授权重构访问控制的信任基础
    • 身份（Identity）
      • 赋予不同的实体不同的身份，解决是谁在什么环境下访问某个具体的资源的问题
  • 架构持续演进原则
• 主要架构模式
  • 服务化架构模式
    • 含义
      • 要求以应用模块为颗粒度划分一个软件
      • 以接口契约（例如 IDL）定义彼此业务关系
      • 以标准协议（HTTP、gRPC 等）确保彼此的互联互通
      • 结合 DDD、TDD、容器化部署提升每个接口的代码质量和迭代速度
    • 用途
      • 把代码模块关系和部署关系进行分离
      • 每个接口可以部署不同数量的实例，单独扩缩容
  • Mesh 化架构模式
    • 含义
      • 把中间件框架（如 RPC、缓存、异步消息等）从业务进程中分离
        • 让中间件 SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响
      • 分离后，业务进程中只保留很“薄”的 Client 部分，Client 通常很少变化，只负责与 Mesh 进程通信
  • Serverless 模式
    • 含义
      • 将“部署”动作从运维中“收走”
      • 当业务流量到来 / 业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭 / 调度业务进程，等待下次触发
    • 用途
      • 适用于事件驱动的数据计算服务、计算时间短的请求 / 响应应用、没有复杂相互调用的长周期任务
  • 存储计算分离模式
    • 含义
      • 对于无状态应用，不存在 C（一致性）维度，可以获得很好的 A（可用性）和 P（分区容错性），因而获得更好的弹性
    • 用途
      • 推荐把各类暂态数据（如 session）、结构化和非结构化持久数据都采用云服务存储
      • 对于保存到远端缓存会导致交易性能下降的数据，考虑通过采用时间日志 + 快照（或检查点）的方式
  • 分布式事务模式
    • 含义
      • 微服务模式提倡每个服务使用私有的数据源，但大颗粒的业务往往需要访问多个微服务，必然带来分布式事务问题
    • 模式
      • 传统 XA 模式
        • XA是由X/Open组织提出的一个分布式事务处理标准，用于确保多个资源（如数据库、消息队列等）之间的操作要么全部成功提交，要么全部回滚。它通常涉及到一个事务管理器（Transaction Manager）来协调参与事务的各个资源管理器（Resource Managers）。XA事务遵循ACID特性，保证强一致性。
        • 一致性强，但性能差
      • 基于消息的最终一致性（BASE）
        • BASE理论是对CAP定理的一种实现思路，强调基本可用性、软状态以及最终一致性。与追求强一致性的XA不同，BASE提倡通过牺牲一定的一致性来换取更好的可用性和分区容忍度。
        • 性能高，但通用性有限
      • TCC 模式
        • TCC是一种补偿型事务模型，分为三个阶段：尝试（Try）、确认（Confirm）和取消（Cancel）。在Try阶段，预留必要的资源；如果所有服务都成功预留，则进入Confirm阶段完成实际操作；若有任何失败，则执行Cancel阶段撤销之前的操作。
        • 由应用层控制事务，事务隔离性可控，比较高效
        • 但对业务侵入性强，设计开发维护成本高
      • SAGA 模式
        • SAGA也是一种长事务解决方案，它将一个大的事务拆分成一系列小的本地事务链。每个本地事务都有相应的补偿操作，当某个步骤失败时，可以通过执行逆序的补偿操作来回滚之前的更改。
        • 与 TCC 类似，但无 try 阶段，每个正向事务都有对应的补偿事务
      • 开源项目 SEATA 的 AT 模式
        • AT模式是Seata框架提出的一种分布式事务解决方案，旨在为微服务架构下的分布式事务提供一种轻量级、高效的方式。AT模式自动拦截并管理跨服务调用的事务边界，并使用全局锁和快照机制来保证数据的一致性。
        • 高性能且无代码开发工作量，支持自动执行回滚
        • 存在使用场景限制
  • 可观测架构
    • 含义
      • Logging
        • 信息跟踪
      • Tracing
        • 调用链路跟踪
      • Metrics
        • 系统度量
    • 目标
      • 对服务 SLO （Service Level Objective，服务等级目标）进行度量，从而优化 SLA（Service Level Agreement，服务级别协议）
  • 事件驱动架构
    • 含义
      • （EDA、Event Driven Architecture）
        • 是一种应用 / 组件间的集成架构模式
      • 和传统消息不同，事件具有 schema，可校验 event 的有效性
        • Schema 示例： { "title": "OrderCreated", "type": "object", "properties": { "eventId": { "type": "string", "description": "唯一标识符" }, "eventType": { "type": "string", "description": "事件类型名称" }, "timestamp": { "type": "string", "format": "date-time", "description": "事件发生的时间戳" }, "data": { "type": "object", "properties": { "orderId": { "type": "string", "description": "订单ID" }, "customerId": { "type": "string", "description": "顾客ID" }, "productId": { "type": "array", "items": { "type": "object", "properties": { "id": { "type": "string", "description": "产品ID" }, "quantity": { "type": "integer", "description": "购买数量" } } } }, "totalAmount": { "type": "number", "description": "订单总金额" } } } } }
      • EDA 具备 QoS（Quality of Service，服务质量）保障机制，能对事件处理失败进行响应
    • 用途
      • （微）服务解耦
      • 增强服务韧性
        • 服务间异步集成，下游失败不会对上游带来影响
      • CQRS
        • （Command Query Responsibility Segregation，命令查询职责分离）
        • 命令模型（Command Model）
          • 对服务状态有影响的命令用事件来发起
        • 查询模型（Query Model）
          • 对服务状态没影响的查询则调用 API 接口
        • 结合 Event Sourcing（事件溯源）机制
          • 维护数据变更的一致性
            • 在事件溯源中，应用的状态变化不是直接存储为实体对象的状态，而是作为一系列不可变的事件被记录下来。每个事件代表了一个状态的变化，所有这些事件按照发生顺序保存起来。 当需要重建系统状态时，可以通过重放这些事件来实现。
• 相关技术
  • 容器技术
    • 容器
      • 作用
        • 标准化软件单元，将应用及依赖项打包，使应用不受环境限制，在不同计算环境间快速、可靠地运行
          • 容器在一个操作系统中，通过进程隔离、内存隔离、文件隔离、用户隔离、网络隔离等技术，形成一个个互相隔离的运行空间，每个空间里运行着应用程序和其所依赖的程序及库，这就是容器。 这样，多个容器共享同一个操作系统，但又互相隔离。容器通常不大，可以秒级启动，非常迅捷。容器实现了完全的可移植性，在支持容器的任何操作系统或环境上都可以兼容运行。因为容器里的软件和所需要的库依赖是封装好的，和所在宿主机的库是互相隔离的，不需要像以前那样，要在宿主机上做各种安装和适配。 在Linux操作系统中，早有通过命名空间（namespace）和控制组（control group）实现应用程序隔离的方法，使得一个或多个进程的 CPU，内存，磁盘I / O和网络使用可以隔离开来互不影响，此即 Linux 容器（LXC）技术。但对用户而言，LXC 并不易用。 Docker 把这些较为复杂的容器功能封装起来，形成对用户友好的操作命令或图形界面，才使得容器流行起来。
      • 传统、虚拟化、容器部署比较图示
        • 虚拟机（Virtual Machine, VM）
          • 通过虚拟化技术在物理服务器上模拟出的一个“完整计算机”，它拥有自己的 CPU、内存、磁盘和网络资源，并可以安装操作系统和应用程序。
        • 裸金属服务器（Bare Metal Server）
          • 是没有虚拟化层的物理服务器，直接将物理资源交付给用户使用。虽然不提供虚拟化能力，但它依然可以通过云平台进行自动化管理、分配和回收。
      • 典型实现
        • Docker
          • 概念
            • 基于操作系统虚拟化技术，共享操作系统内核、轻量、没有资源消耗、秒级启动，极大提示了系统的应用部署密度和弹性
            • 创新的应用打包规范
              • Docker 镜像：解耦了应用与运行环境，使应用可以在不同计算环境一致、可靠地运行
    • 容器编排
      • 作用
        • 自动化管理、调度和联网一组容器的过程
        • 这些容器通常作为微服务架构的一部分运行
      • 典型实现
        • Kubernetes
          • 概念
            • 容器编排的事实标准
            • 屏蔽了 IaaS 层基础架构的差异并凭借优良的可移植性，帮助应用一致地运行在包括数据中心、云、边缘计算在内的不同环境
          • 功能
            • 资源调度
            • 应用部署与管理
            • 自动修复
            • 服务发现与负载均衡
            • 弹性伸缩
  • VPC
    • 概念
      • Virtual Private Cloud，虚拟私有云
      • 在云中构建出来的一个独立的、隔离的虚拟网络环境
      • 可以在 VPC 中自主规划 IP 地址，创建子网，并使用虚拟交换机 vSwitch、虚拟路由器vRouter、虚拟负载均衡 vLB 等网络组件，还能通过网络 ACL、安全组、虚拟防火墙 vFW 等方式，实现网络内虚机的隔离保护
  • 云原生微服务
    • Microservices
    • 设计约束
      • 微服务个体约束
        • 完成的功能在业务域划分上应是相互独立的
        • “微”
          • 按照问题域对单体应用做合理拆分
        • 单一职责，专注于特定业务并将之做好
      • 微服务之间的横向关系
        • 可发现性
          • 当服务 A 发布和扩缩容时，依赖服务 A 的服务 B 如何在不重新发布的前提下，能够自动感知服务 A 的变化？
            • 引入第三方服务注册中心
        • 可交互性
          • 服务 A 采样什么样的方式可以调用服务 B
            • 独立的元数据中心存储服务的元数据信息
        • 随者服务链路的不断增长，整个微服务系统也变得越来越脆弱，因此 面向失败设计 的原则在微服务体系中显得尤为重要
      • 微服务与数据层之间的纵向约束
        • 提倡数据存储隔离（Data Storage Segregation，DSS）原则，数据是微服务的私有资产，对于该数据的访问都必须通过当前微服务提供的 API 访问
        • 微服务设计尽量遵循无状态设计原则，即上层应用与底层基础设施解耦，微服务可以自由在不同容器间被调度
        • 对于有数据存取（即有状态）的微服务，通常使用计算与存储分离方式，将数据下沉到分布式存储
      • 微服务分布式约束
        • 准备全自动化的 CI/CD 流水线满足对开发效率的诉求，支持 蓝绿、金丝雀 等发布策略
          • 蓝绿部署是一种零停机的部署策略，通过同时运行两个几乎完全相同的生产环境——“蓝色”（当前生产环境）和“绿色”（新的待上线环境）。在部署过程中： 新版本的应用程序首先会被部署到绿色环境中。 经过测试验证后，流量会从蓝色环境切换到绿色环境。这种切换通常是瞬间完成的，例如通过更改负载均衡器的配置指向绿色环境。 如果新版本出现问题，可以迅速回滚，只需将流量重新指向蓝色环境即可。 金丝雀发布（也称为灰度发布）是一种渐进式的部署策略，指的是逐步将新版本的应用程序推向一小部分用户群进行测试，观察其表现后再决定是否全面推广。名字来源于煤矿工人曾用金丝雀检测矿井中的有毒气体的做法。 在实施金丝雀发布时： 初始阶段，只有少量用户（比如内部员工或者特定地区/群体）会被引导至新版本。 根据收集到的性能指标、错误率等反馈，评估新版本是否稳定可靠。 如果一切正常，则逐渐增加接受新版本用户的比例直至全部覆盖；反之，若发现问题，则停止进一步推广甚至撤回更新。
        • 全链路、实时和多维度的可观测能力
    • 主要微服务技术
      • Apache Dubbo
        • RPC框架（阿里）
      • Spring Cloud
      • Eclipse MicroProfile
      • Tars
        • （腾讯）
      • SOFAStack
        • Scalable Open Financial Architecture Stack
        • （蚂蚁金服）
      • DAPR
        • Distributed Application Runtime
        • （微软）
  • 无服务器技术
    • 概念
      • 一种云计算执行模型，它允许开发者构建和运行应用程序和服务，而无需管理服务器等基础设施。尽管名称为“无服务器”，实际上还是存在服务器，只不过这些服务器的管理和维护工作由云服务提供商负责，开发者只需专注于编写代码
    • 技术特点
      • Kubernetes 为代表的云原生技术成为云计算的容器界面，成为云计算的新一代操作系统
      • 面向特定领域的后端云服务（BaaS）则是这个操作系统上的服务 API
        • 存储、数据库、中间件、大数据、AI 等领域的大量产品与技术都开始提供全托管的云形态服务
      • Serverless 屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现
      • 特征
        • 全托管的计算服务
        • 通用性
        • 自动弹性伸缩
        • 按量计费
    • 典型产品形态
      • 函数计算（Function as a Service，FaaS）
        • 把应用逻辑拆分为多个函数，每个函数都通过事件驱动的方式触发执行
      • 容器化应用
        • 阿里云
          • 弹性容器实例（ECI）、上层的 Serverless 应用引擎（SAE）
        • Google
          • CloudRun、Knative
    • 技术关注点
      • 计算资源弹性调度
      • 负载均衡和流控
        • 对资源调度服务的负载进行分片，横向扩展到多台机器，避免单点瓶颈
        • 分片管理器
          • 分片迁移、分裂、合并
        • 多租户下，流量隔离控制 保证服务质量，避免应用相互干扰
      • 安全性
  • 服务网格
    • 概念
      • Service Mesh
      • 属于“Sidecar 模式”的应用
      • 将微服务间的连接、安全、流量控制和可观测等通用功能 下沉为平台基础设施，实现应用与平台基础设施的解耦
      • 非功能性业务从业务进程剥离到另外进程中，服务网格以无侵入的方式实现了应用轻量化
      • 图示
        • • 服务 A 调用服务 B 的所有请求，都被其下的服务代理截获，代理服务 A 完成到服务 B 的服务发现、熔断、限流等策略。这些策略在控制平面（Control Plane）配置
    • 主要实现
      • Istio 服务网格
        • 组件
          • Pilot
            • 服务发现、流量管理
          • Mixer
            • 访问控制、可观测性
          • Citadel
            • 终端用户认证、流量加密
        • 接口规范
          • 采纳了 Envoy 所实现的 xDS 协议，作为数据平面和控制平面间的标准协议
        • 效果
          • 比没有服务网格的场景，多 4 个 IPC 通信成本
          • 服务化的应用在没做任何改造的情况下，就可以获得强大的流量控制能力、服务治理能力、可观测能力、4 个 9（99.99%）以上高可用、容灾和安全等能力，加上业务的横向扩展能力。整体收益远大于额外 IPC 通信支出