百度应用层智能网络演进

移动和智能时代的下一个独角兽是谁，大家都在拭目以待。这些年无数案例已经证明，一个独角兽的诞生，不但需要产品上的突破，还有技术上的支撑。在用户爆发式增长的背后，网络接入是极其重要又常常被忽视的一环。

在爆发式增长的情况下，网络接入必须能快速响应各种层面需求，保证用户访问体验流畅。简单来说，在网络接入要做到访问加速、接入高可用、安全防攻击等。而在移动时代的下一幕人工智能时代，万物互联，语音交互……更需要在网络接入时有针对性优化的解决方案。谁拥有快速、稳定、安全网络接入技术，谁才有能力应对起业务增长与服务用户的挑战。云端网络统一接入、网络流量智能调度、终端网络优化组件，是支撑移动与智能时代的网络接入核心技术。

【BFE 篇】- 高效、安全、稳定的统一流量接入

在传统的网络基础设施中，常常使用 F5 等硬件负载均衡设备，实现网络接入的服务发布。前不久 F5 宣布收购 Nginx，这应该是 F5 拥抱开源，以互联网模式面对全球市场的重要布局。

百度经历了 PC 时代、移动时代，正在迎接着智能时代。百度基础技术团队在运维服务的发展和壮大中，逐步打磨出了百度统一前端 BFE（Baidu Front End），实现了网络流量统一接入。

图 1. BFE 流量接入与转发

• 挑战 1：如何快速实现各种新功能并进行优化，快速满足业务定制化需求

快速满足需求的首要原则就是开发用时短。BFE 基于 Go 语言开发，新功能开发快、发布周期短，作为接入层开发极为合适。BFE 团队自 2014 年起使用 Go 语言开发 BFE，服务保持每 2 周一个迭代的速度，不断演化更新。在有限人力的情况下，BFE 高效交付 WAF/HTTP2/限流/IPv6 等多项重要功能，并稳定提供服务；在百度春晚活动中，BFE 承接了百度摇一摇活动流量，在仅仅不到一个月的时间里，实现了对应的活动逻辑。在春晚活动峰值时，BFE 稳定处理了海量用户请求，同时极大程度降低了对后端的服务压力，避免了用户流失。

• 挑战 2：如何低成本的提供更高性能、更安全的 HTTPS 接入能力

HTTPS 已成为网络接入的标配协议。由于硬件负载均衡设备价格昂贵，扩展性和灵活性不足。需要解决性能与成本之间的矛盾，提供扩展性与安全的最优方案。

BFE 使用独立加速卡服务集群模式，既保障了性能又提供了较好的扩展能力，整机群成本远低于购买同类硬件设备成本；

同时，BFE 基于内存安全语言，避免了 OpenSSL 广为人知内存泄露安全风险；BFE 在证书私钥安全方面提供专利保护方案；BFE 提供包括 PCI 兼容在内的多安全等级，灵活满足业务安全性需求。

• 挑战 3：如何降低运维人力成本，同时保障稳定性与快速响应

BFE 提供可视化自助操作和控制的平台。提供配置分级发布降低变更风险。新策略可在 1 分钟实现生效并保障一致性。

同时 BFE 还提供实时多维度数据分析，可展示网络、BFE 接入集群、业务后端集群及所承载的业务流量情况，并支持自动异常检测，为运维判断决策提供全面详尽的信息。

图 2. BFE 平台仪表盘示意图

到目前为止，BFE 日处理请求达万亿级别，是业界最大规模的统一接入服务之一。同时，BFE 为互联网、金融企业提供完整的私有化解决方案。

以开源贡献社区，也是百度技术价值体现的重要方式，在技术的不断的挑战演进中， BFE 也计划开源贡献自己的一份力量。非常欢迎大家一起共同建设中国自己的网络接入领域开源软件及技术生态。

【GTC 篇】- 面向极致并发、用户体验的全局负载均衡

全局负载均衡用来解决多个机房之间的负载均衡、故障容错问题。当前市面上的全局负载均衡方案，提供了加权轮询、地理位置映射、最佳性能等流量分配方案；此外，这些解决方案也提供容灾能力，如果发现某个机房不可访问，则自动将流量切换到备用机房，恢复服务可用性。但是，对于当前这个追求极致并发和用户体验的时代，这些解决方案存在非常明显的缺陷：

