春节期间看完了极客时间的《说透中台》的课程，顺便也读了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》一书。这篇从实际项目的角度来想象一下，如果让我来负责公司的中台，应该怎么做。
首先说下评价：这个课程符合我对ThoughtWorks的刻板印象：有点滥用理论术语，干货不多；问题题了不少，解决方案不落地。可能是都是给其他公司做的项目，有保密协议的缘故。能理解，但还是不推荐。阿里的那本中台书更加实在。
1. 中台概念整理
1.1 中台的目的
中台的目的就是企业能力复用。
1.2 中台的分类
中台主流分为两大类：业务中台/数据中台。业务中台产生数据，数据中台做数据的二次加工，并将结果再服务于业务中台。
也有“技术中台”的概念，可以理解为一些技术中间件的整合和封装，但我倾向于不将其认定为中台。
中台强调一个复用。如果根本没有系统从零开始建设，一上来就搞中台很容易会过度设计。
2. 中台的抓手
中台会面对所有业务线的需求。虽然中台有企业级的属性，但不代表建设中台的时候必须梳理企业的全业务线。中台的愿景是能力复用，那么最好有具体的新业务作为抓手。
- 阿里是以聚划算作为抓手
- 蘑菇街的新增抓手是直播电商
- 美菜网是遇到了生鲜和2B的一些新玩法需求
2.1 对当前所在公司构建业务中台的构想
《说透中台》中虚拟出来了一个极客地产。极客地产做中台的抓手是有新增的长租公寓的需求。长租公寓需要复用已有的地产投资和物业能力，但工程设计/招采/建设/装修/租赁等是从零开始。那么就可以针对地产投资和物业这两块来建设中台。而另外独立发展的业务线可以先跳过。
极客地产这个例子其实和当前所在公司挺像（为了避免再被信息安全“训诫”，这里就不提公司名字了）。已有的业务是投资，金融和运营三个板块，而现在新增了商业地产板块。是不是可以趁这个机会也建设中台？我觉得可以有针对性发展少数几个业务中台，主要做数据中台。
楼宇项目信息可能是少数比较共通的部分，但投前和投后在剩余的部分的交集有限。没有复用，还不如将功能独立建设在自己各自板块的应用里。当然现在对其他三个板块了解也有限，可能在了解更多后会推翻这个判断。
3. 中心与服务如何划分
在具体动手开始搭建中台后，我们首先面临的问题是服务中心怎么划分怎么建设。
淘宝的经历是首先四个服务中心：
- 用户中心
- 商品中心
- 交易中心
- 店铺中心
用户中心因为调用频繁收效大，而且复杂性和重要性较小，不出意外成为了最开始的试点。商品中心后来又拆出了评价中心。交易中心拆出了营销中心。另外还增加了一个库存中心。
中心的划分的原则是：“高内聚、低耦合”。如果只有增删改查这样的简单需求，不建议单独拆出一个中心。像是积分这种，等发展到足够丰富或对其他业务中心的影响已经不可忽视再拆。
每个中心也可以由多个服务组成。例如交易中心可以分为订单服务和购物车服务。服务中心是业务领域的概念，是为了业务和数据的完整性而设立的。而包含的子服务模块是根据系统架构设计的层面来考虑的。但一开始不要拆得太细。
4. 中台的其他技术考量点
4.1 服务插件
《京东服务技术中台探索与实践》的视频中提到了他们建设中台的时候有一个“服务插件”的概念。简单来说就是对于非常个性化的需求（例如对用户体验的预警），提供插件协议，由相应前台团队自己来开发插件。
这种中台的场景可能更适合中台把前端页面也包揽的情况。下图是插件在实际页面上的规定展示区域。
4.2 租户
还是《京东服务技术中台探索与实践》的视频。为了防止某些用户在大促的时候把中台资源（包括计算资源和存储资源）给吃完，引入了租户的概念。
租户的设计对于有2C秒杀大促等场景的企业可能是必要的，毕竟不能在中台层面产生雪崩。
4.3 配置化
包括蘑菇街和京东服务中台的例子中，都提到了中台可以成为业务逻辑的下沉，前台应用做配置。
像蘑菇街就是将促销的逻辑做成模板：
5. 中台的实施路径
阿里的中台实施路径分为三个阶段：
- API as Service
- Product as Service
- Solution as Service
第一个阶段比较好实现，第三个阶段是到一定层次后的追求，我觉得关键是第二个阶段，就是将中台打造成一个产品。
打造成产品，意味着将API进行场景化的组装。如果只是一堆API列表，无法达成快速支持前台的目的。
除此以外，产品化也意味着：
- 产品有自己的定位，可以选择性地实现前台需求
- 产品要想方设法为客户（前台）体现价值，保持用户满意度才能生存下来。如果一定期限内无法获取前台用户，或前台用户不满意，则及时中止建设止损
- 产品要讲究易用性，提供完善的文档和手册
中台的绩效考核可以参考阿里的做法：
- 服务稳定40%
- 业务创新25%（适当允许因此带来的上线事故）
- 服务接入量20%
- 客户满意度15%