前言
大家好，我是Value。这篇文章是《说透中台》这门课程的学习笔记，从一个菜鸟的视角来看待中台，并回答了以下问题：
- 什么是中台？
- 中台的种类
- 中台和微服务，中间件，数据仓库的区别？
什么是中台？
中台是企业级能力复用平台。 企业级定义了中台的范围。 能力定义了中台主要承载的对象。 复用定义了中台的核心价值。 平台定义了中台的主要形式。
我们再来看看企业为什么要建中台？想要回答这个问题，咱得先解决另一个问题，那就是企业为什么需要平台化？企业为什么需要平台化呢？先给我的答案：因为在当今这样一个互联网时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。这背后的逻辑很简单，不断地快速响应、探索、挖掘、引领用户的需求，才是企业得以生存和持续发展的关键因素。
平台化思想（Platform Thinking）恰好鼓励企业不断抽象沉淀自己核心的底层能力，通过平台化包装，得以更好地赋能前台业务，用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。
我还是挺认同这个总结的，这告诉了我并不是所有公司都需要一个中台，没有多条业务线或服务多个前端团队就不用上中台。这里说到服务前端团队，其实说的是中台应该有一个愿景，而这个愿景脱离不开前台。因为中台要为前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力。
说的直白点，就是用户要求企业的反应越来越快，而以前的架构（前台+后台或平台）并不能提供用户需要的响应能力，所以中台顺势而出。
打个不是很恰当的比方，这就像人类的商业最开始是物物交换，后来发展出了货币，后来又发展出了商户，代理商。企业在每个不同的阶段的难题都不同，当企业越来越庞大的时候，最害怕的是自己的手脚（部门协调费时费力）不灵活，而不是担心自己的脑子不好用了。
中台的种类
业务中台
业务这个词，其实是有些宽泛的，我听到很多人口中说的业务都不是一个概念。为此，我还特地做了一些功课。业务，更白话一些来说，就是为了售出产品、换取利润，各行业中需要处理的商业上的相关事务。所以在早期我们通常会把销售叫作业务员。
换个角度看，从企业架构的层面看，应用架构、技术架构、数据架构都是要匹配公司的业务架构的，因为“业务”，即售出产品、换取利润是企业的核心目标。
当我思考业务中台时，我会不断地问自己一个问题：企业的业务能够顺利开展，需要解决哪些核心问题？所以，我们常提到的业务中台，可以理解成狭义的业务中台，通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑。
业务中台算是中台种类里面应用最多，反复提及的一个。因为大部分企业的目的是为了盈利，而为了盈利，就需要展开各种不同的业务，换取利润。而其他所有中台都是为了业务而服务的，不管是数据中台，技术中台，其核心目的都是帮助业务，让业务更快，更高效，赚更多的钱。所以也可以说所有中台都是业务中台。
数据中台
讲完了业务中台，我们再来看目前热度最高的数据中台。 数据中台为什么这么火热？我总结下来主要是这么几个原因。
- 见效快。目前大部分传统企业的问题还在于数据不通，“数据孤岛”现象比较严重，数据中台的建设对于痛点的解决直接，驱动力强。
- 组织调整负担小。一般来说，有一定规模的企业都已经有了大数据团队或是 BI 团队，这个团队自然就承载着相关的职能，不需要再做大的组织调整。
- 有一定技术基础储备。大部分企业都进行了多年的数据仓库建设，或是随着前几年大数据的浪潮，已经构建了多年的大数据技术平台。
- 大势所趋。大家都在讲 DT（Data Technology）时代，对于数据的价值，企业的认识也越来越深刻，大家已经意识到数据不再只是一种运营辅助分析的工具，而逐渐成为企业的核心资产和竞争力。
关于业务中台与数据中台的关系，我比较赞同阿里巴巴技术方案总监谢纯良在一次 InfoQ 采访中提到的观点：“业务中台就是在产生数据，数据中台是做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。”
如果让我选择搭建一个中台，我会优先选择“数据中台”这个方向。因为正如上面所说，一个是大势所趋，还有一个就是较为成熟，见效快，改动小（不容易背锅，哈哈哈）。另外就是目前的大部分应用都可以归纳到“数据密集型应用”这个分类里，对数据的利用和整理是迫切且重要的。用4象限分析法来看，数据中台是落在第二象限的（重要且紧急），业务中台同样如此，但业务中台改造风险大，阻力大。
技术中台
除了业务数据双中台，最常被提到，在我看来介于主流和非主流之间的就得属技术中台了。技术中台相比业务中台和数据中台，边界也会更加清晰，简单来讲就是在 CloudNative 下将使用云或其他基础设施的能力、各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台、数据中台的快速建设。不过业界也有说法，认为技术中台没有很强的业务属性，只是一些中间件的集合，顶多算是个中间件平台而已，称不上中台，你怎么看呢？
研发中台
软件开发是一项工程，涉及到管理、流程、测试、团队协作等等方面。如何将企业的开发流程、最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情，我们可以管这种关注开发效能管理的平台叫作研发中台。
移动中台
在移动互联网时代，移动优先的原则已经成为不争的事实，将 App 开发过程中的通用技术组件进行封装沉淀到移动中台中，就可以在构建新的 App 时大量复用已有组件和能力，快速构建和响应。
中台和微服务，中间件，数据仓库的区别？
这个问题是大家问得最多的，其实这是三个问题，但我觉得相关，就放到了一起。
首先这个问题本身就非常有意思，它体现出目前中台的一种混乱的情况，虽然我们谈的都是中台，但是每个人口中的“中台”可能并不是一个事情。
当我们谈中台与微服务的区别时，更多谈的是业务中台； 当我们谈中台与中间件的区别时，则更倾向于技术中台； 当我们谈中台与数据仓库的区别时，更多谈的则是数据中台。 所以这个问题更严谨的表达，应该是“业务中台与微服务”、“技术中台与中间件”、“数据中台与数据仓库”到底有什么区别？
- 业务中台与微服务的区别？
说完了业务，我们再来谈谈在技术架构设计中，大家最关心也是同样感到困扰的另外一个问题，就是业务中台与微服务架构有什么关系？ 这也是谈及中台时经常会被问到的问题，至少能排到 Top5 里，正好讲到技术架构部分，我稍微谈一下我的理解。
先给出我的答案：这俩没关系！ 是不是有点反直觉，毕竟这两个概念经常被一起提，很多讲业务中台的书讲到技术架构也都在讲微服务，你怎么说这俩没关系呢？
别急，且听我慢慢道来。 总的来说，业务中台与微服务解决的是不同的问题，也处于不同的抽象层次。 前面提到了业务中台解决的是业务领域的业务（数据、功能、流程）复用的问题，而微服务架构作为一种轻量级分布式技术架构，解决的是技术领域的“组件编译时依赖”造成的问题。 而且业务中台不一定是微服务架构的，微服务架构也不一定是为了解决能力复用的问题。 首先来看业务中台。 业务中台要解决的是业务能力如何快速复用的问题，就算背后是一个大单体，只要暴露出来的 API 能够满足业务能力快速复用的目的也是可以的。 这个很容易理解，那我就着重解释一下我对于微服务架构的看法。 提到微服务，不得不说目前被业界普遍接受并采用的我司首席科学家 Martin Fowler 给微服务下的定义：
这里边有个关键点，我认为没有引起大家足够的重视，以致于我认为目前市面上绝大多数的号称微服务架构的系统从老马的定义上来看，都是伪微服务架构。
这个关键点就是“能够被独立地部署”，我认为翻译成“能够被独立地交付”更贴切，而这点也是我认为评判一个微服务架构是否能发挥其价值的关键因素。这也是我前边提到的“组件编译时依赖”的问题。其实组件化一直是大家都追求的，例如我们常见的 jar 包和各种开源的组件本身就是很好的组件化封装。微服务从技术上看无非是将组件间的依赖点从“编译时”推后到了“运行时”而已。
不要小看这一点变化，带来的好处是非常多的。因为依赖被推迟到了“运行时”，才可能实现类似于“组件独立交付”、“组件运行时动态扩展”、“组件技术异构”等好处，但同样也需要承担分布式架构带来的复杂度作为代价。
那为什么说大多数的微服务架构都是伪的呢？因为有集成测试或其他因素存在，导致实际上并没有做到真正的独立交付（注意不是部署）。
为此我还写过一篇文章《你的微服务敢独立交付么？》，讲的就是如何在不需要集成测试的情况下，利用契约测试的策略设计真正实现微服务的独立交付，充分释放微服务架构的价值，有兴趣的话可以看一看。
所以业务中台和微服务架构的区别就在于两者解决的是不同的问题。一个是专注于业务层面，还要从企业级架构层面看待。一个只是专注于技术领域。
微服务架构的概念我也是在学习这个专栏时第一次系统的接触，我个人还是比较赞同“能够独立的交付”这句话，因为既然是服务的话，不止部署，连测试到交付都应该是可以独立完成的。
- 技术中台与中间件的区别？
这个问题大家问得也比较多。 确实，我们看到很多技术中台就是中间件平台包装发展的产物。
对于这个问题，说说我自己的理解。
技术中台强调的是更多从业务视角出发，而中间件主要是从技术去重的视角出发。
具体来说，技术中台为了让业务更好地使用技术相关能力，对于技术做一些治理、安全、可用性和自助式的包装。 如果能通过中台这个概念为驱动力，促使企业的内部技术平台再向业务走出一步，无论是针对用户体验做优化，还是通过产品化，让业务可以自助式（Self-Service）地使用企业技术组件的能力，如果能做到这些或是起到这样的驱动力，我觉得技术中台这个概念才有价值。
总结篇中推荐的《从平台到中台 | Elasticsearch 在蚂蚁金服的实践》，在我看来就是一个非常好的对于中间件平台（Elasticsearch 平台）中台化改造的例子，你可以重点看一下。
- 数据中台与数据仓库的区别？
其实不光是数据仓库，还有同学问到数据中台与大数据平台的区别。
这个问题也是大家比较关心的，可能是因为数据中台确实比较火吧。
其实外边有很多文章也在讨论这个问题，在我看来，其中最大的一个区别还是数据中台和传统的数据系统出发点（视角）不一样。 原来的数据平台也好，数据湖也好，数据仓库也好，它们的出发点很多时候有局限性，应该说更是一个支撑性的技术系统，即一定要去考虑我先有什么数据，然后我能干什么，依赖现有数据的质量、现有数据的状况，来做这样一个支撑性的技术平台。 那数据中台呢？回到我们所讲的中台概念，它更多的是从业务出发，然后再来看这些业务，你需要这些数据服务，它有什么价值？至于说这些数据服务所依赖的数据有没有，只要这个服务有价值，那我们就去想办法拿到数据，如果没有能力，我们就去建设技术能力，去完成数据服务的提供。
所以，传统的数据系统（数仓、大数据平台）更多是偏技术侧，拿着数据和技术找场景；而数据中台更多的是偏业务侧，拿着场景去找数据和技术。 ** 也就是说，数据中台的思维是业务思维，它从业务问题出发，这也就是为什么业务部门对数据中台会这么欢迎。总结篇中推荐的凯哥的《火热的数据中台对企业的价值是什么？》中对此有详细的展开，对数据中台还有疑惑的话，可以重点看一下这篇。
总结
本文开头也提到了这是从我这个菜鸟的视角来看待“中台”这个新事物，那么对我来讲，我能学习到关于以上3个问题的答案或者说见解就很值了，关于中台如何落地，落地时会有什么问题需要解决，我暂时还不需要了解，所以这个专栏的学习我先告一段落。
目前我学习下来，总结到2点：业务+企业级架构。
不管是什么中台，我们都应该更多的站在业务的角度上来设计，设计的时候站的高一点，望的远一些。中台的本质是企业级架构。
本文如有不对之处，还请指正。
