云原生架构应该怎么设计?

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
云原生网关 MSE Higress,422元/月
简介: 阿里巴巴为大量各行各业的企业客户提供了基于阿里云服务的解决方案和最佳实践,以帮助企业完成数字化转型,并积累了大量经验和教训。阿里巴巴将企业的核心关注点、企业组织与 IT 文化、工程实施能力等多个方面与架构技术相结合,形成了阿里巴巴独有的云原生架构设计方法— ACNA(Alibaba Cloud Native Architecting )

头图.jpg

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.png
图 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.pngimage.png
图 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)。

3.png
图 3 ACNA-T1:云原生架构成熟度模型:关键指标维度

结合云原生架构的四个不同成熟阶段,我们定义了整个架构的成熟度模型,如图 4 所示。

4.png
图 4 云原生架构成熟度模型

评估模型的实施指导和工作表

评估模型实施指导的整个工作流程(命名为 ACNA-T2)如表 5 所示。

表5 ACNA-T2:云原生架构评估模型实施指导的工作流程
5.png

为了统一 ACNA 评估模型的产出,我们给出了统一的《云原生架构评估表》(命名为 ACNA-T3 ),以让用户对结果有一致的认知,如表 6 所示。

表6 ACNA-T3:云原生架构评估表
6.png

服务化能力的评估

服务化能力的评估(命名为 ACNA-T4-1)如表 7 所示。

表 7 ACNA-T4-1:服务化能力评估表
7.png

弹性能力的评估

弹性能力的评估(命名为 ACNA-T4-2)如表 8 所示。

图8 ACNA-T4-2:弹性能力评估表
8.png

无服务器化程度的评估

无服务器化(Serverless)程度的评估(命名为 ACNA-T4-3)如表 9 所示。

表9 ACNA-T4-3:无服务器化程度评估表
表9.png

可观测性的评估

可观测性的评估(命名为 ACNA-T4-4)如表 10 所示。

表10 ACNA-T4-4:可观测性评估表
10.png

韧性能力的评估

韧性能力的评估(命名为 ACNA-T4-5)如表 11 所示。

表11 ACNA-T4-5:韧性能力评估表
11.png

自动化能力的评估

自动化能力的评估(命名为 ACNA-T4-6)如表 12 所示。

表12 ACNA-T4-6:自动化能力评估表
12.png

更多信息

13.png

《阿里云云原生架构实践》由阿里云官方出品,阿里云智能总裁张建锋、阿里巴巴首席技术官程立联袂推荐;从设计原则、模式/反模式、技术选项、设计方法、行业案例等多个维度全面总结阿里云云原生架构的方法论和实践经验。

相关实践学习
【文生图】一键部署Stable Diffusion基于函数计算
本实验教你如何在函数计算FC上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。函数计算提供一定的免费额度供用户使用。本实验答疑钉钉群:29290019867
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
相关文章
|
7天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
8天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
10天前
|
消息中间件 存储 Cloud Native
云原生架构下的数据一致性挑战与应对策略####
本文探讨了在云原生环境中,面对微服务架构的广泛应用,数据一致性问题成为系统设计的核心挑战之一。通过分析云原生环境的特点,阐述了数据不一致性的常见场景及其对业务的影响,并深入讨论了解决这些问题的策略,包括采用分布式事务、事件驱动架构、补偿机制以及利用云平台提供的托管服务等。文章旨在为开发者提供一套系统性的解决方案框架,以应对在动态、分布式的云原生应用中保持数据一致性的复杂性。 ####
|
6天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
29 5
|
8天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
22 5
|
8天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
8天前
|
消息中间件 缓存 Cloud Native
云原生架构下的性能优化实践与挑战####
随着企业数字化转型的加速,云原生架构以其高度解耦、弹性伸缩和快速迭代的特性,成为现代软件开发的首选模式。本文深入探讨了云原生环境下性能优化的关键策略与面临的主要挑战,通过案例分析,揭示了如何有效利用容器化、微服务、动态调度等技术手段提升应用性能,同时指出了在复杂云环境中确保系统稳定性和高效性的难题,为开发者和架构师提供了实战指南。 ####
21 3
|
8天前
|
运维 Kubernetes Cloud Native
深入理解云原生架构:从理论到实践
【10月更文挑战第38天】本文将引导读者深入探索云原生技术的核心概念,以及如何将这些概念应用于实际的软件开发和运维中。我们将从云原生的基本定义出发,逐步展开其背后的设计哲学、关键技术组件,并以一个具体的代码示例来演示云原生应用的构建过程。无论你是云原生技术的初学者,还是希望深化理解的开发者,这篇文章都将为你提供有价值的见解和实操指南。
|
8天前
|
Kubernetes Cloud Native 持续交付
云原生技术在现代应用架构中的实践与思考
【10月更文挑战第38天】随着云计算的不断成熟和演进,云原生(Cloud-Native)已成为推动企业数字化转型的重要力量。本文从云原生的基本概念出发,深入探讨了其在现代应用架构中的实际应用,并结合代码示例,展示了云原生技术如何优化资源管理、提升系统弹性和加速开发流程。通过分析云原生的优势与面临的挑战,本文旨在为读者提供一份云原生转型的指南和启示。
22 3
|
8天前
|
运维 Kubernetes Cloud Native
云原生技术在现代应用架构中的实践与挑战####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在实际项目中的应用案例,分析了企业在向云原生转型过程中面临的主要挑战及应对策略。不同于传统摘要的概述性质,本摘要强调通过具体实例揭示云原生技术如何促进应用的灵活性、可扩展性和高效运维,同时指出实践中需注意的技术债务、安全合规等问题,为读者提供一幅云原生技术实践的全景视图。 ####