14. 云原生架构设计理论与实践

发表于 分类于

1 云原生架构产生背景

云原生技术的重要性

  • 云原生技术是推动业务增长的重要引擎，逐渐在人工智能、大数据、边缘计算、5G 等领域崭露头角。

云原生技术的优势

  • 云原生技术提供统一的 IaaS 能力和云服务，提升企业 IaaS 层的利用程度。
  • 云原生技术促进 DevOps 实现，提高开发周期和效率。

云原生技术的挑战

  • 云原生技术需要解决软件的效率和版本更新速度问题。
  • 云原生技术需要与现有 IT 架构和流程相融合。

云原生架构的优势

  1. 支持多场景计算需求
  • 云原生架构支持多种计算场景，满足不同业务需求。
  1. 提升业务应用的迭代速度
  • 云原生架构通过 DevSecOps 提升应用的敏捷开发，提高业务应用的迭代速度。
  1. 管理数据资产
  • 云原生架构帮助企业更好地管理数据，快速构建数据运营能力。
  1. 保障企业安全
  • 云原生架构结合全方位企业级安全服务，保障企业应用在云上安全构建，业务安全运行。

2 云原生架构内涵

云原生架构是基于云原生技术的一组架构原则和实践的集合，旨在解决云应用中的非业务代码部分的去中心化问题。

2.1 云原生架构定义

  1. 云原生架构发生巨大变化
  • 代码结构的巨大变化
    • 云原生架构使得开发人员编写模型发生了巨大变化。今天大部分编程语言中，都有文件、网络、线程等元素，这些元素为充分利用单机资源带来好处，也提升了分布式编程的复杂性。
  • 非功能性特性的大量委托
    • 在云时代，如何获取存储变成了若干服务，包括对象存储服务、块存储服务和具有随机访问的文件存储服务。
    • 企业不再需要掌握各种复杂的事务代码和优化让其变得简单有效。
  1. 非功能性特性大量委托
  • 应用部署到云端后，功能性特性和非功能性特性被区分开来。
  • 非功能性特性如业务管理、业务容灾等也是需要业务需求的，非功能性特性是综合业务属性业务价值，但通常是必不可少的属性。
  1. 高度自动化的软件交付
  • 软件一旦开发完成，需要在公司内外部各类环境中部署和交付，以将软件价值交给最终客户。
  • 在环境变化时，容器及相关技术则帮助屏蔽不同环境之间的差异。
  • 云原生架构标准化的软件开发交付。

2.2 云原生架构原则

云原生架构定义：云原生架构是基于云原生技术的一组架构原则和实践的集合，旨在将云应用中的非业务代码部分进行去中心化剥离。

  • 服务化原则：服务化架构将不同生命周期的模块分离出来，避免选代频繁模块慢速模块拖慢，从而加快整体的进度和稳定性。提高软件的复用程度。
  • 弹性原则：系统部署规模可以随着业务量的变化而自动伸缩。
  • 可观测原则：业务系统的所有活动都清晰可见，便于监控和分析。
  • 韧性原则：核心目标是提升软件的平均无故障时间 (Mean Time Between Failure,MTBF)
  • 所有过程自动化原则：自动化交付和部署。
  • 零信任原则：默认情况下不应该信任网络内部和外部的任何一方。
  • 架构持续演进原则：技术演进速度非常快，架构必须适应这种快速变化。

2.3 主要架构模式

云原生架构有非常多的架构模式，这里选取一些对应用收益更大的主要架构模式进行讨论。

2.3.1 服务化架构模式

  • 服务化架构是云时代构建云应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约（例如 IDL）定义彼此业务关系。
  • 典型模式是微服务和小服务模式，适用于大型软件系统。

2.3.2 Mesh 化架构模式

  • Mesh化架构是云原生组件框架，将中间件框架（如 RPC、缓存、异步消息等）从业务进程中分离。
  • 提供更好的安全性和可观测性，按流量进行动态环境隔离、基于流量做冒烟/回归测试。

2.3.3 Serverless 模式

  • Serverless 将“部署”动作从运维中“收起”，使开发者不用关心应用运行地点、操作系统、网络配置、CPU 性能等。
  • 适合事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。

2.3.4 存储计算分离模式

分布式环境中的 CAP 问题主要是针对有状态应用，推荐各类暂态数据（如 session）、结构化和非结构化持久数据都采用云服务来保存。

2.3.5 分布式事务模式

微服务模式下，业务需要访问多个微服务，必然带来分布式事务问题。架构师需要根据不同的场景选择合适的分布式事务模式。

2.3.6 可观测架构

  • 可观测架构包括 Logging、Tracing、Metrics 三个方面。
  • Logging 提供多个级别详细信息跟踪，Tracing 提供请求从前端到后端的完整调用链路跟踪，Metrics 提供系统量化的多维度度量。

2.3.7 事件驱动架构

  • 事件驱动架构 (EDA,Event Driven Architecture)是一种应用组件间的集成架构模式，事件具有 schema，可以校验 event 的有效性。
  • 增强服务韧性、CQRS、数据变化通知、构建开放接口、流量控制、事件流处理。

2.4 典型的云原生架构反模式

  1. 庞大的单体应用
  • 单体应用的问题包括缺乏依赖隔离、代码耦合带来的责任不清、模块间接口缺乏治理等。
  • 拆分服务化可以解决这些问题，但需要考虑业务关系、服务模块边界和接口定义。
  1. 单体应用“硬拆”为微服务
  • 服务拆分需要适度，过分拆分会导致架构与组织能力不匹配。
  • 拆分后的小规模软件服务拆分、数据依赖和性能降低是常见问题。
  1. 缺乏自动化能力的微服务
  • 软件架构复杂度增加，需要重新考虑解决方案。
  • 缺乏自动化能力会导致软件交付时间变长、风险提升和运维成本增加。

