云原生架构体系内容众多，建设做不到一步到位，彼此之间也存在着先后次序相关性，需要通过一系列项目持续完成相关的能力，从而实现云原生融合架构。本文分享了根据云原生架构体系中技术之间的关系和实际经验，基于“顶层规划+分步实施”的原则，定义为5个步骤的云原生架构实施路线图。通过本文能够相对深入的理解云原生架构体系，并为企业实际做出顶层规划提供启发。

　　上篇《 你需要知道的云原生架构体系内容 》（点击标题可阅读）中对云原生架构体系内容进行了介绍，云原生架构体系内容众多，如果深入到微服务、容器、 DevOps、服务网格ServiceMesh、自服务敏捷基础设施、混沌工程、安全等任何一项内容都有很多的工作需要做。比如说微服务，一套SpringCloud开发框架就需要很多的学习成本，更别说还有很多其他的框架、方法和思想，比如微服务的拆分领域驱动设计DDD方法等。

　　云原生这么多的内容做不到一步到位，而且彼此之间也存在着先后次序相关性，它需要通过一系列的项目持续完成相关的能力，从而实现云原生融合架构。由于云原生架构体系内容众多，需要对其有相对深入的理解并能根据企业实际做出实施顶层规划，然后以分步实施的方法边建设边交付价值，使整个体系建设具备可持续性。

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

　　根据云原生架构体系中技术之间的关系和实际经验，基于“顶层规划+分步实施”的原则，云原生架构实施路线图我们定义为5个步骤：

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

　　2 . 服务管理和治理；

　　3 . 持续交付及安全；

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

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

　　每个实施步骤又可以根据实际建设需要分为若干个子项目，并可能需要多次迭代。比如说，步骤一微服务采用及运行环境构建，容器云平台建设和系统微服务架构采用可能需要分别以不同的项目立项。容器云平台作为基础设施平台，可能还需要规划采购服务器、存储、网络设备等，也可能需要根据微服务系统改造进度持续进行采购。微服务的设计开发就是个持续的过程，可能涉及不同系统的新建或改造重构。同时呢，也可能需要前期的咨询、规划指导和培训等 。不同的单位实际情况不同，所采取的步骤和方式也会不同。

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

　　云原生架构体系中，应用是交付业务价值的载体，而微服务是构建业务应用的技术。经微服务架构分解的应用服务运行在容器中。所以第一步在采用微服务的同时需要构建容器环境支撑微服务的运行。

　　基于容器技术和容器调度管理技术如Kubernetes构建企业内私有容器云平台支撑微服务应用系统的部署、运行和管理，实现微服务运行时环境支持，基于容器云平台可以实现相关的自服务敏捷能力，比如弹性扩展、服务路由、分发限流、健康检查、错误隔离、故障恢复、资源调度等。

　　以云应用12或15要素为指导设计微服务。当前微服务分拆的方式通常是基于 领域驱动设计（DDD）方法。不过DDD 对业务领域的划分往往难以清晰定义领域边界，存在着领域划分不合理、数据同时存在于不同领域的问题，为每个服务选择合适的责任级别及其范围是困难的，需要极深的经验和对业务的理解。因此Martin Flowler建议可以先建一个传统的大一统系统，在对领域知识有更好的了解以后，再通过重构将其改造成微服务。笔者觉得DDD通过领域划分可以在一定程度上简化业务关系，从而简化微服务设计，但 领域划分也使每个领域缺乏全局认识，所以DDD更像是一种分类简化的设计方法， 这会造成多次的重复迭代，造成浪费。而Martin Flowler的建议则使DDD有了全局的视角，能够从上到下，全局来看到领域划分和设计，但这个大一统系统并不容易建设。

　　笔者基于实践提出了“主数据驱动设计”的微服务设计方法，主数据本来就是系统间共享的高价值数据，基于企业主数据设计的微服务天然具备系统间的可重用性。而且基于行业通用数据模型(Comm on Data Model，CDM)则很容易定义并完善主数据微服务，减少重复的迭代设计和实现。

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

