【中项】系统集成项目管理工程师-第4章 信息系统架构-4.8云原生架构

前言：系统集成项目管理工程师专业，现分享一些教材知识点。觉得文章还不错的喜欢点赞收藏的同时帮忙点点关注。

软考同样是国家人社部和工信部组织的国家级考试，全称为"全国计算机与软件专业技术资格（水平）考试"，目前涵盖了计算机软件、计算机网络、计算机应用技术、信息系统、信息服务5大领域，总共27个科目，也是分为初、中、高三个级别。

通信专业主要需要关注"计算机网络"这个专业类别，可以考的科目有初级资格的"网络管理员"、中级的"网络工程师"。

还有5个高级资格专业，分别是"信息系统项目管理师""系统分析师""系统架构设计师""网络规划设计师""系统规划与管理师"。

软考高级证书在通信行业比较吃香，主要原因有两个： 通信行业与计算机软件是相近专业，评职称满足相近专业的要求； 通信高级不能以考代评，但软考高级可以，很多考生通过考软考高级来评高级职称。

---

4.8 云原生架构

"云原生 "来自于CloudNative的直译，拆开来看，Cloud就是指其应用软件和服务是在云端而非

传统意义上的数据中心。Native代表应用软件从一开始就是基于云环境，专门为云端特性而设计， 可充分利用和发挥云环境的弹性与分布式优势，最大化释放云环境生产力。

4.8.1 发展概述

对于信息化和数字化水平不高的组织而言，组织内部IT建设常以"烟简 "模式比较多，即每项 职能（部门）的每个应用都相对独立，如何管理与分配资源成了难题。大多数都基于IDC设施独自 向上构建，需要单独分配基础设施资源，这就造成资源被大量占用且难以被共享。但是上云之后， 由于云服务组织提供了统一的基础设施即服务（Infrastructure asa Service ，laaS）能力和云服务等， 大幅提升了组织IaaS层的复用程度，CIO或者IT主管自然而然想到laaS以上层的系统也需要被统一，使资源、产品可被不断复用，从而能够进一步降低组织运营成本。

对于开发而言，传统的IT架构方式，将开发、IT运营和质量保障等过程分别设置，各自独立， 开发与运行或运营之间存在着某种程度的"鸿沟 "，开发人员希望基础设施更快响应，运行管理及 运营人员则要求系统的可靠性和安全性，而业务需求则是更快地将更多的特性发布给最终用户使用。这种模式被称为"瀑布式流程 "开发模式，一方面造成了开发上下游的信息不对称，另一方面 拉长了开发周期和调整难度。但是随着用户需求的快速增加和产品迭代周期的不断压缩，原有的开 发流程不再适合现实的需求，这时开发建设组织引入了一种新的开发模式------敏捷开发。但是，敏 捷开发只是解决了软件开发的效率和版本更新的速度，还没有和运维管理等有效打通。出于协调开 发和运维的"信息对称 "问题，开发者又推出了一套新的方法---DevOps 。DevOps可以看作是开发、技术运营和质量保障三者的交集，促进他们之间的沟通、协作与整合，从而提高开发周期和效 率。而云原生的容器、微服务等技术正是为DevOps提供了很好的前提条件，保证IT软件开发实现 DevOps 开发和持续交付的关键应用。换句话说能够实现 DevOps 和持续交付，已经成为云原生技术价值不可分割的内涵部分，这也是无论互联网巨头，还是众多中小应用开发组织和个人，越来越 多选择云原生技术和工具的原因。
现在数以亿计的高并发流量都得益于云原生技术的快速弹性扩容来实现。而对于企业而言，选 择云原生技术，也就不仅仅是降本增效的考虑，而且还能为企业创造过去难以想象的业务承载量， 对于企业业务规模和业务创新来说，云原生技术都正在成为全新的生产力工具。过去企业看重的办 公楼、厂房、IT设施等有形资产，其重要性也逐渐被这些云端数字资产所超越，企业正通过云原生 构建一个完整的数字孪生的新体系，而这才是云原生技术的真正价值所在。

各类信息系统开发建设面临的问题往往指向一个共同点，那就是新时代需要新的技术架构，来 帮助组织应用能够更好地利用云计算和云服务的优势，充分释放云计算的技术红利，让业务更敏捷、成本更低的同时又可伸缩性更灵活，而这些正好就是云原生架构专注解决的技术点。

