传统IT架构转型-从SOA和微服务到云原生解决方案实践

今天重新整理和分享下我在今年华南CIO大会关于SOA，微服务和云原生解决方案的一个分享材料。在前面我分享过这个材料的一个老版本，今天分享大会演讲的黑的版本。

大家也可以比下这两个PPT版本风格的差异，我从原来的白底版本修改为当前的黑底风格也差不多用了2天左右的时间才完成。主要就是黑色风格不能简单的大量拷贝白底图形，如果这样的话黑色风格本身也没有任何意义。黑色风格可以看到一个是图形用色上反差，一个就是更多的采用形状透明的方式进行构图，这些大家也可以参考。

今天这个材料一个是分享PPT，一个是针对PPT材料对我演讲的内容关键点进行整理和说明，以方便大家阅读和理解。

整个演讲我实际上分了三个方面的内容。

第一部分首先阐述从SOA到微服务，中台，云原生的一个架构演进过程。将这个的目的就是要说明实际我们当前看到的很多类似中台，云原生这些新的技术概念实际上仍然是传统的SOA，云计算，领域建模等思想的一个延续。

第二部分是讲微服务思想下企业架构规划的核心思路和方法论，重点是讲解对传统企业架构规划方法的优化和改进。原因就是当前在中台规划和建设，微服务架构分析和设计中，仍然还在沿用10多年前一成不变的企业架构规划方法论，这个显然是不合适的。

第三部分结合我们自身的财务共享项目来讲解微服务和云原生的改造案例。

由于自己本身是属于受邀演讲嘉宾的身份参加这次CIO大会，因此整个材料里面没有任何关于我们自己的产品和解决方案推广的材料，而更多的还是关于微服务，云原生核心规划和建设方法论，最佳实践等方面的内容分享。

对于SOA架构方法我在很早以前就讲过，可以简单的总结为找到服务，组合和组装服务。今天再次总结实际我们看到SOA的核心思想是解耦。

即将传统的企业IT系统竖井式的纵向建设方式转变为横向分层的建设模式。在电信里面有个eTom模型总结了横向分为 资源-服务-应用 三个层面，这个相当经典。对应到SOA里面完全适用。即最底层的资源是我们识别的底层遗留系统和组件，而服务层是遗留系统暴露的可以复用的API接口，到了应用层则是对已有服务接口的组装和编排形成新的业务。

即新业务的构建不再是纵向新构建一个系统，而是通过已有的服务能力进行上层组装。在整个横向分层架构里面，服务层相当重要，起到了了底层资源和上层新应用间很好的解耦作用。

在原来我就比较过SOA和云计算的差异，重点说明了SOA的重点是对已有遗留能力进行集成，集成后再以服务方式进行能力共享。而到了云计算我们发现重点不是集成，而是首先识别出共享能力，然后对于共享能力直接集中化进行建设。

在私有云PaaS平台规划和建设里面我就谈到，传统业务系统里面涉及到的数据库，中间件，平台层技术组件和服务等全部都集中化到PaaS云平台进行建设，建设完成后再能力开放。

当我们把传统业务系统中的各种类似中间件，流程，4A，消息缓存等技术能力全部下沉和移除后。传统业务系统就能够进一步进行组件化和松耦合的方式进行建设，以实现业务组件间的彻底解耦。注意这个可以理解为当前微服务架构的前期阶段。

再回来谈微服务，我在很早就专门谈过SOA和微服务的区别，里面强调了一个重点就是微服务丝毫SOA思想在业务系统里面的内化。传统SOA思想应用在业务系统间，而微服务思想应用到业务系统内部。

但是这个并不准确，可以看到微服务是相对单体应用来说的。微服务的核心很简单就是大拆小，传统的单体应用要拆分为更加细的业务组件模块，从这个意义上来说微服务本身并不需要体现我前面谈到的SOA横向分层和复用的思想。对于微服务简单来说核心就是：

• 一个单体变多个微服务模块，而且从数据库到逻辑层到前端完全独立
• 微服务模块间通过Http Rest接口高效集成协同
• 各个微服务完全独立部署，扩展的时候数据库，集群都单独扩展

以上实际上就是我们经常谈到的微服务区别于单体架构最关键的几个点。在掌握了这个核心概念后你才清楚哪些不是微服务基本特征。比如微服务必须容器化部署，没有这个说法，微服务也可以传统方式部署。还有就是微服务开发必须前后端分离，实际上也没有这个说法，前后端不分离只要微服务间完全纵向解耦就是微服务架构。

