转载

Uber微服务实战经验分享

几个月前，Uber决定退出其基于模块的整体monolithic架构，转向灵活的微服务架构，此后，Uber花费了数千个工程小时重写扩展微服务生态系统，使用各种语言和各种框架，这种持续的重构是一项艰巨的任务，在这里讨论一下在Uber采取新技术带来的机会和挑战，使用适合SOA迁移的一套技术堆栈和标准，Uber已经简化了服务的开发。

启动一个新的服务

在工程规模快速扩展期间，很难跟踪所有的工作行为，这种增长方式迫切呼唤一种机制来防止不同团队的之间重复工作，在Uber，通过要求新服务的作者必须提交一个请求注解（Request for Comment，简称RFC）解决了这个问题。

新服务注解实际提出了对新服务的高层次目标，概述服务的目标，架构和依赖以及其他Uber工程师讨论的实现细节。

RFC服务两个目标：

征求反馈意见以提高服务的开发质量。
防止重复的工作或重复暴露合作的机会。

几个熟悉该领域的工程师负责审查服务的设计，一旦反馈已被纳入到服务目标，建设这个新服务的“好玩游戏”（比喻具体实施过程是一个有乐趣的游戏）就启动了。

实现一个新服务

Tincup是货币和汇率的服务案例，使用微服务实现的，Tincup是一个及时更新现金和汇率数据的接口，它提供两个端点服务：一个是获得货币对象，另外一个是获得该货币汇率（对美元的汇率），这些端点是必要的，因为Uber是一个全球业务，汇率变化经常发生，在Uber可以进行将近有60种货币的交易。

步步为营使用新技术实现微服务

当构建Tincup时，重写货币汇率所有逻辑提供了一次重新评估以前设计决策的机会，因此，使用了一系列新框架协议和方式实现了Tincup。

MVCS

首先，我们讨论了有关货币汇率代码的整体结构，过去已经多次修改了很多数据持久层，每一个修改都是漫长和繁琐的，从这个过程中，Uber认识到，如果可能的话，最好是将应用程序逻辑从持久层细节中分离出来。

这导致了一个应用程序的开发方法，称为MVCS: 拓展了普通的MVC模式，将服务层包含到MVC中，MVCS中的S就是Service服务的意思，服务层是应用逻辑所在，通过将应用逻辑从其他地方分离到服务中，持久层能够自我演进发展或被替代，这些都不会需要再重构业务逻辑了。

UDR

其次，我们考虑了货币汇率这个系统的持久层，在之前的Tincup中，数据是保存在关系数据库PostgreSQL数据库，使用自增的ID，这种数据存储方式不能允许跨Uber全球多个数据中心复制数据，因为货币汇率需要从全球所有数据中心访问，因此更好持久层到UDR，这是Uber自己的全局复制可扩展伸缩的数据存储。

微服务增长的预关注

在货币汇率系统决定了新的设计变化以后，关注点开始聚焦于微服务在工程产品领域的不断增长上。

Tornado

阻断网络I/O是一个严重问题，可能会导致uWSGI任务的饥饿，如果在Tincup所有向服务的请求都是同步的，一个服务的崩溃风险会引起多个连锁反应，影响所有调用者，因此决定采取Tornado，这是一个基于事件循环的异步Python框架，能够防止堵塞，因为是从过去整体代码库中分离出了很多小代码，因此选择异步框架可以使得很多应用程序逻辑能保持不变。

TChannel

曾经一个API调用可能会波及大量的服务调用，为了促进大型系统中服务发现和单点风险的识别能力，Uber微服务使用了开源的Tchannel而不是Hyperbahn，后者是一个内部的多路RPC框架，而TChannel提供了客户端和服务器端的协议，使用hyperbahn智能路由网连接客服两端，解决了微服务中以下问题：

服务发现 。所有生产者和消费者将自己注册到路由主机。消费者通过名称访问生产者，而不是需要知道对方的主机或端口。
容错。路由主机使用类似故障率和SLA进行测量。可以检测到不健康的主机，并随后将它们从可用主机池中删除。
限流和断路器 。这些功能确保坏的请求和缓慢的响应不会引起连锁故障。

Thrift

因为很多服务快速增长，有必要维护良好定义的结构供调用，使用IDL来管理结构，决定使用Thrift，能够强迫服务拥有者发布严格的接口定义，简化服务集成过程，不遵守接口的调用在Thrift级别就被拒绝了，而不是向服务泄漏，并导致代码中更深层次的失败。公开声明你的界面的这一策略强调了向后兼容性的重要性，因为服务的Thrift接口的多个版本可以在任何指定时间使用。服务的作者不能进行断崖式的变化，而只能使非断崖式的延续的兼容的接口定义，直到所有的消费者都准备好弃用。

为Tincup大规模生产使用准备

Tincup接近完成时，我们使用一些有用的工具来准备生产环境Tincup：

Hailstorm

我们意识到：Uber的流量是随时间变化。能在预期的时间看到巨大的流量峰值，像新年前夕和万圣节，所以我们必须确保服务可以处理这个突然增加的负载，建立了内部Hailstorm服务用于测试tincup端点负载和确定缺陷以及短路点。

uContainer

有效率使用硬件是Uber工程目标，因为Tincup是一个相对轻量的服务，它可以很容易地与其他服务分享共用的同一个机器。分享是重点关心吗？嗯，不总是，我们还是仍然希望确保每个服务独立运行，不影响在同一台机器上运行的其他服务。为了阻止这种问题，我们使用uContainer一种Uber的Docker来部署Tincup，实现资源隔离和限制。

uContainer利用Linux容器容量和容器化Uber服务。它将一个服务封装到一个孤立的环境中，以保证该服务将始终运行，而不管同一主机上的其他运行过程。ucontainer延伸Dcoker的能力，增加两点：