对于整个云计算产业的发展来说，云原生区别于早先的虚拟机阶段，也完成了一次全新的技术 生产力变革，是从云技术的应用特性和交付架构上进行了创新性的组合，能够极大地释放云计算的 生产能力。此外，云原生的变革从一开始自然而然地与开源生态走在了一起，也意味着云原生技术 从一开始就选择了一条"飞轮进化 "式的道路，通过技术的易用性和开放性实现快速增长的正向循 环，又通过不断壮大的应用实例来推动了组织业务全面上云和自身技术版图的不断完善。云原生所 带来的种种好处，对于组织的未来业务发展的优势， 已经成为众多组织的新共识。可以预见，更多 组织在经历了这一轮云原生的变革之痛后，能够穿越组织的原有成长周期，跨越到数字经济的新赛 道，在即将到来的全面数字新时代更好地开发业务。

开源项目的不断更新和逐步成熟，也促使各组织在Al 、大数据、边缘、高性能计算等新兴业务 场景不断采用云原生技术来构建创新解决方案。大量组织尝试使用容器替换现有人工智能、大数据 的基础平台，通过容器更小粒度的资源划分、更快的扩容速度、更灵活的任务调度，以及天然的计 算与存储分离架构等特点，助力人工智能、大数据在业务性能大幅提升的同时，更好地控制成本。 各云服务商也相继推出了对应的容器化服务， 比如某云服务商的AI容器、大数据容器、深度学习容 器等。

云原生技术与边缘计算相结合，可以比较好地解决传统方案中轻量化、异构设备管理、海量应 用运维管理的难题，如目前国内最大的边缘计算落地项目------国家路网中心的全国高速公路取消省 界收费站项目，就使用了基于云原生技术的边缘计算解决方案，解决了10多万异构设备管理、30多 万边缘应用管理的难题。主流的云计算厂商也相继推出了云原生边缘计算解决方案，如某云服务商 的云智能边缘平台（ IEF）等。

云原生在高性能计算（High Performance Computing ，HPC）领域的应用呈现出快速上升的势头。云原生在科研及学术机构、生物、制药等行业率先得到应用，例如中国科学院上海生命科学研 究院、中国农业大学、华大基因、未来组、欧洲核子研究中心等组织都已经将传统的高性能计算业 务升级为云原生架构。为了更好地支撑高性能计算场景，各云服务商也纷纷推出面向高性能计算专 场的云原生解决方案。
云原生与商业场景的深度融合，不仅为各行业注入了发展与创新的新动能，也促使云原生技术 更快发展、生态更加成熟，主要表现为以下几点。

（1）从为组织带来的价值来看，云原生架构通过对多元算力的支持，满足不同应用场景的个性 化算力需求，并基于软硬协同架构，为应用提供极致性能的云原生算力；基于多云治理和边云协

同，打造高效、高可靠的分布式泛在计算平台，并构建包括容器、裸机、虚机、函数等多种形态的 统一计算资源； 以"应用 "为中心打造高效的资源调度和管理平台，为企业提供一键式部署、可感 知应用的智能化调度，以及全方位监控与运维能力。

（2）通过最新的DevSecOps应用开发模式，实现了应用的敏捷开发，提升业务应用的迭代速

度，高效响应用户需求，并保证全流程安全。对于服务的集成提供侵入和非侵入两种模式辅助企业 应用架构升级，同时实现新老应用的有机协同，立而不破。

（3）帮助企业管理好数据，快速构建数据运营能力，实现数据的资产化沉淀和价值挖掘，并借 助一系列AI技术，再次赋能给企业应用，结合数据和AI的能力帮助企业实现业务的智能升级。

（4）结合云平台全方位组织级安全服务和安全合规能力，保障组织应用在云上安全构建，业务 安全运行。

4.8.2 架构定义

从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合， 旨在将云应 用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹 性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、 敏捷、高度自动化的特点。由于云原生是面向"云 "而设计的应用，因此，技术部分依赖于传统云 计算的3层概念，即基础设施即服务（laaS）、平台即服务（PaaS）和软件即服务（SaaS）。

