媒介：体系集成项目管理工程师专业，现分享一些课本知识点。以为文章还不错的喜欢点赞收藏的同时帮忙点点关注。
软考同样是国家人社部和工信部构造的国家级考试，全称为“天下计算机与软件专业技能资格（水平）考试”，现在涵盖了计算机软件、计算机网络、计算机应用技能、信息体系、信息服务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 }
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
