摘要： 2014年，Uber构建了可扩展的容错数据库Schemaless，但随着业务的增长，原实现方式对资源消耗更多，同时请求延迟也在增加，为了保持Schemaless的性能，Uber在不影响生产服务的情况下用Go重写了Schemaless数据库的分片层，完成了将产品系统从旧实现迁移到新实现的Frontless项目。

2014年，Uber工程构建了可扩展的容错数据库Schemaless，为公司的快速发展提供了便利。我们仅在2016年就部署了40多个Schemaless实例和数千个存储节点。

随着业务的增长，我们的资源消耗和延迟也在增长；为了保持Schemaless的性能，我们需要一个能够很好的支持大规模应用的解决方案。在明确了假如将现有Schemaless“集群”的Python工作节点用Go(一种支持轻量级并发特性的语言)重写的话，我们的数据库可以获得显著的性能提升后，我们在不影响正常生产的情况下，完成了将产品系统从旧实现迁移到新实现的任务。这一任务被称为Frontless项目，它证明了我们可以在不影响生产服务的情况下重写大型数据库的前端。

在本文中,我们会讨论如何将Schemaless分片层从Python迁移到Go，这一改变可以使我们用更少的资源来处理更多的流量，从而改善用户对我们服务的体验。

Schemaless的背景

作为Mezzanine项目，Schemaless于2014年10月首次推出，当初计划将Uber的核心trip数据库从一个独立的Postgres实例迁移到一个高可用的数据库中。

包含核心trip数据的Mezzanine数据库被构建为第一个Schemaless实例。从那时算起，目前已经部署了40多个Schemaless实例用于众多客户端服务。(关于我们内部数据库的完整历史演进过程，请参阅我们的三篇系列文章，Schemaless的设计、架构和triggers概述)。

在2016年中，有数千个工作节点在Schemaless实例中运行，每个工作节点都消耗大量的资源。工作节点最初是使用Python和由NGINX交付的uWSGI应用程序服务器进程中的一个Flask微框架构建的，每个uWSGI进程一次处理一个请求。

该模型简单易行，易于建立，但不能有效地满足我们的需求。为了处理额外的同步请求，我们必须增加更多的uWSGI进程，每个进程都作为一个需要额外开销的新的Linux进程，因而这从根本上限制了并发线程的数量。在Go中，goroutines被用来构建并发程序。goroutine采用轻量级设计，是由Go的运行时系统管理的线程。

为了研究重写Schemaless分片层的优化增益，我们创建了一个实验性的工作节点，该节点实现了一个使用频率较高、资源消耗也比较高的端点。重写的结果显示，延迟减少了85%，资源消耗减少的甚至更多。

图1：该图描述了Frontless形式实现的端点中值请求延迟情况

在进行了这个实验之后，我们明确了重写将使Schemaless通过释放CPU和内存来支持其所有实例中的依赖服务和工作节点。有了这些知识基础，我们启动了这个Frontless项目，用Go重写整个Schemaless分片层。

Frontless架构设计

为了成功地重写Uber技术堆栈的这个重要部分，我们需要确保我们的重新实现100%与现有的工作节点兼容。我们做了一个关键的决定，以验证新实现与原始代码的关系，这意味着每个对新Go工作节点的请求都要得到跟之前对Python工作节点请求相同的结果。

我们估计一个完整的重写会花费我们六个月的时间。在此期间，在Uber的生产系统中实现的新功能和bug修复将在Schemaless的情况下进行，所以我们的迁移有了一个动态的目标。我们选择了迭代开发形式，这样我们就可以一次性在一个端点上不断的从遗留的Python代码库中迁移出功能，并同时在新的Go代码库中验证。

最初，Frontless工作节点只是在现有的uWSGI Schemaless工作节点前面的一个代理，所有请求都通过该节点。迭代将从重新实现一个端点开始，然后在生产中进行验证；当不再有错误出现后，新的实现才会正式上线。