云原生的代码通常包括三部分：业务代码、三方软件、处理非功能特性的代码。其中"业务代 码 "指实现业务逻辑的代码；"三方软件 "是业务代码中依赖的所有三方库，包括业务库和基础库；"处理非功能特性的代码 "指实现高可用、安全、可观测性等非功能性能力的代码。三部分中 只有业务代码是核心，是给业务真正带来价值的，另外两个部分都只算附属物。但是，随着软件规 模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强等，使得今天的软件构建变得越 来越复杂，对开发人员的技能要求也越来越高。云原生架构相比传统架构进了一大步，从业务代码中剥离大量非功能性特性到IaaS和PaaS中，从而减少业务代码开发人员的技术关注范围，通过云服 务商的专业性提升应用的非功能性能力。具备云原生架构的应用可以最大程度利用云服务和提升软 件交付能力，进一步加快软件开发。
1.代码结构发生巨大变化

云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化。今天大部分编程语言 中，都有文件、网络、线程等元素，这些元素为充分利用单机资源带来好处的同时，也提升了分布 式编程的复杂性。因此大量框架、产品涌现，来解决分布式环境中的网络调用问题、高可用问题、 CPU争用问题、分布式存储问题等。

在云环境中，"如何获取存储 "变成了若干服务，包括对象存储服务、块存储服务和文件存储 服务。云不仅改变了开发人员获得这些存储能力的界面，还在于云服务解决了分布式场景中的各种 挑战，包括高可用挑战、 自动扩缩容挑战、安全挑战、运维升级挑战等，应用的开发人员不用在其 代码中处理节点宕机前如何把本地保存的内容同步到远端的问题，也不用处理当业务峰值到来时如 何对存储节点进行扩容的问题，而应用的运维人员不用在发现"零日漏洞（zero-day） "安全问题 时紧急对三方存储软件进行升级。

云把三方软硬件的能力升级成了服务，开发人员的开发复杂度和运维人员的运维工作量都得到 极大降低。显然，如果这样的云服务用得越多，那么开发和运维人员的负担就越少，组织在非核心 业务实现上从必须的负担变成了可控支出。在一些开发能力强的组织中，对这些三方软硬件能力的 处理往往是交给应用框架（或者说组织内自己的中间件）来做的。在新时代云服务商提供了更全面 的服务，使得所有软件组织都可以由此获益。

这些使得业务代码的开发人员技能栈中，不再需要掌握文件及其分布式处理技术，不再需要掌 握各种复杂的网络技术，从而让业务开发变得更敏捷、更快速。

2.非功能性特性大量委托

任何应用都提供两类特性：功能性特性和非功能性特性。功能性特性是真正为业务带来价值的 代码，比如建立客户资料、处理订单、支付等。即使是一些通用的业务功能特性，比如组织管理、 业务字典管理、搜索等也是紧贴业务需求的。非功能性特性是没有给业务带来直接业务价值，但通 常又是必不可少的特性， 比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、 灰度发布能力等。

云计算虽然没有解决所有非功能性问题，但确实有大量非功能性，特别是分布式环境下复杂非 功能性问题，被云计算解决了。 以大家最头疼的高可用为例，云计算在多个层面为应用提供了解决 方案等，如虚拟机、容器和云服务等。
（1）虚拟机。当虚拟机检测到底层硬件发生异常时， 自动帮助应用做热迁移，迁移后的应用不 需重新启动而仍然具备对外服务的能力，应用本身及其使用用户对整个迁移过程都不会有任何感知。

（2）容器。有时应用所在的物理机是正常的，只是应用自身的问题（比如bug 、资源耗尽等）

而无法正常对外提供服务。容器通过监控检查探测到进程状态异常，从而实施异常节点的下线、新 节点上线和生产流量的切换等操作，整个过程自动完成而无须运维人员干预。

（3）云服务。如果应用把"有状态 "部分都交给了云服务（如缓存、数据库、对象存储等）， 加上全局对象的持有小型化或具备从磁盘快速重建能力， 由于云服务本身是具备极强的高可用能力，那么应用本身会变成更薄的"无状态 "应用，高可用故障带来的业务中断会降至分钟级；如果 应用是N：M（N台客户端中的每一台都可以访问到M台服务器）的对等架构模式，那么结合负载 均衡产品可获得很强的高可用能力。

3.高度自动化的软件交付

​​​​​​​软件一旦开发完成，需要在组织内外部各类环境中部署和交付，以将软件价值交给最终用户。 软件交付的困难在于开发环境到生产环境的差异，以及软件交付和运维人员的技能差异，填补这些 差异往往需要一大堆安装手册、运维手册和培训文档等。容器以一种标准的方式对软件打包，容器 及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。

