云原生架构应该怎么设计？-51CTO.COM

ACNA 的概念

阿里巴巴为大量各行各业的企业客户提供了基于阿里云服务的解决方案和最佳实践，以帮助企业完成数字化转型，并积累了大量经验和教训。阿里巴巴将企业的核心关注点、企业组织与 IT 文化、工程实施能力等多个方面与架构技术相结合，形成了阿里巴巴独有的云原生架构设计方法— ACNA（Alibaba Cloud Native Architecting ）。这套方法在阿里云官方最近出版的畅销书《阿里云云原生架构实践》中有更详尽的介绍。

（1）ACNA 的作用与目的

1）提升研发团队的能力，实现成本、进度计划、功能和质量等目标。
2）指导研发团队控制研发和运维过程，优化 IT 组织结构并打造更加高效的软件工程流程机制。
3）引导研发团队，在确定云原生架构的成熟度以及定位云原生化方面关键问题的过程中选择改进策略。

（2）ACNA 的实现步骤

1）确定企业当前所处的云原生架构成熟度级别。
2）了解会对改进生产质量和优化过程起关键作用的因素。
3）将工作重点集中在有限的几个关键目标上，从而有效达到优化现有研发流程的效果，进而持续改进产品。
ACNA 是一个“ 4+1 ”的架构设计流程，其中，“ 4 ”代表架构设计的关键视角，包括企业战略视角（ACNA-S1）、业务发展视角（ACNA-S2）、组织能力视角（ACNA-S3）和云原生技术架构视角（ACNA-S4）；“ 1 ”表示云原生架构的架构持续演进闭环（ACNA-S5）。4 个关键视角和 1 个闭环的关系（命名为 ACNA-G1 ），如图 1 所示。

图 1 ACNA-G1：ACNA 架构设计流程关系示意图

ACNA 除了是一种架构设计方法，还包含对云原生架构的评估体系、成熟度衡量体系、行业应用最佳实践、技术和产品体系、架构原则、实施指导等。本书的其他章节将分别详细讲解云原生的技术和产品体系、架构原则、最佳实践等方面，这里主要介绍云原生架构的成熟度衡量体系和实施指导两个方面。

ACNA-S1：企业战略视角

任何架构都必须服务于企业战略，云原生架构也不例外！与以往架构的升级有所不同，云原生架构的升级不仅是技术的升级，更是对企业核心业务生产流程（即通过软件开发和运营构建数字化业务）的一次重构，云原生架构升级的意义，如同工业时代用更自动化的流水线替换手工作坊一样深刻。

企业必须清楚业务战略与云 IT 战略之间的关系，即云 IT 战略只是对业务战略进行必要的技术支撑，还是云 IT 战略本身也是业务战略的一部分。通常，高科技公司会对云计算提出更高的需求，比如，通过大量使用云厂商提供的 AI 技术为用户提供智能化的用户体验，以及使用 IoT（物联网）和音视频技术为用户建立更广泛、生动的连接。

实际上，在数字化转型的今天，越来越多的企业认为云 IT 战略应该在企业业务战略中扮演技术赋能业务创新的重要角色，云 IT 已经变成了“ Cloud First ”，甚至“ Cloud Only ”，只是在全部采用公有云还是采用混合云的策略上存在一些差别。基于云 IT 战略，云原生架构可以帮助企业实现泛在接入技术，构建数字化生态系统，还可以从技术的角度确保数字化业务的快速迭代，构建面向用户体验管理的数字基础设施，持续优化 IT 成本，降低业务风险。

ACNA-S2：业务发展视角

阿里巴巴在为企业提供云服务和咨询的过程中发现，数字化业务对技术架构的主要诉求是保证业务连续性、业务快速上线、业务成本控制，以及科技赋能业务创新。业务连续性诉求主要是指数字化业务必须能够为用户持续提供服务，不能因为软硬件故障或 Bug 导致业务不可用，还要能够防止黑客攻击、数据中心不可用、自然灾害等意外事故发生。此外，当业务规模快速增长时，软硬件资源的购买和部署一定要及时，以便企业能够更好地拓展新用户。

市场瞬息万变，相较于传统业务，数字化业务具有更灵活的特性，这就要求企业具备更快的“业务到市场”的能力，包括新业务快速构建、现有业务快速更新等。云原生架构能够深刻理解企业对这些能力的诉求，并在产品、工具、流程等多个层面进行不同程度的处理。需要注意的是，这些诉求同时对组织结构带来新的要求，可能会要求应用进行彻底重构（比如微服务化）。

