Uber工程师Emily Reinhold最近介绍了他们是如何将整体式API拆分为灵活的模块化微服务体系结构的。她重点介绍了在Uber的迁移工作中，设计和体系结构方面几个最重要的考虑。
根据 Reinhold的介绍，迁移至微服务的主要目标在于在三个指标方面实现更好的缩放性：应对流量的激增，更轻松地增添新功能，以及转为使用一种在组织迅速增长的情况下能轻松适应规模变化的体系结构。
为了降低微服务之间的耦合，Uber工程师在常规设计方面做出了一些决策：
MVCS，对众所周知的模型-视图-控制器（Model-View-Controller）方法进行的扩展，可明确包含服务层并承载应用程序逻辑。这样Uber就可以在业务逻辑和持久层之间实现解耦，借此更容易地修改持久层。 UDR，Uber的全球复制数据存储，该技术取代了PostgreSQL，使得Uber可以通过多个数据中心同时为用户提供乘车服务。此外为了应对大量服务所造成的后续问题，Uber工程师还对体系结构进行了一些重大更改：
异步网络：为了处理数量日益增加的服务请求，Uber工程师通过一种基于Python事件环路（Event-loop）的异步网络库Tornado实现了同时缩放至数万个开放连接的能力。使用Tornado的优势之一在于该技术可与Uber现有的Python网络代码集成，借此构建结构化的异步范式。 服务的发现和弹性：面对数量激增的服务，关键在于要能发现服务并找出故障点。例如需要收集故障率和SLA违背等指标，检测运行状况不正常的主机，通过短路（Circuit breaking）防止连锁故障。Uber通过Hyperbahn使用TChannel解决了这一问题，这是一种他们自行开发并已开源的，适用于RPC的网络多工（Multiplexing）和帧通讯协议。 严格的接口定义：Uber选择使用Thrift通过IDL定义服务接口，并借此生成不同语言的客户端源文件。Thrift使得他们能够检测出客户发起的，与接口定义规范不符的调用。最后Reinhold还提到Uber会通过下列基本原则确保生产环境正常运行：
通过负载测试发现瓶颈和断点。 通过容器实现更高的硬件利用率。 通过模拟服务中断确保系统能够顺利恢复并发现可能存在的弱点。Emily Reinhold也曾在上一次纽约QCon活动中讨论过这些话题。
====================================分割线================================
本文转自d1net（转载）
