作者：人月神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践
今天这篇文章作为对SOA，中台和微服务等大量基础概念的一次统一说明。我始终认为，当你在学习一个新的知识和技术点的时候，一定不要马上陷入细节，而是需要用你自己最容易理解的方式形成对该事物的核心概念模型理解。
包括我们现在说的很多的中台和微服务。如果你原来就接触过SOA，接触过组件化开发思想，那么你理解这两个概念相当就很清楚。类似的还有数据中台，你如果原来接触过BI系统，大数据平台，那么你理解数据中台就更加容易，你只需要去比较差异即可。
因此这篇文章我准备从SOA架构思想入手，逐步讲解下对中台，微服务等关键概念的理解。
SOA架构思想我们可以来看下SOA本身的定义，即：
SOA是一种架构方法，将传统的单片式应用打破，分解为离散的、自治的业务服务，利用标准提升他们的互操作性，从而可以更好地共享、重用和组装，快速构建复合的应用从而满足业务需求的变化。
在面对企业遗留IT系统架构的时候，SOA本身实际也是做两个重要的事情，其一是找到各个遗留系统共性的可复用的业务能力；其次就是在构建上层业务流程的时候通过服务组装和编排来完成。这个思想和中台思想完全一致。
我们来举个例子详细说明SOA架构思想：
我们以注册一家新公司来举例，可以看到如果我们要注册一家新的公司，我们需要和银行，政府部门中的工商，税务，质量监督等多个业务部门到交道，最终完成新公司注册的完整过程。
其一：找到可复用服务
而对于各个业务部门就是我们说的业务组件，我们首先就是要看业务组件本身对外提供了什么标准的服务能力出来，即先把各个组件可共享，能够复用的能力识别出来。这些业务组件本身提供很多业务服务能力，在这里我们只列举一些和公司注册相关的能力，如下：
其二：组合和编排服务完成业务
在进行一个新企业的注册流程中，涉及到核名，办理验资报告，领取组织机构代码证等诸多的业务活动，这些业务活动都需要和上面说的业务部门（业务组件）打交道才能够完成。
而要完成整个业务流程，就是将上面业务部门暴露的服务能力基于业务活动的流转进行组装起来，这样就完成了一个完整的业务，如下：
可以看到完成整个企业注册业务流程，本身就是底层的接口服务能力的组合和组装。
如果注册流程中增加了一个验证企业信用要求，那么我们也很容易在原来的业务流程中增加一个活动节点，该活动节点调用银行的信用验证服务能力接口即可。即通过接口服务的灵活组合，组装，能够很容易的响应业务流程的变化。
SOA和ESB总线的关系简单来说，SOA是一种架构思想，这种架构思想核心是找到服务，组装编排服务。对于找到的服务我们希望统一进行管理，那么ESB就是实现服务管理和治理的一个技术平台。
也就是ESB企业服务总线是实现SOA架构思想的一个关键平台。
如上图，找到和管理服务你可以借助ESB服务总线能力来完成，而组装和编排服务你可以借助BPM管理软件来完成。而ESB BPM也是我们常说的实现SOA架构思想的关键平台。
没有使用ESB能否叫实现SOA架构？
当然可以，只是遗留系统暴露的接口服务没有进行统一的管控和治理，也就是说对于接口服务的治理水平会比较弱，但是只要你暴露的接口服务是粗粒度和可复用的。同样可以共享给上层业务系统或应用使用。正如没有使用BPM，同样也可以实践SOA编排思想，只是你需要通过自己写代码去编排服务，而不是通过BPM软件去可视化编排服务。
反之同样的道理，不用简单理解使用了ESB就是SOA架构。
比如你使用了ESB，接入了一堆没有经过标准化，不符合粗粒度特点的接口，这些接口本身混乱也没有任何服务价值。上层新业务开发也不能使用这些接口服务，那么这个时候你的ESB就仅仅是一个接口平台，也没有实现任何的SOA架构思想。
类似的道理还有我们做微服务也一样，不要简单的认为使用了SpringCloud框架就是微服务了，必须要考虑微服务类似轻量交互，松耦合等关键思想是否实现。
ESB总线需要同时考虑解决集成和解耦两类问题
由于当前ESB总线产品很多是由原有的EAI和消息中间件产品发展而来，因此更多的强调的是服务或消息集成，而弱化了SOA更加重要的一个能力即服务共享。
而实际上SOA需要解决服务 集成两方面的问题。
- 集成：解决的是业务和流程上的协同问题，服务不一定就能复用
- 复用：解决的是底层共有组件模块提取后能力开放问题，重点是可复用
从上面图可以看到，对于横向交互协同的接口，更多的是解决跨系统的集成问题，而对于系统中纵向使用的共享能力接口，在共享能力平台化后，则接口服务可重用，更多的解决就是服务层面的问题。
举例来说，一个采购系统导采购订单给ERP系统，这个接口往往并不能复用，但是解决了跨系统集成问题；另外对于MDM主数据提供的供应商查询接口服务，这个接口服务本身就是数据能力平台化后提供出的共享数据服务能力，这个服务可以被外围的SCM，ERP，CMS多个业务系统使用，既解决了系统间集成，更重要的解决了服务重用问题。
你也可以理解，对于服务重用问题的解决，更多都是伴随着共性能力下沉产生的。然而当前大部分企业将SOA简单理解为了ESB和集成平台，更多用SOA去解决集成的问题，而忘记了SOA架构思想的本质仍然是共性业务能力下降，上层应用灵活编排。
企业中台和中台思想对于中台概念，大家都比较清楚是阿里最早提出了大中台，小前台的说法。阿里巴巴 “大中台、小前台”机制的提出，某种程度上是从传统的事业部制向准事业部制的转换。
对于中台核心价值可以总结为关键的两点，第一点就是灵活敏捷支撑业务。
就阿里巴巴而言，“前台”就是贴近最终用户/商家的业务部门，包括零售电商、广告业务、云计算、物流以及其它创新业务等；而“中台”则是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。
前台和中台本质上是工作分工的问题。比如，某部门要开发一款App，是部门内部（大前台）自己组织一套技术、产品、设计、运营的团队，还是集团为其提供资源（大中台），由专门的技术团队来帮助其开发、设计产品等等。
所以说， “小前台 大中台”的运营模式，就是美军的“特种部队（小前台） 航母舰群（大中台）”的组织结构方式，以促进管理更加扁平化。十几人甚至几人组成的特种部队在战场一线，可以根据实际情况迅速决策，并引导精准打击。而精准打击的导弹往往是从航母舰群上发射而出，后方会提供强大的侦察火力后勤支援。所以如果中台没有办法承接前线的需求，前线就会不认可它服务的价值。
第二点就是通过中台来实现进一步的资源整合复用，降低成本
阿里巴巴近年来迅速扩张、员工众多，所以可能会存在管理不善、效率低下、各事业部各自为政等问题。为了解决以上问题，阿里提出了“大中台，小前台”机制。“小前台 大中台”的运营模式促使组织管理更加扁平化，使得管理更加高效，组织运作效率提高，业务更加敏捷灵活。
其“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子”的KPI项目。前台要做什么业务，需要什么资源可以直接同公共服务部要。
大家看到这两点，是否觉得跟传统企业内部信息化建设经常说到的SOA架构思想很类似。
微服务本质是单体大拆小接着再来看下微服务，谈微服务一定是和单体应用对比。
微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。
在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。
如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
我们可以先看下从单体应用到微服务架构的变化图。
从上面图里面我们可以清楚的看到单体转到微服务后带来的两个核心差异。
- 一个单体变多个微服务模块，而且从数据库到逻辑层到前端完全独立
- 微服务模块间通过Http Rest接口高效集成协同
谈到这里，我需要纠正下我原来的一个看法。
即SOA和微服务本质上不应该放在一个层面去比较，因为SOA里面强调的横向分层，可复用服务积累，上层服务灵活组装形成应用几个关键点在微服务里面都没有。微服务仅仅是模块间接口交互走了轻量的Http Rest接口而已。
微服务简单来说强调的是纵向大单体拆分小，因此更多应该和单体应用做对比。
题外话：经常看到有人将业务逻辑层理解为中台，这个也是错误对比，这两个不是一个层面的概念。中台模块有业务逻辑层，前台模块也有。要明白不是所有业务逻辑都是共性和可复用的，对于不可复用的业务逻辑仍然是在前台模块中，而非中台。
中台=SOA思想 微服务在了解了前面讲解了概念后，我们看到中台思想实际上SOA思想和微服务两者的融合。为何这样讲，我们来讲中台思想和中台实现两个层面来说。
- 共性可复用业务能力下沉，并提供给前台应用使用=》SOA思想
- 共性能力构建时候尽量大拆小，可扩展，松耦合=》微服务思想
当前互联网企业谈的中台基本就是SOA架构思想和微服务两者的一个融合，既体现了共性业务能力下沉，又体现了共性能力要大拆小的微服务方式构建。如下图：
当我们理解了这个核心概念后，我们才能够认识到如下几点关键认识。
中台是一个业务层面概念，微服务是一个技术层面概念。中台核心仍然是共性业务能力下沉和复用，只是互联网企业在实现中台架构的时候，将中台技术实现和微服务做了融合。
因此企业内业务中台实现，只要满足共性业务能力统一提供给上层使用，即使底层提供能力的仍然是传统遗留业务系统，那么也可以将构建了一个业务服务能力中台。
同时也可以看到微服务仅仅是中台中应用到的一个技术实现，你可以在很多非中台场景下采用微服务，小到原来一个业务系统拆分后全新构建这种场景。因此采用了微服务架构离中台实现十万八千里。同时不采用微服务也可以实现中台。
从传统架构ESB到中台架构里面的API网关对于中台里面下沉的共性业务服务能力也需要统一向外暴露，这个时候就涉及到OpenAPI能力开放平台或API网关，那么首先来解释下API网关。
如何给API网关一个定义？
简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。
- 内部的微服务对外部访问来说位置透明，外部应用只需和网关交互
- 统一拦截接口服务，实现安全，日志，限流熔断等需求
从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：
- 大量适配器实现对遗留系统的遗留接口适配，多协议转换能力
- 进行数据的复制映射，路由等能力
对于两者，我原来做过一个简单的对比，大家可以参考。
这个概念理解后，我们再回到微服务架构里面。
对于微服务架构大家经常说的最多的就是去中心化的架构，认为ESB中心化架构模式已经过时。而实际上经过上面分析你可以看到。在微服务架构里面的API网关仍然是中心化的架构模式，所有的API接口都要经过网关这个点。
- 非中心化架构-》走微服务里面的服务注册中心进行接口交互
- 中心化架构-》走网关进行接口服务暴露和共享交互
对于微服务架构里面有无去中心化的架构？当然是有的，即我们常说的微服务模块之间可以通过服务注册中心来实现服务发现查找，服务间的点对点调用即使去中心化的。
如果一个单体拆分为微服务后，完全不需要和外部应用打交道，也不需要共享自己的接口能力，那么这个微服务体系里面就不需要用API网关，仅仅使用服务注册中心即可。通过服务注册中心实现完全的去中心化和接口调用更高的性能。
再回到我讲ESB的时候谈到解决两个层面的问题，一个是集成，一个是共享。那么转移到微服务架构体系后，即集成的问题通过非中心化架构完全可以解决，而对于共享问题仍然需要轻量的ESB总线或API网关来解决。
业务中台，数据中台，技术中台现在中台的概念太多，导致大家在理解中台的时候很容易出现偏差。
技术中台建议叫技术平台
首先说明下我个人认为中台更加偏向于业务概念，可以说包括了业务中台和数据中台，但是尽量不要说技术中台。技术中台更多的应该理解为技术平台更加合适。
技术平台理解也很简单，当你在开发中台各个微服务的时候，你涉及到各种共性技术能力的需求，这里面既包括了类似消息，缓存等技术服务能力，也包括了微服务开发框架和运行环境，还包括了类似DevOps的持续集成和交付能力。
这些能力是你进行中台微服务开发的基础，让你开发更加高效。
在我最早开始做企业私有云PaaS平台规划建设的时候，就提出了业务能力组件化，组件能力服务化的平台 应用的构建模式。而这也是现在我们谈到的中台 微服务思想是完全一致的。当时我们在我们整体规划里面的PaaS平台就可以看作是技术中台的内容，如下图：
该书近期也将由清华大学出版社出版，也是我们多年大型集团企业SOA和PaaS平台建设实施经验的积累，欢迎大家阅读和指正。
而对于当前的技术中台，其核心实际上就是我们最近几年谈的比较多的云原生解决方案，因为云原生解决方案刚好覆盖了微服务 DevOps 容器云几个关键内容。
云原生=微服务 DevOps 容器云
对于Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。
云原生应用程序开发通常包括DevOps，敏捷方法，微服务，云平台，Kubernetes和Docker等容器，以及持续交付，简而言之，每种新的和现代的应用程序部署方法。
微服务架构 容器化 DevOps 将成为后续企业信息化转型的主流趋势。在构建企业的技术中台的时候完全可以参考云原生解决方案来进行构建。
从传统架构到中台架构
我们可以简单做下对比映射，即传统架构中的业务系统对应到新架构里面的业务中台，传统架构里面的BI系统对应到新架构里面的数据中台。这个对应当然不准确，里面存在差异和区别，也是我们要重点说明的地方。
业务中台和数据中台的区别
对于业务中台相对来说比较好理解，简单一句话就是共性业务能力下沉形成的多个微服务化的业务能力提供中心供上层应用使用。而对于数据中台，我们也可以总结为一句话就是，把数据变成资产并服务于业务的机制。数据来源于业务并反哺业务，不断的迭代循环。
数据中台，类似业务中台定义，如果也一句话定义的话就是共性数据能力下沉和整合，并以数据服务访问对外提供可复用的能力。数据中台是实现业务中台核心共享数据的跨域整合，再通过加工后提供整合后的数据服务能力。这里面有两个重点。
- 第一数据要跨域整合
- 第二数据要加工处理后再提供增值服务能力
这个加工可能简单的汇总表，也可能是复制的底层数据模型和智能分析算法。
业务中台重点是业务数据化，而数据中台重点是数据业务化，数据来源于业务又反哺业务。就建设和支撑层面来说我原来也总结过，即业务中台是基础业务能力支撑，必须要有，数据中台是增值能力支撑，刚开始没有也不会影响到业务本身的运作。
以下我们再总结下两者区别的一些关键点说明
- 业务中台必须有是核心业务支撑，数据中台可以无，是增值能力提供。
- 业务中台是自己产生业务数据，数据中台是采集业务数据再加工。
- 业务中台不再做底层数据交换和集成，这部分能力全部转到数据中台。
我们可以简单的理解为业务中台对应传统架构里面的业务系统，但是业务系统进一步微服务化了。而数据中台对应传统架构里面的BI系统，只是数据不再封闭而需要进一步开放了。
传统BI系统是不是就是数据中台？
实际上对于数据中台，我们不仅仅要比较和业务中台的区别，还需要比较和传统BI的区别。因为从上图我们可以看到数据中台和传统的BI系统架构还是很类似。
简单来说传统BI和数据仓库的主要场景是支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是数据能力渗透到各个业务环节，不限于决策分析类应用场景。数据中台持续不断的将数据进行资产化，价值化并应用到业务，而且关注数据价值的运营。
注意上面构图里面的红线部分，数据中台必须要有数据服务开放层，同时要有红线的接口服务直接被业务系统使用。这两点相当重要。否则就容易把数据中台建成传统BI。
即数据中台能力要服务于业务系统准实时协同需要。数据中台形成的能力，不论是ODS层能力还是DW层能力，都可能通过能力开放方式暴露接口给业务应用使用，为业务提供实时或准实时的增值服务能力。
为了做到实时或准实时，一方面你会看到数据中台架构上实际上是包括了大数据平台的核心架构和分布式存储内容，同时还包括了大数据平台中的实时计算和流处理能力。其次，为了将能力提供给业务系统，往往数据中台整体架构上一定会体现一个统一的数据服务能力开放层，这个在传统的数据仓库或大数据平台上是没有的。
数据中台和传统BI架构有重合，也有交集。相同的就是整个数据采集集成，数据存储，数据模型构建，数据开发和分析，这些都需要。差异点在于数据中台需要有统一的数据服务能力开放层，提供给业务使用，而弱化了传统BI里面的数据分析和报表展现层。
大数据平台是不是就是数据中台？
图片来源网络
首先我们来谈大数据平台是一个技术平台。这个技术平台提供了对于大数据的分布式采集，存储，流处理和计算，实时分析等能力。在没有大数据平台前也有数据集成和管理的平台，这种平台可以实现对结构化数据本身的采集，集成和管理。
因此我们常说的大数据平台你可以理解为一个纯粹的数据技术能力平台，里面本身是空的。就像我们理解ESB总线一样，本身是一个技术平台，一开始没有接口服务注册在上面，需要你自己不断的接入新的服务，才能够形成服务目录体系。
任何一个数据中台，底层都需要一个提供数据存储和处理能力支撑的技术平台。
这个技术平台如果你有大数据需求，构建出来的就是大数据平台。但是如果你没有大数据需求，那么用传统的数据集成和管理技术平台即可。
其次，数据中台的范畴包括了如下几个方面
- 一套底层的数据技术平台（可以是大数据平台，也可以是数据集成平台）
- 一套数据资产（业务层面的内容，实际数据，数据模型，算法装进来了）
- 一套数据服务能力提供和共享
- 一套数据管控和治理标准规范体系
因此可以看到对于数据中台核心重要的反而是数据资产 数据服务能力共享这两点。如果整个数据中台建设有大数据平台，那么大数据平台也仅仅是一个底层技术平台和技术实现手段。
主数据平台是不是数据中台？
那么在传统架构里面的主数据平台是否属于数据中台的一部分内容呢？这个也是我们经常看到会被问起的问题。包括在我原来的理解也是错误的，即把主数据平台理解为了数据中台的一部分。
对于数据中台前面已经讲过了，我们再来看下主数据定义。
主数据是描述核心业务实体（如客户、供应商、地点、产品和库存）的一个或多个属性。所以主数据即是在进行企业业务架构分析中发现的核心业务对象。或者讲主数据是企业已经存在的涉及到价值链核心业务流程的各个IT系统的基础数据。
对于ERP系统客户，供应商，物料，BOM，产品，合同，订单等都应该是最基础的数据，对于项目管理系统而言项目信息，WBS信息则是最基本的基础数据。而对于CRM系统则客户，销售项目是最基本的基础数据。基础数据要上升到主数据的高度还有一个条件，即该数据产生在一个源IT系统中，但是会在多个其它的IT系统中使用到。
在了解清楚了两者的基本定义后，再来看区别。如下图：
对两者的区别点进一步说明如下：
- 主数据在传统架构里面属于业务系统，在中台和微服务架构下可能会被拆分为多个微服务。即原来主数据管理的物料，供应商，人员可能会拆分中台架构里面的物料中心，供应商中心，人员中心。
- 主数据在整个架构演进后，会转变为业务中台各个中心。
- 主数据在传统架构里面由于存在数据共享模式，因此一般也包括ETL，数据集成等功能。但是转到中台架构后，由于在业务中台核心是数据不落地实时开放共享，因此已经不存在这种集成点，即老架构里面的【1】这个点在中台架构中已经不存在。
- 原来主数据系统存在模型数据全域视图查询能力转移到数据中台实现。
以上就是关于主数据平台和数据中台的一些关键区别点。
业务中台是不是就是原来的业务逻辑层？最近经常听到有人把业务逻辑层等同于业务中台，这个是极其严重的错误。
业务逻辑层是我们传统软件开放技术架构中的内部分层，而业务中台则是业务层面的能力分层，本身就不应该放在一个层面来进行对比。
要意识到业务中台只是共性业务能力下沉，非共性业务能力仍然是在前台。
即对于前台的各个应用，仍然有业务逻辑层，只是这里的业务逻辑无法复用，因此在前台各个模块自己实现。包括各个前台仍然也可以有自己的数据库一样，前台也是一个独立完整的微服务。
同样对于中台模块，也不仅仅是逻辑层，同样可以包含前端页面和展现层。
那么业务中台的各个微服务实际的展现形式有哪些？具体如下：
形式1和2：包括数据库，逻辑层
这是中台模块比较典型的一个展现形式，比如类似供应商中心，有独立的Owner数据库，本身的供应商系统管理员维护的功能仍然在这个中心完成，但是供应商能力本身又需要通过API接口发布给前台共享使用。
当然在也存在该微服务不提供前端界面的可能，即该中心全部是服务能力接口对外暴露，所有的对数据的操作功能全部在前端各个应用模块来完成，即使系统管理员维护功能也不提供。
形式3和4：不包括数据库，含逻辑层和前端页面
不Owner数据库是什么意义？可以理解为该中台模块的业务规则和逻辑的实现全部是通过中台其它模块提供的API服务接口的组合和组装来完成的。那么这种情况下中台模块就没有Owner的数据库。
比如供应商绩效评估微服务，这个微服务重点就是供应商静态数据，供应商供货的动态数据，基于某种规则进行绩效计算，最终返回绩效评估结果。而供应商静态动态数据获取需要访问供应商中心，采购中心，质检中心多个微服务来获取数据。
,
