什么是中台？
我自己理解，中台就是对相同业务，技术，模型，数据的抽象整合，对外提供统一的能力，并能让后续工作者能在此基础上快速迭代。关键词有几个，“整合”，“统一能力“。
社会上有没有中台？有的，比如github就可以算是，github统一抽象了代码协作的工作方式，并且对外提供了一系列coder协作能力，能让coder自建规则提高工作效率，例如gitflow。比如电网，我觉得也可以算是中台，电网抽象了电的标准，提供统一的电力，让各家用在不同的设备上，甚至你有发电能力也可以申请接入。
为什么要有中台？
我们讲一个公司初创，或者一个业务新建的时候，流程一定是粗放的，会有一个重头到尾建设的过程。
就拿电商来说，浏览->(加车)->下单->支付->履约->完结。这个流程只要是在电商行业是一定的。但是不同的公司，业务线/项目都基本上会自己开发一遍，毕竟“大都相同，略有不同”。不同的公司也就算了，一个公司里的不同业务线/项目那就是明显的重复劳动。这就是典型的烟囱式架构。（盗图网上）
那么这种架构有错吗，没有的，这就是我前面说的粗放式，任何行业在没有足够的经验积累前，一定不知道哪些是可以共享的，哪些是独有的。比如我前面说的电商流程也是在这几年发展下出现的。在拥有了足够的经验积累后也就有了中台的架构。总结一下一句话，中台是就为了提高效率产生的共享平台(不一定是研发，我相信社会上不同行业都会有类似的中台)。
有哪些中台？
那么对于互联网来说有哪些中台呢，目前我所了解的分为三种，一是数据中台，二是技术中台，三是业务中台。
先说数据中台
数据中台好理解，当一个公司有很多业务线的时候怎么统计总的gmv，刻画用户画像？这个时候就需要把所有数据汇聚在一起。比如你在淘宝上买了件衣服，在饿了么定了个烧烤，又在飞猪买了去日本的飞机票。三种完全不同的消费场景怎么去刻画你这个消费者呢，又怎么在年底给你个年度账单呢。这个时候就需要把这些数据都汇集起来，那就考验整体数据模型的抽象，因为3种订单结构可能是不一样的，要从中抽象出核心的字段，同样也考验数据部门和业务部门的协作能力。总的来说数据中台更像是一个大水库，各个渠道的水来了后经过过滤流到水库里供下游消费。
再说技术中台
这个更好理解了，我们现在很多企业都在讲上云，其实就是技术中台的一种，技术中台屏蔽了业务和技术间的耦合关系，让业务开发可以不用去关心底层技术，更类似于工具，当需要时各取所需。
最后说说业务中台
业务中台也是最复杂的，因为业务一般是由多个节点组成的流程，比如前面说的电商交易流程，每个节点无法独立存在，上下游谁也离不开谁，但是每个节点在单独业务中又会有自己特殊的需求，比如跨境订单需要再履约的时候去清关，清关需要交关税，你会发现从商详开始关税数据就会一路带到履约，假如你目前的公司只做国内生意，设计的时候也没有考虑过相应扩展，那当有一天要做跨境生意的时候，整个全链路都要重新改造，这个成本可想而知。目前一般的做法是在主结构上增加一个feature扩展字段，当某个节点需要定制化的时候从feature中取出数据做处理。但是这仍然避免不了多个节点的联调测试成本。
再说下业务中台的划分，目前已知的有会员中台，交易中台，供应链中台，菜鸟仓储物流中台等等。
中台的优缺点？
既然中台是一种架构，那么一定会有他的优缺点。
先来说优点，上面已经讲了，对新业务来说能快速接入。试想一套完整的电商业务中台，今天你想做一个app渠道，那么只要按文档对接几个接口就完了，而不是还要去思考怎么设计交易订单。
当然缺点其实也很明显，因为能力是确定的，当有需求超过之前设计扩展点的时候，成本会大幅上升。
这也考验了架构师对业务的理解能力，如何提前预留更多更合理的extend。
其实我们在实践的过程中，也发现了很多中台的问题，前面说的优点，但其实实际应用中，没有哪个新业务是直接用一条主链路就能完成的，一般新业务一定是有新玩法的，那么这些玩法的扩展就需要投入资源，但是新业务往往是有很高试错成本的，这就形成了一个死循环，一边新业务业务不确定，不敢过多投入，一边不投入又开展不了新业务。这个问题一直到现在也没有很好的解决。更多的时候只能通过包在其他项目中搭个车。
目前也在讨论把中台做薄，现在大佬们的想法是中台应该”先做厚再做薄“，先要把能力沉淀下来，再去看哪些可以交给前台，哪些继续留在中台。既要保证业务的灵活性，又要保证资源的高效。