​​​​​​​对自动化交付而言，还需要一种能够描述不同环境的工具，让软件能够"理解 " 目标环境、交 付内容、配置清单并通过代码去识别目标环境的差异，根据交付内容以"面向终态 "的方式完成软 件的安装、配置、运行和变更。

​​​​​​​基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例， 应用微服务化以后，往往被部署到成千上万个节点上，如果系统不具备高度的自动化能力，任何一 次新业务的上线，都会带来极大的工作量挑战，严重时还会导致业务变更超过上线窗口而不可用。

4.8.3 基本原则

​​​​​​​云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从 这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。关于云原生架构原则， 立足不同的价值视角或技术方向等有所不同，常见的原则主要包括服务化、弹性、可观测、韧性、 所有过程自动化、零信任、架构持续演进等原则。

1.服务化原则

​​​​​​​当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、 小服务（Mini Service）架构等，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和提升系统稳定性。同时服务化架 构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。
​​​​​​​分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量 （而非网络流量）的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业 务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治 理，不管这些服务是基于什么语言开发的。

2.弹性原则

​​​​​​​大部分系统部署上线需要根据业务量的估算，准备一定规模的各类软硬件资源，从提出采购申 请，到与供应商洽谈、软硬件资源部署、应用部署、性能压测，往往需要好几个月甚至一年的周期，而这期间如果业务发生了变化，重新调整也非常困难。弹性则是指系统的部署规模可以随着业 务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅 缩短了从采购到上线的时间，让组织不用关注额外软硬件资源的成本支出（包括闲置成本），降低 了组织的IT成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为既有软硬件资源储 备不足而"说不 "，保障了组织收益。

3.可观测原则

​​​​​​​大部分组织的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下 需要对多个主机上的信息做关联，才可能回答清楚服务为什么离线，哪些服务违反了其定义的服务 等级目标（Service Level Objective ，SLO）， 目前的故障影响哪些用户，最近这次变更对哪些服务 指标带来了影响等问题，这些都要求系统具备更强的可观测能力等。可观测性与监控、业务探活、 应用性能检测（Application Performance Monitor ，APM）等系统提供的能力不同，可观测性是在云 这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用 的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网 络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数 据指标，获得关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。

4.韧性原则

​​​​​​​当业务上线后，最不能接受的就是业务不可用，让用户无法正常使用软件，影响体验和收入。 韧性代表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，这些异常通常 包括硬件故障、硬件资源瓶颈（如CPU/网卡带宽耗尽）、业务流量超出软件设计能力、影响机房 工作的故障和灾难、软件漏洞（bug）、黑客攻击等对业务不可用带来致命影响的因素。

​​​​​​​韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是提升软件的平均无故障时间 （Mean Time Between Failure ，MTBF）。从架构设计上，韧性包括服务异步化能力、重试/限流/降 级/熔断/反压、主从模式、集群模式、AZ（Availability Zones ，可用区） 内的高可用、单元化、跨 region（区域）容灾、异地多活容灾等。

5.所有过程自动化原则

​​​​​​​技术往往是把"双刃剑 "，容器、微服务、DevOps 、大量第三方组件的使用等，在降低分布 式复杂性和提升迭代速度的同时，因为整体增大了软件技术栈的复杂度和组件规模，所以不可避免 地带来了软件交付的复杂性，如果这里控制不当，应用就无法体会到云原生技术的优势。通过laC （Infrastructureas Code）、GitOps 、OAM（Open Application Model）、Kubernetes Operator和大量自 动化交付工具在CI/CD流水线中的实践，一方面标准化组织内部的软件交付过程，另一方面在标准 化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标 和环境差异，实现整个软件交付和运维的自动化。

6.零信任原则

​​​​​​​零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新建 议。其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和 授权重构访问控制的信任基础，如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。 零信任对访问控制进行了范式上的颠覆，引导安全体系架构从" 网络中心化 "走向"身份中心化 "，其本质诉求是以身份为中心进行访问控制。

​​​​​​​零信任第一个核心问题就是身份（Identity），赋予不同的实体不同的身份，解决是谁在什么 环境下访问某个具体的资源的问题。在研发、测试和运维等微服务场景下，身份及其相关策略不仅 是安全的基础，更是众多（包括资源、服务、环境等）隔离机制的基础；在用户访问组织内部应用 的场景下，身份及其相关策略提供了即时的接入服务。

