企业传统IT架构中台和微服务转型若干问题思考总结

　　今天准备再谈下企业传统IT架构进行微服务架构转型若干问题的思考和总结。对于微服务和云原生，我在前面都写过专门的比较系统的文章，可以翻看我头条上的文章列表进行阅读。今天重新整理这篇文章主要还是对前面谈到过的一些细节问题点或技术点进行总结。
　　对于微服务和容器云是云原生技术中的两个关键内容。
　　企业传统IT架构的中台化或微服务化，本身有明确的业务目标和业务场景驱动，简单来说就是共性业务能力下沉，上层应用能够组合或编排来进行构建，以敏捷的响应上层的业务需求和变化。因此传统架构的微服务化往往是先行的。
　　在微服务化后你会发现管理的微服务太多，对于编译，构建，打包部署等都是巨大的工作量，必须通过自动化进行持续集成，同时由于微服务化后本身也更加适合通过容器部署，因此才由需求驱动进一步实施DevOps和容器云平台建设。企业微服务架构的切入点
　　前面两篇文章我讲解了企业在自身IT成熟度还没有达到一定水平的时候，应该谨慎对待微服务架构，其核心原因就是由于架构微服务化后会导致开发，集成，乃至后期的运维管控的复杂度呈指数级提升。即使企业本身有组件化和服务化的思想，但是也没有能够彻底构建微服务架构的能力。
　　正如很多企业连基础主数据都没有管理，也没有建设集成的研发，生产相关的PLM，MES，CIM等核心系统，就开始谈要一步迈入工业4.0和智能制造是一样的道理。任何事情都要考虑从简单到复杂，通过迭代的方式逐步演进。下面就简单分析下企业实施微服务架构可行的一些切入点。
　　共性技术服务能力下沉建设
　　企业在刚开始规划建设，或者建设到一定阶段后，都会涉及到一下基础性的共性技术需求，类似消息管理，日志管理，文件存储，共性的小应用组件（论坛，通讯录，文档在线阅读）等。
　　这些共性能力既可以是技术服务，也可以是共性小应用程序，其最大的特点就是这些组件本身横向交互相当少，而更多的是将自己的能力向上提供暴露和集成。因此这类场景采用微服务架构方式来独立构建并部署是合适的，这类模块的上线和集成可以最大限度的减少对已有横向业务的影响。
　　要发现这类需求，企业应该有一个统一的需求受理和分析组，对各个业务部门或业务系统提交的需求同意进行分析，抽取出共性需求，然后再考虑是否通过微服务方式统一建设。
　　基础平台层能力先行
　　企业在实施微服务架构的时候，一定要意识到对于4A+流程引擎这两个能力需要提取进行平台化和微服务模块化。因为这两个基础能力往往是任何一个业务微服务模块能够运转起来的基础。正是由于这两个基础能力的平台化，我们在构建新的微服务模块的时候，才能够将重心完全放在只关注业务实现上。
　　新增模块移出
　　如果企业已经实施了采购系统而且已经上线运行多年，那么在对采购系统出现大的模块级需求的时候（例如需求在采购需求中增加招投标的功能），那么这种模块需求就可以考虑移出采购系统，通过微服务架构的方式独立构建，在构建完成后在和采购管理系统集成。
　　对于一个新增模块是否能移出，重点还是要考虑该模块和已有的遗留业务系统间的耦合性和集成度。耦合度越小，越容易单独构建并后期集成。从这个角度来看对于哪些在原有业务系统中上游业务最适合移出，例如招投标模块构建只是需要将合格供应商和采购物料清单信息传递到采购系统，而并不需要从已有的采购系统返回任何信息。
　　新增模块移出并进行微服务化往往是对遗留系统影响最小的方案。在微服务架构在企业内部逐步实施成熟后再考虑更多的模块或组件从已有系统中移出。
　　大变更下模块移出
　　企业在接收到新的变更需求处理时，当已有业务系统的某一个模块出现重大变更时（比如变更内容和范围超过了模块本身30%-50%），在这种情况下可以考虑将变更模块移出并进行微服务架构的改造。
　　要清楚在模块大变更情况下，即使按原有模块开发和处理，也会带来巨大的模块开发和集成，联调和实施工作量，还还不如和企业微服务架构演进策略一起处理。两次对业务的大影响变成一次影响，虽然增加了复杂度，但是实际上是降低了整体工作量和后期迁移难度。
　　企业实施微服务架构不应该是将遗留系统彻底推翻并全新建设，而是应该采用3+4迭代进行的渐进式实施策略。全新构建模式-平台建设
　　微服务架构思想实际上是包含了平台+应用思想，业务组件化服务化思想，SOA和云思想，包括当前主流的DevOps思想的一个融合，而不仅仅是简单的微服务架构。因此对于一个新创建的企业要基于微服务架构思想来整体规划内部IT并不是一件容易的事情。
　　首先我们对整体规划建设进行拆分，主要应该包括以下关键的建设任务和内容。
　　底层私有云平台建设：这个即考虑全部基于IaaS资源池进行并尽量去IOE架构，当前实际上对于涉及到数据库仍然或涉及到部分的Oracle数据库和集中存储，企业在选型和规划的时候要考虑本身去掉这部分潜在风险。服务器资源可以考虑全部采用X86服务器并进行虚拟化，提供虚拟机资源作为计算能力。
　　容器化PaaS平台建设：对于PaaS平台建设当前可以基于轻量的Docker容器进行，并通过Kubernates进行资源管理和动态调度。而如果规划建设DevOps支撑平台，即在DevOps平台建设过程中统一建设容器化PaaS平台，当然在DevOps平台中会进一步实现了持续集成和流水线作业能力，实现开发，运行和后期运维监控的一体化管理。通过实施DevOps平台可以进一步对当前的开发团队规划，岗位角色分工，软件过程改进等进一步优化。
　　技术标准和规范体系建设：在微服务架构实施中，还有一个重点就是制定微服务架构开发框架，标准和规范体系。以指导后续开发厂商按照统一的标准方法，工具和流程进行微服务组件模块和接口服务的开发，确保开发标准和规范一致性，也进一步确保了后续多个微服务模块在集成的时候不会出现问题。
　　把这些都谈后，再转回谈需要统一建设的技术平台部分。
　　4A平台：这个是必须建设的内容，不仅仅是实现统一用户，统一认证和鉴权，统一组织，统一审计等内容。在微服务架构下，4A平台进一步扩展传统业务系统中系统管理模块的内容，即能够实现到微服务模块内部的功能菜单和按钮级的操作授权，同时能够实现灵活定义的数据级授权和配置。
　　公共流程平台：这个公共流程平台也是必须，实现统一的类似内部多租户的流程引擎，实现流程的设计建模，运行，监控的全部统一化。各个业务组件模块仅仅是使用流程平台提供的能力。
　　技术服务平台：这个实际涉及到消息，缓存，文件，任务，日志，通知，分布式存储等诸多技术服务能力，可以根据企业需要来确定哪些要单独实现为独立的技术服务能力开放提供。这个没有明确的要求，但是根据实际项目实践来看，类似发送短信邮件的通知类服务，文件存储类服务往往都是必须要规划建设的。
　　监控运维平台：这个平台实际上包括了传统的IT网管监控，同时还包括了当前的APM业务性能监控两个方面的内容。同时两者内容本身又相互集成和融合。由于采用了容器化PaaS，实际上微服务开发商对底层资源的情况并不清楚，因此更加需要这样一个监控运维平台能够同时监控到业务性能和资源层性能，并实时预警。
　　对于4A平台和流程平台实际是企业内部私有云平台的一个差异化点，当前公有云厂商技术服务能力也很少提供这两块内容，即以上两个平台虽然和具体业务无关，但是本身又和业务存在耦合和相关性，因此不能完全算做技术服务，更好的说法是公共服务能力。
　　除了技术平台外，再来看下业务中台部分可以规划建设哪些内容。
　　主数据平台建设：基于当前企业信息化规划建设实施，对于业务中台部分能够统一考虑的只有基础主数据部分内容，因为这部分是共性基础数据服务提供能力。当然基于微服务架构模式下，实际上也没有独立的主数据平台概念，实际上应该只有类似供应商，产品，客户等微服务模块。
　　在完全微服务架构化下，实际上没有主数据平台的概念，主数据平台能力本身分散到各个微服务中去完成，类似用户中心，商品中心等。同时新架构下主数据不再需要多点同步和集成，而是按需实时访问和获取，数据不多个系统落地。而对于需要数据采集集成提供整合后数据服务能力这块，已经迁移到新的类似数据中台中去完成。
　　中间即是满足各个业务能力实现的微服务模块应用，相互独立自治，松耦合。微服务模块间通过轻量的Http API即可进行交互和协同。当然在这个过程中涉及到微服务网关的使用等。
　　最上层统一门户平台建设：对于最上层，需要统一规划建设即是统一门户平台，门户平台重点就是实现业务功能在应用层的简单组装和配置，类似App Store商店一样，最终的业务用户可以根据自己的需求安装相关的业务系统应用。即门户具备足够的灵活定制能力。同时对于DevOps平台最好和前端门户结合，即通过DevOps平台发布和部署的微服务可以直接发布到最终的门户应用上面。遗留架构迁移-场景分析
　　对于遗留的单体应用，要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难。对于单体应用的微服务架构改造，最常见的方式仍然是将低耦合的模块逐步迁出。下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤。
　　在整个模型中我们将模型进行简化，当迁出一个功能模块进行微服务化的时候，首先要考虑的就是对该模块进行集成架构分析，考虑该模块和外围的集成情况，其次才是考虑该模块内部的私有数据。
　　对于招投标模块我们将模型简化来看，主要涉及到上游，下游和底层共享数据几个方面的集成，初步分析如下：1. 上游需要集成项目管理系统中项目信息，招投标基于已经立项的项目信息。 2. 下游需要集成当前遗留的采购系统，其中招投标结果信息和认证合格的供应商信息需要同步到采购模块。 3. 底层业务需要调用供应商，企业组织，人员等基础数据信息。 4. 底层技术需要调用流程引擎能力，实现招投标模块内部的流程建模和执行监控。
　　有了以上内容后可以看到，对于上述接口都需要进行服务化，不管是招投标模块本身提供的服务还是其需要调用和消费的服务。在该过程中就存在一个现实问题，即：
　　其它已有业务系统是否会配合进行服务化的改造？
　　如果其它系统很难配合，那么在微服务模块的迁移过程中就存在要单独实现一个服务代理模块，由该模块来实现接口的服务化工作，该服务代理模块本身还可以实现统一服务目录库的工作。在企业整个微服务架构逐步成型后可以看到该服务代理模块能力会最终融入到微服务网关和总线上。
　　其次，需要考虑接口服务实时调用
　　在服务实现上需要考虑的一个关键问题就是我们通过服务调用消费的数据尽量不落地，即实时的通过服务同步查询外围共享数据，包括项目信息，供应商，人员等基础信息。而在招投标内部的表中也仅仅存储外键ID，减少对重复数据的冗余。而对于我们需要分发的数据则尽量是通过消息中间件机制实现异步分发，减少耦合。
　　由于数据不落地会导致我们在招投标模块前端实现过程中存在多次数据查询后组合，这是不可避免的问题。当然你也可以在招投标模块中增加一个领域服务层来实现类似组合服务的功能。
　　私有数据库设计-数据库拆分
　　这些都考虑清楚后需要考虑私有数据库的设计，注意在微服务模块剥离过程中，招投标模块本身需要对应一个独立的私有数据库，可以是SID数据库实例级别，也可以是Schema级别。当采用Schema级别的时候务必注意不能使用跨Schema的关联数据库表查询语句，否则在数据库层面仍然是紧耦合。在数据库剥离后可以看到，对于招投标模块本身内部业务功能到私有数据库可以采用内部API方式进行调用，但是对于外部的数据和业务协同只能通过发布的服务进行调用和集成。
　　底层虽然进行了微服务和模块化改造，但是用户最终关心的仍然是完整的业务系统和功能，因此在微服务模块剥离后需要考虑的就是整体外层门户框架的单点集成能力。对于单点集成方案已经有很多标准的实现方式，在此不再进行详细描述。
　　在任何一个微服务模块的改造过程中，仍然涉及到底层平台层能力如何解决的问题。
　　拿上面的场景来说，原有的采购管理系统里面可能已有有完整的流程引擎能力，那么剥离的招投标模块是否采用该流程引擎？还是说在微服务模块的改造过程中将核心的平台层能力也逐步剥离出来，如将流程引擎能力也剥离出来形成独立的共享流程平台。这些都是我们需要考虑的问题。
　　个人建议的方式仍然是伴随着微服务模块的迁出同时，将可共享的核心平台层能力也同步剥离，形成底层共享技术服务能力平台。
　　一个微服务模块没有和Docker集成并不代表不是一个完整的微服务架构，一个微服务架构的核心判断标准仍然是组件化和服务化，数据库的单独剥离。上述的这些问题考虑清楚后，接着才考虑该微服务模块内部的技术架构和服务实现方式等问题。
　　在单个微服务模块的实现中仍然推荐采用类似OSGI总线来实现内部的集成，在该模式下组件本身的动态部署和扩展能力将刚强。也更加容易在后期将内部的API发布为外部可以消费的服务。对于前期对开源ESB的研究可以看到，类似Karaf这种基于OSGI的框架可以是一个备选方案。
　　微服务模块在迁出地过程中应该尽量减少对已有业务系统的影响，减少对用户使用层面的影响。即任何业务系统架构改造和内部的复杂性都应该屏蔽在内部。
　　在上述整体思路清晰后，剩余的即是关键技术问题的解决，包括了分布式事务，接口安全和性能，动态部署，弹性扩展，模块健康监控，DevOps能力等，这些在整个实施过程中都必须逐个考虑和解决。要清楚一个遗留的系统在进行微服务架构改造中，前期是增加了复杂度，特别是前期的解耦和后期的集成。微服务架构改造真正受益的是在后期的运维管控和平台弹性扩展上。
　　对数据库和功能拆分进一步说明
　　还是以招投标系统准备单纯拆分出一个微服务进行建设的思路来说明如何对已有的一个遗留系统将某一个独立功能拆分拆分出来构建微服务。
　　在确认了招投标模块需单独拆分出来构建微服务的时候，实际上对于哪些业务功能需要拆分出来直接对应到原来的大系统的招投标管理一级菜单进行拆分出来即可。
　　比如上图举例，对应FUN打头的为需拆分出来的功能模块，对应EXT打头的为采购系统其他的业务功能模块。那么在功能模块列出后，最简单的仍然是进行CRUD分析来快速的梳理和确认哪些数据库表要进行剥离到独立的招投标数据库。
　　经过上面图分析可以看到三种情况。情况1：CUD操作，这类一般来讲对应的数据库表都需要剥离出来。 情况2：FUN对表有更新操作，这种一般说明招投标模块对采购其他模块表有更新，存在接口。 情况3：EXT功能对招投标的表有R操作，说明微服务拆分出来后仍然需要开放接口
　　如何排查具体的CRUD操作？
　　在基本思路搞清楚后，还需要看下如何具体的排查CRUD操作。
　　做过开发的可能比较清楚，要排除相关的CRUD操作并不是一件容易的事情。还是拿招投标模块剥离来举例。对应招投标业务功能我们可以明确剥离，具体涉及到哪个项目，哪些具体的代码文件。在这块剥离后我们需要做如下方面的工作来逐一分析存在哪些数据库操作点或外部集成点。
　　仅分析当前招投标对应的代码文件本身的数据库CRUD操作，这块把整个项目对应的招投标部分代码全部拿出来，逐一排查数据访问层，基本可以快速的确定。即前面谈到的FUN部分对数据库表之间的CRUD关系信息。
　　其次，这部分项目本身还可能调用了采购订单模块的功能进行相关操作，比如调用了订单模块的Order类中的UpdateOrderStatus方法。那么这些点就需要单独列出来，作为具体的接口改造点。
　　再次，是否存在视图的情况，如果存在视图的情况还需要分析在招投标模块用到的视图是否存在关联了非招投标模块的数据库表的情况，如果有这种情况那么也需要单独列出，即在数据库表拆分后这种操作不再支持，需要在上层通过代码区实现组合。遗留架构迁移-中台和服务代理
　　传统企业转型微服务架构，实际上我们思考最多的就是如何进行平滑迁移和逐步过渡，如何在转向微服务架构的过程中对已有的遗留业务系统影响最小，并对已有的遗留系统逐步进行平滑迁移。
　　在原来的多篇文章中，实际上我提出的思路都是会涉及到对已有系统进行重构，这个一方面是底层数据库的重构，也包括上层的微服务模块化和接口服务化重构，但是这种重构本身一定会对业务系统造成一定的影响。而今天这篇文章谈的重点是：
　　将微服务架构思路应用到我们新的业务应用构建中，对于老系统先保留现状，而在新业务应用构建过程中一定涉及到需要使用已有业务系统的业务能力和数据能力提供。
　　为了达到这点，提出不碰触已有业务系统逻辑层实现，全新建设中台各个微服务模块中心的思路，在建立这些中心的时候可以先不去触碰底层的数据库，而是基于已有的数据库来构建上层的各个中心。
　　各个中心就是我们说的业务或数据能力提供中心，各个中心完全微服务模块化，内部也包含业务规则和逻辑的实现，这部分和已有业务系统的逻辑层部分内容是重复的，但是不要紧。可以理解为已有业务系统的逻辑层逻辑在重新梳理和解耦后，迁移到新的中台层的各个微服务中心中。
　　各个微服务中心直接和已有业务系统的底层数据库打交道，而不是和已有业务系统提供的WS服务或逻辑层API打交道，这样做的目的是尽量减少多层WS服务调用带来的分布式事务处理问题。
　　在构建微服务中心的时候，这个时候就不再是单纯的原子服务提供，也包括了组合服务能力提供，即各个微服务中心能够提供领域层服务能力。这个组合服务在实现的时候可能需要访问底层多个数据库，但是对于前端应用来说并不关系，对于底层实现逻辑对上层透明。
　　这种思路重点就是首先考虑中台能力的微服务模块化，同时将已有业务系统的逻辑层能力进行迁移，然后最终转化为API能力接口朝上层暴露。这些能力接口可以用于构建新的业务应用使用。比如我们说的，当构建一个新的业务应用的时候，如果传统方式下面需要和底层的PMS，SCM，ERP，EAM等多个业务系统打交道和协同，而新的业务应用构建模式就变成了，只需要和中台的API网关暴露的服务接口打交道即可。
　　而中台各个模块的API接口能力的实现本身是包含了业务规则的，包含了能力组合的，这些不是单纯的代理回原来的业务系统逻辑层，而是重新实现了一遍，是原有业务系统逻辑层能力的迁移。这种迁移虽然导致业务规则逻辑有两套，但是也为传统业务系统最终的微服务化打下了坚实的基础。
　　即提供API能力的中台服务层构建完成后，可以看到对传统的业务系统进行重构也很简单的了。即传统的业务系统原有的逻辑层能力大部分已经完成了迁移，我们需要做的仅仅是对前端展现层和能力组合协同部分进行重构和迁移即可。
　　其次我们看到这种方式下，在数据库后续进一步拆分情况下，我们提供的服务接口本身是不需要进行变更的，即上层的业务应用不需要变更，这个时候只需要对服务实现逻辑进行调整接口。这种解耦本身是相对有必要，原因就是我们在传统架构朝微服务架构转移的时候，并不一定一开始就要考虑数据库层的垂直拆分。
　　所有中台的各个中心都按微服务架构模式单独设计实现，单独补充并提供接口能力，最终API接口统一注册到API网关朝上层或外部统一提供。也就是说各个中心之间本身松耦合，同时各个微服务中心和已有的各个遗留业务系统之间本身也是一种松耦合的关系。遗留架构迁移-构建中台能力服务层
　　在前面有一篇博客文章我曾经谈到过，通过服务代理的方式来构建企业中台能力服务层，今天基于这篇文章的思路进一步细化整理，同时对构图进行了重新调整。
　　中台能力适配的三种方式
　　如上面图所示，在构建新的中台能力服务层的时候，为了对已有的业务系统影响最小，我们需要重新构建中台能力接口，这个接口涉及到一定的适配和定制开发工作量。具体接口的实现本身又包括了三种方式，这个在前面一篇博客文章也谈到过，即：1. 直接连接遗留系统的数据库，来重新开发接口服务。 2. 通过遗留系统已有的JAR包引入，来重新开发接口服务。 3. 通过遗留系统已有的WS或Rest等接口服务适配，来重新开发接口服务。
　　可以看到三种模式中对于数据库这种模式是对业务系统依赖最小的模式，但是这个模式本身也是需要我们重新大量完整性校验，业务规则的模式。这种模式本身就可以看到对遗留业务系统的部分业务规则和能力进行了重写，即这部分业务逻辑规则已经在朝中台能力层逐步迁移。
　　这种迁移形成的接口服务能力，一方面是构建全新的业务应用可以使用。而同时，我们建议是及时对于PMS或SCM等业务系统，如果有全新的业务模块需要开发，也完全可以基于中台已有的接口服务能力进行，只有这样才容易实现后续的业务系统逐步迁移到中台架构上。
　　数据重构和服务组合是中台另外一个关键能力
　　在中台能力构建的时候，一定要考虑数据重构和能力组合，即中台的能力接口不是简单的数据库CRUD能力暴露，也不是已有的遗留接口的简单适配和代理接入。而是真正根据业务流程和业务需求驱动，失败关键的业务能力，将业务能力转变为服务。这种服务本身是粗粒度的，有明确的业务含义，有点类似我们在领域架构设计里面经常谈到的领域服务能力。
　　领域服务本身统一，有提供领域数据对象的数据类服务，也有提供业务逻辑和规则处理的业务类服务，这些都是领域服务能力。在前期中台构建的时候我们看到数据类服务相对容易构建，但是业务类服务本身较难，因为遗留系统已经实现的业务处理规则和逻辑在代码里面，如果我们用数据库适配模式很容易遗漏已有的业务规则实现。
　　因此在前期中台服务能力构建的时候，建议还是先以查询能力服务能力开放为主来构建。当然我们也可以提供一些基础的领域对象导入服务能力，这种导入服务提供一些基础的数据完整性校验能力，形成业务系统的单据草稿。而实际的业务单据规则处理和流程仍然还是在遗留业务系统中。
　　服务组合是中台存在的另外一个关键价值，即我们可以根据业务需求一次返回组合后的领域对象数据，这个领域对象可以是多层结构，可以一次返回。这个领域对象也可能是涉及到多个数据库表间的关联。如果多个数据库表是跨物理数据库的。我们可以1. 在中台能力实现的时候，调用多次底层原子服务返回多个数据集对象。 2. 在中台实现的时候对多个数据集对象进行数据重构和组合，并返回组合后的领域对象给消费方。
　　中台层对接口服务进行标准化和规范化
　　中台层在接口服务实现的时候，最好在适配的过程中对对接口服务进行标准化和规范化，即提供标准的WS或Rest接口服务能力，服务预先制定的服务契约或规范要求，同时符合日志审计，安全管控要求。
　　中台层的标准WS接口服务最后统一注册和接入到API网关，这样API网关本身能够更加轻量，不需要做太多的适配，数据映射，转换等工作。而重点是实现服务代理和统一服务目录提供，负载均衡，日志审计，安全能力，流量控制能力即可。
　　即这种模式类似于构建了一个厚中台+轻API网关的模式。
　　通过中台能力层处理业务转换和服务编排
　　对于中台中心，还有一个很重要的作用就是接口规则和逻辑转换中心，数据转换和映射中心，即对于源系统和目标系统间可能存在一个接口数据交互，但是要实现这种接口交互需要对数据进行相关的数据清理转换，数据映射，业务规则逻辑校验后才能够进行，而对于源系统本身不清楚目标系统的业务很难来实现这些规则，而目标系统本身又不太想去做这些标准接口外的转换清理工作，那么这个时候可以由中台来完成。
　　这个时候中台的作用有点类似于数据交换平台，也类似于处理采集和处理中心，也类似于我们原来用ESB总线的时候用到的BPEL服务能力编排。即出现如下场景的时候我们可以考虑由中台来承载。1. 对于需要数据交互和协同的两个系统间有业务鸿沟，相互之间不是一套业务体系或标准。 2. 对于数据集成中需要对数据进行完整性校验，业务规则逻辑处理场景。 3. 对于数据集成过程中，需要调用外部服务进行业务规则逻辑判断。 4. 对于一个业务需要进行数据加工，如组合多类数据形成一个完整的数据包再进行数据集成和推送。
　　数据处理转换和业务逻辑处理
　　当出现以上这些场景的时候我们可以考虑用中台来解决。
　　我们举个例子，在我们一个财务中台的项目建设和实施案例中可以看到，用户的报账申请单在OA系统里面填写，即形成报账申请单，但是财务系统关系的是最终的应付凭证，而将报账申请单转换为财务要求格式的应付凭证，中间就涉及到数据映射转换，数据丰富，业务规则逻辑处理等操作。而这些操作就可以在我们构建的财务中台来完成，这样对于OA系统和财务系统本身都达到改造工作量最小的程度。
　　另外一个就是我们常看到的服务组合编排场景
　　比如在采购订单导入的过程中，需要调用预算系统提供的接口服务对预算进行扣减，但是如果导入过程中出现失败或异常，我们又需要对扣减的预算再次调用接口进行回补或释放。在整个过程中这种操作逻辑就可以在财务中台实现。即类似使用原来的BPEL来实现多个服务的编排操作。
　　也可以看到，在当前中台和微服务架构下，对于原来的ESB服务总线已经变成了轻量的微服务或API服务网关，而ESB总线已有的比较重的数据转换，映射，数据校验，数据丰富，业务规则处理，外部接口服务调用和服务编排等能力都不再保留。因此这些能力需要找一个继续承载的点，而中台层就是一个比较好的继续承载这些能力的地方。这样也方便原有IT架构更加平滑的朝中台架构迁移。
　　基于DevOps和容器云部署
　　对于企业的中台能力服务层，完全可以采用微服务架构和容器化技术进行建设。其中我们可以进行中台各个中心的规划，对于每个中台中心就是一个独立的微服务模块，可以进行完全独立自治的设计开发和后期运维管理。
　　每个微服务模块进行独立部署，可以与容器云平台结合，通过容器资源池来实现计算节点的动态扩展能力。同时对于动态扩展的计算节点在上层进行负载均衡，提供统一的IP地址出口。该层的负载均衡能力需要和容器资源池动态扩展自动结合，因此需要实现微服务框架和容器平台Kubernates资源调度层的融合能力。
　　在类似用户中心，项目中心，订单中心等原子服务中心上层，还需要构建领域组合服务中心，实现原子服务的能力组合。该组合能力提供需要调用原子中心的各个原子服务能力。注意，由于组合服务本身存在分布式事务的问题，因此需要考虑对于前期组合类服务的提供，最好以查询组合类服务接口为主，对于查询类组合服务出现服务异常一般不存在具体回退的问题。
　　中台各个服务中心将其负载均衡后的服务地址再次接入到上层的API服务网关中，通过API网关提供统一的服务目录库地址，同时通过API网关来实现安全，日志，流量控制，服务代理等关键能力。
　　由于当前中台服务能力中心的构建以代理适配模式为主，即数据源头仍然是已有的遗留系统的各个数据库，因此对于中台能力中心实际上不需要有自己的Ower数据库，仅仅是业务逻辑层的服务部署包。除非出现传统业务系统所有业务功能迁移到中台的情况，才涉及到需要重新规划中台模块对应的数据库。
　　在中台能力服务层构建的时候，可以采用我们提供的DevOps支撑平台，该支撑平台提供对容器化资源池，部署流水线，微服务架构，API服务网关等整体打包解决能力。可以进一步实现中台能力层的快速开发和交付上线。对于DevOps支撑平台的介绍可以参考我前面发过的文章。