Zuul 2: Netflix的异步、无阻塞系统之旅

作者: Netflix Technology Blog

译者: java达人

来源: https://medium.com/netflix-techblog/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c

Zuul 2和它的“前辈”做了同样的事情—充当Netflix服务器基础设施的前门，处理来自全世界所有Netflix用户的流量。它还可以进行请求路由，支持开发人员的测试和调试，深入了解我们的整体服务状况，保护Netflix免受攻击，并在AWS区域遇到问题时将流量引导到其他云区域。

Zuul 2与原始版本之间的主要架构差异是，Zuul 2在异步、非阻塞框架(Netty)上运行。过去在生产中运行了几个月，其主要优势(这也是我们在着手这项工作时所期望的)是，它为设备和web浏览器提供了在Netflix量级上具有的持久连接能力。拥有超过8300万成员，每个成员都有多个连接设备，这是一个巨大的挑战。通过与我们的云基础设施的持久连接，我们可以启用大量有趣的产品特性和创新，减少总体设备请求，提高设备性能，更好地理解和调试客户体验。

我们还希望Zuul 2能够在延迟、吞吐量和成本方面提供弹性伸缩的好处和性能改进。但正如你将在这篇文章中了解到的，我们的愿望与结果有所不同。

阻塞和非阻塞系统的区别

要理解为什么我们要构建Zuul 2，您必须首先理解异步和非阻塞(“异步”)系统与多线程、阻塞(“阻塞”)系统在理论上和实践中的架构差异。

Zuul 1是在Servlet框架上构建的。这样的系统是阻塞和多线程的，这意味着它们通过每个连接一个线程的方式来处理请求。I/O操作是通过从线程池中选择一个工作线程执行I/O来完成的，并且请求线程将阻塞，直到工作线程完成为止。工作线程在其工作完成时通知请求线程。这对于处理100个并发连接的现代多核AWS实例很有效。但是，当出现问题，如后端延迟增加或由于错误导致设备重试，活动连接数和线程数也将增加。当这种情况发生时，节点就会陷入麻烦，并可能进入死亡螺旋，其中备份的线程会使服务器负载激增，并使集群不堪重负。为了抵消这些风险，我们构建了限流机制和库(例如，Hystrix)来保持这些事件期间阻塞系统的稳定。

多线程系统架构

异步系统的操作方式不同，通常每个CPU内核有一个线程处理所有请求和响应。请求和响应的生命周期通过事件和回调来处理。因为没有针对每个请求使用线程，所以连接的成本很低, 而只是一个文件描述符和一个监听器的成本。而在阻塞模型中，每个连接的成本是一个线程，需要有大量的内存和系统开销。由于数据在相同的CPU上，可以更好地利用CPU级缓存，进行更少的上下文切换，因此可以提高效率。后端延迟和“重试风暴”(当出现问题时客户和设备的重试请求)对系统的影响也更小，因为连接和队列中增加的事件比线程堆积的开销要小得多。

异步非阻塞系统架构

异步系统的优点听起来很好，但是上面的优点是以操作复杂性为代价的。阻塞系统很容易理解和调试。线程总是执行单个操作，因此线程的堆栈是请求或派生任务的准确快照;线程堆栈可以被读取，以便通过锁跟踪跨多个线程的请求。抛出的异常会弹出堆栈。一个“catch -all”的异常处理程序可以清除所有未显式捕获的异常。

相比之下，异步是基于回调并由事件循环驱动的。当试图追踪请求时，事件循环的堆栈跟踪没有意义。在事件和回调执行时，很难跟踪请求，并且在这方面非常缺乏帮助调试的工具。边缘情况、未处理的异常和未正确处理的状态更改会创建悬空资源，从而导致ByteBuf泄漏、文件描述符泄漏、响应丢失等。这类问题已经被证明很难调试，因为很难知道哪个事件没有得到适当的处理或清理。

构建非阻塞Zuul

在Netflix的基础架构中构建Zuul 2比预期的更具挑战。Netflix生态系统中的许多服务都是基于阻塞的假设建立起来的。Netflix的核心网络库也是根据阻塞的架构假设构建的;许多库依赖于线程局部变量来建立、存储请求相关的上下文。线程局部变量在异步非阻塞环境中不起作用，在异步非阻塞环境中，同一个线程上处理多个请求。因此，构建Zuul 2的复杂性多在于梳理出使用线程局部变量的隐秘角落，其他的挑战则包括将阻塞网络逻辑转换成非阻塞网络代码，并在库中寻找阻塞代码，修复资源泄漏，以及将核心基础设施转换为异步运行。将阻塞网络逻辑转换为异步没有一刀切的策略;它们必须单独进行分析和重构。这同样适用于核心的Netflix库，其中一些代码需要修改，而另一些则需要fork、重构为异步工作。开源项目Reactive-Audit通过插桩server的方式来帮助发现代码块和库被阻塞的情况。

