企业微服务架构转型从技术平台到平台应用的建设模式

　　在很多中台整体架构规划里面，提出了技术中台的概念，实际上这里叫技术平台更加合适。中台体现的是共性业务能力下沉，并将其形成可复用的API能力提供给上层应用使用。那么技术平台强调的就是共性技术支撑能力的统一建设和能力开放。技术平台概述
　　微服务架构强调将传统的单体应用打散为从数据库到中间件到部署包(前端+后端）完全独立的多个松耦合的微服务模块。简单来说仍然是传统的业务系统要实现业务组件化拆分。而传统的单体应用往往包括了技术组件模块和业务组件模块共同组成。
　　简单举例说明下：采购系统 = 采购技术平台 + 招投标模块 + 采购订单管理模块 + 供应商管理模块
　　库存系统 = 库存技术平台 + 出入库管理模块 + 台账模块 + 配送模块
　　这个时候采购技术平台和库存技术平台本身具有大量的重复内容，包括了常说的4A和工作流引擎，也包括了类似消息，缓存，日志处理，文件存储，短信邮件等各种技术模块。
　　那么我们首先要考虑到的就是首先将传统业务系统中的技术平台部分剥离出去，统一下沉到公共的技术平台层构建，构建完成后再以能力开放接口的模式供上层业务模块调用。
　　因此共性技术能力下沉到技术平台，使得传统业务系统只剩余和业务相关的功能模块，是后续进一步进行业务系统模块化和组件化的基础。否则每一个微服务模块都要带流程引擎，各个技术组件，这些大量重复的内容在后续运维中将是灾难性的。
　　微服务架构中的平台包括：技术平台 + 业务平台
　　业务平台中包括提供核心业务能力的组件，也包括了提供核心数据能力的组件，比如规则中心微服务重点是提供业务逻辑能力，而供应商微服务重点则是提供数据服务能力。
　　在微服务架构里面也不再有主数据平台的概念，但是一定会有数据类微服务模块的概念，对于供应商中心，人员中心，用户中心，客户中心等，这些都是典型的数据组件，向外提供数据服务能力。
　　技术平台 = 技术组件1(技术组件+技术服务开放） + 技术组件2 + ... + 技术组件N
　　注意每一个技术组件都可以作为独立的微服务模块独立开发并部署，然后提供技术服务API能力接口出来。也就是说技术平台中的技术组件本身也是微服务模块化的，可完全实现分散部署和独立管理。
　　对于技术服务由于具有很大的并发调用量，因此走传统的ESB总线集成模式是不合适的，更好地丰富还是走轻量的SOA总线或服务注册管理中心，能够实现统一的服务目录管理，鉴权和路由接口。
　　同时对于技术服务类接口可以采用更加轻量的RestAPI 服务接口来实现并暴露。
　　要注意到在技术平台下沉后，原有一个业务系统全部能完成的事情变化为了需要多个业务模块，多个技术模块相互配合和协同才能够搞定。
　　可想而知，这个时候集成复杂度是指数级增加，同时对各个微服务模块本身的高可用，高可靠性要求更加高，任何一个微服务模块出现运行故障都可能影响到整体业务。
　　如果一个业务系统有4个模块，在进行微服务架构拆分后，即使技术组件只有三个独立的技术服务模块，那么也是会有20个集成点，可能上100个服务接口交互才能够完全还原回原来完整的业务系统能力。同时对于平台层任何一个技术组件模块出现故障，都直接会影响到上层的业务组件模块。
　　如果我们对技术组件建设的健壮性没有足够的信心，而轻易去实施上图这种转变，不仅仅是不能为最终的业务用户提供一个高可用性的业务系统，更重要的是在后续运维过程中仍然是灾难性的。
　　当一个企业本身的技术能力成熟度没有到一定水平的时候不要轻易去尝试上述方法。即使技术能力下沉，也只是集中化共建4A和流程平台能力即可。最小化技术平台构建
　　做软件开发的往往都清楚，对于新开始一个软件项目或软件开发，特别是从零开始组建软件开发团队到开发完成并交付，最开始一个重要的工作就是要搭建一个最小化的基础开发框架，基础平台和公共组件能力，这个步骤完成了才是拆分相关的功能模块，然后安排不同的开发人员进行开发和集成。
　　能够完成这个基础支撑平台的搭建，并确定好标准的开发框架和模式，拆分好开发模块和组件，虽然说不一定能叫一个完整意义上的软件架构师，但是已经至少具备了开发组长的能力。一个公司如果从头开始做软件项目，那么最重要的就是要有能够完成上述工作的开发组长的角色。
　　一个软件团队开发完成一个软件项目，哪怕是很小的项目后，一定会有这种公共组件和开发框架的积累，那么在后面接手新的项目的时候很多内容就可以复用原来已有的内容。同时在新的软件开发过程中进一步对基础支撑平台进行功能完善，能力增强。
　　对于善于总结和复用的软件开发团队或架构师，你就会发现后续的新项目开发工作越来越简单，基本上对于标准的技术平台和共性能力你都不用考虑，而只需要考虑业务功能的实现即可。但是有时候也有糟糕的情况，就是一些架构师太痴迷于新技术，对于基础框架和架构总是不断地更换，只要有什么新的流行技术一出来就恨不得马上应用到项目里面去，只用最新的而不是用最合适的，这种思路也极大的增加了平台开发运维成本投入，同时也很难真正形成持续化的技术积累。
　　记得09年做项目的时候，项目团队也是基本每年就换一个框架，类似Ext，传统的jsp,html，Flex，Tapstry5等各种框架都应用了一个遍，最终才最近几年基本固定在JQuery框架上面进行了进一步的封装和固化。里面也走了大量的弯路，投入了大量的重复开发工作量，而这些本身是在前期做好规划和选型完全可以避免的。
　　其实对于最小化技术平台的搭建，我们从一个独立的单系统项目和组织级的大集成项目两种场景来进行分析和说明。
　　独立的单个系统项目
　　如果是构建单个业务系统的基础平台，那么相对来就简单了很多，但是实际上做起来细节的事情仍然是比较多，初步分析也应该包括如下几个方面的事情。1. 初步的UI/UE界面风格要确定下来 2. 采用的开发框架要确定下来，具体是几层架构，数据层，前端展现等各自用什么技术都要定下来 3. 提供最基本的核心系统管理模块能力(用户，角色，授权，组织，菜单，数据字典等） 4. 基础的登录功能实现，并整理提供完整的Session对象值 5. 对于有流程需求的需要提供基础的流程引擎能力，不一定完整，但是具备间的流程审批和流转能力 6. 公共技术组件模块(提供一些类似公共函数，缓存处理，日志封装，异常封装，安全等基础能力)
　　实现上述内容后能够达到了一个效果就是，具体的业务需求可以划分为不同的业务功能模块，并将功能模块的开发安排给不同的开发人员去实现了，即基础底层能力已经具备，开发人员只需要实现功能并集成到整体框架里面来即可。
　　在这个过程中，有复用意识的架构师或开发组长一定要多做CodeReview工作，即通过Code Review来发现有哪些需要进一步抽象的公共组件和方法，并将其统一提供到公共的组件模块里面，以减少整体项目里面的各种重复代码，并提升代码的可维护性。
　　传统的软件开发团队做项目如何做？
　　就是形成上面这个基础的开发框架和平台，然后再接到新项目后，将上面的这个集成平台和公共组件内容完整的拷贝一份出来（新拉一个分支），然后再来开发新的业务子系统。这个时候平台层还很难做到完整的黑盒级别的复用，但是基本可以实现新项目开发不需要再过多考虑这部分内容。
　　由于会全部拷贝出来，容易引发的问题就是在新的项目中对基础组件又进行修改，导致后续基础平台存在多个维护中的版本。因为这个原因，最好的方法仍然是对于基础组件平台最终成型后，最好的方式是提供类似Jar包引入的方式进行黑盒级别的复用。以确保基础平台的版本唯一性。
　　开发多个子系统的大型集成项目
　　在这种情况下，基础平台就不是仅供一个项目使用，而是需要为多个项目提供服务，类似我们前面很多文章都谈到的平台+应用模式，企业私有云PaaS平台建设。在为多个业务子系统提供平台层能力支撑的时候，那么一个关键就是这个平台不会再内嵌在业务系统里面，而是应该独立进行建设和部署，并将平台层的能力通过接口的方式开放出来供上层应用使用。在这种模式下平台层的建设一般会包括如下内容：1. 独立的门户集成能力，提供门户，统一身份认证，单点登录能力。 2. 提供4A能力，特别是统一用户和统一授权，该能力可以集成在门户中统一提供。 3. 提供公共的流程平台和流程引擎能力，对流程建模，执行，监控数据全部集中在流程平台中管理。 4. 提供一些关键的技术服务能力（其中包括消息，缓存，日志，安全，文件处理等） 5. 整体的UI/UE标准规范制定，开发框架规范和技术制定。
　　其中1到3基本是一个最简单的公共支撑平台必须提供的，而对于4一开始可以先不提供，由各个业务系统自己去提供和解决。由于上述内容已经抽象到公共平台进行统一提供，因此对于上层的业务子系统开发就更加简单，具体包括的内容为：1. 提供最基本的核心系统管理模块能力(用户，角色，授权，组织，菜单，数据字典等） 2. 公共技术组件模块(提供一些类似公共函数，缓存处理，日志封装，异常封装，安全等基础能力) 3. 使用统一平台和整体应用架构制定的UI规范和开发框架进行开发
　　这也是我们常说的厚平台+轻应用的模式，即能够复用和共性的内容尽量下沉到平台统一提供，上层的业务应用开发只需要关注业务流程和业务逻辑实现，而不再需要关心技术的内容。如果再将SOA思路实现得更加彻底，就是上层进一步拆分为业务组件层，和业务组件组装和编排业务层。
　　由于底层基础支撑平台的独立，上层门户的独立，那么中间就只剩下实现各个业务功能的业务组件模块，而这些业务组件模块拆分好后完全可以实现高度的松耦合的独立自治。而这也是传统架构转为理想的微服务架构的一个标准演进路线和趋势。平台+应用的构建模式
　　在2013年开始写企业私有云PaaS平台建设，里面谈的最多的就是SOA+云计算，平台+应用的构建模式，同时在里面又涉及到组件化和服务化处理，技术服务提供，因此是一个厚平台+轻应用的构建方式。虽然大部分内容是在2013年写作完成，但是到现在来看这些建设和思路仍然是值得大部分企业在进行传统IT架构转型的时候考虑。
　　对这本书内容感兴趣的可以网上书店搜索《SOA与大数据实战：企业私有云平台规划和建设》，里面对这部分内容有详细的介绍和说明。
　　平台+应用的构建模式本质是云计算+SOA关键思路的最终体现，通过业务系统共性能力下沉形成云平台层的能力，同时通过SOA思想将平台层共性能力通过API或接口服务的方式开放出去供上层应用使用和组装。其次，对于当时我们谈得比较多的业务模块拆分，组件化思想则是当前主流的微服务架构思想的体现，即将传统的大单体应用拆分为松耦合的微服务模块。
　　一个典型的平台应该包括技术平台，数据平台，中间件平台方面的内容。
　　技术平台重点是提供各种典型的业务无相关的技术服务能力，其中包括了缓存，消息，日志，文件，任务，通知等，当然也可以包括我们常说的4A加流程引擎平台；而一个数据平台重点则是提供基础数据能力，如我们常说的MDM主数据平台，当然也可以是共享数据中心，提供静态+动态共享数据能力；而对于中间件平台才是传统说的PaaS技术平台，提供数据库和中间件资源池能力，提供应用托管和资源动态调度能力，从最传统的CloudFoundry等技术平台转变到当前以Docker容器+K8s为核心的轻量化容器调度平台。
　　如果在大的应用架构里面，上面谈的平台更多的仍然是技术平台层面，在技术平台上面则是需要我们去构建的业务应用，只是当前对于业务应用部分我们进一步进行分层，即业务应用本身是有前端应用+业务中台构建成的完整应用。
　　而业务中台我们完全可以理解为业务平台，你也可以理解为前面的数据平台内容没有，而都是在业务中台里面进行完整构建。中台由各个我们常见的中心组成，一般又分为两类，一类是以核心数据中心形成的中台模块，如产品中心，订单中心，客户中心等；另外一类是以业务逻辑处理为核心形成的中台模块，例如计费中心，结算中心，调度中心等。这两类中台模块提供完整的数据能力和业务规则逻辑处理能力，那么在这个业务中台上面构建的前端应用就更加轻量化。
　　也就是说平台+应用构建模式可以分解为 技术平台+业务中台+前端应用。
　　我们所有做的努力都是为了使前端应用尽可能的轻量，只有前端应用足够轻量，才能够快速地响应业务需求的变化，前端不实现具体的业务规则，不管理数据，而只是对各种中台层提供的API服务能力接口进行组装和编排，以满足完整的业务流程和需求。
　　把这个想明白了后，传统企业IT应用和系统的架构方法将发生重大的转变，即我们先是构建完整的技术平台，提供最基础的共性技术能力，该技术平台既包括了设计态的技术开发框架和环境，又包括了运行态的技术服务能力提供，托管和运行环境提供等。在技术平台构建完成后再进行业务中台模块的构建，中台模块构建完成后进行前端应用模块的构建。中台模块可以订购技术平台的技术服务能力
　　前端模块可以同时订购中台模块的业务服务能力，同时也订购技术平台技术服务能力
　　在基础平台搭建完成后，我们在前面讲过最好是提供一个完整的门户类应用，在彻底微服务模块化后企业就只有一个门户应用，其它应用都应该是灵活组装出来的，因此我们只需要构建一个完整的门户，那么后续我们构建的各个中台模块，前端应用模块都可以很灵活地加入到这门户中，也就是说配合微服务DevOps持续集成能力，按道理最终发布的模块可以直接发布和集成到门户里面去。
　　我们来举一个最简单的例子。
　　一个企业原来已有采购管理模块并集成在门户里面，但是没有招投标模块，我们把招投标模块作为一个独立的微服务模块进行构建，在构建这个模块的时候我们完全不用做系统管理，流程引擎，技术组件等模块，只需要考虑业务需求的实现。
　　同时我们首先申请需要构建一个新模块，分配独立的模块ID和账户，同时对该模块进行相关技术服务和业务服务的订购，在这些完成后进行该模块的开发和测试，在测试完成后直接对模块进行发布，发布完成后在门户上就应该形成一个新的招投标模块的人口链接。这就形成了一个完整闭环的模块动态发布和添加的过程。
　　要完成上面这个理想化操作可以看到需要做的内容相当多1. 集中化的云门户能力，可以集成4A模块能力在里面 2. 公共流程平台能力，提供对流程设计，运行和监控的统一管理 3. 基于Dock容器+Kubernates的PaaS轻量平台，包括DevOps的支撑平台 4. 服务总线能力，可以是轻量的微服务网关，也可以类似OpenAPI能力开放平台 5. 微服务架构开发框架和开发环境 6. 实现各种技术服务能力提供的技术平台
　　上面这些内容必须形成一个完整的整体，才能够形成初步的平台+应用的构建模式。