【系统架构设计师】云原生架构设计理论与实践
·
目录
对于开发而言，传统的 IT架构方式，将开发、 IT运营和质量保障分别设置，各自独立，开发与运营之间存在着信息“鸿沟”,开发人员希望基础设施更快响应，运营人员则要求系统的可靠性和安全性，而业务需求则是更快地将更多的特性发布给最终用户使用。
云原生技术与边缘计算相结合，可以比较好地解决传统方案中轻量化、异构设备管理、海
量应用运维管理的难题。
云原生与商业场景的深度融合，不仅为各行业注入了发展与创新的新动能，也促使云原生技术更快发展、生态更加成熟。
二、云原生架构内涵
（一）定义
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化地剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、
可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
（二）特点
基于云原生架构的应用特点包括：
（
1）代码结构发生巨大变化：不再需要掌握文件及其分布式处理技术，不再需要掌握各种复杂的网络技术，简化让业务开发变得更敏捷、更快速。
（
2）非功能性特性大量委托给云原生架构来解决：比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
（
3）高度自动化的软件交付：基于云原生的自动化软件交付可以把应用自动部署到成千上万的节点上。
（三）云原生架构原则
（
1
）服务化原则：通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代。
（
2
）弹性原则：弹性是指系统的部署规模可以随着业务量的变化而自动伸缩。
（
3）可观测原则：通过日志、链路跟踪和度量等手段，使得多次服务调用的耗时、返回值和参数都清晰可见。
（
4
）韧性原则：软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
（
5）所有过程自动化原则：让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
（
6
）零信任原则：不应该信任网络内部和外部的任何人
/
设备
/系统，需要基于认证和授权重构访问控制的信任基础。
（
7
）架构持续演进原则：架构具备持续演进能力。
（四）主要架构模式
（
1
）服务化架构模式：要求以应用模块为颗粒度划分一个应用软件，以接口契约（例如
IDL）定义彼此业务关系，以标准协议（
HTTP
、
gRPC
等）确保彼此的互联互通，结合领域模型驱动Domain Driven Design
，
DDD
）、测试动开发（
Test Driven Design
，
TDD）、容器化部署提升每个接口的代码质量和迭代速度。
（
2
）
Mesh
化架构模式：
Mesh
化架构是把中间件框架（如
RPC、缓存、异步消息等）从业务进程中分离，让中间件
SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。
（
3
）
Serverless
模式：业务流量到来
/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭
/调度业务进程，等待下一次触发。开发者不用关心应用运行地点、操作系统、网络配置、
CPU
性能等，将应用的整个运行都委托给云。
Serverless 模式适合事件驱动的数据计算任务、计算时间短的请求
/
响应应用、没有复杂相互调用的长周期任务。
（
4
）存储计算分离模式：分布式环境中的
CAP 困难主要是针对有状态应用，由于一致性（
Consistency
，
C
），可用性（
Availability
，
A
），分区容错性（
Partition Tolerance
，P）三者无法同时满足，最多满足其中两个。所以无状态应用不存在一致性这个维度，可以获得很好的可用性和分区容错性，因而获得更好的弹性。
（
5）分布式事务模式。由于业务需要访问多个微服务，所以会带来分布式事务问题，否则数据就会出现不一致。因此架构师需要根据不同的场景选择合适的分布式事务模式，常用的有：
- XA 模式（传统采用 XA 模式）：由于 XA 规范是实现分布式事务处理的标准，通常采用两阶段提交（2 Prepare Commit，2PC）的方法，具有很强的一致性，但是由于需要两次网络交互，所以性能差。
- 基于消息的最终一致性（BASE）：在可用性和一致性相冲突的情况下，为了权衡二者， BASE 提出只要满足基本可用（BA）和最终一致性（E），接受数据的软状态或未确定状态（S），来优先实现性能，所以这类系统通常具备很高的性能。但正是由于应用的特点， 选择可用性和一致性的妥协方案，导致通用性有限。
- TCC 模式：采用 Try-Confirm-Cancel 二阶段模式，事务隔离性可控，高效，但需要应用代 码将业务模型拆成二阶段，所以对业务侵入性强，设计开发维护等成本很高。
- SAGA 模式：每个正向事务都对应一个补偿事务，若正向事务执行失败，则会执行补偿事务进行回滚。所以开发维护成本高。
- 开源项目 SEATA 的 AT 模式：它将 TCC 模式中的二阶段委托给底层代码框架，并且取消了行锁，所以非常高性能且无代码开发工作量，且可以自动执行回滚操作，但存在一些 使用场景限制。
（
6
）可观测架构：可观测架构包括
Logging
、
Tracing
、
Metrics
，其中
Logging 提供多个级别跟踪，例如 INFO/ DEBUG/WARNING/ERROR；Tracing 收集一个请求从前端到后端的访问日志聚
合，形成完整调用链路跟踪；
Metrics 则提供对系统量化的多维度度量，包括并发度、耗时、可用时长、容量等。
（
7
）事件驱动架构：事件驱动架构（
Event Driven Architecture
，
EDA
）是一种应用/组件间的集成架构模式。适用于增强服务韧性、数据变化通知、构建开放式接口、事件流处理、命令查询的责任分离（
Command Query Responsibility Segregation
，
CQRS）把对服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的
API
接口等。
（五）典型的云原生架构反模式
（1）庞大的单体应用：缺乏依赖隔离，代码耦合，责任和模块边界不清晰，模块间接口缺乏治理，变更影响扩散，不同模块间的开发进度和发布时间要求难以协调，一个子模块不稳定导致整个应用都变慢，扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容等。
（
2）单体应用“硬拆”为微服务：强行把耦合度高、代码量少的模块进行服务化拆分；拆分后服务的数据是紧密耦合的；拆分后成为分布式调用，严重影响性能。
（
3）缺乏自动化能力的微服务：人均负责模块数上升，人均工作量增大，也增加了软件开发成本。
三、云原生架构相关技术
（一）容器技术
容器作为标准化软件基础单元，它将应用及其所有依赖项打包发布，由于依赖项齐备，应用不再受环境限制，在不同计算环境间快速、可靠地运行。容器部署模式与其他模式的比较如下图
所示。
（二）容器编排技术
容器编排技术包括资源调度、应用部署与管理、自动修复、服务发现与负载均衡、弹性伸缩、声明式
API
、可扩展性架构、可移植性。
（三）云原生微服务
微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。微服务设计约束如下：
（1）微服务个体约束：微服务应用的功能在业务领域划分上应是相互独立的。
（2）微服务与微服务之间的横向关系：在合理划分好微服务间的边界后，从可发现性和可交互性处理微服务间的横向关系。可发现性是指当服务A 发布和扩/缩容的时候，依赖服务A 的服务 B 在不重新发布的前提下，能够自动感知到服务A 的变化。可交互性是指服务A 采用什么样的方式可以调用服务B。
（3）微服务与数据层之间的纵向约束：提倡数据存储隔离（Data Storage Segregation，DSS）原则，对于数据的访问都必须通过相对应的微服务提供的 API 来访问。
（4）全局视角下的微服务分布式约束：高效运维整个系统，从技术上实现全自动化的CI/CD流水线满足对开发效率的诉求，并在这个基础上支持蓝绿、金丝雀等不同发布策略，以满足对业务发布稳定性的诉求。
主要微服务技术
- Apache Dubbo作为源自阿里巴巴的一款开源高性能RPC框架
- Spring Cloud 作为开发者的主要微服务选择之一
- Eclipse MicroProfile作为Java 微服务开发的基础编程模型
- Tars是腾讯将其内部使用的微服务框架TAF(Total Application Framework)多年的实践成果总结而成的开源项目
- SOFAStack(Scalable Open Financial Architecture Stack) 是由蚂蚁金服开源的一套用于快速构建金融级分布式架构的中间件，也是在金融场景里的最佳实践
- DAPR(Distributed Application Runtime,分布式应用运行时)是微软新推出的一种可移植的、无服务器的、事件驱动的运行时
（四）无服务器技术
无服务器技术的特点：
（1）全托管的计算服务—客户只需要编写代码构建应用，无须关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作。
（2）通用性—结合云 BaaS（后端云服务）API 的能力，能够支撑云上所有重要类型的应用。
（3）自动弹性伸缩—让用户无须为资源使用提前进行容量规划。
（4）按量计费—让企业的使用成本有效降低，无须为闲置资源付费。
无服务器技术的关注点是：计算资源弹性调度（容错、资源利用率、性能、数据驱动）、负载均衡和流控、安全性。
（五）服务网格 （Service Mesh）
服务网格旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。下图展示了服务网格的典型架构。服务A 调用服务B 的所有请求，都被其下的服务代理截获，代理服务A 完成到服务B 的服务发现、熔断、限流等策略，而这些策略的总控是在控制平面（Control Plane）上配置。
服务网格的主要技术：Istio、Linkerd、Consul。
四、云原生架构案例分析
（一）某旅行公司云原生改造
1.背景和挑战
某旅行公司 两个前身公司各自存在着不同技术体系的构建、发布等系统 ，必须在技术层面做进一步的收敛，以达到平台统一的目的。 同时，在线旅行业务具有较明显的业务波动特性，在季度、节假日、每日时段上都有比较突出的波峰波谷特性。这样的业务特性对技术资源的整体利用率波动影响较大。
2.基于云原生架构的解决方案
（1）改造第一阶段：利用云原生思维重构部分技术体系，将多套旧有系统合并、收拢到一套以云原生应用为核心的私有云平台上，同时将 IDC、 物理网络、虚拟网络、计算资源、存储资源等通过laaS、PaaS 等，实现虚拟化封装、切割、再投产的自动化流程。
（2）
改造第二阶段：保障服务稳定性，基于公有云、私有云和离线专属云集群等新型动态计算环境，业务构建和运行具有弹性的云原生应用。
（3）改造第三阶段：通过基础组件、服务的云原生改造、服务依赖梳理和定义等方式，使应用不再需要考虑底层资源、机房、运行时间和供应商等因素。
3.应用效益
（1）通过第一阶段改造，共享机器集群，提高资源利用率和调度稳定性，减少资源部署。
（2）通过第二阶段改造，应对季节性流量高峰采购资源减少，平台能够以较低的成本稳定运行。
（二）云原生技术助力某汽车公司数字化转型实践
1.背景和挑战
某汽车公司自2016年开始引入移动互联网、电商等数字化营销系统，逐步布局汽车后服务市场，为更好更快迎合客户需求变化，掌握市场转换的主动权，对某云行为代表的互联网应用进行全面的推广，通过触点连接客户并提供便捷用车和增值服务。同时，积极开拓在线支付、车联网、二手车交易等新型汽车服务业务场景，积累了丰富的实践经验。充分利用容器、微服务、DevOps 云原生转型方法和手段，驱动技术与汽车场景业务深度融合，建立业务与技术之间良性循环。
2.基于云原生架构的解决方案
3.应用效益
（三）某快递公司核心业务系统云原生改造
1.背景和挑战
过往某快递公司的核心业务应用运行在 IDC机房，原有 IDC系统帮助某快递公司安稳度过早期业务快速发展期。但伴随着业务体量指数级增长，业务形式愈发多元化。原有系统暴露出不少问题，传统IOE架构、各系统架构的不规范、稳定性、研发效率都限制了业务高速发展的可能。软件交付周期过长，大促保障对资源的特殊要求难实现、系统稳定性难以保障等业务问题逐渐暴露。
2.基于云原生架构的解决方案
1)引入云原生数据库
通过引入 OLTP跟 OLAP 型数据库，将在线数据与离线分析逻辑拆分到两种数据库中，改变此前完全依赖Oracle 数据库的现状。
2)应用容器化
与虚拟机相比，容器化提供了效率与速度的双重提升，让应用更适合微服务场景，有效提升产研效率。
3)微服务改造
通过引入Kubernetes 的服务发现，组建微服务解决方案，将业务按业务域进行拆分，让整个系统更易于维护。
3.应用效益
成本方面：使用公有云作为计算平台，可以让企业不必因为业务突发增长需求，而一次性投入大量资金成本用于采购服务器及扩充机柜。在公共云上可以做到随用随付，对于一些创新业务想做技术调研十分便捷。用完即释放，按量付费。另外云产品都免运维自行托管在云端，有效节省人工运维成本，让企业更专注于核心业务。
稳定性方面：首先，云上产品提供至少5个9(99.999%)以上的 SLA服务确保系统稳定，而自建系统稳定性相去甚远。其次，部分开源软件可能存在功能Bug, 造成故障隐患。最后，在数据安全方面云上数据可以轻松实现异地备份，阿里云数据存储体系下的归档存储产品具备高可靠、低成本、安全性、存储无限等特点，让企业数据更安全。
效率方面：借助与云产品深度集成，研发人员可以完成一站式研发、运维工作。从业务需求立项到拉取分支开发，再到测试环境功能回归验证，最终部署到预发验证及上线，整个持续集成流程耗时可缩短至分钟级。排查问题方面，研发人员直接选择所负责的应用，并通过集成的 SLS 日志控制台快速检索程序的异常日志进行问题定位，免去了登录机器查日志的麻烦。
赋能业务：阿里云提供超过300余种的云上组件，组件涵盖计算、 AI、 大数据、 IoT等诸多领域。研发人员开箱即用，有效节省业务创新带来的技术成本。
更多推荐
5
0- 0
已为社区贡献1条内容
所有评论(0)