滴滴出行高并发高性能的分布式架构设计之道

&＃xff08;点击上方的蓝色文字&＃xff0c;可快速关注我们&＃xff09;

如今&＃xff0c;我们去任何一个地方都要先问问有没有Wi-Fi&＃xff0c;网络已经明显影响到我们的生活。

互联网生下来就是为了服务海量用户&＃xff0c;在这个时代&＃xff0c;几乎没有哪个应用再为单机而生。每个公司的每个产品将要面临的都是不可预知的用户海量请求。显然这个靠分布式程序来解决&＃xff0c;比靠单机靠谱得多。然而不幸的是&＃xff0c;如果一开始你的架构设计不可扩展&＃xff0c;有再多的机器&＃xff0c;有再多的云解决方案&＃xff0c;对你来说至多是将单机程序跑在了一个虚拟的单机上。下面就让我们回到WOT2016 互联网运维与开发者大会现场&＃xff0c;跟随滴滴出行首席架构师一起了解&＃xff0c;分布时代架构设计和程序开发面临着哪些新挑战&＃xff0c;以及滴滴出行的应对思路。

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

分布式时代的困境

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

很少有一个应用能准确预测自己的用户量有多大&＃xff0c;因此&＃xff0c;一开始就为上亿用户去设计一个极为复杂的分布式架构&＃xff0c;几乎是不可能的。因为这不仅会带来极高的成本&＃xff0c;还会牺牲整个系统的灵活度。并不是每个公司都像谷歌一样&＃xff0c;在创业初期就有面对世界上所有数据的雄心壮志&＃xff0c;来开发一个分布式文件系统。大多数公司一定是从几台服务器起家&＃xff0c;在用户不断增长&＃xff0c;并发请求增加&＃xff0c;业务越来越复杂的过程中&＃xff0c;百临不得已将程序从单机搬到多台机器。把单个进程拆成多个服务的问题。

分布式开发工具的缺乏

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

重造车轮的解决方案

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

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

那么&＃xff0c;在设计分布式系统架构时&＃xff0c;应该考虑哪些方面&＃xff1f;

分布式架构设计基本要素

容错

在分布式环境里&＃xff0c;错误无处不在&＃xff0c;并且无时无刻不在发生。而且&＃xff0c;错误不只是机器故障&＃xff0c;当几百人投入研发工作的时候&＃xff0c;一定会有人犯错&＃xff0c;而且每个人都会犯错&＃xff0c;会常态的犯错。因此&＃xff0c;研发团队不应该只想着如何避免错误的发生&＃xff0c;而是如何在小错误下&＃xff0c;不影响业务&＃xff0c;保持服务健康运营。而一但不加考虑的对架构每个模块进行降级&＃xff0c;势必带来一场巨大的灾难。

数据格式

数据格式实际面临的困境和依赖管理是一样的&＃xff0c;因为每个人只负责单独的模块&＃xff0c;而不会去关心整个业务用什么样的数据格式通信。究竟代码中到底多少是用来Verify Data的&＃xff1f;又有多少是用来Pack/Unpack Data的&＃xff1f;如果不统一就会陷入泥潭&＃xff0c;工作效率低到无法接受&＃xff0c;日志收集和监控也几乎没法实现。

路由层

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

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

服务

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

• 如何稳定高效的迭代&＃xff1f;

• 依赖刚迭代的服务的旧服务怎么办&＃xff1f;

• 我想给某个服务/模块做AB Test怎么办&＃xff1f;

• 多个模块可以同时做AB Test么&＃xff1f;

• 如果不能&＃xff0c;研发变成串行上线真的好么&＃xff1f;

看待这些问题一定要从全局出发&＃xff0c;而最重要的是接口的统一&＃xff0c;形成一致的标准&＃xff0c;让大家在一条共同的准绳上。

监控

现在大家所做的监控&＃xff0c;基本都是在监控机器的状态。其实在几百台机器这样的较小规模下&＃xff0c;这样做的意义并不大。真正应该监控的&＃xff0c;应该是程序。而严控程序的状态&＃xff0c;只能依赖日志。

因此&＃xff0c;每个架构师都要考虑&＃xff0c;如何设计可以监控服务的日志系统&＃xff0c;要提供可监控的接口。是每个架构师要考虑你的服务是怎么被监控的&＃xff0c;你要提供可监控的接口。至于采集间隔。一般来说规模越大&＃xff0c;采集粒度越低&＃xff0c;规模越小&＃xff0c;采集粒度越高。

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

你的运维方案完美吗&＃xff1f;

每个公司的运维团队都在考虑这个问题。你的目的是为了降低你的成本&＃xff0c;提高你的效率。请合理的计算你的成本和效率&＃xff0c;就是你要把人算进去&＃xff0c;而不是就算机器。大家可以通过以下几个维度来评估&＃xff1a;

• 资源利用率如何&＃xff1f;对大部分团队来说&＃xff0c;研发的人力成本要远远高于机器成本&＃xff0c;你要首先考虑的是你的人都并发起来了&＃xff0c;而不是你的CPU都被吃掉了

• 解决方案是否简单&＃xff1f;这对应着人才招聘的门槛。对于新人来说&＃xff0c;总要让他快速的上手做一个项目&＃xff0c;验证自己的能力&＃xff0c;所以解决方案一定要相对简单。怎么扩容&＃xff0c;怎么缩容&＃xff0c;都应该有成型的一整套方案

• 开发测试上线流程是否需要人工介入&＃xff1f;

• 小流量测试的支持如何&＃xff1f;

• 回滚、限流、断流方案是否统一提供等等问题 &＃xff1f;

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

Linux之所以强大&＃xff0c;是因为每一个模块都只负责最简单的事情&＃xff0c;面对输入和输出&＃xff0c;而输入和输出的格式是确定的。分布式架构设计的思路也应如此&＃xff0c;同样的规则&＃xff0c;同样的用法组合在一起是可以发挥巨大作用的。

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

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

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

但这个架构设计显然不能解决所有的问题。比如用MySql作为存储等必须同步的服务时&＃xff0c;需要给有状态的服务提供一个抽象层Seivice。上面的服务可以请求它。可以理解为在Linux中敲一个命令要读一个文件&＃xff0c;那个文件是有状态的&＃xff0c;是存在那里的&＃xff0c;而这些模块是没有状态的。

这个设计要解决的问题不是简简单单的机器运维问题&＃xff0c;而是人在研发过程中&＃xff0c;如何避免我面临复杂环境中的险&＃xff0c;解决由于粗糙的架构设计带来的效率低下&＃xff0c;不可控&＃xff0c;不稳定&＃xff0c;手足无措的状态。

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

最后要说的是&＃xff0c;没有完美的方案&＃xff0c;如果你自己要开发这个事情&＃xff0c;建议大家最好用一种方案&＃xff0c;不要每一个用一种。但是没办法&＃xff0c;你就是不同的好几波人开发的&＃xff0c;并且场景不一样&＃xff0c;很有可能还是那个样子&＃xff0c;如何解决有状态事务的快速扩容和运维管理&＃xff0c;现在还没有最终的结论。希望和业务同仁共同探讨。

欢迎关注“互联网架构师”&＃xff0c;我们分享最有价值的互联网技术干货文章&＃xff0c;助力您成为有思想的全栈架构师&＃xff0c;只聊架构&＃xff0c;不聊其他&＃xff01;打造最有价值的架构师圈子和社区。

长按下方的二维码可以快速关注我们

如想加群讨论学习&＃xff0c;请点击右下角的“加群学习”菜单入群。