7.架构持续演进原则

​​​​​​​信息技术及其业务应用的演进速度非常快，很少有一开始就清晰定义了架构并在整个软件生命 周期里面都适用，相反往往还需要对架构进行一定范围内的重构，因此云原生架构本身也必须是一 个具备持续演进能力的架构，而不是一个封闭式架构。除了增量迭代、 目标选取等因素外，还需要 考虑组织（例如架构控制委员会）层面的架构治理和风险控制，特别是在业务高速迭代情况下的架 构、业务、实现平衡关系。云原生架构对于新建应用而言的架构控制策略相对容易选择（通常是选 择弹性、敏捷、成本的维度），但对于存量应用向云原生架构迁移，则需要从架构上考虑遗留应用 的迁出成本/风险和到云上的迁入成本/风险，以及技术上通过微服务/应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制。

4.8.4 常用架构模式

​​​​​​​云原生架构有非常多的架构模式，不同的组织环境、业务场景和价值定位等，通常采用不同的 架构模式，常用的架构模式主要有服务化架构、Mesh化架构、Serverless 、存储计算分离、分布式 事务、可观测、事件驱动等。

1.服务化架构模式

​​​​​​​服务化架构是新时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件， 以接口契约（例如IDL）定义彼此业务关系，以标准协议（HTTP 、gRPC等）确保彼此的互联 互通，结合领域模型驱动（Domain Driven Design ，DDD）、测试驱动开发（TestDriven

​​​​​​​Development ，TDD）、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式 是微服务和小服务模式，其中小服务可以看作是一组关系非常密切的服务的组合，这组服务会共享 数据。小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗 （特别是服务间调用和数据一致性处理）和治理复杂度。

​​​​​​​通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例， 单独扩缩容，从而使得整体的部署更经济。此外， 由于在进程级实现了模块的分离，每个接口都可 以单独升级，从而提升了整体的迭代效率。但也需要注意，服务拆分导致要维护的模块数量增多， 如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效 率的降低。

2.Mesh化架构模式

​​​​​​​Mesh（网格）化架构是把中间件框架（如RPC 、缓存、异步消息等）从业务进程中分离，让 中间件的软件开发工具包（Software Development Kit ，SDK）与业务代码进一步解耦，从而使得中 间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进 程中只保留很"薄 "的Client部分，Client通常很少变化，只负责与Mesh进程通信，原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。整个架构如图4-28所示。

​​​​​​​实施Mesh化架构后，大量分布式架构模式（如熔断、限流、降级、重试、反压、隔仓等）都 由Mesh进程完成，即使在业务代码的制品中并没有使用这些三方软件包； 同时获得更好的安全性 （比如零信任架构能力等），按流量进行动态环境隔离，基于流量做冒烟/回归测试等。

3.Serverless模式

​​​​​​​Serverless（无服务器）将"部署 "这个动作从运维中"收走 "，使开发者不用关心应用运行 地点、操作系统、网络配置、CPU性能等。从架构抽象上看，当业务流量到来/业务事件发生时， 云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待 下一次触发，也就是把应用的整个运行都委托给云。

​​​​​​​Serverless并非适用任何类型的应用，因此架构决策者需要关心应用类型是否适合于Serverless 运算。如果应用是有状态的， 由于Serverless的调度不会帮助应用做状态同步，因此云在进行调度 时可能导致上下文丢失：如果应用是长时间后台运行的密集型计算任务，会无法发挥Serverless的 优势；如果应用涉及频繁的外部I/O（包括网络或者存储，以及服务间调用等），也因为繁重的I/O 负担、时延大而不适合。Serverless非常适合于事件驱动的数据计算任务、计算时间短的请求/响应 应用、没有复杂相互调用的长周期任务。事件驱动架构图如图4-29所示

-订阅-一 事件→- 事件 → 一事件→

图4-29事件驱动架构

4.存储计算分离模式

​​​​​​​分布式环境中的CAP（一致性：Consistency；可用性：Availability；分区容错性：困难主要是 针对有状态应用，因为无状态应用不存在C（一致性）这个维度，因此可以获得很好的A（可用性）和P（分区容错性），因而获得更好的弹性。在云环境中，推荐把各类暂态数据（如session）、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但仍然有一 些状态如果保存到远端缓存，会造成交易性能的明显下降， 比如交易会话数据太大、需要不断根据 上下文重新获取等，这时可以考虑通过采用时间日志+快照（或检查点）的方式，实现重启后快速 增量恢复服务，减少不可用对业务的影响时长。
5.分布式事务模式