• 缺少对流量的精细调度能力，导致带宽成本居高不下

市面上无论采用哪一种流量分配方案，都缺少实际的流量和带宽数据作为支撑，无法精确控制各个网络入口的实际流量。在缺乏精确调度能力的情况下，为了避免频繁的带宽打满等问题，只有依靠购买远超实际需要的带宽，增加全局的带宽冗余度，这就导致了带宽成本的成倍增加。当流量达到了 T 级别，每 10%的带宽冗余，意味着 100G 的预留带宽，更意味着每月的数百万带宽成本。而实际运作中，带宽冗余度往往高达 50%以上，带来高额的带宽资源浪费。

• 缺少基于实时流量、负载的动态调度能力，导致难以有效应对突发情况

流量和服务能力都不是一成不变的，为此静态的调度方案在突发流量、突发故障等场景下，往往响应延迟，调度处理力不从心。例如春晚期间，百度 APP 摇一摇的流量在数分钟内出现上千倍的增长，而且各个地域的流量分布和常态有极大的变化，依靠静态的流量调度是无法挺过春晚全过程的。故障是另外一个需要考虑实时流量、负载的场景，如果主机房故障，但是备机房的负载率已经达到了 80%，这时只做一个简单的主切备动作，都会导致备机房过载，出现全局性的不可用。

• 缺少用户侧的监控数据，导致无法解决用户访问的质量问题

市面上的方案往往基于本地的、或者是少数自有机房的探测点对服务进行探测，来判断服务的性能和可用性，这种探测并不能反应用户真实的访问体验。用户的实际请求要经过复杂的运营商网络才能到达服务，而运营商网络可能会出现各种问题，例如由于骨干网拥塞，四川用户访问华北节点出现异常，但是访问华东却质量良好。如果只依赖少数监控点，是无法发现这种异常的，常规预案将导致四川用户依然被调度到华北出现流量丢失。

全局流量调度 GTC（Global Traffic Control）是百度自研的全局负载均衡系统，目的是做到全 IDC 流量统一、自动化控制。GTC 当前控制着百度几乎所有的用户交互流量，而且整个运行过程高度自动化，仅在极端大规模故障场景需要人工判断是否执行进一步切换止损还是保守切换。

GTC 基于精确的流量统计和巧妙的调度优化算法，加上细粒度的访问质量数据，将全局流量调度定义成一个针对带宽和用户访问质量的规划问题，有效解决传统全局负载均衡的调度不精确、不实时、不细致的缺陷，如下图所示：

图 3. GTC 调度模型和传统全局负载均衡差异

春晚百度红包活动期间，通过 GTC 的精确调度能力，各个网络入口的负载差控制在 5%以内，并且基于实时流量数据将由于南北用户参与度不同造成的超过 20%的服务峰值负载差降低到 8%以内，充分验证了高精度、动态的调度能力。

从传统的全局负载均衡过渡到量化、实时的控制，有一系列技术上的困难问题需要解决：

• 流量采集的实时性和高可用要求带来的挑战

GTC 基于实时流量数据进行调度，流量数据的实时性和可用性如同生命线一样重要。一旦流量数据采集出现中断或者高延时，直接导致精确的流量负载均衡无法实现。GTC 设计了高度冗余的流量采集系统，充分利用百度的内网链路和机房资源，对流量数据进行多副本、多链路汇聚，保证除非出现了内网孤岛，那么流量数据就可以被正常采集，而内网孤岛可以通过调度手段直接从全局服务中摘除。此外，GTC 将来自 BFE 的流量数据和来自网络设备的流量数据作为相互补充，如果其中一路流量数据出现了中断，基于其中另外一路数据的调度依然能有效控制带宽利用率，避免过载。

• 调度生效慢对于调度精准度造成的挑战

