滴滴业务中台构建实践
点击上方“开发者技术前线”，选择“星标”
13：21 在看 真爱
滴滴做中台已经有好几年的历史。早在 2015 年，滴滴就开始组建中台，2016 年的时候方向调整做了出行中台，目前滴滴很多出行业务都是基于这个中台。滴滴的很多业务场景，都是配置出来的，在出行中台里面进行孵化，孵化了之后，通用能力像支付、定单、计价、passport 等，不但能支持出行，也能支持别的业务，于是出行中台在今年年初演进成了公司级的业务中台，把原有中台中更加通用的部分带过来了。
目前整个滴滴业务中台团队研发有一百多人，算上产品经理团队规模更大。目前滴滴的大部分业务场景都在使用业务中台，已经构建了订单中心、计价中心、支付中心、passport、用户中心、触达平台六大能力。
搭建业务中台，不应完全从技术的层面来看，因为业务中台最终要看到的是仍旧如何快速支撑业务。技术只是实现业务的手段，滴滴本身也有技术中台，用来提供一些基础的设施，像云基础设施、MQ、NOSQL 存储、监控平台等，业务中台背后有提供大量技术支撑的技术中台。
除了技术中台以外，滴滴还有规模庞大的大数据团队在做数据中台，业务中台是依托于技术、数据中台，更贴近于业务，主要是对业务负责。最终业务中台能做到对整个业务进行抽象，把通用的部分沉淀下来。从整体来讲，我们支持业务的发展，让业务能跑得更快。
举个例子，各个业务模块过去没有支付系统，从头开发一套支付是很麻烦的，现在有了业务中台可以一键接入支付，至于下单后，微信支付宝怎么调用，怎么支付，失败后怎么处理，就不需要业务方再去操心了，依赖业务中台的统一接口就可以搞定，在整个业务的支持上来讲，肯定是让它更快了。
滴滴在 2015 年的时候就开始尝试搭建中台，有了一些成果，到了 2016 年，公司调整思路，从比较务实的角度出发，提出基于最大的业务线——出行业务线去孵化滴滴出行中台的思路。当时提出了一个目标，滴滴的业务肯定是配置的，最合适的十几分钟就能配置出来。
经过几年的发展，慢慢进化到今天这个样子。从 0 到 1 的过程中，最主要就是务实，基于解决问题，从业务出发，再基于当前的最大业务线做孵化，逐步迭代、逐步抽象，小步跑快，最终达到一个比较理想的状态。
2015 年的时候，中台的概念还不是那么火，业界都处于摸着石头过河的状态。同一件事情，会出现不同的解决方案。小步快跑、快速试错的方式比较容易成功，另一种可能最开始的规划比较多，受外界影响的变化也比较多，最终可能导致做出来的东西跟实际情况不匹配，或者需要经常改影响了实际效果。滴滴也有类似的尝试，结果并不是很成功，所以就换了另一条思路，最终在 2016 年开始取得了一些成果。
滴滴出行业务会有高峰期的概念，工作日的早晚高峰、节假日的高峰期，中台对于业务的支撑也会加大支持力度。业务中台是整个业务中非常重要的一环，针对高峰期，中台部门需要在处理方案上做功夫，至于这个模块中台不好处理能否放在业务部门，或者业务部门不好处理能否放在中台，都是可以商量的。对于最核心的业务，比如滴滴的出行业务，在技术上的投入、资源上的倾斜力度都会更大。
业务中台是为业务服务的，跟业务线要走得很近，滴滴今年在内部提出“向前一步”，每个技术团队都会向前一步，了解你前面所支撑的业务到底是什么样的，这样整个前后信息是打通的，从一个统一的认知上去理解问题、沟通问题，最终就更加容易达成一致。
业界一些中台部门存在的业务接入遇到阻碍的问题，在滴滴这很少遇到，因为滴滴的业务中台直接是从最大的业务中孵化出来的。订单中心、计价中心、支付中心、passport、用户中心、触达平台等都是配置孵化而来，对于目前不需要中台的业务线，中台部门也不会去强制接入，内部更多是通过沟通机制划定边界。
中台团队需要下到各个业务线去沟通，考虑对方的需求如何通过我们的抽样能力、复用能力，以最终达到提高人效的结果。背后会有一些资源上的倾斜，需要沟通、对齐，对于滴滴而言整体最优是最合理的。达成整体最优就需要共同协商、解决，可能有些需求暂时排不上期，就会让业务线自己先做，中台部门永远不可能比业务线人多，同样也不可能像业务线那样对于业务的变化那么敏感，在这个过程里，需要中台部门与业务线之间拉通信息以解决问题。
滴滴业务中台部门的成员大部分是内部转化，最开始的出行中台孵化出来了一些工具和基础能力，带来了一些业务中台部门的早期成员。中台部门其实是有些延续性的，也会招聘一些新的人，但只要有老人这些文化、种子存在，新人进来以后就会快速融入，融入之后带来新的思想、新的碰撞，可能会产生新的思路、新的文化。
业务中台部门成员跟纯粹的底层开发之间肯定存在一些差异，相对而言前者的技术工作可能更加容易，跟真正的业务开发人员相比，对业务的了解也会存在一些差距。所以，滴滴提出“向前一步”的做法，也是希望中台人员能跟业务开发人员拉齐，久而久之就会有业务上的感觉，也可能对未来业务发展产生自己的想法，同时基于对内部技术、后台的理解，做出一些技术上的创新，从而支撑整个的业务层未来的创新。
理论上来说，业务部门的开发人员可以做任意开发需求，但这背后存在一个性价比的问题。比如说登录功能，任何一家小公司、小团队都可以做，但是不是能做到体验一致？比如说滴滴一家公司有好几个 App，如果每个 App 的体验做得都不一样，用户会怎么想？
所以对业务中台部门而言，以一个统一的接口去做系统的优化，沉淀下那些通用的能力，这是性价比最高的方案。此外，中台部门在技术上也会做得更深入一点，考虑更加全局化一点，不会随意造轮子。
中台是微服务的集散地这个观点我不认同。所谓集散地，代表的是一种杂乱无序的状态，是一大堆东西硬塞进去的混乱的地方，但中台背后一定是有一套机制、一群人来保障、有序的状态。
中台部门首先是有序的、有规划的，其次是解决一些业务上的问题，并且在这些业务问题之间，中台团队试图去把它打通，找出共性。再者，中台是有自己的门槛的，不是随便写个微服务或者其他的组件就可以放到中台里。中台部门希望技术团队去贡献一些基础能力，但贡献出来的基础能力最终是否能融入到中台里，最终仍旧需要通过一定的机制去做相应的评估。因为一旦进入中台，就有责任对它去做扩展、推广、运营，保证其生命周期，让其长久地活下去。
杂乱无序的集散地，汇集的肯定不止各种各样的微服务模块，还有其他杂七杂八的组件，缺乏强有力的管理，它的生命力是不会长久的。
但微服务对于构建中台而言是一个很好的技术手段。现阶段，构建一个大型的互联网系统，普遍为业界接受的基本上就是微服务加上 DDD（领域驱动设计）的架构设计模式。互联网迭代速度快，传统的单体架构模式无法适应，而微服务因为比较简单灵活、独立扩展、发挥，对技术栈没有特别要求，底层存储也不要求跑在同一个数据库上，是现阶段互联网架构设计的一种比较好的解决方案。中台团队服务的是大型互联网企业的业务，也需要灵活的变化，跟微服务的理念是相吻合的。
当然微服务也存在一些问题，比如网络上的不可靠性等等。任何一种技术，如果缺乏规范化的管理，最终都会陷入杂乱无序的状态，因此也催生了微服务的治理平台。滴滴是一个比较新的公司，技术上有后发优势，技术债比较小一点，目前在中台层面使用的微服务治理做得比较令人满意。
滴滴业务中台的发展方向仍在探索中，在此之前我们已经构建了订单中心、计价中心、支付中心、passport、用户中心、触达平台六大能力。现在首先是要满足对各个业务线的支撑，做到又稳定又快又高效。
第二阶段，我们希望业务之间能够打通，联结起来，做到赋能。比如 A 业务做了一个新功能，B 业务可以直接拿过来，通过业务中台赋能，产生更多新的玩法。
第三阶段，做到业务之间的协同与创新。通过业务中台作为一个统一的出口，对一些新业务做管控，让它保持在正确的轨道上发展。