而对于中台，我在前面谈到过里面有两个核心点。

• 其一是共性业务能力下沉，并将共性能力以API接口方式提供给前台。
• 其二是共性能力的构建也需要大拆小，可扩展和松耦合。

可以看到第一点正是我前面强调的SOA横向分层和复用的思想，而对于第二点即是微服务架构的思想。也正是这个原因可以将中台理解为SOA+微服务思想的融合。

而这里面最关键的必要条件又是共性业务能力下沉。而对于中台能力构建是否微服务化反而非必要。对于全新构建中台你可以全部微服务化，而对于企业IT遗留架构下构建中台，那么你完全没有必要一定要去微服务化。

其次就是中台更多的应该是一个业务词汇而不是技术架构，特别是对于技术中台这种实际上划分到中台里面并不合适，技术中台更加类似我前面谈到的企业私有云PaaS平台。

对于Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。

因此云原生是一系列Cloud技术、企业管理方法的集合。

云原生应用程序开发通常包括DevOps，敏捷方法，微服务，云平台，Kubernetes和Docker等容器，以及持续交付，简而言之，每种新的和现代的应用程序部署方法。

CNCF给出了云原生应用的三大特征：

• 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用。
• 动态管理：通过集中式的编排调度系统来动态的管理和调度。
• 面向微服务：明确服务间的依赖，互相解耦。

实际上我们看到对于完整的DevOps是包括了持续交付方面的内容的。因此对于云原生的概念完全和我前面经常谈到的微服务，容器化PaaS和DevOps相吻合。

即云原生 = 微服务+ DevOps + 容器化PaaS

云原生本身包括了云原生平台和云原生应用，而平台则是指容器PaaS平台和DevOps能力支撑平台，而云原生应用可以理解为基于微服务思想和开发框架开发的微服务应用。

对于如何更好的理解云原生，我们可以完全从字面理解，即企业开发的应用系统天生的适合云环境，因云而生。即应用开发前就要考虑充分采用云环境所提供给你的平台支撑能力，技术支撑能力，充分考虑云环境已有的各种标准和约束来进行应用的开发。

这样开发出来的应用可以做到平滑从私有云环境迁移到公有云环境，或者说这样开发的应用方便后续进行更好的对应用进行管理和弹性扩展。

对于云原生完全符合当前云计算发展和演进趋势，对于这个趋势简单来讲就是企业后续的IT系统开发完全只需要关心业务功能和逻辑实现，其它原来我们关心的IT基础设施，数据库和中间件，技术服务，开发框架和环境等全部都不再需要关心，而由公有云平台提供能力。

特别是到了Serverless无服务器阶段，更是这个思想的终极应用。

在把前面的基础概念讲清楚后，我们再来回顾下企业IT架构演进过程。

即最初可能只是实现了IaaS虚拟化资源池，但是业务系统仍然是纵向独立构建。到了第二阶段开始规划PaaS平台，实现中间件资源池，一些类似4A，流程等共性技术服务能力的下沉。但是业务系统本身各个业务模块仍然紧耦合，同时业务系统里面还是存在一个私有的技术平台层。

而到了第三个阶段，目标就是业务系统里面的技术平台层全部移出到PaaS平台，这样业务系统可以彻底组件化大拆小，采用微服务架构进行设计，开发和集成。由于业务系统微服务化，颗粒度更小，因此PaaS平台本身也演进到更加轻量高效的容器云平台。

在微服务模块应用开发和容器云平台之间，我们需要一个衔接的平台，即我们常说的覆盖软件需求，设计，开发，测试，部署，交付完整生命周期的支撑平台。

所以从上图里面我们也可以清楚的看到，最底层对应到容器云，中间是DevOps，最上层是微服务，而这三点也就是我们当前说的云原生解决方案最核心的内容。

到了第二部分重点是分享微服务对传统企业架构规划方法的优化改进。

对于传统企业架构思想可以看到基于业务驱动IT思路，从端到端流程分析出发进行企业核心的业务流程活动，业务对象识别，然后再规划业务架构，数据架构，应用架构和技术架构，在应用架构中又包括了我们常说的集成架构规划。

在业务流程梳理和分析中，我们会识别关键的业务活动单元和数据单元，而这正是进行业务架构规划和数据架构规划的基础。而基于业务和数据架构规划，业务和IT差距分析，我们会整理完整的应用架构规划。在应用架构规划完成后，还需要进一步进行跨系统的业务交互流程分析，以梳理和识别关键的交互集成点，基于这些集成点形成集成架构规划。同时我们将共性技术能力下沉，参考SOA和云计算核心架构思想进行技术架构。