　　微服务架构在分解应用的同时也带来了微服务数量的成倍增长，使服务的管理和治理难以通过人工完成。随着微服务量的增加，需要完善服务的管理和治理能力。在完成容器云平台运行时支撑建设之后，可以侧重实现服务的治理和 API的定义，以支持高效的管理和敏捷的服务编排响应，同时实现基于 API的协同。

　　微服务治理有多种实现的方法。基于容器云平台可以直接利用k 8s的能力实现服务的注册发现、配置、路由分发、负载均衡、弹性扩容等，不过容器云平台要作为企业级应用支撑平台，需要在Kubernetes之上扩展实现服务的管理和治理能力。CNCF推荐用 ServiceMesh，代理东西向流量，支持跨语言。Porvital的 SpringClou d框架提供了相对完整的服务治理实现，比如服务的注册发现、配置、熔断、客户端负载均衡等，但仅支持Java；等等有众多的框架和技术 。微服务架构提出的一个主要目的就是通过API来屏蔽开发语言，无论用什么开发语言，只要遵循同样的 API，都可以进行协同。其实这类似于地球上不同国家之间的交流，通过相互可以理解的公共语言就可以对话。因此在实现服务治理时需要考虑跨平台能力以及对内和对外 API服务能力。这里要区分下微服务的 API和对外的 OpenAPI ，可以看作是两个层次 。OpenAPI通常是跨平台、跨企业的，用于构建生态系统，不过企业内部也可以用于构建企业内部生态。思想都是一样。

　　云原生以API为协同方式，因此在公司内部可以实现容器云平台和 API网关两层的服务治理能力。同一个微服务可以通过 API网关暴露为不同的 API，或者也可以多个微服务暴露为一个 API。API既可以面向企业内部，也可以面向外部生态伙伴。

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

　　前两个步骤完成了微服务运行运营的基础能力，具备了支撑微服务弹性扩展、协同交互的能力。有了部署运维平台和服务管理治理能力，则就可以侧重提升研发端的持续交付能力。这样，无论开发多少微服务，在服务管理和治理方面也就没有了后顾之忧。以DevOps理论为指导，构建持续集成、持续部署、持续交付、持续监控、持续反馈的闭环流程。

　　兵马未动，粮草先行，之所以要先建设容器云平台和服务管理治理能力，就是要提前准备好在应用微服务化、分布式微服务量的爆炸增长，具备支撑弹性伸缩、可视化、可观察性、故障隔离、容错、故障自恢复等能力。这样才能支持各个团队的持续交付要求。这也是我们一直提倡先着力构建微服务运行支撑环境的重要原因。

　　DevOps一种思想和方法论，其核心是协作反馈，只有及时的反馈才能反思和改进。利用 DevOps思想构建持续交付能力的过程中，会涉及组织架构的优化，这可能是一个难点。首先组织领导要能够理解 DevOps思想和理念，知道组织的弱点并愿意尝试改进；其次， DevOps 体系（DevOps体系可能不仅仅是一个平台 ） 可能涉及众多的组件和工具，或者需要一体化的设计研发，每种方式都会花费大量人力和时间。比如说用开源工具，持续集成和持续交付流程涉及开发、源码管理、源码检查、单元测试、用例管理、构建、安全测试、交付管理等众多的工具，仅考虑打通这些工具的认证权限管理，就不是一件容易的事。因此有些DevOps厂商直接自研持续集成、持续交付等流水线。如果具备这样的研发能力，笔者建议尽可能自研或者合作研发，这也是为系统融合打好基础，避免众多的开源第三方工具带来众多的集成问题，难以有效融合在一起。

　　认证和权限是DevOps体系中的基础安全措施。代码安全检查、镜像安全检查、系统安全、应用安全、接口安全、容器安全等等都需要在 DevOps工具链和流水线实施和使用过程中逐步完善，以提升云原生的整体安全性。

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

