云原生架构实施路线趋势分析

云原生架构实施路线趋势分析

【导读】云原生架构体系内容众多，建设做不到一步到位，彼此之间也

存在着先后次序相关性，需要通过一系列项目持续完成相关的能力，从而实现

云原生融合架构。本文分享了根据云原生架构体系中技术之间的关系和实际经

验，基于“顶层规划+分步实施”的原则，定义为5个步骤的云原生架构实施路

线图。通过本文能够相对深入的理解云原生架构为系，并为企业实际做出顶层

规划提供启发。

云原生架构体系内容众多，如果深入到微服务、容器、DevOps、服务网格

ServiceMesh＞自服务敏捷基础设施、混沌工程、安全等任何一项内容都有缎多

的工作需要做。比如说微服务，一套SpringCloud开发框架就需要很多的学习

成本，更别说还有很多其他的框架、方法和思想，比如微服务的拆分领域驱动

设计DDD方法等。

云原生这么多的内容做不到一步到位，而且彼此之间也存在着先后次序相关

性，它需要通过一系列的项目持续完成相关的能力，从而实现云原生融合架

构。由于云原生架构体系内容众多，需要对其有相对深入的理解并能根据企业

实际做出实施顶层规划，然后以分步实施的方法边建设边交付价值，使整个体

系建设具备可持续性。

图1云原生融合架构实施步骤

根据云原生架构体系中技术之间的关系和实际经验，基于“顶层规划+分步实

施”的原则，云原生架构实施路线图我们定义为5个步骤：

1.微服务采用及运行环境容器云平台构建；

2.服务管理和治理；

3.持续交付及安全；

4.自服务敏捷向基础设施建设；

5.增强生产环境韧性和安全性。

每个实施步骤又可以根据实际建设需要分为若干个子项目，并可能需要多次迭

代。比如说，步骤一微服务采用及运行环境构建，容器云平台建设和系统微服

务架构采用可能需要分别以不同的项目立项。容器云平台作为基础设施平台，

可能还需要规划采购服务器、存储、网络设备等，也可能需要根据微服务系统

改造进度持续进行采购。微服务的设计开发就是个持续的过程，可能涉及不同

系统的新建或改造重构。同时呢，也可能需要前期的咨询、规划指导和培训

等。不同的单位实际情况不同，所采取的步骤和方式也会不同。

1.步骤一：微服务采用及运行环境构建

云原生架构体系中，应用是交付业务价值的载体，而微服务是构建业务应用的

技术。经微服务架构分解的应用服务运行在容器中。所以第一步在采用微服务

的同时需要构建容器环境支撑微服务的运行。

基于容器技术和容器调度管理技术如Kubernetes构建企业内私有容器云平台支

撑微服务应用系统的部署、运行和管理，实现微服务运行时环境支持，基于容

器云平台可以实现相关的自服务敏捷能力，比如弹性扩展、服务路由、分发限

流、健康检查、错误隔离、故障恢复、资源调度等。

以云应用12或15要素为指导设计微服务。当前微服务分拆的方式通常是基于

领域驱动设计（DDD）方法。不过DDD对业务领域的划分往往难以清晰定义领

域边界，存在着领域划分不合理、数据同时存在于不同领域的问题，为每个服

务选择合适的责任级别及其范围是困难的，需要极深的经验和对业务的理解。

因此MartinFlcwl”.建议可以先建一个传统的大一统系统，在对领域知识有更

好的了解以后，再通过重构将其改造成微服务。笔者觉得DDD通过领域划分可

以在一定程度上简化业务关系，从而简化微服务没计，但领域划分也使每个领

域缺乏全局认识，所以DDD更像是一种分类简化的设计方法，这会造成多次的

重复迭代，造成浪费。而MartinFlowler的建议则使DDD有了全局的视角，能

够从上到下，全局来看到领域划分和设计，但这个大一统系统并不容易建设。

