前面有一篇文章谈了企业微服务架构中的中台，实际上在中台的下面应该还有一层技术平台。这篇重点谈下技术平台本身的构建策略和包括的内容。
微服务架构强调将传统的单体应用打散为从数据库到中间件到部署包(前端+后端）完全独立的多个松耦合的微服务模块。简单来说仍然是传统的业务系统要实现业务组件化拆分。
而传统业务系统包括了 技术平台或组件 + 业务组件1 + 业务组件2 + ... + 业务组件N
我们再来简单举例说明下：
采购系统 = 采购技术平台 + 招投标模块 + 采购订单管理模块 + 供应商管理模块
库存系统 = 库存技术平台 + 出入库管理模块 + 台账模块 + 配送模块
而这个时候采购技术平台和库存技术平台本身具有大量的重复内容，包括了常说的4A和工作流引擎，也包括了类似消息，缓存，日志处理，文件存储，短信邮件等各种技术模块。那么我们首先要考虑到的就是 首先将传统业务系统中的技术平台部分剥离出去，统一下沉到公共的技术平台层构建，构建完成后再以能力开放接口的模式供上层业务模块调用。
因此共性技术能力下沉到技术平台，使得传统业务系统只剩余和业务相关的功能模块，是后续进一步进行业务系统模块化和组件化的基础。否则每一个微服务模块都要带流程引擎，各个技术组件，这些大量重复的内容在后续运维中将是灾难性的。
微服务架构中的平台包括： 技术平台 + 业务平台（数据组件+业务组件（各个模块化业务中心））。
在微服务架构里面也不再有主数据平台的概念，但是一定会有数据类微服务模块的概念，对于供应商中心，人员中心，用户中心，客户中心等，这些都是典型的数据组件，向外提供数据服务能力。
技术平台 = 技术组件1(技术组件+技术服务开放） + 技术组件2 + ... + 技术组件N
注意每一个技术组件都可以作为独立的微服务模块独立开发并部署，然后提供技术服务API能力接口出来。也就是说技术平台中的技术组件本身也是微服务模块化的，可完全实现分散部署和独立管理。
对于技术服务由于具有很大的并发调用量，因此走传统的ESB总线集成模式是不合适的，更好的丰富还是走轻量的SOA总线，能够实现统一的服务目录管理，鉴权和路由接口。同时对于技术服务类接口可以采用更加轻量的RestAPI 服务接口来实现并暴露。
要注意到在技术平台下沉后，原有一个业务系统全部能完成的事情变化为了需要多个业务模块，多个技术模块相互配合和协同才能够搞定。 可想而知，这个时候集成复杂度是指数级增加，同时对各个微服务模块本身的高可用，高可靠性要求更加高，任何一个微服务模块出现运行故障都可能影响到整体业务。
可以参考下图来理解：
如果一个业务系统有4个模块，在进行微服务架构拆分后，即使技术组件只有三个独立的技术服务模块，那么也是会有20个集成点，可能上100个服务接口交互才能够完全还原回原来完整的业务系统能力。同时对于平台层任何一个技术组件模块出现故障，都直接会影响到上层的业务组件模块。
如果我们对技术组件建设的健壮性没有足够的信心，而轻易去实施上图这种转变，不仅仅是不能为最终的业务用户提供一个高可用性的业务系统，更重要的是在后续运维过程中仍然是灾难性的。 当一个企业本身的技术能力成熟度没有到一定水平的时候不要轻易去尝试上述方法。即使技术能力下沉，也只是集中化共建4A和流程平台能力即可。
注：本文内容来自互联网，旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜，请你联系站长进行处理。