Zuul - Netflix API Gateway that handles 2M requests per second

How do we effectively route 2M requests per second to hundreds of backend services? How do we protect those backend services from constant DDoS attacks and retry storms? How do we keep Netflix humming along when an Amazon Web Services outage takes an entire AWS region out?

Meet Zuul - Netflix's swiss army knife for application networking. Zuul is Netflix's API gateway, load balancer, reverse proxy and more. It fronts all of the API traffic entering Netflix cloud and routes it to many backend services. It shields these backend services from retry storms, DDoS attacks and other outages shifting traffic across AWS regions, if necessary. It load balances millions of requests per second across thousands of machines, routing them intelligently and automatically around faulty instances.

In addition to this mission critical role in live production, Zuul is also invaluable during development and test to debug, canary and load test new features. Zuul lets us define new routing rules dynamically at run time that take effect near instantly without any deployments or restarts. This capability to slice, dice and change route for a portion of traffic quickly lets Zuul do all sort of tricks like canary / load testing, surgical traffic debugging for a single customer / device, black-holing malicious traffic etc.

At its heart, Zuul is a high performance, non blocking reverse proxy and layer 7 load balancer built on top of Netty. It supports multiple protocols including HTTP 1.0, HTTP 1.1, HTTP/2, WebSockets and Server Sent Events. It also offers flexible, configurable transport layer security including TLS, mTLS and application layer security like Netflix specific security protocols like MSL.

We will cover:

• Zuul concept - where Zuul fits in overall Netflix architecture.
• Zuul design -  Architecture of Zuul and its fundamental components.
• Zuul operation - How we operate 80+ Zuul clusters to proxy traffic to hundreds of backends
• Zuul future - where are we going next with Zuul

参考译文：

我们是如何有效的在每秒中向数百个后端服务发送请求的？我们又是如何保护这些后端服务免受持续的DDoS攻击和重试风暴？当AWS服务中断时，我们如何保持Netflix正常运作。

Zuul——被称为Netflix应用网络的瑞士军刀，它是Netflix的API网关，负载均衡器，反向代理等等。它掌控着Netflix云的所有API流量，并将这些流量分发到多个后端服务上。必要时，它可以保护这些后端服务免受重试风暴，DDoS攻击以及其他服务中断在AWS区域之间转移流量带来的影响。它可以在数千台计算机上平衡每秒数百万个请求，并在故障实例周围智能的调度资源。

不仅在处理在线业务的过程中发挥关键作用，Zuul在开发和测试过程中也非常有价值，可用于调试、测试、加载测试新功能。Zuul支持在运行时动态定义新的分发规则，这些规则可以在无需任何部署或重新启动的情况下即时生效。这种切片，切块和更改部分流量分发的功能可以让Zuul执行各种任务，如为单个客户/设备、黑洞恶意流量做Canary(金丝雀部署)/负载测试，以及外科式流量调试。

从本质上讲，Zuul构建于Netty之上，是一个高性能，无阻塞的反向代理和7层负载均衡器。它支持多种协议，包括HTTP 1.0，HTTP 1.1，HTTP / 2，WebSockets和Server Sent Events。还提供灵活可配置的传输层安全性，包括TLS，mTLS和应用层安全性，如Netflix特定的安全协议MSL。

演讲提纲：

• Zuul概念 -  Zuul适合整体Netflix的架构
• Zuul设计 -  Zuul架构及其基本组成部分
• Zuul运维 - 我们如何运维80多个Zuul集群来代理数百个后端的流量
• Zuul未来 - Zuul的下一步打算

2007年淘宝网在服务化架构的演进和落地中就产出了内部第一代的软负载产品。随着淘宝网这些年在异地多活，混合云部署，微灰度，流量调度，线上引流压测等高可用架构的建设过程，这个软负载产品也已经发展成为淘宝网架构中不可或缺的核心的工业级基础中间件产品。我们也惊讶的发现，这几年风行的微服务架构中关于微服务系统的软负载体系建设思路和业界实践中，居然有很多和我们走过的路不谋而合。当然，我们也趟过一些坑，沉淀了一些独到的经验。

