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