[译]NGINX 和 ZooKeeper，动态负载平衡和部署(上)

原文：NGINX and ZooKeeper, Dynamic Load Balancing and Deployments
译者：杰微刊翻译张迪

这篇文章改编自Derek DeJonghe在2015在2015年9月的nginx。conf 上的演讲。

目录

介绍
0:00 引言
2:05 主题
3:03 表演者
3:57 目标

云计算和DevOps的概念
5:06 云和DevOps的概念
5:18 微服务
6:44 微服务的复杂性
7:20 部署更多的服务
7:35 持续部署
8:34 Blue Green
9:33 Blue Green 部署
9:47 Blue Green NGINX部署
10:13 自动缩放
11:24 自动缩放示例
11:33 弹性负载均衡器
13:22 为什么是NGINX ?

ZooKeeper 和 NGINX
14:19 服务发现
14:28 ZooKeeper
17:12 Znode 示例
17:57 如何工作
18:53 节点端
20:58 NGINX 客户端
24:05 Upstream Pools
24:08 应用 x 版本
24:43 Upstream Pools伪代码
24:55 结果
24:59 请求
25:21 向上游请求
26:13 请求的伪代码

成果
26:45 部署
28:48 部署示例
29:42 成果
30:07 前后执行
30:23 影响
30:35 问题

0:00 引言
欢迎，感谢大家今天来听我在nginx.conf上的演讲。我在这里讲的是动态负载平衡和Nginx和Zookeeper部署。我来告诉你，为什么你应该投资于你的流量控制器，并谈论我在日常工作中建立的核心系统。

首先，我是谁？我的名字叫Derek DeJonghe。我是云解决方案架构师和NGINX的爱好者——以至于我的主张已经使NGINX默认了可以在我的组织里上网冲浪和代理。

我注册了亚马逊的网络服务，我为一家名为RightBrain Networks的公司工作。我们是一个高级的咨询合伙人团队，为AWS和Azure托管服务提供商。我们帮助企业迁移到AWS上，以至于通过引入CI / CD和基础设施即代码，如基础设施管理和配置管理，来彻底改变他们的工作流程。

我们通常与SAS系统交易，向世界提供服务，等等。我还为更大的组织提供咨询服务，也为很多较小的组织运行大量的系统。

2:05 主题

所以今天，我们来讲一些主题。我们将简要介绍一下我们正在做这样事情的原因。我们将谈论我们的表演者是谁、我们的目标是什么。我们还要讲一些基本的云概念和DevOps.

我们要谈论一下我关于动态负载平衡的见解。我们也会解释一些微服务和自动缩放的分布式体系结构的困难。

我会详细讲解一下发布代码的流程，在动态基础设施上使用的方法，和如何利用NGINX和服务发现影响这些解决方案。

3:03 表演者

所以我的表演者是谁？表演者是你的最终用户。我们的用户想要什么？他们想要零停机，他们不想为新特性或bug修复等待维护模式，他们当然不希望畸形的请求。

我们的其他表演者是开发软件的团队。他们想花更少的时间去部署。他们希望部署的时候工作更少。他们想花时间做最擅长的事，并让产品发展和前进。

3:57 目标

我们的目标是什么？我们想要自动操作生活指数和代码部署。我们要经常更新。我们要消除冗长部署和部署资源的需要。

你们见过一个堆满零食的战争屋吗？人们连续36个小时坐在那里。我们需要远离。

我们要消除数据中心生产能力过剩的需求。我们想要零服务中断。我们要确保每一个请求被发送到正确的应用服务器和正确的版本。我们也希望动态负载平衡，因为在我的世界里，一切都是建立在云端的；这是一个问题，我夜以继日必须解决的问题。

5:06 云计算和DevOps的概念

让我们了解一下以下包含的几个云和DevOps的概念。

5:18 微服务

随着驱动器来到云端，很多公司都在解耦他们的独立应用程序服务器，发展微服务。这种观念使许多不同的分布式服务共同努力，为您的服务或产品提供支持。

微服务允许你在一个非常细粒度的水平上缩放，这样做可以节省成本，并能让开发人员更简洁地完成工作、更有效地推进。云和微服务在一起就像工程师和咖啡。工程师可能不非得需要他们的咖啡，但有了咖啡，他们的工作会更好一点；这与云和微服务原理是一样的。

能够在细粒度的水平上缩放，也只是说，”好的，我们得到了很多的认证请求；我们需要扩展一个应用程序的一部分，而不是在后台的一些工作，这可能不是在这样的负载情况下。”

6:44 微服务的复杂性

当你在整体环境中部署的时候，微服务肯定会带来一点复杂性。让我们来看一个非常简单的结构，它可能看起来像一个运行通过的包。我们有一个请求，点击我们的web层，返回到NGINX，到我们的API层，最后是我们的数据。

重要的是要注意我在这个特殊的例子所说的数据是Solr碎片：他们是不可变的，它们是静态数据，我们有多个碎片。

这样，我们的包就通过堆栈返回到最终用户那里了。

7:20 部署更多的服务

如果我们有另一个服务或十个服务，你会发现这样会变得多么的复杂。当你想提供零停机和更高可用性得时候，这样部署将会更复杂。

7:35 持续部署

持续交付是一个完全自动化的系统。持续交付可以让你花更少的时间来发布工作，提高你的工作效率，保证版本的可靠性。它能减少你新功能、博客等上市的时间，并能提高你产品的质量。

它增加你的客户满意度，因为你快速修复了那些错误，并以更快的速度发布了那些新功能。我们必须建造作战室时你不必等待部署时间，这有很多人。它给你更多的时间专注于真正重要的事情——提高你的产品。

8:34 Blue Green

所以这个持续部署、零停机时间等的另一个概念是Blue Green部署。这是如今最受欢迎的一种部署形式。这种部署风格可以无缝地将通信量导向一个新版本的应用程序的代码，它运行在不同基础设施上。

无论是DNS或者类似的NGINX的代理，这些部署的支点是通信路由器。这些部署提供零停机时间，如果事情出错还可以切换回旧版本。这降低了工程团队的压力，再次增加了客户满意度。零停机这正是我们所要寻找的。

未完，等续... ...