Uber平台架构设计介绍.pdf

Uber 平台架构设计介绍 1 首先谈到 Uber 的初心，他们想实现一键打车功能。左边是 Uber 最早期的界面，大家可以看到跟现 在有很大的区别，按一下就可以打到车了。 Uber 的最初架构 为了支持这样的服务， Uber 最初的架构是怎么样的呢？会很复杂吗？其实不会。 2 前面是一个手机，中间是 PHP 来负责业务逻辑，最后是 MySQL 的数据。司机每隔 4 秒上传自己的 经纬数据来更新自己的位置，而这些数据会存在 MySQL 里，当用户请求来的时候， PHP 会调用 MySQL 的查询语句来寻找匹配的司机。这是一个非常简单的架构，能够快速的支撑 Uber 的需求。 架构扩展 那这样的架构如何扩展呢？因为 Uber 非常火爆，用户蜂拥而至，很简单的方法就是将 PHP 变成多 进程多线程，可以同时访问 MySQL 得到数据。 3 但是这样的架构有很多缺点： 缺点一：一个司机两个乘客 因为每个 PHP 是独立访问 MySQL 的，而有些机制没有做好的话，很可能一个司机被两个 PHP 进程 查询到了后台，同时返回给两个用户，所以会出现一个司机被派给两个用户的情况。 缺点二：两个司机一辆车 有时候两个司机公用一辆车，他们用两个 APP ，这时候只能派遣一次，就会出问题。 缺点三：一个账号两辆车 4 两个用户登录同一个账号，这时你会看到用户的位置在不断的漂移，你会非常困惑。 出现这么多问题，我们应该如何改进呢？ 谈到改进，我们再把刚才的服务具体化，会有派遣服务，派遣服务后面是 MySQL 的存储状态，整体 是一个实时逻辑，用户可以通过 iphone ，Android ，SMS 连在上面。谈到改进，这是一个逐步的过 程，不可能一口吃一个胖子。 5 我们首先可以把一些 影响我们派遣服务的逻辑拿出来。 比如商业逻辑， 像用户绑定手机号， 付款之列， 可以通过 Python 的 API 进行调用，因此减轻了派遣服务的能力。再进一步，我们 可以在中间加上消 息队列 ，因为有各种请求，不见得所有请求都通过派遣服务走，像商业逻辑可以直接走 API 。而且消 息队列在这里面可以抵挡更大的连接，更多的请求，本身还有个消息队列的机制。同时为了存储一些 比如 GPS 日志，可以 在 MongoDB 里保存 ，从而也减轻了派遣服务。我们可以看到逐渐减轻派遣服 务的压力。这之后大家如果在各个层级里出问题可以重试。重试很好，因为便于出错以后的恢复。但 也存在一个隐患，稍后会讲到。 6 在这个基础上，我们还可以进一步变化， 将派遣服务也变成 Node.js ，派遣数据变成 MongoDB ， 这是非常