　　基础设施在第一步搭建容器云平台和微服务的时候就会用到，只不过这个阶段微服务量相对较少，对自服务敏捷响应基础设施没有迫切需求。随着持续交付能力的提升，微服务量的增长，运维能力需要从量变演化到质变。自动化、自服务敏捷响应能力提上日程。

　　基础设施大致可以划分为三个部分：基础设施资源、支撑平台和纯技术工具。基础设施资源可能有很多种异构资源和云平台，需要通过统一的层次（比如多云管理平台）来封装，提供统一的基础设施资源服务，隔离底层异构资源细节，简化应用资源调度。支撑平台主要是微服务开发、运行、运维的平台，例如 持续交付平台、容器云平台等。纯技术工具指的是和业务无关、围绕支撑平台周边的工具，比如消息平台（ RabbitMQ、Kafka ）、监控平台、权限管理平台、认证平台、人脸识别平台等等。这些平台可以提取构建技术中台能力，各业务应用都可以复用这些能力。

　　在实施持续交付的同时，也是在部分构建自服务敏捷响应基础设施能力，比如持续集成、持续交付流水线等。在这个步骤，需要重点构建和完善自动化、自服务的基础设施能力，包括统一身份认证和权限服务、日志服务、配置服务、监控服务、告警服务、安全服务、AI服务（人脸识别、文字识别、图像识别、语音识别、自然语言处理、知识图谱、算法等）、消息服务、调度服务等基础服务和CICD研发流程服务等 。实现这些服务的自服务能力是构建应用敏捷响应的关键。

　　基础设施资源的自服务敏捷响应是所有这些服务的实现敏捷响应的前提。由于基础设施资源多种多样，可能来自不同的厂商品牌、不同的型号、不同的架构、不同的协议、不同的云平台等等，为基础设施资源的融合管理和敏捷响应带来了挑战。需要考虑构建统一的基础设施资源管理平台或多云管理平台来提供统一的基础设施资源服务，封装底层资源细节，提升资源交付效率。

　　这个过程中，组织架构可以同步调整，比如基础设施资源团队来运维运营基础设施资源，为平台和工具提供资源服务；平台团队来运维运营平台，工具团队来持续研发工具和技术中台服务，支撑以应用管理为中心的架构；应用研发团队专注于业务应用微服务的研发，使用自服务的资源、平台、工具实现服务的研发、测试、部署、运行、运维等全生命周期管理。

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

　　脆弱性的反面是健壮性、韧性。抗脆弱性（或反脆弱性，Antifragility ）的目的就是持续定时或不定时通过在运行环境中注入故障的方式来主动的找到弱点，并强制修复这些弱点，从而提升环境的健壮性和韧性。以人类免疫系统为例，当受到病毒侵害时，人体的免疫系统就会自动做出反应，会变得更强；而当人被隔离时，免疫系统会变得更弱。用人类免疫系统的思想来构建云原生架构的韧性，以抵御不同场景下的故障。Netflix Simian Army项目有个著名的子模块“混沌猴（Chaos Monkey ）”，它将随机故障注入生产组件，目的是识别和消除体系结构中的弱点。通过明确查找应用程序体系结构中的弱点、注入故障并强制进行补救，体系结构自然会随着时间的推移收敛到更高的安全程度。因此可以在完成前几个步骤之后，或者在条件允许的情况下，也可伴随着前述步骤过程通过抗脆弱性试验持续增强环境的韧性。

　　安全措施是防御性的，而系统是在持续的变化之中，随时可能会出现不可预知的漏洞，因此除了在开发设计时尽可能消除安全隐患，运行时的安全措施一样也不能少，而且是持续性的，所以需要不断地改进安全举措，持续增强抗击漏洞攻击等行为。安全能力建设也是系统抗脆弱性的一部分。

　　总结

　　云原生架构实施路线图只是基于实践和思考而提出的一个参考方案，具体的实施过程中还有众多的细节，以及不同公司有不同的实际情况，可能难以满足所有的场景需求，因此仅供参考。

　　原题：云原生架构实施路线图