构建Uber端到端技术栈十条经验.pdf

跟大家分享一下如何以 Uber 的方式快速稳定的做一个端到端的大型应用。 下面我谈谈实战中的系统设计的经验。 一、选择微服务 系统设计包括若干个层面。先说顶层的系统设计原则, 如 REST ，SOA。由于 Uber之前一 直是算一个创业公司 ，所以开发速度至关重要 ，由于微服务 能够极大的促进不同组件的平 行开发 ，SOA 成为了 Uber的选择。 在这种选择下 ，我们需要先按功能设计出不同责任的 Service ，每一个 Service作为这个责 任的唯一真实信息源。在开发新的功能时 ，只需要先设计好不同Service之间的合约, 就可 以按照合约平行开发了。在实际工作中 ，这点被证明非常有效。 二、服务要设计为幂等 （idempotent ） 第二点是不同 Service之间的合约和依赖。一个 Service 的合约决定了它跟上游 Service之 间的关系 ，如果这个合约设计的不好 ，那就会给上游 Service 上的开发带来各种不方便和重 复工作。 比如说如果一个节点可以被设计成幂等 （多次操作均返回相同结果 ）但却没有这么做 ，那就 会导致上游 Service在使用这个节点时 ，失败处理逻辑会复杂很多 －－如果是幂等, 上游只 需要重新调用就可以了 ；但是如果不是幂等, 上游就需要跟据出错信息来判断依赖系统的状 态 (有时甚至很难判断 ，比如在下游系统状态更新后网络出错) ，然后再根据状态来选择不 同的处理方式。 在有些情况下 （比如下游系统挂掉了 ），上游系统甚至需要记录下游系统的状态 ，这样在 backfill的时候才可以直接做正确的处理 ；而在幂等的情况下 ，我们只需要无脑调用下游的 Service就好。举个例子 ，很久以前 Uber有次分单系统坏了 ，导致之后要重新 backfill ， 由于依赖 Service设计的是幂等, 该次 backfill就一个简单 script 跑完即可。当然 ，现在 Uber 的分单系统还是非常稳定的。 三、考虑 RPC消息的语义 （semantics ） 同时 ，我们也要考虑 RPC semantics是 at least once, 还是 at most once。具体的应用情 境下有不同的适用。比如说如果是要做一个付钱的有状态更新的 api, 那我们就应该保持 at most once 的使用 ，当调用 api 出错时 ，我们不能贸然再次调用该 api。At least once和 at most once在大部分情况下对应于幂等 和非幂等的操作。另外 ，我们在实现系统时也要 考虑已有系统提供的接口 ，比如说一个已有的接单系统已经提供了一个 at least once 的消 息队列 ，而我们需要做的是跟据累积的交易数来做一些行为 ，在这样的情况下 ，我们就需要 我们的系统能够消重 ，或者保证我们要做的行为是幂等的。 四、Design for failure 第二个层面是 Service之间交互可能发生的问题 ，在设计一定要考虑周全 ，比如通信可能发 生的 failure case。我们要假定在线上各种奇怪的情况都会发生。比如我们曾经有上下游 Service之间通信时使用的 kakfa ingester一直不是非常稳定 ，导致不时发生下游 Service 无法拿到数据来计算 ，最后我们干脆把 kafka换成了 http polling, 再也没有问题了。 第三个层面是 Service 内部的故障, 比如缓存, 数据库断了 ，或者依赖的第三方 Service挂 掉了 ，我们需要根据情况进行处理 ，做好日志和监控。 五、合理选择存储系统 如果一个 Service是无状态的 ，那往往它做的事情是根据请求把下游各个 Service 的返回结 果加工一下然后返回。我们可以见到很多这样的 Service, 比如各种 gateway ，各种只读的 Service。 服务无状态的情况下往往只需要缓存(如 Redis) ，而不需要持久化存储。对于持久化存储, 我 们需要考虑它的数据模型、对 ACID的支持、稳定程度、可维护性、内部员工对它的熟练程 度、跨数据中心复本的支持程度 ，等等。到底选择哪一种取决于实际应用情景 ，我们对各个 指标要不同的需要 ，比如说 Uber对于跨数据中心复本的要求就很高 ，因为 Uber每一个请 求的用户的期待值都很高 ，如果因为存储系统坏了 ，或存储系统阻挡 failover ，那用户体验 会非常差。 另外关于可维护性和内部员工的熟练程度 ，我们也有血淋淋的例子 ，比如说一个非常重要的 系统在订单最多的一天挂掉了 ，原因是当时使用的 PostgreSQL数据库不知