转载

中台和微服务(11.14)

从我前面写过的企业中台和微服务架构的文章可以看到，基本上一谈到中台构建都会涉及到微服务架构，微服务模块划分和API服务接口识别，统一的接口服务能力开放。今天再来谈下中台和微服务关系。

中台本质是共性业务能力下沉并形成可共享服务API接口再统一开放。

微服务本质是单体应用的模块化拆分和轻量化接口协同

所以实际上我们是没有必要将中台构建一定和微服务架构设计和实施绑定死。只要满足了前后端分离，共享业务能力下沉并开放给前台，就是构建的业务中台，对于中台里面是否进行了微服务架构设计，是否进行了模块化拆分并不是至关重要的。而对于微服务架构而言，原来也强调过，只要满足了单体垂直拆分，同时轻量化接口协同就是微服务架构核心，而对于微服务架构暴露的API接口是否属于共性业务能力接口并统一暴露给前台使用，也不是微服务架构所强调的重点。

而中台+微服务为何是我们经常说的相互结合的最佳实践呢？

因为这种方式既满足了共性业务能力下沉和接口能力开放共享，又重复满足了在构建中台能力中心的时候进行微服务化拆分，真正实现松耦合和后期灵活扩展。这样处理既满足了业务本身的需求和快速构建业务，又满足了技术架构本身的灵活扩展性。

当我们原来谈软件类企业的时候经常会说到平台之战，这个平台偏指技术平台，即软件类企业可以基于一个好的技术平台来快速的开发或定制新的业务系统并快速交付客户。这个技术平台本身和业务无关，更多的是类似4A，流程引擎，消息缓存等各类技术服务能力。

而对于电信，金融，制造，互联网运营等业务类企业来说也存在平台之战，而这个平台就是业务平台+能力开放，也就是我们现在说的共性能力下沉后形成的能力中台。为什么说这个中台很重要，因为基于这个中台我们可以快速的响应灵活多变的业务需求和目标，快速的通过组装和编排的方式来灵活构建前端应用。

前端应用为何能够快速的构建？其核心原因就是当前业务中台已经具备完整的业务能力可用，前端应用仅仅是挑选现有的能力，并对能力进行组装和组合，并形成新的能力来满足业务需求或流程。

但是我们也看到在企业进行微服务架构转型和实施的时候，往往并没有形成完整能力中台，其原因在于我们实施微服务架构更加强调的是单体应用拆分，只是原来构建一个大应用方式变化成了构建多个小微服务模块应用，时间的分析，设计和构建方式和原来还是一样的。这种模式下无法形成完整中台能力层。

而在中台构建思路中可以看到，核心不是原单体应用的纵向垂直切分，而是横向的分层，这个分层首先是形成中台各个能力中心，然后是暴露核心共享能力，其次才是构建前台应用模块。

因此中台构建的思路实际上和简单的微服务模块拆分思路还不完全一样，其顺序是先构建中台层各个中心，再提取服务，再构建前台应用。那么中台各个中心如何构建才是中台构建的重点，而这些中心的构建在前面我博客文章里面也谈到，最简单可行的不是从业务流程驱动出发，而是从数据架构分析，数据域划分出发，以核心基础主数据和共享数据域的划分和松耦合来构建中台各个中心，提供接口服务能力。这才是中台构建重点。

原文 http://blog.sina.com.cn/s/blog_493a84550102z4lv.html

正文到此结束