云计算必须为企业释放成本红利，帮助企业从原来的 CaPex 模式转变为 OpEx 模式，即不用事先购买大批软硬件资源，而是用多少支付多少；同时，大量采用云原生架构也会降低企业的开发和运维成本。有数据显示，通过容器平台技术可使运维支出成本降低 30%。

传统模式下，如果要使用高科技赋能业务，则会经历一个冗长的选型、POC、试点和推广的过程，而如果选择使用云厂商和第三方提供的云服务，则可以更快速地应用新技术进行创新。因为这些云服务具备更快的连接速度和更低的试错成本，且在不同技术的集成上具备统一平台和统一技术依赖的优势。

ACNA-S3：组织能力视角

云原生架构升级是对企业的整个 IT 架构的彻底升级，每个组织在进行云原生架构升级时，必须根据企业自身的情况量体裁衣，其中，组织能力和技术栈处于同等重要的地位。云原生架构涉及的架构升级对企业中的开发、测试和运维等相关人员都带来了巨大的影响，技术架构的升级和实现需要企业中相关组织的积极参与和配合。特别是在架构持续演进的过程中，需要类似“架构治理委员会”这样的组织负责云原生的规划和落地，并不断检查和评估架构设计与执行之间是否存在偏差。

此外，云原生架构的设计还需要考虑组织结构的改变。前面提到一个非常重要的云原生架构原则就是服务化（包括微服务、小服务等），这个领域的一个典型原则就是康威定律，要求企业的技术架构与沟通架构必须保持一致，否则会导致畸形的服务化架构，甚至导致组织沟通成本上升和“扯皮”现象增多的问题。

企业需要考虑的另外一个很重要的问题就是，企业接受改变的程度如何，或者说，企业能够快速进行组织结构调整，并保持业务稳定性的能力如何。云原生架构升级要求大量的企业 IT 人员也进行技术体系的升级和岗位职能的重新设计，这势必导致原本处于稳定和舒适区的技术领导者和底层员工必须破而再立，所以组织改变的风险不得不慎重考虑。

ACNA-S4：云原生技术架构视角

从技术架构的维度看，ACNA 认为架构维度包含七个重要的领域，具体说明如下。

（1）服务化能力
用微服务或小服务构建业务，分离大块业务中具备不同业务迭代周期的模块，业务以标准化 API 等方式对模块进行集成和编排；服务间采用事件驱动的方式集成，减少相互依赖；通过可度量建设不断提升服务的 SLA（Service Level Agreement，服务等级协议）能力。

（2）弹性能力
利用云资源的特性，根据业务峰值和资源负载情况来自动扩充或收缩系统的规模，业务不再需要进行容量评估、按量付费。

（3）无服务器化程度
在业务中，应尽量使用云服务，而不是自己持有第三方服务，特别是自己维护开源软件的模式；应用的设计应尽量变换成无状态模式，把有状态的部分保存到云服务中。进一步采用 Serverless 技术体系重构应用运行时，让软件的底层运维逐渐“消失”。

（4）可观测性
IT 设施需要得到持续治理，任何 IT 设施中的软硬件发生错误后都要具备快速修复的能力，以避免影响业务，这就需要系统具备全面的可观测性，内容涉及对传统的日志方式、监控、APM、链路跟踪、服务质量（Quality of Service，QoS）度量等多个方面。

（5）韧性能力
韧性能力除了包括服务化中常用的熔断、限流、降级、自动重试、背压等特性之外，还包括高可用、容灾、异步化等特性。

（6）自动化水平
关注开发、测试和运维三个过程的敏捷性，推荐使用容器技术自动化软件构建过程、使用 OAM 标准化软件交付过程、使用 IaC（Infrastructureas Code ，基础设施即代码）和 GitOps 等自动化 CI/CD 流水线和运维过程。

（7）安全能力
关注业务的数字化安全，在利用云服务加固业务运行环境的同时，采用安全软件生命周期开发，使应用符合 ISO27001、PCI/DSS、等级保护等安全要求。安全能力是基础维度，要求在架构评测中关注，但它不会参与评分。

ACNA-S5：架构持续演进闭环

云原生架构演进是一个不断迭代的过程，每一次迭代都要经历从企业战略、业务诉求到架构设计与实施这样一个完整的闭环，整体关系（命名为 ACNA-G2）如图2所示。

图 2 ACNA-G2：架构持续演进闭环

下面就来详细介绍架构持续演进闭环的关键输入和实现过程。

1. 关键输入

1）企业战略视角（ACNA-S1）：包括数字化战略诉求、技术战略（特别是云战略）诉求、企业架构诉求等，建议量化描述创新效率提升百分比、IT 成本降低值、风险成本降低值等。

