关于中台，现在已经烂大街了。随便几个微服务整一整，对外就号称中台。但中台到底是什么?做好中台需要具备哪些能力?今天我们就来聊一聊中台。
什么是中台?
2015 年阿里巴巴提出中台概念和战略，从那时候开始「中台」这个技术名词就开始火热起来，尤其是从 2019 年开始进入了爆发期。前段时间还有一篇关于阿里拆中台的文章，刷遍了全网。
在我看来，中台就是功能的复用，并且还是业务功能的复用。例如：一个电商公司里，所有系统都需要给用户发送消息。如果每个系统都要自行实现消息发送，那这个成本就太大了。于是乎就有一个系统专门来做这个事情，实现「发送消息」这个业务功能的复用。
如此一来的话，那其实用微服务不就可以了，何德何能叫得上中台呢?
这是一个很好的问题，可以让我们进一步深入思考中台这个事。
在微服务时代，消息服务提供接口出去，各个系统直接调用发送就行了。这个时候，系统调用方与系统提供方之间的通信，还是非常技术性的，他们之间的通信可能是这样的：我要发给 XX 用户、内容是 XX、用 XX 账号发送、要发送的是 XX 语言等等。
对比起微服务，中台应该是微服务的产品化。比起微服务方式，中台的设计需要抽象出自己的一套业务逻辑，屏蔽底层的细节。 就拿发消息这个例子来说：之前是非常简单地将要发送的参数传递给消息发送系统，消息发送系统不做任何封装。
但对于消息中台来说，它可能提出一个业务编码的概念，通过业务编码与模板与账号关联。而对于调用系统来说，只需要告诉我你需要发给哪个用户，发哪个业务的消息即可。至于怎么匹配模板、怎么匹配账号，调用方不需要关心。
总的来说，中台与微服务的区别在于：中台是对功能的更深层次封装，可以说是产品层面上的包装。
说起中台与微服务的区别，可能还不止功能封装程度上的区别，可能还有数据开放、权限管控等方面的区别。对于微服务来说，其只是简单的提供一个服务。如果后续调用方的 B 端管理系统需要查询消息发送记录，那么你就会让一个 B 端系统去查询一个 C 端系统，这明显不合适。另外，查询数据时需要做权限控制，一个系统只能查询自己的数据，这时候你又得在 C 端的消息发送系统里去做权限控制，整个系统就非常冗余了。
对于中台来说，其思考的层次会更高一些。中台将自己当成是某块通用业务的服务提供者，而不仅仅是一个内部系统。对于核心的业务功能，其与微服务一样通过接口提供功能。对于数据开放，其通过开放平台开放数据，并做权限控制。其实企业内部的业务中台，就很像淘宝开放平台、京东开放平台，只不过是开放的对象以及程度不同而已，因此我们完全可以按照开放平台的思路去建设业务中台。
中台的平衡点
我们都说中台是通用能力的复用，那么哪些是通用能力?哪些该做、哪些不该做?这或许是困扰我们中台设计人员一个很痛苦的问题了。
要找到平衡点，我的经验是首先找到两个极端点。 就拿我做过的消息中台这个例子来说，左边的极端点是极端定制化，即业务方要做什么，我们就做什么，冗余了大量的各种各样的业务细节。右边的极端点是极端地平庸化，平庸到提供的服务其实和第三方服务商提供的服务没啥两样，那么业务方干脆直接对接第三方得了。
知道了两个极端点，我们也知道了一个范围，我们后续要做的就是在两个点中找到一个平衡点。 其实对于这个平衡点的选择，更多的是依赖设计人员对于这块业务的理解。业务人员需要深入地了解整个业务流程，了解哪些功能是所有调用方都重复做的，以此找出中台要实现的通用功能。接着需要做的，就是将这些内容封装起来，设计一套业务逻辑和使用流程，让调用方能简单、方便地使用。
以我做过的消息中台而言，我发现许多系统存在的重复功能是：多语言模板匹配和替换、多地区发送账号匹配。多语言模板匹配和替换，指的是在国际化背景下，用户都是各个国家的人，我们需要根据用户的语言匹配对应的模板。多地区发送账号匹配，指的是在国际化背景下，用户分布于各个国家地区，每个国家地区的服务商都不同，因此需要匹配不同的账号去发送。
找出消息中台的重复功能之后，我们要做的是设计一套业务逻辑和使用流程。对于消息中台，我们设计了：「系统 - 业务 - 模板组(账号组)- 模板(账号)」的核心业务逻辑。1 个调用方对应 1 个系统，1 个系统可以有多个业务，1 个业务在某个渠道(邮件、短信等)只对应一个账号组，模板组(账号组)则通过语言 + 站点(国家)去唯一确定一个模板(账号)。
通过「系统 - 业务 - 模板组(账号组)- 模板(账号)」的业务逻辑设计，以及对应的管理后台配置流程，我们为消息中台建立了一整套消息发送逻辑。调用方系统可以建立多个业务，来关联其真实的消息发送场景。每次需要发送某个消息发送场景，提前在管理后台配置好对应的模板组和账号组。在发送的时候，只需要告诉消息中台发送哪个业务、发给谁就可以了。
中台的演变
当我们设计好一个中台之后，我们可能希望其实一成不变的。但事实上，中台也是随着业务的变化而变化的。就拿我做过的消息中台来说，一开始其定位只是发送消息通知类，即注册发送邮件、发货通知等小批量的消息。但随着业务的发展，有些系统需要在很短的时间内发送几百万甚至几千万的消息。
这时候如果使用原有的系统功能，那么势必导致消息挤压，造成消息发送延迟。这时候作为中台的设计者就需要根据自己对业务的理解，以及未来需要的可能性，去做一个架构上的调整。如果判断未来很可能有更多的系统需要这个功能，那么我们需要调整中台的业务架构，去实现这个功能。对于短时间内发送几百万消息的这种功能，我们后续是用了与之前完全不同的架构去实现的，也设计了完全不同的数据结构以及实现方法。但整体上，还是与原有功能融为一体，成为一个统一的消息中台服务的。
前面说的是属于业务发展中出现的新功能，但实际上也有可能是原有功能的不断精细化。例如我们所说的通知类消息，它们可能有：发货通知、注册验证码邮件、COD 货到付款邮件等。随着业务的发展，通知类消息越来越多，不同类型的消息的优先级矛盾会越来越明显。
对于 COD 货到付款邮件来说，其涉及到用户订单付款，因此优先级无疑是最高的。而注册验证码邮件，影响到用户的注册，相对来说也是优先级较高的。而发货通知，则只是一个通知的功能，优先级相对优先。在消息越来越多的情况下，消息中台需要支持发送资源完全隔离的功能，以此来保障高优先级业务的低延迟快速发送。
那么如何进行业务架构调整，既能满足新功能的需要，又不影响原有的业务功能。这其实就极度考验中台设计者对于业务的理解以及对于系统的理解了。
说到消息优先级的问题，有些朋友会说：那我一开始设计的时候就考虑到优先级问题，直接解决了不就好了么?
这个想法很好，但事实是很骨感的。很多时候我们不仅要考虑技术实现，还要考虑业务当前的情况。如果业务当前并没有多少消息发送流量，所有消息基本上都能很快发送出去，这时消息中台来实现优先级的功能，有什么意义呢?不仅增加研发成本不说，还让系统更加复杂，增加了维护成本。
业务这个因素，其实是很多技术人员忽略的一个问题。我们做设计以及实现的时候，不仅要考虑技术扩展性，还要考虑业务目前的发展情况、团队成员的能力情况，才能做出适合当下情况的最优选择。 而不是简单地拍脑袋做一个大而全的东西，用大炮打蚊子，浪费资源。其实对于是否要在项目中使用设计模式，也是类似的思考方式，重点还是得看团队成员的专业能力。
总结
什么是中台?我认为中台是对重复业务功能的产品级别封装，有别于微服务的系统级简单封装。产品级别的封装需要深入了解业务，定制出一套自己的业务概念，屏蔽底层的细节。此外，数据开放也是中台本身有别于微服务的一个关键点。
如何找到中台的平衡点?对于平衡点，我提出了一个方法论：确定区间范围，即知道最好、最差的情况下是什么，然后找到合理的中间态。这个中间态取决于中台的定位，如果你的定位是公司级的中台，那么你解决的就应该是公司级别的通用功能。
如何看待中台的演进?中台是随着业务发展的，中台设计者需要紧跟业务需求，从需求中洞见未来的趋势，找到中台的方向。此外，设计之时不仅应该考虑技术问题，也应该考虑当时业务规模、团队协作、人员能力问题，做出综合成本最低的设计方案，而不是用大炮打蚊子。
那么做中台需要哪些能力呢?
其实从上面我的一些思考不难看出：需要有高度抽象思考的能力。 这可以说是最最重要的能力，没有这种能力，你很难找出共同的功能点，也就很难找到中台的定位。另一个能力是综合权衡，做出最优选择的能力。 在中台的演进中我们说到要考虑业务规模、团队协作等情况，这就需要中台设计者去综合各种因素，做出最优选择，而不是单单追求技术的高大上。