笔者基于实践提出了“主数据驱动设计”的微服务设计方法，主数据本来就是

系统间共享的高价值数据，基于企业主数据设计的微服务天然具备系统间的可

重用性。而且基于行业通用数据模型(CommonDataModel,CDM)则很容易定义

并完善主数据微服务，减少重复的迭代设计和实现°

2.步骤二：服务管理和治理

微服务架构在分解应生的同时也带来了微服务数量的成倍增长，使服务的管理

和治理难以通过人工完成。随着微服务量的增加，需要完善服务的管理和治理

能力。在完成容器云平台运行时支撑建设之后，可以侧重实现服务的治理和

API的定义，以支持高效的管理和敏捷的服务编排响应，同时实现基于API的

协同。

微服务治理有多种实现的方法。基于容器云平台可以直接利用k8s的能力实现

服务的注册发现、配置、路由分发、负载均衡、弹性扩容等，不过容器云平台

要作为企业级应用支撑平台，需要在Kubernetes之上扩展实现服务的管理和治

理能力。CNCF推荐用ScrviccMesh,代理东西向流量，支持跨语言。Porvital

的SpringClond框架提供了相对完整的服务治理实现，比如服务的注册发

现、配置、熔断、客户端负载均衡等，但仅支持Java；等等有众多的框架和技

术。微服务架构提出的一个主要目的就是通过API来屏蔽开发语言，无论用什

么开发语言，只要遵循同样的API,都可以进行办同。其实这类似于地球上不

同国家之间的交流，通过相互可以理解的公共语言就可以对话。因此在实现服

务治理时需要考虑跨平台能力以及对内和对外API服务能力。这里要区分r微

服务的API和对外的OponAPI,可以看作是两人层次。OpcnAPI通常是跨平

台、跨企业的，用于构建生态系统，不过企业内部也可以用于构建企业内部生

态。思想都是一样。

云原4以APT为协同方式，因此在公司内部可以实现容器云平台和APT网关两

层的服务治理能力。同一个微服务可以通过API网关暴露为不同的API,或者

也可以多个微服务暴露为一个APEAPI既可以面向企业内部，也可以面向外

部生态伙伴。

3.步骤三：持续交付及安全

前两个步骤完成了微服务运行运营的基础能力，具备了支撑微服务弹性扩展、

协同交互的能力。有了部署运维平台和服务管理治理能力，则就可以侧重提升

研发端的持续交付能力.这样，无论开发多少微服务，在服务管理和治理方面

也就没有了后顾之忧。以DevOps理论为指导，构建持续集成、持续部署、持续

交付、持续监控、持续反馈的闭环流程。

兵马未动，粮草先行，之所以要先建设容器云平台和服务管理治理能力，就是

要提前准备好在应用微服务化、分布式微服务量的爆炸增长，具备支撑弹性伸

缩、可视化、可观察性、故障隔离、容错、故障自恢复等能力。这样才能支持

各个团队的持续交付要求。这也是我们一直提倡先着力构建微服务运行支撑环

境的重要原因。

DevOps一种思想和方法论，其核心是协作反馈，只有及时的反馈才能反思和改

进。利用DcvOps思想构建持续交付能力的过程二，会涉及组织架构的优化，

这可能是一个难点。首先组织领导要能够理解DevOps思想和理念，知道组织

的弱点并愿意尝试改进；其次，DevOps体系（DevOps体系可能不仅仅是一个

平台）可能涉及众多的组件和工具，或者需要一体化的设计研发，每种方式

都会花器大量人力和时间"比如说用开源工具，持续集成和持续交付流程涉及

开发、源码管理、源码检查、单元测试、用例管理、构建、安全测试、交付管

理等众多的工具，仅考虑打通这些工具的认证权限管理，就不是一件容易的

事。因此有些DevOps厂商直接自研持续集成、持续交付等流水线。如果具备这

