不喜勿喷，大部分为Google翻译
Netflix流媒体应用程序是一个交织在一起的系统的复杂阵列，它们共同为我们的客户提供无缝的体验。 Netflix API是该系统的前门，支持超过1,000种不同的设备类型，并在繁忙时间每秒处理50,000个请求。 我们每天都在不断增加新的功能。 与此同时，我们的用户界面团队不断推动对服务器端客户端适配器脚本的更改，以支持新功能和AB测试。 新的AWS区域被部署到新的国家并添加目录以支持国际扩张。 为了应对所有这些变化以及支持复杂和高规模系统的其他挑战，需要一个能够实现快速开发，极大的灵活性，广泛的洞察力和弹性的强大的边缘服务。
今天，我们很高兴地向大家介绍Zuul是如何应对这些挑战的，以及我们开源软件套件的最新成员。虽然Zuul是最初设计用于面向Netflix API的边缘服务，但现在正在以各种方式使用它 整个Netflix的一些系统。
Zuul如何工作？
Zuul的中心是一系列过滤器，能够在HTTP请求和响应的路由过程中执行一系列操作。 以下是Zuul滤波器的主要特性：
Type：最经常定义在应用过滤器时路由流程中的阶段（尽管它可以是任何自定义字符串）
Execution Order：在“类型”中应用，定义跨多个过滤器的执行顺序
Criteria：为了执行过滤器所需的条件
Action：如果符合条件，则执行该行动
下面是一个简单过滤器的例子，它延迟发生故障的设备发出的请求，以便将负载分配到我们的原点上：
class DeviceDelayFilter extends ZuulFilter {
def static Random rand = new Random()
@Override
String filterType() {
return 'pre'
}
@Override
int filterOrder() {
return 5
}
@Override
boolean shouldFilter() {
return RequestContext.getRequest().
getParameter("deviceType")?equals("BrokenDevice"):false
}
@Override
Object run() {
sleep(rand.nextInt(20000)) // Sleep for a random number of
// seconds between [0-20]
}
}Zuul提供了一个动态读取，编译和运行这些过滤器的框架。 过滤器不直接相互通信 - 而是通过每个请求唯一的RequestContext共享状态。
尽管Zuul支持任何基于JVM的语言，但是过滤器目前是用Groovy编写的。 每个过滤器的源代码都被写入到Zuul服务器上的一组指定的目录中，这些目录被定期轮询以进行更改。 更新的过滤器从磁盘读取，动态编译到正在运行的服务器中，并由Zuul为每个后续请求调用。
有几种标准的过滤器类型对应于请求的典型生命周期：
- PRE过滤器在路由到原点之前执行。 示例包括请求身份验证，选择原始服务器以及记录调试信息。
- ROUTING过滤器处理将请求路由到原点。 这是使用Apache HttpClient或Netflix Ribbon构建和发送原始HTTP请求的地方。
- POST过滤器在请求被路由到原点后执行。 示例包括向响应中添加标准HTTP头，收集统计信息和度量标准，以及将响应从源发送到客户端。
- ERROR 在其他阶段发生错误时，执行错误过滤器。
除了默认的过滤器流程，Zuul允许我们创建自定义的过滤器类型并明确执行它们。 例如，Zuul有一个STATIC类型，它在Zuul中生成一个响应，而不是将请求转发到一个源。
我们如何使用Zuul
Zuul有许多方法可以帮助我们运行Netflix API和整个Netflix流媒体应用程序。 下面是一些更常见的例子的简短列表，对于一些我们将在下面更详细的介绍：
- Authentication
- Insights
- Stress Testing
- Canary Testing
- Dynamic Routing
- Load Shedding
- Security
- Static Response handling
- Multi-Region Resiliency
Insights
Zuul通过使用其他Netflix OSS组件，为我们提供了对我们系统的深入了解。
Hystrix被用来包装呼叫到我们的来源，这使我们能够在发生问题时减少流量并划分优先级。
Ribbon是我们的客户端，它提供来自Zuul的所有出站请求，它提供了有关网络性能和错误的详细信息，并处理负载均衡的软件负载平衡。
Turbine实时聚合细粒度的度量标准，以便我们可以快速观察并对问题做出反应。
Archaius处理配置并提供动态更改属性的功能。
因为Zuul可以在运行时添加，更改和编译过滤器，所以可以快速更改系统行为。 我们添加新路由，分配授权访问规则，并通过添加或修改过滤器来对路由进行分类。 当出现意想不到的情况时，Zuul有能力迅速拦截请求，以便我们可以探索，解决问题或解决问题。
Zuul的动态过滤功能使我们能够查找和隔离在大量请求中通常很难找到的问题。可以编写过滤器将特定的客户或设备路由到单独的API集群进行调试。当网站的新页面需要调整时使用了这种技术。观察到性能问题以及无法解释的错误。调试问题很困难，因为问题只发生在一小部分客户身上。通过将流量隔离到单个实例，可以实时查看请求中的模式和差异。 Zuul有我们所说的“SurgicalDebugFilter”。这是一个特殊的“预”过滤器，如果patternMatches（）条件为真，它将把请求路由到一个孤立的集群。添加此过滤器以匹配新页面，使我们能够快速识别和分析问题。在使用Zuul之前，Hadoop被用来通过数十亿记录的请求来查询数千个新页面的请求。我们能够通过几台服务器上相对较小的日志文件将问题减少到搜索范围，并实时观察行为。
以下是SurgicalDebugFilter的一个示例，用于将匹配的请求路由到调试群集：
class SharpDebugFilter extends SurgicalDebugFilter {
private static final Set<String> DEVICE_IDS = ["XXX", "YYY", "ZZZ"]
@Override
boolean patternMatches() {
final RequestContext ctx = RequestContext.getCurrentContext()
final String requestUri = ctx.getRequest().getRequestURI();
final String contextUri = ctx.requestURI;
String id = HTTPRequestUtils.getInstance().
getValueFromRequestElements("deviceId");
return DEVICE_IDS.contains(id);
}
}除了动态地重新路由符合指定条件的请求之外，我们还有一个建立在Zuul和Turbine之上的内部系统，允许我们在整个集群中显示所有匹配请求/响应的实时流日志。 这个内部系统可以让我们快速找到异常行为的模式，或者只是观察到一些交通段落的行为如预期的那样（通过询问“圣保罗有多少PS3 API请求”等问题）？
Stress Testing
Gauging the performance and capacity limits of our systems is important for us to predict our EC2 instance demands, tune our autoscaling policies, and keep track of general performance trends as new features are added. An automated process that uses dynamic Archaius configurations within a Zuul filter steadily increases the traffic routed to a small cluster of origin servers. As the instances receive more traffic, their performance characteristics and capacity are measured. This informs us of how many EC2 instances will be needed to run at peak, whether our autoscaling policies need to be modified, and whether or not a particular build has the required performance characteristics to be pushed to production.
Multi-Region Resiliency
Zuul is central to our multi-region ELB resiliency project called Isthmus. As part of Isthmus, Zuul is used to bridge requests from the west coast cloud region to the east coast to help us have multi-region redundancy in our ELBs for our critical domains. Stay tuned for a tech blog post about our Isthmus initiative.
Zuul OSS
Today, we are open sourcing Zuul as a few different components:
zuul-core — A library containing a set of core features.
zuul-netflix — An extension library using many Netflix OSS components:
- Servo for insights, metrics, monitoring
- Hystrix for real time metrics with Turbine
- Eureka for instance discovery
- Ribbon for routing
- Archaius for real-time configuration
- Astyanax for and filter persistence in Cassandra
zuul-filters — Filters to work with zuul-core and zuul-netflix libraries
zuul-webapp-simple — A simple example of a web application built on zuul-core including a few basic filters
zuul-netflix-webapp — A web application putting zuul-core, zuul-netflix, and zuul-filters together.
Netflix OSS libraries in Zuul
Putting everything together, we are also providing a web application built on zuul-core and zuul-netflix. The application also provides many helpful filters for things such as:
- Weighted load balancing to balance a percentage of load to a certain server or cluster for capacity testing
- Request debugging
- Routing filters for Apache HttpClient and Netflix Ribbon
- Statistics collecting
We hope that this project will be useful for your application and will demonstrate the strength of our open source projects when using Zuul as a glue across them, and encourage you to contribute to Zuul to make it even better. Also, if this type of technology is as exciting to you as it is to us, please see current openings on our team: jobs
- Mikey Cohen — API Platform
- Matt Hawthorne — API Platform
2717
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