从部署的角度来看，Frontless和uWSGI Schemaless的工作是一起构建和部署的，这使得在所有实例中都可以实现统一的Frontless，并同时支持所有生产场景的验证。

图2：在我们的迁移过程中，一个名为worker节点的服务，其中Frontless和Schemaless在同一个容器中运行。Frontless随后收到请求，并决定是否应该将其转发给Schemaless，或者由Frontless处理。最后，Schemaless或Frontless从存储节点获取结果，并将其返回给服务。

读取端点:对比验证

我们首先聚焦在用Go重新实现读取端点上。在我们最初的实现中，Schemaless实例上读取端点处理平均占用90%的流量，并且它也是最消耗资源的。

当一个端点用Frontless实现后，将会启动验证进程，检测与Python实现的差异性。Frontless和Schemaless执行请求操作时便会触发验证并对比响应结果。

图3：当一个服务发送请求到Frontless时，它会将请求转发给Schemaless，该请求将通过查询存储节点生成响应。然后，由Schemaless做出的响应将返回到Frontless，并将其转发给服务。Frontless还将通过查询存储节点来创建响应。这两种响应是由Frontless和Schemaless构建的，如果出现任何差异，结果将作为bug报告发送给Schemaless开发团队。

使用此方法验证，将使发送到存储工作节点的请求数量增加一倍；为了使请求数量增加后工作正常，我们添加了配置标志来激活每个端点的验证，并调整请求验证的百分比阈值。这样便可以在几秒内启动或禁用对指定端点任意部分的验证功能。

写入端点：自动集成测试

Schemaless的写入请求只能一次性成功，所以为了验证这些我们不能再使用以前的策略了。然而，由于与读取端点相比，在Schemaless中写入端点要简单得多，因此我们决定通过自动化集成测试来测试它们。

我们建立起了集成测试环境，这样Schemaless Python和Frontless Go就可以运行相同的测试场景了。测试是自动化的，可以在本地执行，也可以在几分钟内通过持续的集成来执行，这可以加快开发周期。

为了规模化测试我们的实现，我们设置了一个Schemaless测试实例，其中流量测试模拟了生产流量。在这个测试实例中，我们将Schemaless的Python流量写入实现迁移到了Frontless上，并运行验证来确保写入的正确性。

最后，一旦所有实现都满足生产环境时，我们就可以通过运行时配置将Schemaless的Python实现的流量写入功能缓慢地迁移到Frontless上，这样便可以在几秒钟内将部分流量写入工作移动到新的实现中。

Frontless的成果

到2016年12月为止，所有的Mezzanine数据库都是由Frontless处理的。如图4所示，所有请求的中值延迟降低了85%，p99请求延迟降低了70%:

图4：上图展示了由Python(Schemaless的工作语言，用红色表示)和Go(Frontless的工作语言，用蓝色表示)实现时数据库请求处理的时间。

随着我们Go的实现，Schemaless的CPU使用率下降了85%以上。这种效率的增加让我们减少了在所有Schemaless实例中使用工作节点的数量，这些节点也是基于与以前相同的QPS，这从而提高了节点利用率。

图5：上面的图展示了在我们的数据库中由Python(Schemaless工作语言，红色的)和Go(Frontless的工作语言，蓝色的)处理的一个稳定的请求流中的CPU使用情况。

Frontless的未来

Frontless项目表明，我们有可能在零停机的情况下，用一种全新的语言重写一个关键系统。通过重新实现服务而不改变Schemaless的现有客户端，我们能够在几天内而不是数周或几个月内实现、验证和启用端点。重点是，验证过程(新的端点实现与现有生产中的实现进行比较)给了我们信心，因为Frontless和Schemaless可以得到相同的结果。

然而，最重要的是，我们在生产中重写关键系统的能力证明了Uber迭代开发过程的可伸缩性。

原文链接：https://eng.uber.com/schemaless-rewrite/

创作场景

放弃 Python，Uber 用 Go 重写 Schemaless 数据库的分片层