样的研发能力，笔者建议尽可能自研或者合作研发，这也是为系统融合打好基

础，避免众多的开源第三方工具带来众多的集成问题，难以有效融合在一起。

认证和权限是DevOps体系中的基础安全措施。代码安全检查、镜像安全检查、

系统安全、应用安全、接口安全、容器安全等等都需要在DevOps工具链和流

水线实施和使用过程中逐步完善，以提升云原生的整体安全性。

4.步骤四：自服务敏捷响应基础设施

基础设施在第一步搭建容器云平台和微服务的时候就会用到，只不过这个阶段

微服务量相对较少，对由服务敏捷响应基础设施.殳有迫切需求。随着持续交付

能力的提升，微服务量的增长，运维能力需要从量变演化到质变。自动化、自

服务敏捷响应能力提上日程。

基础设施大致可以划分为三个部分：基础设施资源、支撑平台和纯技术工具。

基础设施资源可能有很多种异构资源和云平台，需要通过统一的层次（比如多

云管理平台）来封装，提供统一的基础设施资源服务，隔离底层异构资源细

节，简化应用资源调度。支撑平台主要是微服务开发、运行、运维的平台，例

如持续交付平台、容器云平台等。纯技术工具指的是和业务无关、围绕支堂平

台周边的工具，比如消息平台（RabbitMQ、Kafka）、监控平台、权限管理平

台、认证平台、人脸识别平台等等°这些平台可以提取构建技术中台能力，存

业务应用都可以复用这些能力。

在实施持续交付的同时，也是在部分构建自服务敏捷响应基础设施能力，比如

持续集成、持续交付流水线等。在这个步骤，需要重点构建和完善自动化、自

服务的基础设施能力，包括统一身份认证和权限服务、日志服务、配置服务、

监控服务、告警服务、安全服务、AI服务（人脸识别、文字识别、图像识别、

语音识别、自然语言处理、知识图谱、算法等）、消息服务、调度服务等基础

服务和CICD研发流程服务等。实现这些服务的自服务能力是构建应用敏捷响

应的关键。

基础设施资源的自服务敏捷响应是所有这些服务的实现敏捷响应的前提。由于

基础设施资源多种多样，可能来自不同的厂商品牌、不同的型号、不同的架

构、不同的协议、不同的云平台等等，为基础设施资源的融合管理和敏捷响应

带来了挑战。需要考虑构建统一的基础设施资源管理平台或多云管理平台来提

供统一的基础设施资源服务，封装底层资源细节，提升资源交付效率。

这个过程中，组织架构可以同步调整，比如基础-殳施资源团队来运维运营基础

设施资源，为平台和工具提供资源服务；平台团队来运维运营平台，工具团队

来持续研发工具和技术中台服务，支撑以应用管涯为中心的架构；应用研发团

队专注于业务应用微服务的研发，使用自服务的资源、平台、工具实现服务的

研发、测试、部署、运行、运维等全生命周期管理。

5.步骤五：增强生产环境韧性和安全性

脆弱性的反面是健壮性、韧性。抗脆弱性(或反脆弱性，Antifragility)的

目的就是持续定时或不定时通过在运行环境中注入故障的方式来主动的找到弱

点，并强制修复这些弱点，从而提升环境的健壮畦和韧性。以人类免疫系统为

例，当受到病毒侵害时，人体的免疫系统就会自动做出反应，会变得更强；而

当人被隔离时，免疫系统会变得更弱。用人类免疫系统的思想来构建云原生架

构的韧性，以抵御不同场景下的故障。NetflixSimianArmy项目有个著名的

子模块“混沌猴(ChaosMonkey)”，它将随机故障注入生产组件，目的是识

别和消除体系结构中的弱点。通过明确查找应用程序体系结构中的弱点、注入

故障并强制进行补救，体系结构自然会随着时间的推移收敛到更高的安全程

度。因此可以