中台化是决定小团队生死存亡的事情。
就我所在团队来说，这四年来我所在业务中台接入了 11 个产品线，其中三个产品线死掉了，4个产品线被其他团队抢走了，目前还剩 4 个产品线。四年的时间里这 11 个业务从生到死，从 A 团队到 B 团队，系统架构换了又换。一直在变化，一直折腾，从不停歇。
有时候我在想，第一个业务线接入后，假如我的团队停滞不前，没有进行中台化建设，没有后面 10 个新业务的接入。那么我的团队也许早就灰飞烟灭，被公司裁掉了。
如果你的系统还未进行中台化，请及时跟进，这真的至关重要。无论是基层员工还是管理者，都应该把中台化建设的思路应用到工作上，为团队提供接入新业务、新产品的能力。在行业寒冬来临到处裁员之际，你多负责一个产品一个业务，被裁掉的可能性就越低。
在互联网公司六七年以来，我感受这个行业变化极快，行业风口、业务形态、技术热点、组织架构无时无刻不在变化。从生到死只有一两年时间的业务比比皆是，最近大厂小厂都在裁员，每个人都能意识到行业寒冬的来临，互联网最美好的黄金时代已经过去了。
中台化建设不是要不要做的问题，而是如何做的问题。
中台化的第一步很简单
中台化是一定需要 定义产品线字段的。
产品线字段几乎存在于存储、系统流程、领域能力和接口上等系统的各个地方。中台化的第一步就是定义产品线字段。要首先确定什么粒度为一个产品线。例如我要售卖会员，美团外卖会员就是一个产品线， 如果我要新增售卖单车会员，那么就是另一个产品线。但是如果我要新增售卖年卡会员，就不是一个新的产品线，而是由会员卡商品的其他字段区分是年卡还是月卡。
定义产品线字段是第一步，完成第一步，我们就可以宣称我们实现了中台化，即便新的业务接入依然需要定制化开发，那只能说明我们的中台化目前处于早期，处于定制化阶段，而非不具备中台化能力。
除此之外，中台化建设重点在于厘清业务场景的通用性和差异性。通用性体现在哪里呢？
领域模型、存储模型的通用
多个业务在领域模型、存储模型等数据层面可能存在通用性。例如我曾经写到的 社交系统关注关系的 存储模型是极其类似的。# 解密亿级流量【社交关注关系】系统设计。 那么我们可以复用相似的存储结构，并且通过产品线进行数据隔离。
业务流程的相似性
多个业务在流程的相似性可能更加明显。例如 我曾经写到的# 人人都能设计复杂的业务系统------营销中台(1) 选择一批用户批量赠课和批量赠券。首先我们想到的就是选取海量的用户发放某些权益，无论是赠课也好、赠券也好，他们在流程上是非常相似的。都需要保证海量数据发放的可靠性、稳定性和发放速度。
发券和赠课这两个动作在模型上也许并不相似，但是只需要配置好发券和赠课需要的发放属性，由不同的履约扩展点适配就好了。每新增一种权益类型，新增一个履约扩展点实现。在配置数据上如果无法统一，那么即使使用 JSON 也无所谓。因为系统在保证海量数据发放的可靠性、及时性上，实现了复用，中台已经实现了最大的价值。
接下来我来说明中台如何支持业务的差异性。这也是至关重要的。如何沉淀中台的能力，也主要在差异性上体现。
中台如何应对差异性
如何理解产品线之间的差异性。举例来说，美团外卖会员、外卖券包都是虚拟商品的售卖，在提单交易环节，是否扣减库存有不同、是否对用户限额有不同。发放的物料是红包还是会员身份+红包 也是有差异。退款逻辑上，会员生效不允许退款，券包则有主动退和过期系统退款。这都是实实在在的差异。
不同的产品形态在业务逻辑上是存在不同的，我们重点要进行流程和存储上的抽象。对于差异点我们要提炼出来一个个对应的能力。
例如新接入的产品形态需要扣减库存，我们建设了库存能力，另一个产品形态要求支持日库存，我们需要则建设周期库存或分时库存的能力。
在只有一个业务时，所有的能力都是个性化能力，但是当有了第二个......第N个业务，业务逻辑上的相似性、共通性就会体现出来。例如券包的过期自动退款在一开始我们认为就是个性化的，因为现有会员形态都不支持过期自动退款，但是后续的一系列券包产品都开始尝试过期自动为用户退款。这说明一个问题：【别看现在是个性的，以后就可能是通用的。】
基于此，开发者要认真对待每个个性化的业务逻辑，没准哪一天就有其他业务复用这个业务逻辑。不要觉得这个逻辑奇葩就排斥。接入的业务多了，总会有可能复用这个逻辑。抽象+复用是中台的价值所在，这是我们建设中台、对待新业务的基本态度。对于总想把新颖的、个性的业务逻辑踢给业务方的中台，我是鄙视的。
中台的差异性体现在各种地方，例如限额能力包含按天限额、活动期限额、按月限额等等。履约的会员卡可能有月卡、年卡、季卡。卡的生效期可能是固定天数，可能是自然月。有的券包会预售，需要履约一个下周才生效的会员卡。也就是这说明同一个系统能力业务不光可以选择 需要或不需要，还可以说：我希望使用这种类型的系统能力。一个系统能力可以有多个可选项。
业务中台如何应对这些差异性呢？
配置化
产品线之间的差异性一定是存在的，配置化是中台支持差异性的法宝。
在没有配置化的时候，我们开发的是专为业务定制化的代码，当另一个业务需要接入时，需要硬编码适配到新业务。使用配置化以后，我们只需要在XML配置 这个产品是否具备这个系统能力。
举个例子：拿过期自动退来说，新的付费券包产品如果需要支持过期自动退，只需要在产品线的 XML 配置里 enableExpireAutoRefund=true 即可。这样归、过期退的扫描任务就会扫描这个产品线的可退付费券包，调用对应的退款逻辑。
如果退款逻辑不同，例如有的付费券包 部分使用不可以退，有的付费券包部分使用可以退，那么我们在退款的校验逻辑上就要为各自业务线配置不同的校验逻辑。 我们可以提炼出红包部分使用不可以退的校验组件、红包全部使用不可以退的组件，分别配置在各自业务线的退款逻辑。这些组件都是和业务无关的，而我们只需要在 XML 配置上对应的组件，就能满足新付费券包的差异性。根本不需要重新开发。
我再举个例子：目前的付费券包和付费会员生效期有多种形态，包括按固定天数履约、按照自然月履约、按照自然年履约，更甚至有的季卡，产品要求按照 30天，30天,31天 的顺序履约。在配置化之前，我们都是 case by case的针对每个产品线单独编写代码，生成对应的履约期。
后来我们转变为配置化的思路，我们迭代了周期类型的概念，不同产品线选择对应的周期类型。履约期计算组件根据产品线配置的周期类型：固定天数、按照自然月、按照自然年、指定天数序列等，选择对应的策略模式计算履约期。这样只要新的付费商品周期类型是上面的几种类型，就可以直接 XML 配置复用了，无需开发。然而如果新的付费商品周期计算类型和以上都不同，那么我们就根据他的逻辑设计一个新的类型，不对具体的产品线编程。这样在未来，如果还有业务使用类似的逻辑，我们只需要XML 配置下就能支持了。
所以我们永远可以自豪的说：如果一个新业务和现有的任何业务类似，我们无需开发，就可以接入。 这应该成为业务中台的宣言和信仰。
业务中台或中台的建设就是一个不断整理实现配置项的过程，不断丰富补齐系统的可配置化能力，日拱一卒，不断精进，不断降低新业务接入成本，成为高效、快速支持业务迭代、支持业务试错的利器。
未来我会继续用美团外卖的实际场景给大家举例，如何实现配置化
如果大家觉得看完有收获，点赞、收藏、评论，怎么方便怎么来。小弟在此拜谢了🤗。