通过这个分享，和大家交流阿里巴巴这10年来在软负载体系的实践之路，共同看看该领域的未来趋势。

演讲提纲：

1. 什么是“软负载”
2. 万物皆“服务”，以服务为中心的现代应用架构
3. 微服务的基石，服务发现
4. 负载均衡体系的变迁
5. 阿里巴巴精细的流量控制体系

• 阿里巴巴8年双十一中的“软负载“实践
• 软负载流量网关之统一接入层
• 从软负载层面看阿里的”单元化及异地多活“容灾体系
• 基于软负载的阿里巴巴的”微灰度“流量灰度体系
• 双十一中精细的流量调度
• 阿里巴巴基于标签的复杂环境的智能路由系统

1. “软负载”与新技术趋势（云计算，Service Mesh，Cloud Native）

• Service Mesh的流量控制和智能路由与软负载的关系
• 服务治理与基于标签的流量控制

听众受益点：

• 了解阿里巴巴在大规模微服务体系下的”数据化驱动的精准流量控制“的软负载体系
• 了解阿里巴巴在微服务流量控制实践过程中踩过的坑和最佳实践
• 了解动态服务发现和配置中心在这个体系中要发挥的关键作用
• 涉及MicroService/Cloud Native/Service Mesh等最新前沿领域中设计的软负载领域

当无界零售战略要求打破边界，对人、货、场进行重新组合来创造更多应用场景时，系统需要具备积木式赋能的能力，微服务架构是构建这样的应用系统的不二之选。然而，相对于传统的电商系统，现在面对着的是更复杂的业务领域，更灵活多变的组合场景，如何让这些微服务具有高度的内聚性，把耦合度降到最低变成了首要的挑战。

7Fresh架构团队使用DDD进行战略和战术建模，进一步实现了较为合理的微服务架构风格的应用系统，期间遇到了很大的挑战也总结了很多经验。本次分享会和大家回顾这个艰辛却很有收获的过程。

演讲提纲：

1. 简介

2. 新场景面临的挑战

• 多样化的智能终端
• 纵深化的业务整合
• 积木式赋能的挑战

3. DDD指导微服务落地的经验总结

• 衔接上下文和微服务的关系
• 边界本身不能保证你不越界
• 不要上下文的映射关系
• 面向服务集成不是面向数据
• 战术建模和设计低表示差异
• ……

4. 总结

当前微博服务化采用公有云＋私有云的混合云部署方式，承载了每天百亿级的流量，vintage作为微博微服务的注册中心，为管理10w级微服务节点以及在流量激增的情况下的服务快速扩缩容，面临了极大挑战。例如：复杂网络条件下vintage服务的高可用保障、解决大批量节点状态变更触发的通知风暴、异常情况下vintage节点的自适应和自恢复能力、vintage多云部署场景下节点数据同步和一致性保障等。vintage 3.0优雅的解决了上述问题，具备了良好的扩展性，可用性达到6个9。

本次演讲将以挑战和问题切入与大家分享vintage设计原则与方案，以及线上应用的最佳实践。

演讲提纲：

1. 微博为服务注册中心－vintage简介

• 注册中心微服务的基石
• 微博vintage 使用经验总结及混合云前景下的挑战，要求

2. 从问题，挑战思考vintage系统的设计与实现 

• 微博混合云场景下vintage系统的设计选型
• vintage系统架构及核心模块技术实现

3. vintage的高可用保障

4. 微博峰值时vintage系统表现 & 总结

 听众受益点：

• 帮助听众了解业界不同注册中心的特点与设计理念；
• 了解多云微服务环境下服务注册中心面临的挑战，了解微博最佳实践；
• 了解注册中心运行过程中常见及核心问题的应对与解决方案；
• 了解分布式系统中，节点管理，cap原则的取舍和高可用保障机制。