Uber 架构（Four）

在开始之前介绍一下一些算法。一般高峰是平时的 5倍。如果您的服务是面向未来开发的。对于快速发生业务 3 月后不是大概是现在高峰 10 倍左右，。

uber-app-portland.jpg

当一个乘客发起请求时候，会计算以乘客为中心按一定半径进行画圆。然后如果之前切分好的方形区域如果和这个圆形有交集。就可以覆盖空间找到符合条件的司机。为了更快找到符合条件司机，uber 是将司机的位置连接成窜，以便快速查询。

major-google-maps-update-brings-uber-integration-new-navigation-more.w1456.jpg

不但需要面对当前的策论还需要面对未来的策论，假设离乘客最近的司机1 到达可能要花费时间 8 分钟，而还有一个司机 2 花费 2 分钟后送完乘客后，只需要 1 分钟就可以到达乘客。Uber 经过计算会把司机 2 推荐给乘客。把这个考虑进去就会有更好的策论。这就是旅行家销售的问题，也就是 np 问题。

如何把供给保存起来，现在有了 google s2 就不需要按城市来划分区域来保存，而是切分区域进行保存同步数据，在存储是通过 ringpop 实现分布式存储，ringpop 实现了哈希环，在环上每个点是完全等价，每个节点负责一定的区域范围的位置信息，地址算出来通知环上任何一个点，环上的节点将数据保存到对应的节点上。

具体位置信息是那一块。发给舞会服务，发给环上的服务这些节点， 节点会路由到响应的位置上得到具体信息，返回匹配结果，

uber 对通讯进行了优化，为了是性能优越转发消息，从新做一个通讯就是因为 http 太慢了。20 倍以上的优化，而且跨语言支持，优化消息调度，避免消息堵塞。追踪以便发现问题，对消息也进行封装，上层跑的是我的协议下层跑的是 http 服务。
这些都是通过 tchannel 实现的，随后介绍。

服务设计选择的是微服务。在微服务中错误是常态，所以要求服务可以重试。而且为了避免转账这样操作重复出现，还得保证服务只能被执行一次，对服务要进行切分，细分到原子级别，从而降低服务间的耦合度。

398_L_lorry-in-Sahara.jpg

传统负载均衡在中心，服务在两边，搭建到一起。但是如果负载均衡挂掉了呢，这里也可以用 ringpop 还能实现路由功能，例如服务 A 想找到服务 B，在环形各个节点会指向服务 B。

data-center.jpg

如果数据中心挂掉了，数据中心挂就是，当然可以将数据中心 A复制到数据中心 B的这样做也是可以的。uber 有什么策论呢，其实这里 uber 的策论是当司机 A连接到数据中心时，数据中心会将用户的信息做一个概要，然后加密后发送给客服 A ，当数据中心关掉，启动数据中心 B 如果这时数据中心没有司机的数据， B 会要求司机 A 发送数据给数据中心。在更新地理位置时候就会更新到数据中心 B