​​​​​​​微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度 的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根 据不同的场景选择合适的分布式事务模式。

（1）传统采用XA（eXtended Architecture）模式，虽然具备很强的一致性，但是性能差。

（2）基于消息的最终一致性通常有很高的性能，但是通用性有限。

（3）TCC（Try-Confirm-Cancel）模式完全由应用层来控制事务，事务隔离性可控，也可以做 到比较高效；但是对业务的侵入性非常强，设计开发维护等成本很高。

（4）SAGA模式（指允许建立一致的分布式应用程序的故障管理模式）与TCC模式的优缺点类 似但没有Try这个阶段，而是每个正向事务都对应一个补偿事务，也使开发维护成本高。

（5）开源项目SEATA的AT模式非常高性能，无代码开发工作量，且可以自动执行回滚操作， 同时也存在一些使用场景限制。

6.可观测架构

​​​​​​​可观测架构包括Logging 、Tracing 、Metrics三个方面，Logging提供多个级别（verbose/debug/waning/error fatal）的详细信息跟踪， 由应用开发者主动提供；Tracing提供一个请求 从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量化的多维度 度量。

​​​​​​​架构决策者需要选择合适的、支持可观测的开源框架（比如Open Tracing 、Open Telemetry等），并规范上下文的可观测数据规范（例如方法名、用户信息、地理位置、请求参数等），规划 这些可观测数据在哪些服务和技术组件中传播，利用日志和Tracing信息中的spanid/raceid ，确保进 行分布式链路分析时有足够的信息进行快速关联分析。

​​​​​​​由于建立可观测性的主要目标是对服务SLO（Service Level Objective）进行度量，从而优化 SLA（Service Level Agreement ，服务水平协议），因此架构设计上需要为各个组件定义清晰的 SLO ，包括并发度、耗时、可用时长、容量等。

7.事件驱动架构

​​​​​​​事件驱动架构（Event Driven Architecture ，EDA）本质上是一种应用/组件间的集成架构模式。 事件和传统的消息不同，事件具有Schema ，所以可以校验Event的有效性，同时EDA具备QoS保障 机制，也能够对事件处理失败进行响应。事件驱动架构不仅用于（微）服务解耦，还可应用于下面 的场景中。
（1）增强服务韧性。由于服务间是异步集成的，也就是下游的任何处理失败甚至宕机都不会被 上游感知， 自然也就不会对上游带来影响。

（2）CQRS（Command Query Responsibility Segregation ，命令查询的责任分离）。把对服务状 态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的API接口；结合

EDA中的Event Sourcing机制可以用于维护数据变更的一致性，当需要重新构建服务状态时，把 EDA中的事件重新"播放 "一遍即可。

（3）数据变化通知。在服务架构下，往往一个服务中的数据发生变化，另外的服务会感兴趣， 比如用户订单完成后，积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级。

（4）构建开放式接口。在EDA下，事件的提供者并不用关心有哪些订阅者，不像服务调用数据 的产生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性。

（5）事件流处理。应用于大量事件流（而非离散事件）的数据分析场景，典型应用是基于 Kafka的日志处理。

（6）基于事件触发的响应。在IoT时代大量传感器产生的数据，不会像人机交互一样需要等待 处理结果的返回，天然适合用EDA来构建数据处理应用。

4.8.5 云原生案例

​​​​​​​某快递公司作为发展最为迅猛的物流组织之一，一直积极探索技术创新赋能商业增长之路，以 期达到降本提效的目的。 目前，该公司日订单处理量已达千万量级，亿级别物流轨迹处理量，每天 产生数据已达到TB级别，使用1300+个计算结点来实时处理业务。过往该公司的核心业务应用运行 在IDC机房，原有IDC系统帮助该公司安稳度过早期业务快速发展期。但伴随着业务体量指数级增 长，业务形式愈发多元化。原有系统暴露出不少问题，传统IOE架构、各系统架构的不规范、稳定 性、研发效率都限制了业务高速发展的可能。软件交付周期过长，大促保障对资源的特殊要求难实 现、系统稳定性难以保障等业务问题逐渐暴露。在与某云服务商进行多次需求沟通与技术验证后， 该公司最终确定云原生技术和架构实现核心业务搬迁上云。