在所有架构规划完成后，再结合企业业务目标，投资预算等进行演进路线规划。

在企业架构规划中，架构分析的入口点，我们认为合理的方式是从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。

第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来，如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。这也是端到端流程分析要注意点，高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。

流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，进一步可以分析到具体的概念模型或逻辑模型。流程分析偏业务操作和事件，而数据正是业务操作的对象。SOA中强调操作和数据解耦，则正好是分析的两个维度。

业务架构中的业务组件划分强调的是业务本身的高内聚和松耦合原则。对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源、资产等核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

对于业务架构的构建，特别是我们对某个业务域并没有深入的理解前，最好的方式就是流程驱动分析，抽离数据进行数据建模，然后进行CRUD矩阵分析，分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则，然后从底向上的对细粒度的业务功能进行组合，形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型，如供应链的scor模型，电信行业的etom模型等。

业务架构完成后，将会过渡到应用架构，两者基本是对应的。其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需求中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了纯技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会分为技术支撑平台和应用支撑平台，技术支撑平台包括了安全，管控等；而应用支撑包含了数据平台，集成平台和流程平台等。应用架构一般会分为支撑层，应用层和决策层。其中的应用层基本可以做到和业务架构一一映射。

服务架构需要考虑业务系统间的集成点。这个集成点的分析我们期望可以将端到端流程结合应用架构中的业务系统，CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已不是纯粹业务层面的流程图，而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主，而后者即以数据服务为主。两者在分析完备后最终都体现到应用集成架构中。

从上面我们对传统企业架构规划方法的核心逻辑说明来看，传统EA企业架构规划方法仍然相当完整，但是我们也需要看到在整个SOA和云架构思想下，在中台和微服务思想逐步演进的过程中，传统的企业架构规划也需要进行优化和调整。

传统企业架构规划方法仍然是按照传统遗留大单体应用垂直纵向建设的模式来进行的规划，同时很少考虑到了集中化的云平台建设模式。然后在当前企业的信息化规划建设，平台+应用构建模式已经逐步成为主流。

同时在平台+应用分层构建的模式下，进一步将传统应用大单体拆分为多个独立自治的微服务进行独立建设和管控，而对于平台层则进一步融入云平台建设思路，包括最近1到2年我们谈的最多的面向云原生的解决方案。

这个云原生已经从传统的IaaS云平台过渡到了完整的PaaS云平台和技术服务能力提供。基于以上分析，可以看到传统企业架构优化点主要体现在

• 从纵向到横向：架构规划分析需要从纵向过渡到横向分层规划设计
• 数据库拆分：业务架构和数据架构结合分析，在规划阶段形成数据库拆分
• 业务和应用架构融合：在剥离了平台后，进一步融合业务和应用架构
• 基于业务组件规划设计微服务
• 技术架构规划新增加PaaS和技术中台服务内容

以上即是我们考虑需要进行优化的一些关键点。基于上面的思路，我们可以看到中台规划和建设的方法论可以进一步简化为上图。

从上面图可以看到，对于流程分析和数据架构分析仍然无大变化，核心都是为了划分业务组件和微服务模块。但是对原来的业务架构和应用架构可以合并，原因就是传统应用架构的平台层已经将其移到技术架构规划中。其次就是技术架构不再是单纯的IT基础设施架构，而且需要包括我们当前说的PaaS云平台和面向云原生的整体解决方案。

对于微服务架构，不是简单的采用类似SpingCloud微服务开发框架或Http Rest API接口就是微服务。在前面我们已经谈到微服务的核心是大拆小。

因此在这个大拆小的过程中重点就是考虑微服务模块的识别，和API接口服务的识别。究竟是拆分为6个微服务还是10个微服务，我们判断的准则是什么？还有就是应该识别哪些API接口服务，还是将数据库所有对象都暴露为接口服务？这些都是我们需要考虑的问题。

不论是组件识别还是服务识别，都存在两种方式可以参考。

一种是从顶向下的模式，基于前面谈到的企业架构规划的思想进行组件识别和接口识别。一种就是从底向上的方式，基于已有遗留系统模块和集成进行分析，来重新梳理和定义模块和接口。

对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源、资产等核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

从底向上思路则是参考遗留系统已有组件模块划分，下沉系统内共性能力，通过对组件集成关系或CRUD分析来重构组件粒度和组件接口。同时打破系统边界从端到端流程贯通重新分析。

当我们在分析一个业务或业务系统的时候，经常会用到端到端的业务流程分析，而业务流程分析完成后一个完整的流程阶段也就清晰了。

