滴滴出行分而治之的架构设计之道

【本文是WOT2016互联网运维与开发者大会的现场干货，  新1届主题为WOT2016企业安全技术峰会将在2016年6月24日⑵5日于北京珠3角JW万豪酒店隆重召开！】

如今，我们去任何1个地方都要先问问有无Wi-Fi，网络已明显影响到我们的生活。

互联网生下来就是为了服务海量用户，在这个时期，几近没有哪一个利用再为单机而生。每一个公司的每一个产品将要面临的都是不可预知的用户海量要求。明显这个靠散布式程序来解决，比依托单机靠谱很多。但是不幸的是，如果1开始你的架构设计不可扩大，有再多的机器，有再多的云解决方案，对你来讲最多是将单机程序跑在了1个虚拟的单机上。下面就让我们回到WOT2016 互联网运维与开发者大会现场，跟随滴滴出行首席架构师1起了解，散布时期架构设计和程序开发面临着哪些新挑战，和滴滴出行的应对思路。

李令辉，滴滴出行首席架构师，于2014年中加入滴滴，经历了滴滴高速成长的阶段，见证了滴滴从1个打车软件变成1个出行平台。移动互联网资深从业者，对移动互联网技术发展趋势和技术团队的组建有独道见解。他具有多年互联网架构的设计经验，善于高性能高并发高可用的架构设计工作，主导了滴滴打车技术迭代中的核心服务架构升级。

散布式时期的窘境

为单机而生的利用将不复存在

很少有1个利用能准确预测自己的用户量有多大，因此，1开始就为上亿用户去设计1个极其复杂的散布式架构，几近是不可能的。由于这不但会带来极高的本钱，还会牺牲全部系统的灵活度。其实不是每一个公司都像谷歌1样，在创业早期就有面对世界上所有数据的雄心壮志，来开发1个散布式文件系统。大多数公司1定是从几台服务器起家，在用户不断增长，并发要求增加，业务愈来愈复杂的进程中，百临不得已将程序从单机搬到多台机器。把单个进程拆成多个服务的问题。

散布式开发工具的缺少

每一个人的工作量无缘无故1个互联网的多个节点组成的，通过网络耦合的1个散布式环境。无缘无故的被这类散布式带来的必定复杂性提高了。但是，真实的散布式开发工具还远未成熟。 程序员可使用的工具还是古老的VI,410年前的Emacs和10几年前的Eclipse等单机开发工具，服务之间的依赖关系完全没法管理，日志格式和日志内容没法保证1致和可追溯。上线，扩容，降级等运维工作和规范没有被很好的设计。 任何1次问题或开发，都需要多人协作，效力极其低下。

重造车轮的解决方案

看起来，业界解决方案百花争鸣。但实际上，大部份都是基于开源的RPC方案，比较成型的几个方案包括Erlang OTP, Scala Akka等。公司内通过各种定制的方案去耦合，去相互管理关系，相互依赖，把1个事工作起来。大1点的公司会强迫的推行运维规范。而每一个公司或社区都对这类散布式环境用自己的理解。 这带来的后果是，大家都在开源社区的基础上重复造一样的东西，这个是本钱很高的事情。

再者，很多解决方案都依赖于特定的业务场景来制定。比如通讯软件，对实时性要求很高，对可用性要求非常高，但是电商其实不那末关心1个要求能不能快速返回，而是强调数据的1致性。所以每一个业务特点决定了有不同的解决方案，而且很少有为散布式而生的方案，都是从单机方案演变或渐变来的，这些问题都会让每个在从中开发的人不能不知道全貌，对研发效力来说是个巨大的伤害。散布式也确切个足够复杂的领域，很难有1揽子通用解决方案。

那末，在设计散布式系统架构时，应当斟酌哪些方面？

散布式架构设计基本要素

容错

在散布式环境里，毛病无处不在，并且无时无刻不在产生。而且，毛病不只是机器故障，当几百人投入研发工作的时候，1定会有人出错，而且每一个人都会出错，会常态的出错。因此，研发团队不应当只想着如何避免毛病的产生，而是如何在小毛病下，不影响业务，保持服务健康运营。而1但不加斟酌的对架构每一个模块进行降级，必将带来1场巨大的灾害。

数据格式

数据格式实际面临的窘境和依赖管理是1样的。由于每一个人只负责单独的模块，而不会去关心全部业务用甚么样的数据格式通讯。究竟代码中到底多少是用来Verify Data的？又有多少是用来Pack/Unpack Data的？如果不统1就会堕入泥潭，工作效力低到没法接受，日志搜集和监控也几近没法实现。

路由层

关于路由层的解决方案没有高低之分，只要能解业务中的问题，下降运维本钱和开发本钱，就是好的方案。

但是，1定要尽可能避免同时存在多种解决方案。函数调用是路由，反射是路由，URL是路由，RPC的IP+Port+Function也是路由。虽然说，其实不是所有业务都能用统1的方法来路由的。路由的灵活性和规范性决定了运维难度，盲目寻求灵活度无缘无故的又把运维提的工作高1个量级。架构本质是控制复杂度，主要方法就是分而治之，解耦，耦合从本质上来讲就是路由。

