从事服务管理、监控、平台可用性建设相关工作。在分布式系统、大规模数据处理、可用性工程方向有广泛的实践经验。
干货概览
在前两篇文章中，我们介绍了内网流量调度解决的核心问题，并以 qproxy 的实际使用场景进行了案例解析。
流量接入层根据从 BNS 获取到的实例和相关配置信息，实现流量调度功能。
本文将重点介绍配置分发和流量调度引擎的实现。
设计目标 – 通用的流量调度逻辑
通用的流量调度逻辑，可以让我们适配尽可能多的流量接入方式。 在实际的使用过程中，我们至少兼容了以下流量接入方式：qproxy、nginx、rpc和其它用户自研的流量接入层。
实现细节
为了降低实现复杂度以及接入成本，我们在 Naming Service 层增加了流量调度引擎的逻辑。
Naming Service 负责配置分发。用户通过 SDK 从本地服务端获取服务单元和实例信息。
上游服务调用 SDK 获取实例列表，请求发给本地服务端，本地服务端通过远程服务端获取到原始实例列表，之后，由流量调度引擎根据原始实例列表和路由表中的路由规则，生成最终返回给 SDK的实例列表。
流量调度引擎
流量调度引擎是一组根据用户使用场景实现的代码，它的功能是参考路由表和其它用户配置，对实例信息进行筛选和重组，最终返回给流量接入层，达到控制流量的目的。
它可以根据用户的需求来自定义功能，例如：
- 参考上游请求的来源机房（可以是物理机房或逻辑机房）和路由表，决定返回上游来源所对应的下游机房中的实例。
- 根据流量接入层类型，在返回的实例列表中增加自定义的标签信息。
路由表
下图是一个实际的路由表，包含逻辑机房和物理机房的映射关系，路由规则，流量配比信息：
- 逻辑机房和物理机房的映射关系：为了便于管理，我们一般会将某个地域的集群，按照逻辑机房的形式进行组织。用来规避物理机房的变更导致流量映射关系的频繁调整。也便于批量配置和运维操作。
- 路由规则和流量配比：路由规则描述了上下游逻辑机房之间的映射关系，还有他们之间的流量配比。
- 流量配比的计算方法：在默认场景下，会根据流量配比计算出对应的实例数量。对于不同的逻辑机房，原始实例数量可能有相当大的差别。因此需要根据流量配比对实例进行补全或抽样。
当然，以上描述的是理想情况。在实际的系统中，还存在实例数上限、按权值返回实例等场景和需求，需要针对这些场景进行处理。限于篇幅，这里不详细展开。
时效性
对于流量调度场景来说，调度生效时间是一个最关键的性能指标。它决定了从流量调度操作发起到流量实际生效之间消耗的时间。
以业务的止损场景为例，生效时间决定了止损操作的速度。更低的生效延迟意味着更快的止损和更低的收入损失。
在实现上，我们选择了推拉结合的方式。即所有变更推送到客户端，并保留轮询服务端作为可用性保障的降级预案。这样，在时效性指标的保障范围内，实现了秒级别的变更延迟。
可用性
流量调度系统包含的配置分发和调度引擎都处于流量接入的核心环节。这部分系统的可靠性直接影响到上下游调用的成功率。
原则上，我们通过冗余的方式，提升系统的整体可用性。在整个服务中，有多层次的缓存。另外，在流量调度引擎方面，我们也实现了按机房的灰度发布，缩小故障的影响范围。
总结
通过以上三篇文章，我们为大家解析了百度内网流量调度系统。这是基于百度复杂的内网结构和多样的业务，综合考虑功能、成本、性能、可用性等指标的一种工程实践。随着DevOps 的不断发展，新的服务框架和方案不断涌现。例如 istio，linkerd 等开源项目都为服务发布、测试、追踪等流量调度的典型场景提供了新的解决方案和思路。我们也将在这个方向上持续探索，后续会有更多的工程应用经验与大家分享。
原文来自微信公众号：AlOps智能运维
本文链接：http://www.yunweipai.com/24982.html