DNS 生效是缓慢的，往往需要 10 分钟才能生效 80%以上。在这种情况下，需要控制策略来保证调度的精准性，否则可能由于 DNS 的生效问题导致入口流量的上下震荡，出现成本升高或者过载。GTC 基于负反馈的方式来控制入口流量逼近预期。GTC 不断基于各个入口流量的实际流量和计算的预期值，评估各个入口上的真实可用资源，将评估出来的可用资源参与下一次计算，以修正调度行为。由于预期流量参与到控制中，GTC 不会向一个入口调度远超预期的流量；而由于实际流量也在调度中起到作用，可以在流量逐渐收敛时，发现不符合预期的生效情况，及时进行动态平衡，精确控制入口带宽。

• 质量、成本的双目标优化对于调度策略设计的挑战

多数情况下，带宽的高质量和低成本是不可兼得的。高质量的带宽往往位于运营商的骨干节点，一般位于在人口密集的大城市，相应的成本也更高。对这个问题的解决来自于我们发现不同的业务对于质量和成本具有不同的权衡方式。对实时性要求极高的业务需要尽可能好的质量，几乎不在乎带宽成本；而大量的日志打点、数据回传类型的业务，则很关注成本问题。GTC 设计了多个等级的质量和成本平衡策略。最高等级的业务总是调度到质量最高的入口，忽略成本问题；而最低等级的业务，总是尽可能使用成本最低的入口，除非出现计费峰值问题或者严重的质量问题。通过业务分级策略，将全局业务作为一个整体取得优化。在完全满足业务方需求的前提下，非常有效的节约了带宽成本。

图 4. 各产品线接入 GTC 前后 MTTA 对比

当前，GTC 服务着百度全部核心产品，实现了全百度流量的统一调度和管理。在对外服务中，提供了公有云产品 ITM 和私有云产品 GTC 作为流量管理的行业解决方案。

【HTTPDNS 篇】- 安全精准的移动域名解析

PC 用户 DNS 解析往往依赖于运营商的 Local DNS 或者公共 DNS。在移动和智能时代，APP 业务可以构建基于 HTTPDNS 的专有 DNS 解析通道，这种模式带来的优势如下：

1. 不依传统的 DNS 解析通道，避免 DNS 劫持、运营商 DNS 故障场景带来的业务损失；

2. 直接基于用户 IP 进行智能解析，避免通常情况下基于运营商 local DNS IP 进行智能解析，对精准度造成的影响；

3. 域名切换场景下，移动端直接从 HTTPDNS 服务端获取解析结果，避免传统 DNS 多级 cache 影响，切换收敛效率更高；

4. 可根据业务需求进行定制化的解析，在解析层面提供更高的可控性。

• 挑战 1：如何针对移动端场景特点制定接入方案

首先，接入 HTTPDNS 需要对移动端网络请求的实现进行改造，在常见各种网络库场景下，将域名解析部分独立出来，解决 URL 改造、证书校验等一系列适配问题。

其次，综合考虑 HTTPDNS 请求的时延特性，在端上提供适当的 cache 预加载/更新策略，提升 HTTPDNS 覆盖率。

最后，HTTPDNS 基于 HTTPS 协议栈，需考虑服务成本问题，百度 HTTPDNS 方案在接入点、连接、协议、请求层面均针对成本进行了深入的优化。

图 5. HTTPDNS 应用策略示意图

• 挑战 2：如何极致优化域名解析精度？

对于托管在百度云的域名，HTTPDNS 能够直接根据用户 IP 返回权威解析结果，这是最精准的情况。

对于第三方域名，百度 HTTPDNS 提供了一套广泛分布的递归集群，尽可能的模拟真实用户，基于 EDNS 协议从权威服务器获取最优解析结果。

图 6. HTTPDNS 递归系统示意图

总结

在实际的业务应用中，HTTPDNS 和 GTC 配合是绝佳的对移动端流量自动控制的解决方案。目前同时支持私有化和公有云两种模式提供服务。

综上，从 PC 时代主要从服务端提升访问质量，到智能调度流量，演进到移动智能时代，将接入控制能力延伸到终端。百度基础技术通过提供完整解决方案，实现了访问全链路优化。

如果您有不同的见解，以及对 BFE 开源有更多建议，希望做进一步技术的交流和咨询，欢迎留言或邮件in-team@baidu.com

本文来源：AIOps 智能运维（微信公众号：AI_Ops）

原文链接：https://mp.weixin.qq.com/s/AmL-g_RmaNRsBdeAazcpuA