服务

为了满足用户新的要求，追上市场新的步伐，每一个互联网公司的研发团队都不曾停下脚步，保证服务不断进化和升级。这同时也带来了许多问题：

• 如何稳定高效的迭代？
• 依赖刚迭代的服务的旧服务怎样办？
• 我想给某个服务/模块做AB Test怎样办？
• 多个模块可以同时做AB Test么？
• 如果不能，研发变成串行上线真的好么？

看待这些问题1定要从全局动身，而最重要的是接口的统1，构成1致的标准，让大家在1条共同的准绳上。

监控

现在大家所做的监控，基本都是在监控机器的状态。其实在几百台机器这样的较小范围下，这样做的意义其实不大。真正应当监控的，应当是程序。而严控程序的状态，只能依赖日志。

因此，每一个架构师都要斟酌，如何设计可以监控服务的日志系统，要提供可监控的接口。是每一个架构师要斟酌你的服务是怎样被监控的，你要提供可监控的接口。至于收集间隔，1般来讲范围越大，收集粒度越低，范围越小，收集粒度越高。

另外，监控的信息是Pull or Push？监控的结果全部需要人来处理么？日志是不是可以用来作为系统之间交互的数据？这些问题都需要大家根据自己的业务场景不断探索。

你的运维方案完善吗？

每一个公司的运维团队都在斟酌这个问题。你的目的是为了下降你的本钱，提高你的效力。请公道的计算你的本钱和效力，就是你要把人算进去，而不是就算机器。大家可以通过以下几个维度来评估：

• 资源利用率如何？对大部份团队来讲，研发的人力本钱要远远高于机器本钱，你要首先斟酌的是你的人都并发起来了，而不是你的CPU都被吃掉了
• 解决方案是不是简单？这对应着人材招聘的门坎。对新人来讲，总要让他快速的上手做1个项目，验证自己的能力，所以解决方案1定要相对简单。怎样扩容，怎样缩容，都应当有成型的1整套方案
• 开发测试上线流程是不是需要人工参与？
• 小流量测试的支持如何？
• 回滚、限流、断流方案是不是统1提供等等问题 ？

滴滴出行的散布式设构设计思路

Linux之所以强大，是由于每个模块都只负责最简单的事情，面对输入和输出，而输入和输出的格式是肯定的。散布式架构设计的思路也应如此，一样的规则，一样的用法组合在1起是可以发挥巨大作用的。

滴滴出行的散布架构设计想要解决的问题，不只是简单的机器运维，而是人在研发进程中，如何避免复杂环境中可能面临的风险，解决由于粗糙的架构设计带来的效力低下，不可控，不稳定的状态。

这样的架构设计带来的1个巨大好处是，信息流在进来的时候进入信息分发，信息分发把它分到适合的管道，那个管道处理完再放给下1个管道。每一个管道都只做输入和输出的事情，实现高可用、高吞吐。这类方案很多云服务商都会提供。这样做的好处时是，我们只需要管理消息队列，可以在任意1个节点把流量复制走。在任何1个环节中可以拿到它所有的数据，不再依赖日志，只依赖输入、输出。而输入、输出是存在硬盘上的，数据不会丢失。

另外一个优点是进程是异步传输的。同步模型1个很明显的缺点是在所有的层次中，1个进程在履行某个要求的时候如果需要1段时间才能返回信息，那末这个进程将会1直等待下去，直到收到返回信息才继续履行下去。在流量很大的时候，做1个重试可能某1个环节就会面临崩溃了，某个环节的连接数被打满。

而在这个方案中，连接就只有两3处，不需要等待数据回报，只需要确认收据接收，而且不需要逐条验证。本钱很低，性能很高。

但这类架构设计明显不能解决所有的问题。比如用MySQL作为存储等必须同步的服务时，需要给有状态的服务提供1个抽象层Service，上面的服务可以要求它。大家可以理解为在Linux中敲1个命令要读1个文件，那个文件是有状态的，是存在那里的，而这些模块是没有状态的。

滴滴选择了Docker+Kubernetes作为散布集群管理解决方案，它的好处是可以直接提供资源管理，资源隔离，部署，升级，路由等等需求。但是，只有Kubernetes是不够的，Kubernetes只能管理那些无状态的事务。其实不是所有的事情都可以完全抽象成无状态的，有状态的部份应当如何实现扩容，都要根据具体的业务场景，这是很难的设计。

最后要说的是，没有完善的方案，如果你自己要开发这个事情，建议大家最好用1种方案，不要每个用1种。但是没办法，面对不同的研发人员，不同的场景等现实，现在还没有终究的结论。也希望能借此文，与各位业界同仁共同探讨。

【演讲视频】

散布式时期的架构设计（上）

 散布式时期的架构设计（下）

【作者推荐】

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