Uber从单体架构转向微服务架构

在成立之初，Uber采用单体架构构建了一款仅服务于一座城市的产品。但随着Uber的迅速发展、核心领域模型的扩大，组件成了紧耦合的，持续集成成了很大的负担。新增特性、Bug修复、技术债务解决，全都在单个库中进行，这极其困难。因此，他们决定效仿那些快速成长的公司（如亚马逊、Netflix、Twitter等）将单个代码库拆分成多个代码库，由单体架构迁移到微服务架构。近日，Uber官方网站介绍了这一迁移过程。

他们之所以迁移到微服务架构，主要是为了达成以下三个目标。

易见性

在迁移之前，他们已经有500多个服务，服务发现变得非常困难。每个服务都有自己的结构，服务的用法不能做到显而易见。通常，服务提供的REST或RPC端点都是弱契约。向REST API添加JSON模式可以提高安全性及改进针对服务的开发过程，但不易于编写或维护。总之，无法保证容错性或延迟，也没有标准的方法处理客户端超时和中断或者确保一个服务中断不影响其它服务。这些缺陷也影响了系统弹性。因此，他们需要一种可以提供类型安全、验证且具备容错性的标准通信方法。而且，该方法还要满足如下要求：

• 提供客户端库的方式要简单；
• 提供跨语言支持；
• 超时和重试策略可调整；
• 测试和开发高效。

因此，他们认为Uber需要一种已有的接口定义语言（IDL），而且该语言还提供了大量预构建的工具。经过评估，他们发现，Apache Thrift最能满足他们的需求。Thrift提供一个构建可扩展、跨语言服务的库和工具集合。数据类型和服务接口定义在一个语言无关的文件中，然后生成代码将服务之间RPC消息的传递和编码抽象出来，而这些服务是使用不同语言编写的。

安全性

Thrift最吸引他们的地方是其安全性。Thrift通过将服务绑定到严格的契约来确保安全性。该契约描述了服务的交互方式，包括如何调用服务、提供什么输入以及会产生什么输出。

弹性

他们从Netflix的Hystrix库和Twitter的Finagle库获得了处理系统弹性问题的灵感，编写了一个可以确保客户端成功处理失败场景的库。他们后续会对此进行详细介绍。

遗憾的是，Thrift工具集相对还不成熟，面向Python和Node的工具也不够多。这有个风险，就是他们可能需要花费大量的时间创建这样的工具。另外，身份验证和跨服务跟踪也是他们面临的两个挑战。

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。