1.解决方案

该公司核心业务系统原架构基于VMware+Oracle数据库进行搭建。随着搬迁上云，架构全面转 型为基于Kubernetes的云原生架构体系。其中，引入云原生数据库并完成应用基于容器的微服务改造是整个应用服务架构重构的关键点。
（1）引入云原生数据库。通过引入OLTP跟OLAP型数据库，将在线数据与离线分析逻辑拆分 到两种数据库中，改变此前完全依赖Oracle数据库的现状。满足在处理历史数据查询场景下Oracle 数据库所支持实际业务需求的不足。

（2）应用容器化。伴随着容器化技术的引进，通过应用容器化有效解决了环境不一致的问题， 确保应用在开发、测试、生产环境的一致性。与虚拟机相比，容器化提供了效率与速度的双重提 升，让应用更适合微服务场景，有效提升产研效率。

（3）微服务改造。由于过往很多业务是基于Oracle的存储过程及触发器完成的，系统间的服务 依赖也需要Oracle数据库OGG（OracleGoldenGate） 同步完成。这样带来的问题就是系统维护难度 高且稳定性差。通过引入Kubernetes的服务发现，组建微服务解决方案，将业务按业务域进行拆分，让整个系统更易于维护。

2.架构确立

综合考虑某快递公司实际业务需求与技术特征，该企业确定的上云架构如图4-30所示。

1）基础设施

​​​​​​​全部计算资源取自某云服务商上的裸金属服务器。相较于一般云服务器（ECS），Kubernetes 搭配服务器能够获得更优性能及更合理的资源利用率。且云上资源按需取量，对于拥有促活动等短 期大流量业务场景的某公司而言极为重要。相较于线下自建机房、常备机器云上资源随取随用。在促活动结束后，云上资源使用完毕后即可释放，管理与采购成本更低。
2）流量接入

​​​​​​​云服务商提供两套流量接入，一套是面向公网请求，另外一套是服务内部调用。域名解析采用 云DNS及Private Zone 。借助Kubernetes的Ingress能力实现统一的域名转发，以节省公网SLB的数量，提高运维管理效率。

3）平台层

​​​​​​​基于Kubernetes打造的云原生PaaS平台优势明显突出，主要包括：

●打通DevOps闭环，统一测试、集成、预发、生产环境；

●天生资源隔离，机器资源利用率高；

●流量接入可实现精细化管理；

●集成了日志、链路诊断、Metrics平台；

●统一APIServer接口和扩展，支持多云及混合云部署。

4）应用服务层

​​​​​​​每个应用都在Kubernetes上面创建单独的一个Namespace ，应用和应用之间实现资源隔离。通 过定义各个应用的配置YAML模板，当应用在部署时直接编辑其中的镜像版本即可快速完成版本升 级，当需要回滚时直接在本地启动历史版本的镜像快速回滚。

5）运维管理。

​​​​​​​线上Kubernetes集群采用云服务商托管版容器服务，免去了运维Master结点的工作，只需要制 定Worker结点上线及下线流程即可。同时业务系统均通过阿里云的PaaS平台完成业务日志搜索，按 照业务需求投交扩容任务，系统自动完成扩容操作，降低了直接操作Kubernetes集群带来的业务风 险。

3.应用效益

​​​​​​​该公司通过云原生架构的使用，其应用效益主要体现在成本、稳定性、效率、赋能业务等方 面。

（1）成本方面。使用公有云作为计算平台，可以让企业不必因为业务突发性的增长需求，而一 次性投入大量资金成本用于采购服务器及扩充机柜。在公共云上可以做到随用随付，对于一些创新 业务想做技术调研十分便捷，用完即释放，按量付费（ 中22上广）。另外云产品都免运维自行托 管在云端，有效节省人工运维成本，让企业更专注于核心业务。