一个大流程的各个阶段往往就是我们划分微服务时候重要参考。

比如上图我们在进行一个供应链端到端流程分析的时候，在流程梳理清楚后我们可以很清楚的看到采购需求，采购请购，采购合同，采购订单，物流管理等大的流程执行阶段。而这些阶段就是我们划分微服务的一个重要参考。

其次，在同一个阶段里面涉及到不同的职能部门单元的时候，我们看到耦合性本身也较弱，那么就还可以进一步进行拆分。比如对于采购需求阶段可以进一步拆分为采购需求和采购计划，而对于采购溯源阶段，可以进一步拆分为采购请购和招投标两个独立的微服务。

即你在进行微服务拆分的时候，除了基于流程分析，企业当前的业务部门和岗位角色设置情况也可以作为一个重要参考。

在业务功能和业务对象都识别出来后，接着重要的一个步骤就是业务域的划分，你也可以理解为中台规划中的一个关键，就是业务组件或微服务模块的划分。划分的原则是高内聚和松耦合，但是核心的方法仍然业务和数据各种交互矩阵分析。其中包括

业务组件交互矩阵：横向和竖向都是业务组件，内容单元格里是具体的业务交互接口点，通过此矩阵可以看出业务组件的划分是否会导致大量的业务接口存在，分析每个业务接口产生的原因，以进行组件的合并、业务功能转移等。

业务对象和业务交互矩阵：横向是业务组件和业务功能，纵向是具体的业务对象，内容单元格是具体的CRUD信息（即传统的CRUD矩阵分析）。对于同一个业务对象，CUD操作尽量减少分离，而读操作则可以共享，以减少业务对象的多头管理和维护，将业务表单和数据的维护尽量控制在同一个业务大组件中完成，减少数据间的交互和传递。

流程交互分析矩阵：横向是具体的流程信息，纵向是具体的流程活动信息，在这个矩阵图上可以看到同一个流程活动或流程片段往往存在于多个不同的流程。该分析的重要作用是对流程建模中可复用的流程片段或流程活动进行抽象和分析。

功能业务组件分析矩阵：横向是具体的业务组件，纵向是业务功能，在该交互分析上重点是分析具体的可复用的业务功能，以对可复用的业务功能进一步进行抽取，形成可复用的服务。

对于数据架构分析，我们可以看到进一步和业务流程和业务架构分析方法融合。即数据架构的作用首先是找到所有的业务对象和数据对象。而对于数据域的划分本身意义不大，因为我们在前面业务模块分析中已经看到通过业务交互分析本身就已经在做数据库拆分和拆库的事情。

数据架构一个重点变成识别出所有的数据对象和业务对象，然后补充进矩阵交互分析中。因为我们常规的业务流程分析可能会持续识别遗漏的情况。

要注意到对于业务架构我们只分析到业务对象模型，没有进入到逻辑模型和物理模型阶段，因此在后续数据库拆分清楚后具体的数据模型设计，仍然是传统的数据架构分析方法进行。

在数据对象分析里面有一个重点就是主数据识别和分析。

这个仍然保留，因为前面业务分析方法有可能出现主数据或基础数据识别不全的情况。其次将所有的数据对象仍然纳入到业务数据交互矩阵分析中。对于基本上大部分跨域业务功能都需要使用到的数据纳入到主数据或共享数据的范畴，并将这部分数据拿出来单独拆库进行处理。企业内部信息化建设模式，主数据就一个大数据库，而新的架构模式下我们可以看到主数据也可以拆分为多个基础数据库。

对于传统企业IT架构演进，我们看到往往存在全新系统建设和遗留系统迁移两种。

对于全新系统建设，我们完全可以做到平台层和应用层并行建设和构建，在建设完成后同时进行集成，集成完成后一起上线。而对于遗留系统迁移这种模式，我们往往需要优先进行平台层能力建设，在平台层建设完成后再根据优先级对遗留系统逐步进行迁移上线。

而在整个过程中传统竖井架构本身也发生了变化。从最初的IaaS云平台和SOA集成平台，逐步发展为容器云PaaS平台，API网关和微服务的云原生解决方案。

对于微服务架构本身也包括了全新建设和遗留适配两种思路。

对于全新构建模式可以看到，最底层仍然是传统的IaaS云资源池，上层则是容器云和DevOps支撑平台，再上层可以理解为当前说的比较多的技术中台能力层，其中既包括了4A，流程，消息，缓存等各种共性技术服务能力提供，也包括了对整个软件从开发，运行到运维监控全生命周期的支撑平台能力。