2）业务发展视角（ACNA-S2）：包括新业务（特别是数字化业务）的技术诉求、BI/AI（商业智能 / 人工智能）诉求、IoT（物联网）诉求、用户体验诉求等，建议量化描述业务迭代速度提升值、用户体验改善百分比、业务开发效率提升百分比等。

2. 关键过程

1）识别业务痛点和架构债务（ACNA-S5-P1）：明确并量化业务痛点（比如，云上云下一套部署、端到端的可观测性等）；技术债务依据各企业的具体情况而有所不同，通常包含容器化改造、CI/CD 完善、微服务改造、老应用下线、遗留系统集成方案、非 x86 架构的转移等。

2）确定架构迭代目标（ACNA-S5-P2）：建议每次迭代不超过 1 年，并通过 OKR（ObjectiveandKey Result，目标与关键成果法）的方式，在目标中描述本次迭代的业务目标，在关键成果中量化业务价值和技术价值。注意，在确定迭代目标的时候，要充分识别架构升级的利益相关者（Stakeholder）及其价值诉求，避免出现项目很成功但是得不到业务方认同的情况。

3）评估架构风险（ACNA-S5-P3）：风险和价值往往是一对矛盾体，不要因为风险大而不做云原生架构升级，也不要因为迫切升级而忽视风险，建议在风险和价值间获得平衡。P3 阶段的重点是识别风险类别和风险点，它们会根据企业所在行业和企业自身特性的不同而不同。风险类别通常包括组织风险、市场风险、技术风险、设计实现风险、实施落地风险、运维风险、IT 文化风险、财务风险、数据风险、合规风险等。

4）选取云原生技术（ACNA-S5-P4）：P4 阶段需要从云原生技术栈中选取在本次迭代中需要采用的云原生技术，也需要把采用该技术可能造成的风险和带来的价值放在首位考虑。

5）制订迭代计划（ACNA-S5-P5）：P5 阶段需要充分考虑是否每个里程碑都能够得到各参与方的认同，一定要避免先闭门开发然后期望产出一个高价值产品的情况，因为像云原生架构升级这样的项目，需要与各参与方深度合作，且在执行过程中很可能出现改变计划和目标的情况。

6）架构评审和设计评审（ACNA-S5-P6）：P6 阶段作为改变企业整个生产流水线的重要架构升级，需要在技术上进行架构评审和重要设计评审，让重要设计在各参与方之间得到认同，这也是减少整体风险的重要手段。

7）架构风险控制（ACNA-S5-P7）：在 P3 阶段确定了风险点之后，就需要马上设定这些风险的监控方法和预警阈值，并在架构升级的过程中不断监控这些阈值的变化情况，做到实时风险评估和预警。整体而言，在整个实施过程中，企业需要建立“识别—监控—评估—预警—改进”的风控闭环。

8）迭代验收和复盘（ACNA-S5-P8）：为了让云原生架构升级的下一个迭代取得成功，即使本次迭代已经成功验收，也需要团队客观、深入地对本次迭代的得失进行复盘，特别是在组织能力、项目和产品的管理能力等软技能。

云原生架构成熟度模型

云原生架构成熟度模型是一种能够帮助企业找到当前软件架构与成熟的云原生架构之间的差距，从而在后续的架构优化迭代中进行针对性改善的评估模型。ACNA 参考 CMM（Capability Maturity Model，能力成熟度模型）的定义，从主要的架构维度定义了云原生架构的成熟度模型。我们需要注意到，ACNA 的云原生架构成熟度评估模型不会帮助企业从通用技术架构、应用架构或信息架构的维度进行评估，因此它并没有帮助实施者梳理架构的核心利益相关者和架构交付合同。同时，评估模型本身也没有对团队核心人员技能以及组织的流程、文化和流水线建设进行评估，而是从基于云的现代化应用这一特定的软件技术架构进行评估。虽然这样的评估范围相对较小，但是更专业，可操作性更强。

此外，ACNA 云原生架构成熟度模型的评估对象不是企业或架构实施人员，而是某个具体软件所采用的架构。因此，对于一个企业而言，可能部分软件的评估结果是零级（初始级），部分软件的评估结果是中级（发展级），这完全取决于每个软件自身的架构情况。

6 个评估维度

ACNA 云原生架构设计共包含 6 个关键架构维度（Service + Elasticity + Serverless + Observability + Resilience + Automation，简写为 SESORA），在此我们先定义关键维度的成熟度级别，如图 3 所示（命名为 ACNA-T1）。