我们采用了一种有趣的方法来构建Zuul 2。由于阻塞系统可以异步运行代码，因此我们首先更改Zuul过滤器和过滤器链代码为异步运行。Zuul过滤器包含我们网关功能(路由、日志、反向代理、防ddos等)的特定逻辑。我们使用RxJava重构了Zull核心功能，基本的Zuul过滤器，使它们能够异步运行。现在我们有两种类型的过滤器组合使用:用于I/O操作的异步过滤器，以及运行逻辑操作(不需要I/O)的同步过滤器。异步Zuul过滤器允许我们在阻塞系统和非阻塞系统中执行完全相同的过滤逻辑。这使我们能够使用一个过滤集， 既可以为我们的合作伙伴开发网关功能，也可以在独立的代码库中开发基于netty的体系架构。有了异步Zuul过滤器，构建Zuul2 “只是”让我们的Zuul基础架构异步且非阻塞地运行。相同的Zuul过滤器可以直接进入这两种体系架构。

Zuul2在生产环境表现

关于异步架构对我们网关的好处，与假设的有很大的不同。一些人认为，由于上下文切换的减少和CPU缓存的更有效使用，我们将看到一个数量级的效率提升，而另一些人则认为，我们得不到效率的提升。对于改造和开发工作的复杂性，意见也各不相同。

那么，我们从这种架构改造中获得了什么?值得吗?这个话题引起了激烈的争论。云网关团队率先尝试在Netflix创建和测试基于异步的服务。人们对理解使用异步的微服务如何在Netflix上运行很感兴趣，而Zuul是一种可以观察改造收益的典型服务。

虽然我们在迁移到异步和非阻塞时没有看到显著的效率优势，但我们确实实现了连接扩展的目标。Zuul确实大大降低了网络连接的成本，使设备之间的推送和双向通信成为可能。这些特性将支持更多关于实时的用户体验创新，并将通过推送通知替代当前的“聊天”设备协议(占API流量的很大部分)来降低总体云成本。与阻塞模型相比，在处理来自原始系统的重试风暴和延迟方面也有一些弹性优势。我们正在不断改进这一领域;然而，应该注意的是，弹性优势的取得并不是直接的，需要一些经过努力和调整。

通过将Zuul的核心业务逻辑放入阻塞或异步体系结构的能力，我们可以对阻塞和异步进行有趣的比较。那么，尽管两个系统在特性、性能和弹性方面的方式非常不同,它们是如何完成完全相同的实际工作的呢? 在生产环境中运行Zuul 2几个月后，我们的评估是，一个系统的越是cpu密集型的，我们看到的效率提升就越少。

我们有几个不同的Zuul集群，用于前端服务，如API、回放、网站和日志。每个origin服务都要求由相应的Zuul集群处理不同的操作。例如，面向API服务的Zuul集群承担了所有集群中最多的开箱工作，包括度量计算、日志记录和对输入有效负载和压缩响应的解密。在这个集群中，将阻塞zuul转化为异步Zuul 2并不会提高效率。从容量和CPU的角度来看，它们本质上是等价的，考虑到Zuul服务前端API的CPU密集型程度，这是合理的。每个节点在吞吐量相同的情况下也会降级。

面向日志服务的Zuul集群具有不同的性能配置文件。Zuul通常接收来自设备的日志记录和分析消息，并且需要大量的写操作，因此请求很大，但是响应内容很小，而且未被Zuul加密。因此，Zuul为这个集群做的工作要少得多。虽然仍然是CPU密集型，但是通过运行基于netty的Zuul，我们可以看到吞吐量增加了25%，同时CPU利用率降低了25%。因此，我们观察到，系统实际做的工作越少，我们从异步中获得的效率就越高。

总的来说，我们从这个架构变更中得到的价值是很高的，连接扩展是主要的好处，但是它确实是有代价的。我们的系统调试、编码和测试更加复杂了，而且我们在Netflix的技术生态系统中工作，这个系统的运行假设是阻塞系统。技术生态系统不太可能在短时间内发生改变，所以当我们向网关添加和集成更多的特性时，我们很可能需要继续梳理出线程局部变量以及客户端库和其他支持性代码中的阻塞假设。我们还需要异步地重写阻塞调用。这是一个独特的工程挑战，重新开始构建和集成Zuul 2本可以避免这些复杂性，但我们所处的环境中，这些库和服务对我们的网关功能和Netflix技术生态系统中的操作至关重要。

— 云网关团队(Mikey Cohen, Mike Smith, Susheel Aroskar, Arthur Gonigberg, Gayathri Varadarajan, 和 Sudheer Vinukonda)