Upsync，微博开源基于Nginx容器动态流量管理方案 。
Nginx 以其超高的性能与稳定性，在业界获得了广泛的使用，微博的七层就大量使用了 Nginx 。结合 Nginx 的健康检查模块，以及动态 reload 机制，可以近乎无损的服务的升级上线与扩容。这个时候扩容的频次比较低，大多数情况下是有计划的扩容。
Upsync，开发了模块 nginx-upsync-module，它的功能是拉取 consul 的后端 server 的列表，并更新 Nginx 的路由信息。此模块不依赖于任何第三方模块。consul 作为 Nginx 的 db，利用 consul 的 KV 服务，每个 Nginx work 进程独立的去拉取各个 upstream 的配置，并更新各自的路由。
流程图如下：
应用案例：
模块已经应用在微博的各类业务中，下面图表对比分析使用模块前后的 QPS 与耗时变化。
从数据可以得出，reload 操作时造成 nginx 的请求处理能力下降约 10%，Nginx 本身的耗时会增长 50%+。若是频繁的扩容缩容，reload 操作造成的开销会更加明显。
官方商业版对 Nginx plus 支持了 DNS 与 push 版本提供了支持。
在使用过程中因为数据一致性等问题，扩展支持了基于 consul 的 pull 版本。
-
什么是动态负载均衡 传统的负载均衡，如果Upstream参数发生变化，每次都需要重新加载nginx.conf文件,因此扩展性不是很高，所以我们可以采用动态负载均衡，实现Upstream可配置化、动态化，无需人工重新加载nginx.conf。这类似分布式的配置中心 动态负载均衡实现方案 Consul+Consul-template 每次发现配置更改需要raload nginx，重启Nginx。 Co
-
一、Consul 1、作用 服务注册：可能通过API将服务注册到Consul中。 服务发现：可以通过API获取服务的IP和PROT。 故障检测：支持如TCP、HTTP等方式的健康检查机制，从而当服务有故障时自动摘除。 K/V存储：使用K/V存储实现动态配置中心，其使用HTTP长轮询实现变更触发和配置更改。 多数据中心：支
-
一、nginx reload的问题 问题描述 nginx reload是有一定损耗的，如果你使用的是长连接的话，那么当reload nginx时长连接所有的worker进程会进行优雅退出，并当该worker进程上的所有连接都释放时，进程才真正退出。 解决办法 对于社区版nginx目前有三个选择方式： Tengine 的Dyups模块。 微博的Upsync+Consul 实现动态负载均衡。 Open
-
一、说明 nginx一般直接在配置文件里配置upstream即可实现负载均衡，但有些特定的环境下此种方式就显得有些局限性。比如后端服务器无法依据端口占用检查存活的时候；后台动态调整节点的时候；调整节点后不想修改配置文件重启nginx的时候等等。 此文的思路是将配置文件从nginx本地迁移到其他第三方服务上如etcd、consul上，然后时候拉取配置到本地。理论上说任何第三方配置中心都可以实现该功能
-
Consul环境搭建 下载consul_0.7.5_linux_amd64.zip到/usr/local/src目录 cd /usr/local/src wget https://releases.hashicorp.com/consul/0.7.5/consul_0.7.5_linux_amd64.zip 解压consul_0.7.5_linux_amd64.zip 需要先确认是否安装了unzi
-
这一任务演示istio对流量进行镜像复制的能力。流量镜像是一个有力的工具，在业务团队对生产系统进行变更的过程中，这一能力能够有效的降低风险。流量镜像功能可以对实时流量进行复制，将这一副本发送给镜像服务，并把主服务的关键请求路径放到带外。 Mirroring brings a copy of live traffic to a mirrored service and happens out of
-
本任务将演示如何将应用流量逐渐从旧版本的服务迁移到新版本。通过Istio，可以使用一系列不同权重的规则（10%，20%，··· 100%）将流量平缓地从旧版本服务迁移到新版本服务。为简单起见，本任务将采用两步将流量从reviews:v1 迁移到 reviews:v3，权重分别为50%，100%。 开始之前 参照文档安装指南中的步骤安装Istio。 部署BookInfo示例应用程序。 请注意：本文档
-
Pilot负责部署在Istio服务网格中的Envoy实例的生命周期管理。 Pilot架构 如上图所示，Pilot维护了网格中的服务的规范表示，这个表示是独立于底层平台的。Pilot中的平台特定适配器负责适当填充此规范模型。例如，Pilot中的Kubernetes适配器实现必要的控制器来watch Kubernetes API server中pod注册信息、ingress资源以及用于存储流量管理规则
-
缺省情况下，启用了Istio的服务是无法访问外部URL的，这是因为Pod中的iptables把所有外发传输都转向到了Sidecar代理，而这一代理只处理集群内的访问目标。 本节内容会描述如何把外部服务提供给启用了Istio的客户端服务使用，你会学到如何使用Egress规则访问外部服务，或者如何简单的让特定IP范围穿透Istio代理。 开始之前 遵循安装指南设置Istio 启动sleep示例，用于测
-
本文中的这一任务展示了弹性应用的熔断能力。开发人员可以凭借这一能力，来限制因为故障、延迟高峰以及其他预计外的网络异常所造成的影响范围。下面将会演示如何针对连接、请求以及外部检测来进行断路器配置。 开始之前 遵循安装指南设置Istio。 启动httpbin实例作为本任务的后端： kubectl apply -f <(istioctl kube-inject -f samples/httpbin/ht
-
用于展示Isito服务网格的流量路由特性的任务。 配置请求路由。这个任务展示如何基于权重和HTTP header配置动态请求路由。 故障注入。这个任务展示如何注入延迟并测试应用的弹性。 流量转移。这个任务展示如何将服务的流量从旧版本转移到新版本。 设置请求超时。这个任务展示如何使用Istio在Envoy中设置请求超时。 Istio Ingress控制器。描述如何在Kubernetes上配置Isti
-
本页概述了Istio中流量管理的工作原理，包括流量管理原则的优点。本文假设你已经阅读了 Istio是什幺？并熟悉Istio的高级架构。有关单个流量管理功能的更多信息，您可以在本节其他指南中了解。 Pilot和Envoy Istio流量管理的核心组件是Pilot，它管理和配置部署在特定Istio服务网格中的所有Envoy代理实例。它允许您指定在Envoy代理之间使用什幺样的路由流量规则，并配置故障恢
-
概述:概述Istio中的流量管理及其功能。 Pilot：引入Pilot，负责在服务网格中管理Envoy代理的分布式部署的组件。 请求路由：描述在Istio服务网格中服务之间如何路由请求。 发现和负载均衡:描述在网格中的服务实例之间的流量如何负载均衡。 处理故障: Envoy中的故障恢复功能概述，可以被未经修改的应用程序来利用，以提高鲁棒性并防止级联故障。 故障注入: 介绍系统故障注入的概念，可用于