标签 - 流量管理
编者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文由姚四芳在高可用架构群分享。转载请注明来自高可用架构公众号「 ArchNotes 」。
姚四芳，新浪微博高级技术专家，微博平台架构组技术负责人。2012 年加入新浪微博，参与微博 Feed 架构升级，平台服务化改造，混合云等多个重点项目，现任微博平台架构组技术负责人，负责平台公共基础组建的研发工作。曾在 QCon 进行《新浪微博高性能架构》技术分享，专注高性能架构及服务中间件方向。
Nginx 使用的业务背景与问题
Nginx 以其超高的性能与稳定性，在业界获得了广泛的使用，微博的七层就大量使用了 Nginx 。结合 Nginx 的健康检查模块，以及动态 reload 机制，可以近乎无损的服务的升级上线与扩容。这个时候扩容的频次比较低，大多数情况下是有计划的扩容。
微博的业务场景有非常显著的峰值特征。既有例行的晚高峰，也有像元旦、春晚、红包飞这样的预期内的极端流量峰值。更有#周一见# #我们#等明星/社会事件引发的偶发峰值。之前通常的做法就是 buffer + 降级。在不考虑降级时（会影响用户体验）buffer 小了无法承担峰值大了则成本无法承受。因此，从 2014 年开始，就在尝试利用容器化来实现 buffer 的动态调整，从而实现依据流量对 buffer 按需扩/缩容，以节省成本开销。
在这种场景下，会有持续的大量的扩/缩容操作。业界基于 Nginx 的 backend 变更有两种常用的解决方案。一种是 Tengine 提供的基于 DNS 的，一种是基于 consul-template 的 backend 服务发现。下面的表格简单对比了两种方案的特点。
基于 DNS : 该模块由 Tengine 团队开发，可以动态的解析 upstream conf 下的域名。这种方式操作简单，只要修改 dns 下挂载的 server 列表便可。
缺点:
DNS 定期轮询解析 ( 30s )，若配置的时间过短如 1s，则对 DNS server 形成压力，配置的时间过长，则时效性会受影响。
基于 DNS 的服务下面不能挂过多的 server，会发生截断 ( UDP 协议 )，也会对带宽造成压力。
基于 consul-template 与 consul : 作为一个组合，consul 作为 db，consul-template 部署于 Ng