再上层则是我们说的应用层，对于应用层当然还可以进一步分为中台和前台，中台和前台均可以参考微服务架构思想进行构建，对于需要统一暴露的API接口服务则通过API网关进行集成和管理。

而对于遗留系统适配方式，我在前面文章里面也谈到过，则是构建一个新的能力中台，能力中台去适配遗留系统的数据库，业务模块，已有业务系统的API接口，然后形成一个统一的可复用的服务能力提供层。这个服务能力提供给出来后，新的业务应用完全就可以采用微服务方式进行开发。

对于技术架构规划，传统企业架构里面的技术架构更多的都是IT基础设施的架构规划，而当前则是将所有的PaaS平台能力纳入到技术架构规划中，即：

• 从传统的IT基础设施规划过渡到IaaS云+PaaS云平台规划
• 云原生=微服务+DevOps+容器云
• 原应用架构规划里面的平台层移出-转移到技术架构中技术平台层规划

最后一个部分，结合我们自己的财务共享平台项目进行了微服务架构改造案例分析。

对于改造前的应用，实际上存在四个方面的问题。

其一是关于高可用性方面的，即传统的单体应用我们在进行数据库水平扩展的时候已经很难扩展，已经出现了大并发，大数据量下数据库的性能问题。

其二是多团队异地协同上，传统的IT架构很难进行更好的多团队分工，同时在异地协同过程中对于开发，测试，前方实施经常出现大量的无效沟通情况。

其三是敏捷性已经不能满足客户的需求，比如我们一个小版本规划最少2到3周，而很多时候在客户往往我们能够在一周就实施一个变更版本上线。

其四是开发和运维之间的沟通协同困难，同时由于原来是一个大单体应用，版本升级和变更同样困难，一个是部署包好几百M很难管理，一个是往往修改A模块功能导致B模块出现异常等。

也正是由于这些原因我们启动了项目的微服务架构改造工作。

在整个改造过程中，重点仍然是如何划分微服务，而核心思路仍然是流程分析入手。即：基于业财一体化最佳实践，重新梳理端到端业务流程和协同，找到关键阶段划分。对于关键阶段进一步细化，分析详细的业务操作和协同流程(二到三级流程）。

我们首先进行粗颗粒度的模块拆分和集成分析，在分析完成后储备可以明确的识别出类似报账，资金，发票，电子凭证，影像，预算，ERP集成等关键微服务模块。

在微服务模块识别完成后，我们还需要针对单个微服务进一步进行业务交互和协同分析，以梳理和识别API接口服务能力。

在整个微服务架构改造和转型中，我们还需要进行技术平台的统一。采用SpringCloud框架体系，启用注册中心，负载均衡，限流熔断，网关能力。同时前后端完全分离开发，前端基于VUE框架进一步封装和定制。

我们采用禅道项目管理工具统一敏捷研发管理，需求拆分到用户故事点实现端到端管理，形成产品-微服务两级的产品架构和版本管理体系，实现和持续集成和版本发布过程集成。

同时我们采用DevOps支撑平台来实现整个微服务架构设计和开发过程中的持续集成和交付能力。对于DevOps平台的核心架构和功能，可以参考我前面发布过的文章详细了解。

在整个DevOps实施过程中，我们通过DevOps流水线对大量的开源工具进行了整合。其中包括了Git库，Sonar静态代码检查，Jekins持续集成，Kurbernetes和Docker容器，自动化测试工具，ELK日志采集和分析，监控工具等。

实现研发过程和DevOps过程的集成。一个DevOps支撑平台离不开和容器化PaaS平台的集成，即最终的编译构建完成的内容形成镜像并放到镜像仓库，后续部署，环境迁移，资源扩展基于镜像仓库进行快速的拷贝和复制。对于Docker容器一般会和K8S结合来实现资源的动态调度，集群管理能力。

环境迁移是基于镜像进行环境拷贝和迁移，而不再需要重新构建和打包，这也是我们原来在谈持续集成技术的时候一直强调的一点。只有这样才能够保证测试通过的包就是最终部署到生产环境的包。

对于DevOps实施效果可以总结为，版本构建频度：2天一次->半天一次或实时触发；版本构建时间：缩短到1分钟内完成；应用交付部署：实现环境自动化迁移和云部署；测试执行效果：接口测试全部自动化。

当然整个微服务架构改造和DevOps实践仍然在持续优化和改进中，我也将在后续进一步分享相关DevOps实践和优化的内容供大家参考。