| 编辑推荐: |
| 本文来自于百度，本文介绍了从系统规划建设期到IT管控治理和运维期，业务组织和IT系统紧耦合到解耦需求等。 |
|
关键诉求
微服务架构这个概念出来也有2-3年的时间了，从最开始在互联网企业的广泛应用，到现在越来越多的企业开始关注和希望尝试使用微服务架构。在前面的博客文章里面我也专门谈到过对于传统企业如何进行微服务架构转型，包括从哪些小的地方开始切入等。
对于企业从传统IT架构到微服务架构的转型，绝对不是盲目的跟风互联网企业，而是企业的业务规范，企业的信息化水平和IT成熟度发展到一定阶段后的比如诉求，那么这些关键的诉求究竟有哪些？
从系统规划建设期到IT管控治理和运维期
首先可以看到当企业的信息化和IT系统建设发展到一定阶段后，自然会从IT系统的规划和建设期发展到后期的IT系统管控治理和运维期。到了后期不会再有大量的新系统规划建设，而更多的都是为了业务流程优化进行的IT系统需求变更，优化和功能改造。那么关键的问题就变成了如何快速的响应业务需求变化并发布系统，同时如何又以最小的代价和影响来发布系统？
传统的IT架构模式可以看到很难解决这个问题，每次需求或功能变更的发布周期相当长，同时由于是一个大单体应用全部发布，往往增加了一个新功能反而导致多个老功能出问题。这些都是我们经常遇到的问题，其核心的原因就是原来我们管理的业务系统本身的颗粒度太大了，其次就是从需求到开发到测试到发布整个过程如何自动化衔接。第一点涉及到微服务架构，第二点涉及到PaaS和DevOps方面的内容。
在微服务架构下，我们管理的单位从原来的大单体应用变化为了细粒度的微服务模块，自然在变更和发布的时候影响单位也相应变小到各个业务模块粒度。这将有效的解决子在后期运维变更功能发布的影响。
从业务组织和IT系统紧耦合到解耦需求
其次，在传统IT系统规划和建设中，在企业架构规划设计中，我们经常谈业务和流程驱动IT，强调端到端流程的贯通。但是系统规划设计和实现的过程中，最普遍的现象就是不是业务驱动IT，而是业务部门驱动IT，导致我们的IT系统和业务部门是紧耦合的。举例来说，一个企业只有供应链部，那么建设的系统就是供应链系统；但是如果一个企业有采购部，有物流部，那么建设完成的系统就是采购系统和物流系统。
在这种情况下，带来的最大问题就是企业的业务组织架构一调整，往往带来IT系统巨大的调整工作量，在我原来的企业也经常遇到IT系统经常配合业务组织架构调整的事情。这类工作已经不是简单的HR系统组织结构调整，还包括了本身的业务系统中业务功能点的调整，已有的业务数据的调整，这些都需要进行动态切换和割接。
当企业建设的业务系统越多，和业务部门关系绑定的越紧密，这种调整带来的复杂度和工作量也就越大。
而真正的解决思路就是要将业务部门和业务系统解耦，如何解耦？仍然是从业务流程驱动的角度去考虑和拆分具体的业务单元，这些业务单元形成独立的业务组件（微服务架构中的微服务模块），由于这些业务组件粒度已经足够细，因此更加容易灵活的组装或组合去满足实际业务部门的日常业务需求。
举例来说：如果是大的供应链部门，就配置供应商管理，物料管理，采购订单，招投标，库存管理，物流配送管理等多个微服务模块。如果是拆分为采购部门和物流部门，那么采购部门配置供应商管理，物料管理，采购订单，招投标管理，物流部门配置库存管理，物流配送管理等微服务模块。
在规划和拆分微服务模块的时候更多是业务和流程角度出发，只要划分的足够合理，就能够最小化的减小业务组织架构调整对IT系统本身造成的影响。
从单打独斗信息孤岛到共享思路下的平台战略
企业信息化发展到一定阶段，自己都会意识到按照传统的一个个孤立的业务系统建设模式越来越行不通，这不仅仅是业务系统很多功能重复建设的问题，同时还导致了业务系统中数据不一致性，集成困难，后续的运维和变更处理困难等一系列问题。即典型的钱花的更多，但是系统却越来越复杂和难用。
而解决这个问题的的关键就是平台战略，对于平台战略本身又有两个重要的核心，即不是简单的遗留系统能力直接服务化共享，而是首先要集中，其次才是共享。集中化是云的思路，而共享才是SOA的思路，两个关键点都解决了才是云计算+SOA的关键思路融合。
为啥要把这个问题在微服务架构里面谈，因为平台+应用构建模式本身也是微服务架构实施的一个基础条件，微服务模块更多都应该是独立承担某个业务域的业务组件模块，而不应该包括类似流程引擎，系统管理等共性底层组件，否则微服务模块又变成很重的单体应用，没有了任何价值。
要做好微服务架构，我们就必须做好底层基础共性平台的建设，只是微服务架构里面会谈为共性的技术服务能力提供，都是一个道理，就是共性的东西或能力要下沉，然后再以标准的服务接口方式暴露或共享出来给上层的业务系统使用。
资源池的有效利用和资源动态调度
这是微服务架构结合PaaS容器化技术和动态调度技术后带来的一个新的亮点，即可以真正实现按照业务需求和业务并发量动态的申请和分配资源，以满足业务并发访问的需求。在整个过程中不需要人为去干预，而只需要设置好相应的调度规则和资源动态扩展规则即可。
对于这个点实际当前并不是很强企业的诉求，只是后续成熟度发展到一定阶段后带来的亮点功能，真正解决了IT系统的灵活资源分配，扩展和动态调度问题。
问题解决
企业从传统架构转型到微服务架构后可以解决的问题点或潜在的收益。
进一步节约IT基础设施建设投入，容器比虚拟机更加轻量化，同时结合Kubernate后可以实现自动化的资源调度，可以最大限度的提升资源的利用率。要明白，没有真正实现PaaS层能力的企业云平台，往往仅仅是简单的实现了从物理机到虚拟机的使用转变，而并没真正解决资源利用率大幅提升的问题。要解决资源利用率的大幅提升就必须实现应用托管和资源动态调度，而是要非人为干预全部自动化完成。
彻底贯彻平台+应用，以及业务部门和IT系统解耦的思想，以后企业扩展的都不再是业务系统，而是业务组件或模块，同时逐渐不再有业务系统的概念，只有业务组件模块的概念。业务部门不会和IT系统严格一一对应，而是通过业务组件的组合和组装来类似积木化方式搭建业务部门需要的功能。这是IT系统能够更加灵活或柔性的适应企业业务流程，企业组织架构变化的关键一步。
进一步加强企业作为甲方的时候，对业务系统开发厂商的管控能力，即从粗粒度的业务系统管控到更加细粒度的微服务模块。同时结合DevOps可以使整个从需求，开发，测试，上线的整个过程全部透明化，而不是作为开发商的黑盒。正是由于整个过程的全程可视和自动化，甲方企业才可能后续真正做到业务系统的接维。
敏捷的响应业务变化的能力增强了，你会看到从业务部门提出业务需求或变更，到最终功能发布的上线时间会大大缩短。这种缩短的原因体现在整个流程中能够自动化的工作，全部自动化掉了，包括打包，自动化的单元测试，环境迁移和部署等；其次变更发布影响的范围减小，从影响一个业务系统变化到往往只需要影响一个微服务模块，大大减少了变更发布的测试验证工作量。最后，理想状态下很多平台层的能力和技术服务都全部实现，而实现业务组件的开发只需要关注业务本身，而不需要再去考虑任何技术层的共性能力，这本身也可大大提示业务组件和模块的开发效率。
在整个微服务基础框架+技术服务组件建设完成后，实际上单个业务微服务模块开发本身反而更加容易，在这种情况下微服务模块的开发人员并不需要完整的了解详细的完整业务流程细节。而只需要按业务需求开发业务功能和实现业务逻辑，消费微服务API接口，并按要求提供和暴露共享接口即可。对于微服务模块的集成和组装可以由专门的技术架构人员来完成。
进一步提升企业对IT资产的管理水平，企业管理的不再是简单的最终便也部署包，而是实现从最开始的需求到源代码文件的全流程管理和检查。
当企业所有应用都按照标准的微服务架构，开发工具和环境进行开发后，同时严格实施DevOps后，可以看到企业的运维就完全实现统一管控和运维。包括运维管理流程，运维工具，运维监控和预警等，安全管理等都可以进行统一。同时在这种运维能力统一并自动化后，IT运维人员效率提升，需要的IT运维人员数量也大幅减少。
厚服务层（领域服务能力下沉）概念，真正实现了前端应用和后端服务的解耦和分离，服务可以更加灵活的组合和组装来构建前端应用。同时可以支撑移动APP，BS网页，Pad等多种前端应用类型。也可以更加灵活的支撑不同的前端业务应用使用相同可共享的业务服务或技术服务能力。
从传统偏重的ESB服务总线集成模式转变到轻量的去中心化的微服务网关集成模式，真正实现整个架构搭建中无中心化节点（也就是无关键瓶颈节点），从而实现整个架构极强的资源动态水平弹性扩展能力。另外从传统的代码编译和部署包交付模式转变为基于Docker容器的镜像交付模式，极大的提升了部署和环境迁移的效率，同时提升了整个业务系统的弹性可伸缩性。
实施难点
数据库的拆分
如果数据库没有拆分而仅仅是应用组件拆分不能称为完整意义上的微服务架构，传统单体应用转变为微服务架构后，从页面前端到逻辑层到数据库都应该完全独立的一套，可以独立进行需求，设计，开发，部署和后续的运维管理。因此要转为微服务架构，首先数据库要拆分，微服务模块在拆分的时候一定要考虑对应数据库拆分的合理性和自治性。
数据库拆分后，原来简单的底层数据库关联查询，变化为需要通过领域服务层进行服务组合才能够完成。原来数据库层很容易控制的数据库事务，转变为了由于进行WS接口交互带来的分布式事务问题。这个我们在谈组件化和微服务架构的时候多次谈到，是微服务架构实施的一个关键难点。
其次，基础平台层和技术服务能力的建设是转型中第二个难点
这些能力有可能在传统架构建设模式下已经独立建设，如何将这些共性能力抽象出来并下沉到平台层共性建设，并再将能力以WS接口方式开放出去供上层微服务模块使用，是微服务架构转型中必须首先考虑实施的内容。
要实施这点，就会造成原有业务模块的较大改造，特别是对于原有各业务系统中的技术组件本身差异就大的情况下，这种统一往往更加困难，势必对已有的业务系统造成较大的影响。这也是很早我们在谈企业微服务架构实施策略中谈到的尽量是逐步迁移，老系统或平台也逐步消亡的渐进模式实施。
新技术的引入，微服务架构思想的引入
对于微服务架构，前面已经强调过多次不仅仅是单纯的微服务开发框架的引入，更加重点的是和容器化技术，和DevOps实践的结合，进一步对组件化架构和领域建模思想的实践，同时可能还涉及到EDA事件驱动架构方面的内容。在业务层面还涉及到如何去更好的划分微服务模块，这个粒度究竟如何把控，对于划分完成的微服务模块如何去识别和定义微服务接口，确保接口本身的复用性和粗粒度特性。
因此不是使用了WS接口就是SOA，也绝对不是简单的使用了Rest接口，使用了Spring Cloud等微服务框架就是微服务架构。更加重要的是组件化和服务化，持续集成和DevOps等思想的最终实践和落地。只有这些思想真正落地，才能够解决我在上篇文章中谈到的关键诉求说描述的问题。
企业本身的软件过程成熟度
如果一个企业原来就实施了组件化开发，或者原来就使用了一些开源了SOA总线或服务网关产品，已经实践过了持续集成方法论，或者已经建立了自己的类似流程引擎，4A等基础技术平台，那么实施微服务架构相对就很容易。反之，如果一个企业在传统IT架构下都没有形成标准的开发过程，开发框架，技术组件积累，标准软件生命周期，编码规范和接口使用标准等，那么要实施微服务架构就相对难。
其次对于微服务架构下，我们管理的最小单位将从原来的一个大的单体应用变化为多个更加细粒度的微服务模块，原来单体应用内部的接口和集成可能属于混乱状态，但是在黑盒内部没有暴露出来，但是事实微服务架构后这些都会被完全暴露出来需要去管控。我们需要管理的微服务模块数量，接口数量等都会成倍的增加，没有一定的IT管控和治理流程的积累，要做好这些管控也是相当困难的事情。
最后谈下运维监控能力差距
由于要管理的模块数和接口服务数都成倍的增加，对管控和运维的能力要求都相应提升，如果还按照传统的人工去运维的方式肯定行不通。这里面一方面就是要实现自动化的监控和运维能力，模块和接口服务的性能分析和及时预警能力；其次就是要实施DevOps，真正将从需求开始，到设计，开发，测试，部署的全过程实现流水线式作业。
可以看到，对当前传统企业和传统IT架构建设和实施过程中，运维和后续管控的能力差距还很大，这就很容易发送上了微服务架构，后续服务很好的管控和运维的情况，人员疲于奔命的应付各类故障和问题，那么这样不是节约了运维和管理工作量，反而是使整个运维管控流程复杂化了。
实施准备
前面已经谈到过，微服务架构不是简单的微服务开发框架的使用，更不是简单的Restful接口的使用，而是大量的SOA，持续集成，组件化和服务化，云平台和容器，DevOps等思想的融合应用。因此在考虑转型到微服务架构的时候可以首先进行相应的准备，而这些准备基本都是可以独立完成并实施的，具体如下：
持续集成实践：
在很早就有持续集成的思想和最佳实践，里面涉及到配置管理，自动编译部署，环境迁移，自动化的单元测试，每日构建和冒烟测试等方法和实践的使用。这些即使没有实施微服务架构，对单个业务系统也可以进行持续集成的实践。持续集成和自动化的构建是后续微服务架构和DevOps的一个重要内容。
领域建模思想：
对于领域驱动架构是面向对象分析和设计中的一个重要内容，通过领域服务层的构建可以很好的解决业务高内聚和粗粒度的服务接口提供的问题，而不是简单的将对数据库表的CRUD操作发布为服务接口，同时领域建模也很好的解决了原有的贫血业务逻辑层的问题，真正在业务建模和架构设计阶段，从对数据对象的关注转移到对业务领域对象的关注。粗粒度的服务接口即使在实施微服务架构后也是必须关注的内容，否则会出现微服务模块间大量的接口交互的场景，这种接口越多越导致了微服务模块之间越紧耦合。
SOA思想的深入理解:
对于微服务架构实际上是SOA参考架构思想在原有的单体应用内部的实践和落地，因此SOA思想是基础，而SOA思想本质就是业务能力组件化，组件能力服务化，将业务流程或业务的实现转变为多个松耦合的业务组件（微服务模块），同时通过微服务模块暴露的API服务接口实现组件之间业务功能的组合和编排，以完成完整的业务流程。
微服务开发框架的学习：
比如对当前主流的Spring Cloud微服务框架的学习和理解，其中包括了服务目录和服务注册，微服务网关，服务的发布，服务后续的管控治理，服务运行监控等诸多内容。这些都需要去学习和理解。通过微服务开发框架，真正实现了各个微服务模块的开发完全独立自治，可以独立进行设计，开发和最终的部署。而微服务模块暴露的服务在注册到微服务网关后又实现了多个微服务模块之间的联动。
关键技术的学习：
这里面主要包括了Web Service，消息中间件，事件引擎，Restful接口和面向资源的概念，CXF开发框架，Spring
Boot和Spring Cloud，Maven构建，DevOps，云和容器技术，前端技术等。这些都是在微服务架构实现和微服务模块开发中会用到的内容，需要学习和掌握。
基础平台和技术组件和服务的学习：
这里面包括了常用的工作流引擎，4A和权限管理，日志管理，缓存，文件服务，ETL数据集成，消息和通知等，这些也都是在实施微服务架构的时候可能会下沉到基础平台层统一规划和实现的内容。
软件过程改进方面的内容：
企业遵循什么样的软件开发过程和软件生命周期模型？是传统方法还是敏捷方法论？需求，架构，设计，开发，测试，发布完整的流程是如何的？对于配置，变更，评审和Review等过程又是如何的？这些都需要有一定程度的定义和标准。即使实施了微服务架构，也需要遵循传统或敏捷的软件工程方法论。而在微服务架构中，很重要的一个就是微服务模块的划分，微服务API接口的识别和定义，我们可以在传统方法论中进一步补充这方面的内容。
总述
对于企业的微服务架构总体架构设计可以参考下图：
其中关键组件信息描述如下：
l 资源池：提供基础的计算、存储、网络等资源，可以是虚拟化资源、也可以是物理资源，如需对资源层进行弹性调度和精细化管理，可实施IaaS平台；
l PaaS平台：以多租户的形式提供应用运行过程中所需的各类技术服务，与传统PaaS平台不同的是，剥离了中间件服务，即应用部署，此能力由容器平台实现；
l CI/CD（DevOps平台）：提供应用全生命周期所需要的工具和流程，如项目管理、源代码管理、构建、部署、自动化测试、应用看板等；
l 容器平台：提供容器化部署、管理、监控的能力，支撑DevOps平台的部署服务；
l 微服务平台：提供微服务的注册/发现、管理、监控、负载均衡等能力；
l 统一运维：即传统的IT服务管理、IT资产管理等能力；
l 服务中心：各个业务系统沉淀到平台层的共享服务，可支撑上层的多个业务应用；
l 应用层：通过调用和组合服务中心的各类服务，为最终用户提供业务能力。服务中心和应用层均为符合微服务架构的组件；
l 微服务网关：微服务的统一访问接口，提供服务的流控、鉴权等能力；
我们在谈微服务架构的时候更多会谈在开发态的微服务开发框架，而实际上一个微服务架构和DevOps结合后，特别是在运行期最重要的三个组件是基于轻量容器技术的PaaS平台，微服务网关和DevOps平台。
而到了运维期后一个重要的平台就是对微服务架构的自动化监控运维平台。
对于PaaS平台，不是传统的以虚拟机为调度单位的PaaS资源托管和调度平台，而是以Docker容器为调度单位的轻量的PaaS平台。Docker容器既可以部署在虚拟机上面，也可以直接部署到物理机上，同时通过容器平台实现自动部署和部署完成镜像的自动环境迁移，通过Kubernate实现资源动态调度和容器集群的负载均衡能力。
对于微服务网关（或微服务管理平台）最重要的能力就是为微服务提供了注册、发现、路由、负载均衡、断路器、流量管理等功能。可以看到这些能力在传统的ESB服务总线中也都有，但是对于ESB很重要的数据流传输，复杂的遗留系统适配，协议转换等全部不需要了。
对于DevOps我在前面博客文章已经多次谈到过，核心就是实现自动化的流水线作业和发布，要实现这个就需要和持续集成技术，容器化技术紧密结合，并定制相应的自动化脚本来完成。在整个过程中还可以进行相应的自动化单元测试，代码静态检查等工作。具体参看下图：
中台
中台这个概念最早也是在阿里的互联网架构中提出的，对应中台还有一个概念即中心化。有很多人问我中心化的实践方法，当时我还比较纳闷，互联网架构谈的更多的都是去中心化的架构思想，怎么又会出现中心化这个概念。后面经过了解，这个中心化正是指的阿里中台概念里面，下沉到中台里面实现的各个中心，例如产品中心，订单中心，客户中心，库存中心等等。因此今天要谈下中台和中心化里面的一些重要内容。
首先中台里面的各个中心正是各个独立松散耦合的微服务模块，只是这里的各个中心会体现一些特点：
1. 中心是以提供和共享数据和业务能力为主，而不是以提供前端应用功能为主。
2. 中心更多是原来的领域服务层+API接口服务暴露为主。
3. 中心的形成更多是传统应用涉及到的共享业务和数据部分能力的下沉，在能力下沉后再开放共享。
4. 中心属于中台，那么一定会实现一个关键能力，即真正实现前端应用和后台的彻底解耦
在这个初步理解清楚后，接着需要重点考虑的问题就是中台中的各个中心如何识别和定义，由于对于电商类应用构建，我们往往参考阿里当前架构设计中的中心拆分方法即可，那么对于企业围绕ERP信息化的各个业务系统，或者传统企业IT的转型，究竟如何规划中台，如何定义各个中心，以及如何规划各个中心的粒度和复用性？
如何定义中台中的中心，这可以从三个层面去考虑各个中心的定义和识别。
其一：从基础主数据和核心共享数据出发去定义中心，如对于供应商，客户等主数据可以定位为供应商中心，客户中心。对于采购订单，合同，项目等核心共享数据可以定义为订单中心，合同中心，项目中心等。这种中心所有的功能都围绕核心主数据和共享数据展开。例如订单中心，所有功能目的都是最终形成正式和生效的订单，包括前面的采购申请，请购单等都会为最终形成的订单服务。
其二：围绕核心业务展开进行中心的定义，对于企业在进行共享服务中心转型过程中，很多中心都类似该思路建立，比如采购服务中心，财务共享中心，人事共享服务中心，招投标中心等，在这种中心的定义中更加强调了核心业务能力，而不是专门去强调核心业务能力最终形成的业务对象和数据。
其三：基于数据和业务类构建的中心外，还有一类就是以核心业务规则和逻辑构建的中心，这类中心本身不会沉淀核心的业务主数据和共享数据，而重点是业务规则和逻辑的实现，最典型的例子包括了计费中心，调度中心，规则中心等，这些都是实现核心业务逻辑处理为主的中心。
要注意到对于中台中的中心本身也是分层的，最下层更多的是数据类的中心，再上层是业务类+规则类的中心，再上层则是可能跨越多个中心能力组合来实现的流程类中心，比如客户服务中心，流程处理中心等，这些中心重点是组合底层中心提供的服务能力，有点类似SOA中的服务组合和流程编排。因此这类中心很可能自己Owner的数据库很轻，或者根本就没有，一定要注意这点变化。
另外还要注意，各个中心本身不仅仅是提供共享服务API能力，本身也可能是有独立的应用和前端，即中心本身提供前端应用功能，同时又预留足够的外部API接口，可以和外部其它应用进行协同。这是我们对中心的另外一个关键理解。
前后分离
再来分析下在微服务架构实践和实施过程中，在传统企业业务系统转型和迁移到微服务架构过程中比较重要的一点改变就是前后分离。
首先在重申下微服务架构的几个关键点：
1. 原有业务系统拆分为多个离散自治的组件或微服务模块，从数据库到前端完全独立自治。
2. 从单个微服务模块来看，能够实现前端和后端分离为独立的组件
3. 不仅仅是微服务模块间通过RestAPI交互，对于前后端也通过轻量的Rest API接口服务交互。
再简单点来说，如果一个已有的业务系统拆分为4个独立的微服务模块的话，实际在拆分后会有4个独立的数据库实例ID，4个独立的前端JAR包，4个独立的逻辑层JAR包，N个RestAPI服务接口。
对于任何一个企业来讲，只要经营和生产方向没有做出大的转型，其涉及到的供应链，生产，财务流程，包括涉及到基础主数据和核心共享业务单据基本都是固定的，这些是识别中台战略中各个中心的基础。在这里有一个关键的观点如下：
在中台的各个中心规划，定义和建设好后，后续在企业业务发展的过程中，不应该再增加任何大的中心，而是仅仅增加了前端应用类组件和模块。这些模块的构建更多是充分复用已有的各个中心暴露的接口服务能力，为各个中心提供数据，或者消费和使用各个中心已有的数据或业务规则能力。
一个中心在构建的时候，能力的开放性不仅仅体现在暴露已有的数据服务能力，而更加重要的是提供外围数据导入的能力，或者类似网管里面的叫法，提供完整的南向接口和北向接口服务能力。
我们可以举例来说，拿订单中心的构建来说：
最初我们考虑的更多的是正式生效的订单能力以RestAPI接口服务的模式暴露出去，给其它微服务模块和前端应用使用，即已有数据以查询服务方式进行服务能力开放。但是对于订单的生产后续会产生类似通过招投标模块，通过合同系统，通过计划管理模块等多个外部渠道都可以产生订单，即订单的生成不一定非要在订单中心模块中完成，而是可以从外部导入，那么这个时候就需要提供完整的订单导入类接口。
再拿简单点的方式来说，按照完全的前后端分离的构建模式，订单中心的构建更多仅仅是提供订单数据的存储，订单生产的业务规则校验，订单能力的发布，而对于订单如何录入，如何消费等前端应用功能全部不在订单中心中构建，订单中心只把数据和业务规则管理好即可。
在ERP系统的实施过程中，可以看到围绕ERP和ERP外围系统建设很多时候类似该思路，即ERP中的采购，库存等模块进行了中心化，更多的只是提供服务能力接口处理，管理好最终的数据和业务规则逻辑，而对于数据的导入全部都是外部的类似采购系统，合同系统，项目管理系统等外挂系统导入。
因此对于前后分离一般包括了两种典型的实施场景：
1. 中台中的各个中心完全没有前端应用，不录入单据，只提供服务能力接口。
2. 中台中的各个中心既含前端，也含后端逻辑，但是提供完整的南向开发能力接口支持数据导入。
不论是上面哪种方式，我们建议的仍然是对于前端和后端能够完全分开，后端重点是形成完整的提供领域服务能力的微服务模块，前端重点是能够实现接口服务的组合和拼接，形成满足业务需求的功能。
技术平台
微服务架构强调将传统的单体应用打散为从数据库到中间件到部署包(前端+后端）完全独立的多个松耦合的微服务模块。简单来说仍然是传统的业务系统要实现业务组件化拆分。
而传统业务系统包括了 技术平台或组件 + 业务组件1 + 业务组件2 + ... + 业务组件N
我们再来简单举例说明下：
采购系统 = 采购技术平台 + 招投标模块 + 采购订单管理模块 + 供应商管理模块
库存系统 = 库存技术平台 + 出入库管理模块 + 台账模块 + 配送模块
而这个时候采购技术平台和库存技术平台本身具有大量的重复内容，包括了常说的4A和工作流引擎，也包括了类似消息，缓存，日志处理，文件存储，短信邮件等各种技术模块。那么我们首先要考虑到的就是首先将传统业务系统中的技术平台部分剥离出去，统一下沉到公共的技术平台层构建，构建完成后再以能力开放接口的模式供上层业务模块调用。
因此共性技术能力下沉到技术平台，使得传统业务系统只剩余和业务相关的功能模块，是后续进一步进行业务系统模块化和组件化的基础。否则每一个微服务模块都要带流程引擎，各个技术组件，这些大量重复的内容在后续运维中将是灾难性的。
微服务架构中的平台包括： 技术平台 + 业务平台（数据组件+业务组件（各个模块化业务中心））。
在微服务架构里面也不再有主数据平台的概念，但是一定会有数据类微服务模块的概念，对于供应商中心，人员中心，用户中心，客户中心等，这些都是典型的数据组件，向外提供数据服务能力。
技术平台 = 技术组件1(技术组件+技术服务开放） + 技术组件2 + ... + 技术组件N
注意每一个技术组件都可以作为独立的微服务模块独立开发并部署，然后提供技术服务API能力接口出来。也就是说技术平台中的技术组件本身也是微服务模块化的，可完全实现分散部署和独立管理。
对于技术服务由于具有很大的并发调用量，因此走传统的ESB总线集成模式是不合适的，更好的丰富还是走轻量的SOA总线，能够实现统一的服务目录管理，鉴权和路由接口。同时对于技术服务类接口可以采用更加轻量的RestAPI
服务接口来实现并暴露。
要注意到在技术平台下沉后，原有一个业务系统全部能完成的事情变化为了需要多个业务模块，多个技术模块相互配合和协同才能够搞定。可想而知，这个时候集成复杂度是指数级增加，同时对各个微服务模块本身的高可用，高可靠性要求更加高，任何一个微服务模块出现运行故障都可能影响到整体业务。
可以参考下图来理解：
如果一个业务系统有4个模块，在进行微服务架构拆分后，即使技术组件只有三个独立的技术服务模块，那么也是会有20个集成点，可能上100个服务接口交互才能够完全还原回原来完整的业务系统能力。同时对于平台层任何一个技术组件模块出现故障，都直接会影响到上层的业务组件模块。
如果我们对技术组件建设的健壮性没有足够的信心，而轻易去实施上图这种转变，不仅仅是不能为最终的业务用户提供一个高可用性的业务系统，更重要的是在后续运维过程中仍然是灾难性的。当一个企业本身的技术能力成熟度没有到一定水平的时候不要轻易去尝试上述方法。即使技术能力下沉，也只是集中化共建4A和流程平台能力即可。
实施步骤
步骤1:4A和流程平台的下沉和能力开放
这个是我谈的最多的问题，即在实施微服务架构转型的时候必须将4A（也可先狭义理解为原业务系统的系统管理模块）和流程引擎下沉到平台层共性建设，或者说优先要将这两个模块做为微服务模块剥离出来，同时给上层的业务组件模块提供API服务接口能力。
对于4A模块剥离后，我们希望的是涉及到人员，组织，用户，权限等能力的获取都是通过服务接口实时查询获取，这些基础主数据信息也不要落地。在进行这样实施的时候确实会增加上层业务系统的改造工作量。对于流程平台的签出相对来说比较容易，最主要的还是给业务模块提供流程启动，暂停，获取待办已办列表等关系服务接口信息为主。
进行4A和流程平台的剥离核心目的仍然是是的后续需要进行拆分的业务模块只包含业务功能，而不再包含共性的技术能力功能。
步骤2：基础主数据模块能力独立建设
这是我们谈的第二个重点，即希望将提供共享基础主数据的功能单独剥离出来进行独立建设，比如建设独立的主数据平台或叫提供基础主数据的各个数据中心模块。然后数据能力以数据服务的方式暴露出去供上层业务系统使用，同样我们希望上层业务模块在使用这些基础主数据的时候最好主数据不落地，实时用实时查。
在传统PaaS平台建设中会涉及到MDM主数据平台的建设，到了彻底的微服务架构可能并不存在主数据平台的概念，而是各个类似产品中心，供应商中心，客户中心的各个微主数据中心模块，这些微服务模块也是我们常说的中台的核心数据能力提供中心。
要规划和建设中台，首先要考虑的就是这种基础数据中心，其次才是提供业务支撑和业务逻辑处理的中心。
步骤3：业务模块的拆分到微服务模块或逐步剥离出来
我们一直在讲，传统企业的微服务架构转型是一个渐进的过程，是一个老的IT架构逐渐被新架构替换，老架构逐步消亡的过程。在步骤1和步骤2这种共性的基础技术和数据能力下沉后，剩余的业务系统迁移和微服务模块拆分就可以开始逐步进行，逐步签出。
对于一个业务系统的业务模块逐步剥离出来，一个关键的策略就是优先剥离耦合性最低的业务功能模块，在这个思路下最可能的实施策略就是先将业务系统支持流程的两端（最前端流程或最后端流程）逐步剥离出来。因为两端的流程往往是耦合性最小的流程。
拿采购系统来举例，前端的招投标模块是最容易剥离出来的，后端的采购过程跟踪，采购评估等模块往往也是最容易剥离出来的。这里拿招投标模块来举例。
注意招投标模块在剥离出来后，横向的交互接口往往并不多，最多也就是招投标执行过程的结果信息或配额信息需要传递到采购管理模块。而对于招投标本身的一些结果数据已经可以下沉到平台层的主数据模块中，而设计到流程处理部分也已经下沉到平台层的流程引擎模块，因此可以看到只要步骤1和2迁移到平台层后，再迁移出招投标模块基本就很容易了。
步骤4：及早的进行统一门户的建设
要注意，在各个微服务模块建设完成后，单个微服务模块本身是不能提供支撑完整业务流程的能力。对于用户来说并不关系是否进行了微服务架构化，而是关心涉及到业务流程处理的功能和操作是否能够很方便的在一个业务应用里面操作和完成。
而这些业务模块基于业务流程，基于业务场景和使用部门的组装和展现，就需要在门户层完成。对于统一门户不仅仅是提供统一认证和单点登录，也还包括了统一的待办集成和任务处理，统一的消息通知等共性功能能力。也就是说，只要是各个微服务模块共性的一些需要展现的能力，都可以集中化到统一门户层去集中处理和展现。
门户层还有一个重要的功能就是进行微服务模块的组装，这些模块组装后可以为业务用户提供完整的端到端业务流程功能支持，让最终用户的感觉就是在使用一个系统，没有系统不停切换的感觉。因此实际上在门户层不仅仅是简单的模块选择，也还可以做一些展现层的编排和组合工作。
对于微服务模块的灵活组装也是相当困难的，因为很多模块组装最终都是体现到模块提供的南北向接口的自动对接，这往往是比对服务组合和服务编排进行定制更加困难，对于这个问题后续将在单独进行讨论。
门户建设
在统一门户的规划和建设过程中，有一些关键点说明如下：
关于4A类功能的建设
对于4A层面的内容，或者说至少要实现单点登录和统一认证，统一用户和统一授权。企业在规划建设的过程中可能没有独立的4A系统，那么这些内容可以规划到统一门户里面来集中化建设。在这块内容简单的过程中有几个关键点，需要在统一门户建设中注意。
1. 实际的统一认证仍然是在LDAP库，因此需要门户和LDAP库集成实现统一认证过程。
2. 门户实现统一用户和账号管理，实现用户对业务系统或模块的授权，这些信息从门户朝下游系统分发。
3. 单独登录的过程相对授权来说是一个反向过程，但是最终的验证仍然需要由LDAP验证完成后返回。
4. 对于组织和人员的分发，即可以由HR系统直接分发到业务模块，也可以通过门户分发到业务模块，这里面的一个关键点是临时人员和临时组织在哪里管理的问题。如果存在临时人员和组织在门户系统统一管理的话，那么最好的方式是由门户进行人员和组织的分发。
关于单点登录
对于单点登录是门户系统建设必须实现的一个功能。常见的做法可以描述为：
1. 业务系统获得token，根据实现方式，可由其它系统传递，也可从公共位置获取
2. 若无token(未登录过或token已过期)，则弹出登录窗口并调用4A服务认证，认证通过发放token
3. 取到token后，使用token调用4A服务进行验证，验证通过后带着加密后的token信息进入业务系统
4. 在进入业务系统的时候，业务系统根据token进行验证，而不需要再在业务系统进行重复登录和密码验证
在单点登录实现后，就很容易实现各个业务系统，已经门户到各个业务系统间的页面集成和直接跳转。如果保持一套UI/UE规范，那么对于最终业务用户来说，完全可以做到最好的感知，即整体感觉就是在操作一个业务系统或应用的效果。
关于统一待办
统一待办是门户建设的另外一个关键内容，要注意在没有进行统一统一门户系统建设的时候，很多企业会把统一流程引擎和统一待办全部放到OA系统里面来实现。即把OA系统的工作流引擎上升到为各个业务系统提供流程引擎能力的公共流程平台。对于统一待办，已已经规划建设了统一流程平台来举例来看，统一待办如何集成和实现的问题。
1. 建设了统一流程平台后，所有的待办都在流程平台，因此门户只需要和流程平台集成。
2. 流程平台提供获取统一待办信息查询服务接口，门户调用该接口获取统一待办。
3. 建议是统一待办信息的获取完全可以做到数据不落地，即实时用实时查(并发量会很大，因此解决性能问题是关键）
如果做到待办信息不落地，那么就不再存在需要对落地的待办信息进行动态刷新的问题。因为在传统的统一待办解决方案里面，待办信息会推送到门户系统进行落地，那么实际在业务系统处理完成待办后就必须通知门户对待办列表进行刷新。如果这个刷新出现问题，就会出现待办数据在业务系统已经处理，但是在门户中还能够看到待办这种不一致性的情况。
在待办信息列表中，通过处理超链接，再加上前面已经实现的单点登录，就很容易通过传统Token方式实现跨业务系统或模块的页面集成。要注意对于页面集成是比底层的数据交换和集成，已经到服务层的业务服务集成更优的方案，可以最大程度减少跨系统的接口服务调用，已经底层数据集成的数据交换带来的数据不一致。
关于消息和通知
对于消息，通知，包括公告等也是属于门户建设的一个关键内容。这类功能更多的是知会最终用户，而不需要实际处理和反馈。因此既然集中了统一用户，统一登录，那么对于消息的通知也最好能够集中和统一。对于消息通知的统一，相对来说比较简单，只需要集中门户提供一个消息导入的接口服务，由各个业务系统将需要实时通知的消息导入即可。对于消息通知一定有范围，可以通知到一个人，也可以通知到一个组织或一个群组，这些都需要能够做到灵活配置。
关于门户层功能和页面编排
对于这点，绝对不是简单的实现一个功能菜单的配置，收藏夹或快捷操作的配置功能。这只是门户层页面功能集成最简单的一个实现。在这里我们提出一个新概念，即是否能够在门户层实现一个页面级的功能编排功能，这个功能可以实现基于业务流程或业务场景的业务功能的操作组合以方便最终的业务系统用户使用。
对于具体的页面编排，其复杂度实际上不亚于服务组合和流程编排，我们可以先构思一个最简单的业务流程场景举例来说明，比如一个完整的采购流程可能涉及到供应商和物料信息录入，采购请购，采购订单，采购接收等几个关键功能。那么实际在采购里面既有端到端流程的思路，将这些离散的独立功能衔接到一起。比如我们提供一个完整的端到端流程的引导页面，从提交采购需求开始，到拟制采购订单，再到采购执行和跟踪，采购入库，采购付款等将这些流程相关功能展现到一个完整的端到端流程中。
最终的用户只需要按照类似Wizard向导的思路按着步骤一步步的朝下面操作即可。通过这种完整的基于流程的向导式页面完全将离散的功能集成到一起，而实际上这些功能的提交本身涉及到MDM主数据模块，采购订单模块，库存模块等，但是这些底层的各个微服务模块或拆分并不需要最终用户关心。用户关心的仅仅是基于业务流程和场景的操作是否方便，是否能无缝衔接的完成，同时方便后续跟踪和监控。
开发过程思考
在这里我们还是举一个例子来说明比较好，比如企业需要建设一个采购管理应用，那么经过分析后你会发现可以将采购管理应用拆分为招投标，采购管理，供应商+物料基础数据管理三个独立的微服务模块来做，同时这三个微服务模块可以分给不同的开发团队来做。
基于以上场景，首先我们看到，在进入三个微服务模块的并行开发前，有一个重要的工作必须要做，就是整体的总体架构设计，其中需要包括业务架构设计，整体功能架构设计，数据架构设计，整体集成架构和接口设计。我们一直在讲这个工作实际上是很难分解到各个微服务模块开发中自己去做和完成的，仍然需要有个总体的方案设计，定义清楚各个微服务模块的业务和数据边界，定义清楚各个微服务模块需要实现的功能和对外接口。这个定义清楚才是开始进行微服务模块功能开发的基础。
在微服务架构中，有一个重点就是涉及到的组织过程支撑和团队结构的改进，简单来说就是前面应该有总架构，后面有总集成，而中间则是完全可以相对独立的微服务模块开发团队。每个团队都可以配置自己的需求，设计开发，测试人员，完成自己负责的微服务模块的交付和集成。同时总集成角色完成对所有交付微服务模块的端到端基于业务场景的集成工作。
把上面这个思路讲清楚后，我们再来举最简单的场景来说明。
总架构+并行分解+中集成的整体思路
对于采购订单管理微服务模块开发团队，他们拿到的需求和总架构设计应该包括哪些内容，即至少应该包括我这个微服务需要实现哪些业务功能，需要消费哪些微服务模块提供的接口服务，同时需要暴露哪些接口服务给下游的微服务模块使用。只有这个搞清楚了才能够启动内部的需求设计和开发工作。
那么简单来说做初步梳理：
1. 采购管理模块需要实现采购框架协议，采购订单，订单变更，采购执行跟踪几个功能。
2. 需要消费招投标模块提供的招投标结果信息，需要消费基础模块提供的供应商和物料查询接口服务。
3. 需要提供采购订单查询信息服务给下游模块使用。
那我们如何去消费招投标模块和基础数据模块提供的接口服务呢？这些接口服务本身的定义和消费说明又在哪里？而这部分内容整合体现在微服务整体架构中的微服务网关部分的能力，即微服务网关不仅仅是提供服务注册，寻址，路由，安全，流控等功能，同时还需要提供服务目录发布功能，服务订购功能等。
采购管理模块首先应该到微服务网关发布的服务API目录查看有需要订购哪些服务，同时进行服务订购，同时服务首先在开发测试环境进行服务开通，同时也需要将自己需要发布的服务注册和接入到微服务网关以方便别的系统使用。
注意这里的关键是在开发阶段，各个微服务模块就是独立和拆分的，在开发环境就有一套独立部署的微服务网关并发布服务能力，如果脱离这块那么单个微服务模块也跑不起来。即使是在我本机做我自己开发的微服务模块的测试和Debug，也需要访问到到开发环境提供的微服务接口服务能力。
这种方式虽然增加了依赖，但是一个最大的好处就是做采购模块的开发团队完全不用去关心招投标模块和基础数据管理模块的代码和项目，只需要关注其它两个微服务模块发布出来的接口服务即可。所有的交互都是通过接口服务进行，没有其它的渠道。
进一步结合容器和DevOps后带来的一些新差异点说明
在前面这个概念理解清楚后，再来看微服务架构开发过程中和容器化技术和DevOps过程的集成过程中带来的一些新差异点。我们假设这块会有一个独立的DevOps支撑平台来提供这些支撑能力。
那么我们来看这个过程应该是如何的。
采购管理微服务模块首先要做的就是写好自己的自动化构建脚本，构建脚本要做的就是完成配置管理库的自动Update，同时运行自动编译基本进行自动编译。编译完成后进行自动的打包。
在打包完成后需要自动能够部署到测试环境中去，在这个过程中涉及到自动部署就可以和Docker容器能力进一步集成，包括了镜像的生成，基于镜像的自动部署。当然在这个之前需要先基于IaaS资源池能力在上面再部署一次Docker容器。
在这个过程中我们还需要解决一个重要的事情，即微服务模块本身的接口发现和自注册。比如来说采购订单模块需要发布5个RestAPI接口服务能力，这5个接口服务需要能够自动的注册到测试环境的微服务网关中并进行发布。由于每次部署后容器的IP地址都能够在变化，因此就需要微服务网关提供一个能力将最新的IP地址信息注册到微服务网关里面去，通过网关形成一个统一的负载均衡IP再发布出去。
也就是说不管自动部署和动态容器化和IP变动过程是如何的，我们都需要微服务网关提供一个能力把底层的变动给屏蔽掉，提供一个统一的测试环境IP和地址出去。即采购模块在进行测试环境部署的时候，按道理这个模块是可以提前配置好它需要访问的其它微服务模块提供的测试环境RestAPI接口服务地址的。
只是采购模块完成自动化构建和部署，那么这个微服务模块很多功能都跑不通，只有招投标，采购管理，基础数据三个微服务模块全部构建通过后整个应用才能够跑通。
架构设计和概要设计
需要做完整的架构设计工作，即一个原来的业务系统需要拆分为几个微服务模块？在这里一直强调过微服务模块不适合拆分的太细，拆分的越细整个集成和管理的复杂度越大。
架构设计阶段要考虑清楚的就是首先要拆分为几个微服务模块，其次各个微服务模块的对应的数据库数据表的Owner究竟是谁？即微服务模块的拆分不仅仅是前端功能的，更加重要的是后端数据库层面的。再次拆分到微服务模块后，各个微服务模块应该暴露哪些API接口服务，同时又需要消费哪些API接口服务。
同时对每一个接口服务，应该已经有详细到字段级的接口规范和契约文件定义。
也就是要做到最终形成的概要设计文档应该是每个微服务模块一个，每个微服务模块可能是独立的开发团队在开发，那么他们拿到这个概要设计文档后，不仅仅是清楚该模块要实现哪些业务功能，更加重要的是要清楚这个微服务模块的底层数据库表如何建？同时这个模块需要提供哪些接口出去，同时又需要消费哪些外部接口。
当一个小团队拿到一个微服务模块的时候，跟外围的关系全部能够理清楚，这是最基本要达到的要求，只有这样才能够真正做到各个微服务模块的需求，设计，开发，测试，部署等一系列工作是松耦合和相对独立的。
详细设计和开发阶段
各个模块的开发要完全独立，也就是在开发环境中对于工程项目打开的时候只看到你当前做的微服务模块。其它微服务模块完全不用在当前项目中打开，也就是开发环境中各个微服务模块中的项目也完全是独立开的。
我们来假设下这个业务涉及到A，B，C三个模块，当前工程打开进行A模块的项目开发。
这个时候本身又有两种思路，其一就是在A模块开发的过程中，将B和C模块的Jar包直接引入进行开发，这个在本地可以是调的本地Java
API，但是发布到测试环境后则调用RestAPI接口。其二是在本地开发的环境就直接配置为访问远程的开发环境的API接口服务，这样即使在本地开发环境测试也需要开发环境的API服务网关和其它模块的配合才能够完成。
怎么讲呢？也就是为了各个模块都能够并行，完全相互不影响的开展工作，需要的就是各个模块先开发对外暴露的接口服务能力，里面可以先不实现规则和逻辑，只要能确保数据能够查询出来后，或接收到的数据能导入即可，因为要完成这部分接口开发只需要有对应的数据库和表就能够完成。
测试和联调阶段
每个模块在进行自动构建并发布的时候，要确保对自己模块提供的所有API进行自动化的单元测试，并确保单元测试通过后再发布到测试环境。否则将影响到其它微服务模块对接口的消费和使用。
对于微服务模块需要对外暴露的微服务API接口，我前面一直在说最好是做到当微服务模块编译构建并部署到测试环境的时候，能够将需要暴露的API接口服务自发现，自注册到微服务网关上面。这样将大大减轻我们手工在微服务网关上进行注册的工作。
在单个微服务模块进行测试的时候，首先：需要对自己需要访问和消费的所有微服务API接口进行自动化的冒烟测试，确保没有问题。然后再进行微服务模块里面详细的功能点测试。
按道理，即使在企业内部多个微服务模块间，比如微服务模块A需要调用微服务模块B的微服务，最好也需要进行服务订购，然后进行访问授权。否则后续微服务的调用很难进行安全和访问控制。
在微服务架构体系下，个人认为最大的复杂度增加都在后续的微服务模块间的相互集成和联调上面。要注意在互联网企业或互联网很多应用中，更多的是上层应用模块调用底层各个微服务模块的API能力；而在企业内应用最大的不同的就是上层的业务微服务模块之间有大量的横向相互调用，则就对微服务模块的集成顺序，集成过程提出了相当高的要求。这也是为何我一直强调微服务模块不要拆分的太细的原因。微服务模块内部你可以再细分模块和组件，但是这些模块和组件之间不再独立进行设计，部署和运维。 |
