TL;DR（太长别看了）1.业务中台就是流程模板+扩展点2.抽象不好就不要做中台。没有那么多需求和业务线就不要做，做中台。很多同学会问，什么是中台，中台是什么水平？我们可以用一小群精锐的海、空、海军陆战队来说明这个例子。我们都知道海、空、海军陆战队是非常强大的，但是他们可不只是3-7人的队伍，强到什么程度呢？原来他们背后有着强大的中台系统，他们在海上待命，随时运送弹药。3人小队一旦侦测到地点的精确位置，直接向目标派出空军或导弹，将作战能力发挥到极致。从系统上，我们也可以创建一些这样的中间站。业务中心提供可重用服务，例如用户中心、订单中心等开箱即用的可重用能力。算法平台提供算法能力，帮助提供更加个性化的服务，提升用户体验。数据中心为公司内外的行业决策提供基础服务，提升数据应用能力。技术中心为自建系统提供技术支持能力，帮助解决基础设施、分布式数据库等底层技术问题。研发中心为自建系统提供管理和技术实践支持能力，帮助快速构建项目、管理进度、测试、持续集成和持续交付。简而言之，我们把这些能够保证前端需求的大部分能力开箱即用，又能快速响应前端需求迭代的服务，我们称之为中端。什么是需求迭代的快速响应？为什么会有中间站？有必要建中台吗？今天我们只从业务中台的概念来梳理一下中台的定位。接下来我们以一个登录服务为例，从知名的登录服务平台到登录服务中台，对比平台与中台的差异，看看如何快速响应需求迭代。根据我们的设计，一个登录服务平台一般需要提供发送验证码、注册、登录、注销、身份/权限验证等服务。开始的时候，每一分钟总是美好的。我们设计的平台总能很好的满足业务的需求，对一些需要扩展平台能力的地方也能比较及时的做出响应。但是，慢慢地，事情似乎发生了变化。平台在发展过程中，业务方越来越多，需求也越来越复杂。一个业务系统要指定一个特定的验证码平台，而我们从来没有接入过这种验证码方式。平台开发者和商家只好派两个人去对接。B业务系统来了，说要给N次登录失败的用户发送短信提醒和邮件提醒。平台开发商和商家不得不派出两个人来满足这些需求。C商也来了。D商也来了。慢慢地，这个所谓的平台已经没有人在上面工作了。本来我们设计的是前台后台拆分，让前台满足用户需求的快速迭代，同时期望后台稳定。当我们的平台开发人员不能保证我们搞清楚业务人员的需求是产品经理的脑洞还是实际需求时，大量频繁的平台开发，甚至规则的变更。对于平台的稳定性和业务团队来说都是灾难性的。这是一个爆炸。那怎么解决呢？中间平台能解决吗？如何解决？为了解决这个问题，我们将上面的登录服务抽象成一个标准的模板流程：输入账号密码->验证码验证（默认由平台实现，可在平台选择或下载SDK扩展中找到）->账号密码验证->账号密码验证后身份验证（默认为平台实现，平台可以选择或下载SDK扩展）->登录失败次数后续动作扩展（下载SDK，调用此自定义扩展在每次登录时）。三个扩展点，验证码验证，身份验证，登录失败后续动作。对于这三个动作，平台可以提供几种默认实现，也支持业务系统定制。当业务系统有相应的需求时，可以自行开发，生成SDK，嵌入到平台运行时，根据请求内容执行指定的扩展动作。这样既保证了服务的稳定性，又减轻了服务团队的压力。让我们把场景回到A系统，他不是要自己的验证码吗？OK，扔掉一个文档，让系统A的团队自己扩展验证码校验，然后以插件的形式部署上台。我们继续场景，回到系统B，他不是要在3次登录失败后发短信通知吗？OK，扔掉一个文档，让A系统团队展开实现登录失败的后续动作，然后以插件的形式部署到中台。看看吧，这个简单的模板流程+扩展点的实现，把中端开发人员从繁杂的业务系统中解救出来了。如果某个扩展点的实现被很多用户频繁使用，那么这个扩展点的实现可以直接作为平台的默认扩展选项出现。如何理解这个扩展？假设我们是厨房，我这里有肉桂、八角和糖。那有一天我想要卤蛋，怎么办呢？我要调料，按照菜谱慢慢称出肉桂1小块，八角3颗，白糖5克。然后第二天，我必须将调味料一种一种重新混合。还有30个小伙伴也想开自己的卤蛋摊。我拿了之前的方子，直接腌在一大桶酱汁里，取名卤蛋一号酱。然后两天后，专家告诉我加2g糖会使颜色变深，但只用过一次，所以我没有命名这个食谱。又过了两天，大家更喜欢这个专家的菜谱，说很好吃，所以30个小伙伴都在找这个菜谱。卤蛋2号酱，直接把这大桶2号酱打包卖了，让卤蛋摊主开箱继续用。你看，效率如何？不需要每个卤蛋摊老板都调酱汁，而且一旦卤蛋摊老板有了自己的菜谱，再改之前的菜谱就很方便了。是否有很多好的标准流程模板，是衡量一个模板+扩展点是否是一个业务平台的标准。说了这么多，有必要搭建中台吗？从例子中我们可以了解到，1.中台需要对实际的业务或者技术沉淀进行抽象，想要做好需要有扎实的业务技术抽象能力。2.当产品线多，业务拓展需求多时，搭建中台更有价值，但当产品线少，业务拓展需求少时，中台不划算。
