Uber改造整体单一式代码库后的微服务架构实践

　　几个月前，我们讨论到 Uber 决定将原有的整体单一式代码库更换成模块化、更具灵活性的微服务架构。从那时起，Uber 有许多工程师投入了数千小时，改造拓展 Uber 微服务的生态环境。新的架构使用了多种语言以及很多不同的框架结构，鉴于重构任务非常庞大，我们也利用此机会在 Uber 使用了一套新的微服务构建技术。借助适合 SOA 迁移的技术堆栈及标准，我们改进了在 Uber 开发服务的方式。

　　开始一项新服务

　　在一家快速成长的工程类公司，想要追踪所有进行中的任务是非常困难的，需要有相应的方法，才能避免各团队工作重复。在 Uber，我们通过要求新服务的编写者提交 RFC（Request for Comments） 来解决这个问题。RFC 是一份关于新服务的详细议案，其中需要列出新服务的目的、架构、依赖与其他执行细节，让 Uber 工程部门的其他员工一并参与讨论。

　　提交 RFC 有两个目的：

　　1.为即将开发的服务征集反馈，以提高服务质量；

　　2.避免工作重复，或者提供合作机会。

　　其他一些熟悉该领域的工程师会审阅这份服务设计稿，一旦将反馈融入到服务议案中，我们就可以开始快乐地投入新服务的构建了。

　　执行一项新服务

　　我们的货币与汇率服务「Tincup」正是微服务在 Uber 实现的良好案例。Tincup 是最新货币与汇率数据的接口，负责两个主要端点任务：

　　1.获得货币目标；

    2.获得指定货币的当前汇率（兑美元）。由于 Uber 提供的是全球性的服务，这些端点非常必要。汇率经常变动，而我们的业务涉及了将近60种货币。

　　无论你在什么地方，都可以点击按钮随时叫车，Tincup会为你确保自动使用当前所在国的货币单位支付车费。

　　通过新技术来引导微服务

　　构建 Tincup 需要重构所有与货币和汇率相关的逻辑，这正好为我们提供了机会，重新评估 Uber 一些很久之前所做的设计决策。我们使用了一些新的框架、协议和约定来执行 Tincup。

　　MVCS

　　首先，我们搞定了货币与汇率相关的整体代码结构。近几年，我们修改了 Uber 很多数据集的持久层（点击查看样例），由于所有变化都是长期而繁琐的，从这个过程中我们学到：如果可能的话，最好将持久层规范从应用逻辑中分离出来。这样就形成了我们所谓的 MVCS 应用开发方法：扩大常见的 MVC 方法，将应用逻辑所在的服务层也包括在内。通过隔离服务层中的应用逻辑以及应用的其他部分，就能在无需重构业务逻辑的情况下，修改或替换持久层的内容——只需改动直接与存储/读取相关的那部分代码。

　　UDR

　　其次，我们考虑了货币与汇率的持久层。在使用 Tincup 之前，这些数据存储在PostgreSQL 关系数据库中，以增量整数 ID 为标记。然而这种数据存储方法无法支持 Uber 数据中心在全球范围内执行数据复制，无法匹配我们的 all-active（所有数据中心同时提供行程服务）工作架构。由于访问货币和汇率时，需要涉及所有的数据中心，我们换掉了持久层，用 UDR（Uber 的全球复制可扩展数据库）来代替。

　　预测微服务成长中的问题

　　在决定对货币及汇率作出设计改动后，我们解决了随着工程生态环境中的微服务数量增长而自然出现的新问题。

　　Tornado

　　网络吞吐堵塞是非常严重的问题，可能会导致 uWSGI 的 worker 无事可做，如果类似 Tincup 的所有服务请求都是同步的，某个服务出现问题会导致连锁反应，并影响所有调用者。我们决定采用 Tornado，这是一个基于 event-loop 的 Python 异步框架，目的是为了防止出现阻塞。由于我们从 Flask 整体单一式数据库中剥离了大量的代码，选择使大多现有应用逻辑保持不变的异步框架让风险降到最低，对我们来说非常重要。Tornado 符合这一需求，因为它允许同步查看代码，但不会堵塞输入/输出。另外还有个替代方案：为了解决上述的吞吐问题，很多服务提供者都在使用新语言 Go。

 1/3    1 2 3 下一页 尾页