开篇
本文说的小团队是指50人左右技术团队，包括了产品，开发，测试，运维等，一般传统企业的技术团队差不多就是这个规模。很多人会有质疑，就几十号人，有必要做中台吗？能做出效果？
本文解答下以上两个问题，这里先回答第一个问题，为什么御家汇要做中台，在最后总结里回答第二个问题，做了中台后的效果。
御家汇是一家上市化妆品公司，旗下知名自有品牌有御泥坊，小迷糊，薇风大水滴。水羊国际平台下有数十个国际知名代理品牌，城野医生，露得清，kiko，伊菲丹等。
多品牌决定了我们需要探索各种前台业务，比如每个品牌都有自建商城的需求，怎么用少量的技术资源来支撑灵活多变的前台需求是我们需要迫切解决的问题。
同时公司建设的业务系统也多，有ERP，订单系统，仓储系统，OA，HR，自营商城等十多个系统，每个系统都是烟囱建设，需要投入的技术资源非常多，有时就得加班干了。
整体建设思路就是：下面分3个部分介绍中台建设前，技术中台和业务中台的一个建设过程。
中台建设前
中台建设前，我们技术团队负责了公司所有内部的业务支撑系统和C端的商城，每个系统技术栈是独立的，并且技术比较陈旧，开发效率低。然后公司正好上市了，业务快速发展，技术部门越来越跟不上节奏。
随着微服务和中台概念的流行，18年初，技术部门负责人决定开始中台建设，一个是把以前陈旧，效率低的技术栈升级，二个是快速响应业务变化。当时也接触了阿里云和一些中台实施商，考虑到费用都比较高，高层决定自研。
首先组织架构上的调整，成立架构组来主导中台建设，当然投入资源也是比较大气的，准备给我3个人，希望是美好的，现实是残忍的，最后给了1个人，一个工作经验3年的小伙伴，最终就是我和这个小伙伴两杆枪踏上了不归路--中台。
当然部门负责人也是一开始就给予我足够的决策权和自由度，整个技术方案完全由我决定。先走出第一步，做技术中台。
第一阶段：技术中台先行
（编者注：李昊和老G先生观点，技术中台更可能是对应于技术infrastructure。）
这个阶段的时间节点主要是2018年。面临的第一个问题是技术选型，先前陈旧的技术栈肯定是不行，当时备选方案有三个：dubbo,spring cloud,阿里云edas。当时从几个维度对比了三个方案：
考虑到spring cloud处于上升期，就觉得用spring cloud搭建微服务开发平台，大约花两个月时间搭建了开发框架后，正好有个新项目要开发，就直接采用新的开发框架进行开发。
开发过程中提升了开发框架的稳定性，并沉淀了一些业务无关的服务，比如单点登录服务，权限服务，短信服务等。这类业务无关的基础服务，最终服务于所有业务系统，比如权限服务，就能给所有业务系统进行接入（外购系统除外）。
在技术中台建设中，除了提供开发平台，更关注一些软性能力的提升。
1. 输出开发规范，强制每个开发学习。
2. 定期代码评审
3. 分享技术中台的所有技术组件，提升各个开发的视野和能力
4. 打造学习型文化，让每个人感受学习氛围，驱动自我提升
第二阶段：技术中台持续优化，业务中台起步
这个阶段的时间节点主要是2019年。这个阶段组织架构上有些调整，由于技术中台取得了一定的成效，测试、运维、DBA和大数据几个小团队也归到架构团队一起管理。
由于团队上整合了测试，运维等多个职能，技术中台的范围也扩展到覆盖需求，开发，测试，运维整个敏捷价值链条，技术中台因此也越来越完善。到2019年底，开发了测试平台，从原始的功能测试升级到自动化测试；搭建了持续集成和发布系统；构建了包含基础监控，应用监控，业务监控的立体化监控体系；做了很多提效的自动化工具。人员能力上也得到了大幅提升，比如我们的测试人员能够自己开发和维护测试平台。
业务中台的建设方式我们采取的方式是由架构团队指导业务开发团队自己来开发业务中台，好处是他们懂业务，这样开发出的业务中台更贴合实际。
怎么指导业务开发团队来开发业务中台？这里我们引入了DDD方法论。由于我是业务系统开发出身，以前做过大型复杂业务系统，对垃圾代码深恶痛绝，深受其害。从19年初，就引导业务开发团队开始学习领域驱动设计(DDD)，最开始团队学习是比较吃力的，通过一些读书会，分享讨论等方式，把学习节奏带起来，经过半年学习，一些核心骨干慢慢有感觉了，并逐步在开发中使用。
技术中台加上DDD，让业务开发团队能从技能和思维上，转型为中台开发人员。开发团队通过DDD的方式指导业务的中台边界划分，针对电商划分出商品，支付，订单，客服，物流，营销活动，积分等多个中台服务，利用这些中台支撑前台的商城系统开发。一个具体划分图如下：
括号中的百分数是我们在开发一个新系统时，中台需要改造的范围，可以看到大部分服务很少改造就可以支持。
在划分中台时，坚持一个原则，先用DDD的限界上下文粗粒度划分，后面再按需重构。
业务中台复用时如果支持个性化功能，我们借鉴了阿里TMF框架的思路，引入了扩展点的概念，比较灵活的支持了个性化功能。举个例子：营销活动在复用时，会出现不同业务组合的活动不一样，所以我们抽象了一个扩展点
总结
总的说来，到目前为止，中台建设的效果有：
- 开发效率大大提升，团队内部调研技术中台带来的效率提升达到60%，其中一个同事的前公司是YY，他反馈比YY当时的开发效率也要高50%左右。
- 响应业务速度加快，2020年初一个综合性商城上线，只花一个月时间，中台复用达到70%以上
- 用户体验更好，各个系统性能加快了，比较轻松应对大促
- 申请了十来个专利，提升了部门的影响力
从效果来看，还是不错的，从资源投入上来看，只有2个人是额外投入来做中台基础设施，也就是说中小团队走上中台建设之路具备可行性。下面总结一点个人经验：
- 领导层支持非常重要，组织上要是不坚定，那么就不要贸然
- 刚开始经验不足时，不要步子迈太大，投入太多资源，可以先从技术中台开始，然后新项目试点
- 业务中台一定是最熟悉业务开发的人来参与，效果最好
- 持续提升个人和团队能力，没这个基础，中台就会变成PPT中台
- 不造轮子，只使用轮子，得益于各种开源工具的丰富性，让我们少走很多路，感谢各路技术大神
