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