（2）稳定性方面。云上产品提供至少5个9（99.999%） 以上的SLA服务确保系统稳定，而自建 系统稳定性调高很多。在数据安全方面云上数据可以轻松实现异地备份，云服务商数据存储体系下的归档存储产品具备高可靠、低成本、安全性、存储无限等特点，让企业数据更安全。
（3）效率方面。借助与云产品深度集成，研发人员可以完成一站式研发、运维工作。从业务需 求立项到拉取分支开发，再到测试环境功能回归验证，最终部署到预发验证及上线，整个持续集成 流程耗时可缩短至分钟级。排查问题方面，研发人员直接选择所负责的应用，并通过集成的SLS日 志控制台快速检索程序的异常日志进行问题定位，免去了登录机器查日志的麻烦。

（4）赋能业务。云服务商提供超过300余种的云上组件，组件涵盖计算、AI 、大数据、IoT等诸 多领域。研发人员开箱即用，有效节省业务创新带来的技术成本。

4.9 本章练习

1.选择题

（1）信息系统架构通常有

A.系统架构、数据架构、技术架构、应用架构、网络架构、安全架构

B.系统架构、数据架构、技术架构、网络架构、安全架构、云原生架构

C.系统架构、数据架构、技术架构、应用架构、网络架构、安全架构、云原生架构

D.数据架构、技术架构、应用架构、网络架构、安全架构、云原生架构 参考答案：C

（2）常用的应用架构设计原则有。

A.业务适配性原则、应用企业化原则、IT专业化原则、风险最小化原则和资产复用化原则

B.业务适配性原则、应用企业化原则、IT专业化原则、风险最小化原则 C.业务适配性原则、应用企业化原则、IT专业化原则和资产复用化原则 D.业务适配性原则、IT专业化原则、风险最小化原则和资产复用化原则 参考答案：A

（3）常用的数据架构设计原则有

A.数据分层原则、数据处理效率原则、保障数据一致性原则、服务于业务原则

B.数据分层原则、保障数据一致性原则、保证数据架构可扩展性原则

C.数据分层原则、数据处理效率原则、保障数据一致性原则

D.数据分层原则、数据处理效率原则、保障数据一致性原则、保证数据架构可扩展性原则、服 务于业务原则

参考答案：D

WPDRRC信息安全体系架构模型有个环节和大要素。

A.6 ，3 B.5 ，3 C.4 ，3 D.6 ，2

参考答案：A

（5）云原生架构原则有。

A.弹性原则、可观测原则、所有过程自动化原则、零信任原则、架构持续演进原则 B.服务化原则、弹性原则、所有过程自动化原则、零信任原则、架构持续演进原则

C.服务化原则、弹性原则、可观测原则、韧性原则、所有过程自动化原则、零信任原则、架构 持续演进原则

D.服务化原则、弹性原则、可观测原则、韧性原则、零信任原则、架构持续演进原则 参考答案：C

（6）框架是一个用于架构的概念结构。

A.规划、开发、实施、管理和维持 B.规划、开发、实施和管理

C.规划、实施、管理和维持 D.开发、实施、管理和维持

参考答案：A

（7）云原生的主要架构模式有

A.服务化架构模式、存储计算分离模式、分布式事务模式、可观测架构、事件驱动架构

B.服务化架构模式、Mesh化架构模式、Serverless模式、存储计算分离模式、分布式事务模式

C.服务化架构模式、Mesh化架构模式、Serverless模式、分布式事务模式、可观测架构、事件 驱动架构

D.服务化架构模式、Mesh化架构模式、Serverless模式、存储计算分离模式、分布式事务模 式、可观测架构、事件驱动架构

参考答案：D

（8）OSI开放系统互联安全体系包括以下类安全服务。 A.访问控制、数据机密性、数据完整性和抗抵赖性

B.鉴别、访问控制、数据机密性和数据完整性

C.鉴别、访问控制、数据机密性、数据完整性和抗抵赖性

D.鉴别、数据机密性、数据完整性和抗抵赖性 参考答案：C

（9）架构的本质是决策，是在权衡等各方面因素后进行的决策。信息系统项目可基于项目建设 的指导思想、设计原则和建设目标展开各类架构的设计。

A.方向、策略、关系以及原则 B.方向、结构、关系以及原则

C.方向、结构、方针以及原则 D.方向、结构、关系以及文化

参考答案：B

2.思考题

（1）云原生架构原则有哪些，请简述？

参考答案：略

（2）常用的数据架构设计原则有哪些，请简述？

参考答案：略

1 #include "stdio.h"
2 void main()
3 {
4     int time;
5     for (time=1;time<=10;time++)
6     printf("%d、喜欢的帮忙点赞收藏加关注哦！\n",time);
7 }