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

本文涉及的产品
应用实时监控服务ARMS - 应用监控,每月50GB免费额度
函数计算FC,每月15万CU 3个月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 阿里巴巴为大量各行各业的企业客户提供了基于阿里云服务的解决方案和最佳实践,以帮助企业完成数字化转型,并积累了大量经验和教训。阿里巴巴将企业的核心关注点、企业组织与 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 Java
云原生架构下微服务治理策略与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境下微服务架构的治理策略,通过分析当前技术趋势与挑战,提出了一系列高效、可扩展的微服务治理最佳实践方案。不同于传统摘要概述内容要点,本部分直接聚焦于治理核心——如何在动态多变的分布式系统中实现服务的自动发现、配置管理、流量控制及故障恢复,旨在为开发者提供一套系统性的方法论,助力企业在云端构建更加健壮、灵活的应用程序。 ####
50 10
|
1天前
|
Kubernetes Cloud Native API
云原生架构下微服务治理的深度探索与实践####
本文旨在深入剖析云原生环境下微服务治理的核心要素与最佳实践,通过实际案例分析,揭示高效、稳定的微服务架构设计原则及实施策略。在快速迭代的云计算领域,微服务架构以其高度解耦、灵活扩展的特性成为众多企业的首选。然而,伴随而来的服务间通信、故障隔离、配置管理等挑战亦不容忽视。本研究聚焦于云原生技术栈如何赋能微服务治理,涵盖容器编排(如Kubernetes)、服务网格(如Istio/Envoy)、API网关、分布式追踪系统等关键技术组件的应用与优化,为读者提供一套系统性的解决方案框架,助力企业在云端构建更加健壮、可维护的服务生态。 ####
|
2天前
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
8 2
|
2天前
|
弹性计算 监控 Cloud Native
云原生架构下的性能优化实践与策略####
在数字化转型加速的今天,云原生技术以其弹性、敏捷和高效的特点成为企业IT架构转型的首选。本文深入探讨了云原生架构的核心理念,通过具体案例分析,揭示了性能优化的关键路径与策略,为开发者和企业提供了可操作的实践指南。 ####
|
7天前
|
运维 Cloud Native 持续交付
云原生架构下的微服务设计原则与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境中微服务设计的几大核心原则,包括服务的细粒度划分、无状态性、独立部署、自动化管理及容错机制。通过分析这些原则背后的技术逻辑与业务价值,结合具体案例,展示了如何在现代云平台上实现高效、灵活且可扩展的微服务架构,以应对快速变化的市场需求和技术挑战。 ####
27 7
|
7天前
|
监控 Cloud Native 持续交付
云原生架构下微服务的最佳实践与挑战####
【10月更文挑战第20天】 本文深入探讨了云原生架构在现代软件开发中的应用,特别是针对微服务设计模式的最优实践与面临的主要挑战。通过分析容器化、持续集成/持续部署(CI/CD)、服务网格等关键技术,阐述了如何高效构建、部署及运维微服务系统。同时,文章也指出了在云原生转型过程中常见的难题,如服务间的复杂通信、安全性问题以及监控与可观测性的实现,为开发者和企业提供了宝贵的策略指导和解决方案建议。 ####
30 5
|
5天前
|
监控 Cloud Native 测试技术
云原生架构下的性能优化与实践####
【10月更文挑战第21天】 本文深入探讨了在云原生环境下,如何通过一系列技术手段和最佳实践来提升应用性能。文章首先概述了云原生架构的基本原则与优势,随后详细分析了影响性能的关键因素,包括容器编排、微服务设计、持续集成/持续部署(CI/CD)流程以及监控与日志管理。针对这些因素,文中不仅介绍了具体的优化策略,如资源请求与限制的合理配置、服务间通信的高效实现、自动化测试与部署的优化,还结合案例分析,展示了如何在实际项目中有效实施这些策略以显著提升系统响应速度和处理能力。此外,文章还强调了性能测试的重要性,并提供了几种常用的性能测试工具和方法。最后,总结了云原生性能优化的未来趋势,为开发者和架构师
11 2
|
6天前
|
Kubernetes Cloud Native 持续交付
云原生架构下的微服务设计原则与最佳实践##
在数字化转型的浪潮中,云原生技术以其高效、灵活和可扩展的特性成为企业IT架构转型的首选。本文深入探讨了云原生架构的核心理念,聚焦于微服务设计的关键原则与实施策略,旨在为开发者提供一套系统性的方法论,以应对复杂多变的业务需求和技术挑战。通过分析真实案例,揭示了如何有效利用容器化、持续集成/持续部署(CI/CD)、服务网格等关键技术,构建高性能、易维护的云原生应用。文章还强调了文化与组织变革在云原生转型过程中的重要性,为企业顺利过渡到云原生时代提供了宝贵的见解。 ##
|
6天前
|
运维 Cloud Native API
云原生时代下的微服务架构实践
【10月更文挑战第22天】在数字化转型的浪潮中,云原生技术正以前所未有的速度重塑软件开发和运维的模式。微服务架构作为云原生的重要组成部分,其设计哲学、技术栈选择以及与传统单体应用的根本区别成为了现代软件工程讨论的焦点。本文将深入探讨微服务架构的核心概念,通过实际案例分析其在云平台下的应用,并分享在实施过程中的经验教训,旨在为读者提供一套清晰的微服务架构实践指南。
|
1天前
|
缓存 资源调度 Cloud Native
云原生架构下的性能优化实践与策略####
【10月更文挑战第26天】 本文深入探讨了云原生环境下性能优化的核心原则与实战技巧,旨在为开发者和企业提供一套系统性的方法,以应对日益复杂的微服务架构挑战。通过剖析真实案例,揭示在动态扩展、资源管理、以及服务间通信等方面的常见瓶颈,并提出针对性的优化策略,助力企业在云端环境中实现更高效、更稳定的应用部署。 ####
5 0