【51CTO.com原创稿件】2017年12月01-02日，由51CTO主办的WOTD 2017全球软件开发技术峰会在深圳中洲万豪酒店召开。秉承专注技术、服务技术人员的理念，自2012年以来，WOT品牌大会成功举办了十四届，积累了大量的技术专家资源，获得了广大IT从业者和技术爱好者的一致认可，成为了业界重要的技术分享交流平台以及人脉拓展平台。
本次会议分为10个技术主题，分别是：编程语言与框架，大数据系统架构设计、微服务与容器技术、前端开发实战、物联网（IOT）技术、软件性能优化、深度学习与智能应用开发、创新运维探索、技术架构遇到业务架构、CTO训练营。51CTO作为本次大会的主办方，将全程图文直播报道与后期视频展示这场盛宴。
12月01日上午WOTD2017主会场，滴滴出行执行总监赖春波进行了主题为《如何构建滴滴出行业务中台》的精彩演讲。以下是演讲梗概，让我们先睹为快！
赖春波·滴滴出行执行总监
今天，很高兴和大家分享我们在滴滴构建出行中台的经验和方法论。先简单做一个自我介绍，我于2008年走出校门，便加入了百度，做了将近8年时间的基础架构，一直在跟分布式系统、大规模存储打交道，一开始做得非常有热情，因为百度的数据规模和系统规模都非常大，面对的挑战也非常大。随时间推移，热情逐渐减退，重要的原因是因为做底层，只负责支持业务，但业务能不能做起来，并不主要取决于你。
为什么选了滴滴呢？因为我觉得滴滴发展非常快，在业务发展非常快的公司，它的业务技术的挑战一定很大，而且远远没有做好。所以决定加入了滴滴。加入滴滴之后，比我想得要更难，因为我觉得它挑战很大，但是我没想到比我想的更大。从那个时候开始，慢慢的开始构建出行的中台。
演讲主要涉及五方面：
一、 简单介绍滴滴的情况，这是为什么构建出行中台有关系；
二、 构建出行中台的原因，整个系统面临的问题；
三、 构建出行中台在软件复杂度上的挑战
四、 具体的对策和实践；
五、 简单总结一下我们的经验。
滴滴的情况
滴滴非常年轻，我们才发展了5年，我们2012年9月9日才出来***个版本，到现在为止我们把整个领域绝大多数的方向做了一轮变革。这是我们现在的数据，现在我们从单量来说是全球出行的***，有超过4.5亿的用户，有超过400座城市在运营，有超过2000万的车主，只有少数像出租车和专车和租赁公司这样的全职车主，我们日单量突破2500万单，整个覆盖超多个业务线。
滴滴的发展历程，这是非常重要的点，2012年9月上线***个出租车版本，后来在持续两年时间内，按照我们CEO的说法，一直在中国打小组赛，从最开始在北京和优步开始竞争，后来在杭州、深圳，***是和快的在全国进行竞争，***才合并成为统一的滴滴出行。但是紧接着，2014年8月开始，短短一年时间内业务多元化发展且很迅速，从专车到企业到快车到顺风车到代驾到拼车，发展很快。这样的多元化的过程，确实能够帮助滴滴迅速的在市场上，在各个子的领域都占据着龙头的地位，确实互联网的发展还是唯快不破，其实也带来了一个很大的问题。
构建出行中台的原因，整个系统面临的问题；
2015年末，我们的架构是多业务的垂直化的，每个业务都有自己的业务系统，都有自己的客户端，中间有一个分发层，下面基本上是基础架构，基础架构也没有什么特别的东西。
非常有意思的一点，大家现在看到的滴滴出行的页面，其实就是因为当时的架构所设计的。当时的设计、客户端的设计专门做了架构，做虚拟机的机制，每个都可独立运行，不会互相干扰，每个业务都可以快速跑，而不会影响别的业务，而这样的设计模式一直发展到今天，以至于我看到国内绝大多数小的出行领域的公司也都沿用这个架构，但没有想到这其实是因为这样的特殊组织结构或者研发的组织结构带来的。
出行相似性。在这样的架构下，其实我们看到它有很大的问题，本质还是来源于出行业务是非常相似的，虽然我们看着有这么多业务，但是从滴滴APP打进去看，出租车、快车、专车，不管是他们的界面还是交易流程其实都非常相似。
专业深度。这个相似性在当时的情况下有问题，我有这么多的工程师，可能有4、5波工程师都开发同样一套交易流程，同样一套出行交易流程，但技术深度很难做得那么深，因为每个地方都要有快速的方式构建自己的交易流程。我们看到客户端，当时流畅度非常低，在后端稳定性也非常严重。
人力资源。在2015年的10月份挂过半天，在之后也遇到过类似的宕机，非常明显。其实也会严重影响这些系统的可扩展性，因为开发者都是为了快，没有考虑任何未来的发展。 但是有人说，那加人就好了，把每个业务加到足够的人，它***都可以发展很好。原则上来说都是这样子，但现在的工程师都非常贵。如果一个公司要招这么多工程师开发同样四五套系统，研发的成本也是非常高的。那时候滴滴说我不缺钱，因为每年烧的钱比工程师成本高多了，只要工程师愿意来就可以，即使这样的情况下也很难招到这么多工程师。
用户体验。流畅度、稳定性、扩展性等都是影响用户体验的重要因素。其实还有很多的是直接影响用户体验，如每个业务进去颜色不一样，交易流程，一个滴滴用户进去是很崩溃的，完全不知道打快车和专车的流程是一个样子，这是不可理解的。在当时的组织结构和研发情况下就会产生这样的问题。
全局打通。因为有这么多业务，这些业务本质都是出行，出行本质有协同效应，我们想要把网络协同起来，那如果在各自独立发展情况下，这个协同性就完全没有，而我们在构建中台过程中，逐步把协同性加起来。
构建出行中台在软件复杂度上的挑战
中台并不是只有好处，它一定会带来很多问题，***的问题是软件复杂度，因为你要把这些多业务合到一个体系下去，那是很挑战的。尤其像滴滴，它是实时性的O2O业务，它的场景差异很大，它有很多不同，北京和上海不一样、上海和杭州不一样，这种差异性甚至可能会到一个区域，中关村和国贸就不一样。第二个，大家知道互联网公司的需求不明确，他不知道今天做的事情明天会怎么样，很多的需求是不明确，而且持续变化，而且非常快。这种情况下，你们怎么用一套相对稳定、相对固定的架构去支持？这是具备很大的挑战。
第二个挑战是组织的复杂性，在滴滴，我们有7个以上的出行事业部，前面讲有400多个城市，他们的组织变化和结构变化很快，怎么应对组织的挑战？在阿里，我知道他们的中台相对是偏底层，其实天猫、淘宝还是有自己的研发团队的，滴滴我们怎么走得更近一些、更快一些，更进一步，核心的原因是因为在出行上的相似度可能会比电商更强一些。我们现在绝大多数事业部没有它的研发，像出租车、快车、代驾都没有研发，研发团队都在我这儿。如果有人和业务打过交道应该有这个感受，这种情况下怎么解决这个问题？我觉得这就是中台。所以我把中台的定义总结为这样，“中台的目标是要在业务多元化发展的组织中，我们去构建一套工程架构，构建一套组织结构，以及对应的管理机制，以保证这个业务可持续的，又快又好的发展”。这就是我们的目标。这里有三个关键词，快、好、可持续。如果失去任何一个词，都会让这个平台变得没有那么有价值，这就是中台的挑战。
具体的对策和实践：服务化、异步化、配置化、插件化和数据化
我们的对策和实践，首先先简单给大家一个整个的架构层次的设计，我们分几个边界的上下文，边界上下文的好处是把相关性不强的逻辑拆开，同时在一个相关性下面，通过分层能够去把这个业务进行更好的建模，服务编排层，是我们的入口去牵引多个业务线，业务流程再服务上面的服务编排，下面我们有对应的状态去支撑上面的两层。我们要对业务和产品进行更好的建模，在建模的基础上，我们要做的事情是用我自己的抽象的话说，建设五话，因为我们小时候讲建设四话，我把中台建设总结为“建设五化”。
一是服务化，大部分人都非常熟悉，以下单为例，我们下单的流程能够调用下面很多服务，在多个层次，以接口层次结果拆解。需要注意的是，服务化要注意三点，一个是建立很好的服务之间的协议和规范。第二点是注意控制力度，这个力度不能太小，也不能太大，太小、太大都会有问题。第三点是说还要考虑这个系统是不断演化的，今天设计的服务不一定合适明天，所以随着时间的发展，你的服务化本身要不断的演进。所以这就是服务化的过程。
二是异步化，很多人在做，滴滴做得特别多，因为每个事件我们都会把它作为事件拆解，在事件拆解的情况下，我们把非核心的逻辑或者说不需要在当时反馈给客户端的逻辑进行拆解，有这个拆解之后就可以把核心的主流程变得更加简洁，而剩下的逻辑在事件上做订阅再做二级处理就好，以结束订单为例，结束订单的时候有很多逻辑要做，但是都是通过Binlog网站处理，或者在MQ网下处理。如果你是一个新用户，打开滴滴登录，那这时候我们就会有用户登录的事件，紧接着会有拉新的模块会订阅这个事件，然后自己识别和判断你是不是新用户，你是新用户就会给你一个券的礼包，像这样的逻辑都是很异步化的方式处理。
三是配置化，虽然服务化和异步化能解决很多迭代效率的问题，但是我刚才讲了，由于我们的系统、我们的业务非常复杂，各个业务都有些差异，体现在不同的产品线、不同的城市、不同的区域、不同的时间等等，配置化的核心是对这些东西进行建模，把每个对象模型化，然后抽象成ID，在不同的服务化里把这些可配置的能力进行抽象。我们有一个非常有意思的一点，我们***级的抽象用的是类似于iptables这样的规则引擎，你可以有很多特征，根据不同特征的差异，我们会对你进行一个抽象，然后再到第二层的规则引擎，由模块自定义。所有配置化都是用自生成平台，你要配置什么，你自己定义要配置什么就可以，它是一个动态，通过这样的方式，我们现在的系统已经可以支持上千个配置点，不同层次的计价规则不一样，不同产品线的车样子不同。不同的场景，比如拼车和接送机，他们管控规则不一样，他们有很多的可配置的点。
四是插件化，这比配置化要更进一步，配置化解决的是这个业务线有差异，你找我，我重新配置解决这个问题。但是有些逻辑确实差异会比较大，这时候怎么办？我们要做一些插件，所以我们叫FPI。在FPI的能力上，不同的团队可以开发很多插件，在特定的配置点下，把它的逻辑去进行加载。真正的业务流程到他这儿，可以调起它对应的插件做出来。也有一些业务说，我没有差异化的需求，你可以用我们开发的default逻辑，也可以，这是更极端的灵活性的体现。有这个灵活性的体现之后，我们的团队还可以做一些组织上的调整，原来看起来，每个服务或者平台是一个垂直化的架构，有些团队是横向的，是FT，有些FT是接送机FT，他们专门做接送机的事情，通过插件的形式在每个系统加载它的插件，它就可以跟着业务思考、跟着产品思考这个业务怎么走、这个产品怎么演化，他们相对的逻辑是更加专注的，这也带来了很好的组织的结构对中台的适应性。
五是数据化，在大数据时代，数据是我们不得不考虑的问题，所以在我们的系统，刚才讲了我们要实现全局打通，本质是要把数据打通，所以在我们的核心在线交易流程之外，我们有两个数据决策，***个是离线做分析，可以做数据血缘、模型训练，同时可以把它放到在线决策层面，构建很好的智能客户引擎和交易引擎，这个可以干预，因为干预可以让升舱或者多业务线的清单成为可能。因为有这样的决策，使我们在线服务的管控和判决做得更加智能。在数据化这块，可能有三个做工作，***个是让数据更加规范和标准化，其实这个事情是没那么容易的，因为不同的公司，我知道很多时候数据的标准差异都特别大，不同的系统差异特别大，所以要把这步做好不容易，做好这步之后，要构建完整的数据流，从在线到离线，从日志到模型的在线使用，要构建完整的数据流，在数据流的基础上，我们要引入机器学习的算法、人工智能的算法去构建在线数据智能的决策。 这就是我们刚才讲的五条对策，所以刚才讲要多记15字，就是这“五化”，服务化、异步化、配置化、插件化和数据化，服务化和异步化主要解决传统的系统架构问题，怎么做到高耦合和内聚，怎么提高迭代下面。配置化和插件化解决灵活性问题，把灵活性开放给不同团队。数据化实际上是中台赋能业务，有中台的赋能才能变得更好。
经验总结
***点，滴滴做的***经验就是从***的业务孵化中台，***的业务最复杂，把最复杂的业务搞定了，用最复杂的业务落地别的业务会容易，反过来非常难。滴滴，我从快车开始做，因为快车是***的业务，逐步用快车整合专车、出租车、代驾等，是这样的过程。
第二个是稳定，中台对业务有收益，最根本的是保证稳定，稳定是发展的前提和基础。我们在整个构建中台的过程中非常重视稳定性，我们有各种机制，包括灰度发布、分层次发布、流量回放、全电动压测等等机制，保证代码的质量和系统的稳定。
三是加强沟通，我们要平衡多业务的优先级，刚才讲我们有七个业务，有很多大区和城市，每个地方都有很多需求，要有一套机制和资源池，怎么保证相应的每个业务都能按照他所对应的在公司的重要性的那部分资源，要保障它的灵活性和效率，所以要有很多沟通工作，有很多平衡的工作，这是一门艺术。
四是中台系统要不断演进，你不能一层不变，要发现问题、解决问题。我们今天的中台系统也不是***天就想清楚的。在未来的发展中，我们也会不断的变化。所以这是持续迭代的过程。这是我们在中台建设中总结的经验。
***还有一点，本次演讲只要记住9个字就可以，把前面所有讲的东西都忘掉，只要记住“没有***，只有最合适”，为什么呢？因为所有的中台都一定是适合某个公司特点，最合适的中台是当你深入了解业务、深入了解产品、深入了解你的系统、深入了解你的组织，而且不仅了解他们今天在哪里，还要了解他们过去是怎么演变而来的，未来又会怎么演化。只有当你了解所有的东西之后，你才能做出***的中台架构的设计。
所以我相信每个公司、每个多元化的公司，都会有自己最合适的中台的机制和架构的设计。 我也希望未来能够有越来越多的人来分享你们的中台建设的经验。
以上是51CTO.com记者从一线为您带来的精彩报道。后续我们还有更加精彩的独家报道，敬请关注。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
