百度应用层智能网络演进

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

 

在爆发式增长的情况下，网络接入必须能快速响应各种层面需求，保证用户访问体验流畅。简单来说，在网络接入要做到访问加速、接入高可用、安全防攻击等。而在移动时代的下一幕人工智能时代，万物互联，语音交互……

 

更需要在网络接入时有针对性优化的解决方案。谁拥有快速、稳定、安全网络接入技术，谁才有能力应对起业务增长与服务用户的挑战。云端网络统一接入、网络流量智能调度、终端网络优化组件，是支撑移动与智能时代的网络接入核心技术。

 

1

【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也计划开源贡献自己的一份力量。非常欢迎大家一起共同建设中国自己的网络接入领域开源软件及技术生态。

 

2

【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作为流量管理的行业解决方案。

 

3

【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

 

文中涉及的公有云产品链接：

智能流量管理ITM：

https://cloud.baidu.com/product/itm.html

移动域名解析HTTPDNS：

https://cloud.baidu.com/product/httpdns.html