3 云原生架构相关技术

3.1 容器技术

3.1.1 容器技术的背景与价值

  • 容器技术标准化软件单元，使应用及其依赖项打包，使应用不再受环境限制。
  • 容器部署模式与虚拟机比较，容器更轻量、高效。

3.1.2 容器编排

Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提供了分布式应用管理的核心能力。

  • 资源调度
  • 应用部署与管理
  • 自动修复
  • 服务发现与负载均衡
  • 弹性伸缩
  • 声明式 API
  • 可扩展性架构
  • 可移植性

3.2 云原生微服务

3.2.1 微服务发展背景

  • 单体应用功能复杂，开发和运维效率低。
  • 微服务架构通过将单体应用拆分为多个微服务，提高开发和运维效率。

3.2.2 微服务架构约束

  • 微服务架构需要解决服务间通信、数据一致性、服务发现等问题。
  • 微服务需要满足独立性、可扩展性、容错性等特性。

微服务设计原则

  • 单一职责原则：每个服务只负责单一职责。
  • 服务间松耦合：服务间通过定义良好的接口通信。
  • 服务自治：每个服务独立部署、扩展和更新。

3.2.3 主要微服务技术

  • Apache Dubbo 作为源自阿里巴巴的一款开源高性能 RPC 框架
  • Spring Cloud 作为开发者的主要微服务选择之一，为开发者提供了分布式系统需要的配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、 全局锁、决策竞选、分布式会话与集群状态管理等能力和开发工具。
  • DAPR(Distributed Application Runtime, 分布式应用运行时) 是微软新推出的一种可移植的、无服务器的、事件驱动的运行时

3.3 无服务器技术

3.3.1 技术特点

无服务器技术 (Serverless) 因为屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。 Serverless 计算包含以下特征：云服务器技术具有全托管计算服务、通用性、自动伸缩性、按需计费等特点。

函数计算 (Function as a Service,FaaS) 是 Serverless 中最具代表性的产品形态。通过事件驱动执行函数。

3.3.2 技术关注点

  • 计算资源弹性调度：根据应用负载自动调整资源。
  • 负载均衡和流量隔离控制
    • 负载均衡可用于支撑每秒近百万次的资源调度请求
    • 流量隔离控制是保证服务质量的关键。由于用户是按实际使用的资源付费，因此计算资源要通过被不同用户的不同应用共享来降低系统成本。这就需要系统具备出色的隔离能力，避免应用相互干扰。
  • 安全性：系统应从权限管理、网络安全、数据安全、运行时安全等各个维度全面保障应用的安全性。

3.4 服务网格架构

3.4.1 技术特点

  • 服务网格（ServiceMesh）是分布式应用的新型架构技术，旨在将服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施。
  • 服务网格以无侵入的方式实现应用轻量化。

3.4.2 主要技术

  • Istio 是服务网格设计开源项目，定义了数据平面和控制平面的开源软件 Envoy 来实现服务网格。
  • Istio 利用已有的 Lyft 恩尼代理进行构建，可在无需对应用程序代码作任何改动的前提下实现可视化与控制能力。

4 云原生架构案例分析

4.1 某旅行公司云原生改造

  1. 背景和挑战
  • 同程旅行公司面临技术架构整合和云原生改造的挑战，需要解决技术资源利用率波动和成本控制问题。
  1. 基于云原生架构的解决方案
  • 改造第一阶段：提升集群资源利用率，降低资源使用成本。
  • 第二阶段：通过云原生改造，实现跨地域、跨云自动化部署、自动部署，并向云原生场景下的 DevOps 演进。
  1. 应用效益
  • 通过改造，提升了资源利用率，降低了成本，增强了业务的稳定性和灵活性。

4.2 云原生技术助力某汽车公司数字化转型实践

  1. 背景和挑战
  • 汽车行业数字化转型，需要快速响应客户需求，提升业务效率。
  1. 基于云原生架构的解决方案
  • 采用云原生技术，通过 DevOps 平台实现快速迭代和持续交付。
  1. 应用效益
  • 通过云原生技术，实现了业务的快速迭代和持续交付，提升了业务效率和客户满意度。

4.3 某快递公司核心业务系统云原生改造

  1. 背景和挑战
  • STO 申通快递公司面临业务体量指数级增长，传统 IOE 架构限制业务发展。
  • 需要云原生技术实现核心业务系统上云。
  1. 基于云原生架构的解决方案
  • 引入云原生数据库，重构应用架构。
  • 采用 Kubernetes 服务实现微服务架构。
  1. 应用效益
  • 提升资源利用率，降低成本。
  • 增强系统稳定性和可维护性。

4.4 某电商业务云原生改造

  1. 背景和挑战
  • PerfectDiary 完美日记电商平台面临大促活动流量挑战。
  • 需要云原生技术实现系统弹性扩展。
  1. 基于云原生架构的解决方案
  • 引入阿里云容器服务 ACK、Spring Cloud Alibaba、PTS、AHAS 等。
  • 通过 DevOps 实现快速迭代和持续交付。
  1. 应用效益
  • 提升资源利用率，降低成本。
  • 提升系统稳定性和可维护性。

4.5 某体育用品公司基于云原生架构的业务中台构建

  1. 背景和挑战
  • 特步体育用品公司需要快速响应市场变化。
  • 需要云原生技术实现业务中台构建。
  1. 基于云原生解决方案
  • 引入阿里云容器服务 ACK、Spring Cloud Alibaba、PTS、HAS 等。
  • 通过 DevOps 实现快速迭代和持续交付。
  1. 应用效益
  • 提升资源利用率，降低成本。
  • 提升系统稳定性和可维护性。

参考