微服务弹性伸缩与负载均衡
 
微服务如何实现弹性伸缩
 
云帮的应用弹性伸缩有不同的层次、类型及形式，且进行伸缩操作对用户是无影响的，服务不会有任何的中断（平滑伸缩）。由于平台是基于容器技术的，因此伸缩的最小粒度是容器。 
 下面分别从三个不同的伸缩角度来介绍一下：
 
1) 不同层面的伸缩
 
应用级别伸缩：这个层次的伸缩是针对应用的，也就是说我可以针对应用进行实 
 例个数以及每个实例的资源进行伸缩调整。但如果云帮的资源池不够用了，就会触发 
 IaaS 层的伸缩。
 
IaaS 层的资源池的伸缩：这个层次的伸缩不会主动触发，都是通过接受云帮的请 
 求来完成的。举个例子来说明：如果用户的 web 服务想从 10 个节点扩容到 1000 个节 
 点，这时候云帮会先分析资源池的资源是否够用，如果不够用就会调用 IaaS 层的接口 
 创建虚拟机，并将虚拟机的资源加入到云帮的资源池中。
 
2) 不同类型的伸缩
 
水平伸缩：可以分别针对有状态和无状态的服务进行水平分割。无状态服务只是简单的扩容节点。有状态的服务是针对集群或者分片进行的伸缩。后文会针对zookeeper 进行演示。
 
垂直伸缩：单纯的伸缩一个节点的资源数量，如：内存
 
混合伸缩： 可以对应用同时进行水平和垂直伸缩
 
3) 不同种形式的伸缩
 
自动伸缩：可以通过配置自动伸缩的条件来实现自动伸缩，如单个实例的内存超过90%或者CPU使用连续3分钟超过 100% 就进行扩容 1 倍的节点数。
 
手动伸缩：可以通过手动调节实例和资源进行手动伸缩。
 
微服务如何实现负载均衡
 
摘要：面对大量用户访问、高并发请求，海量数据，可以使用高性能的服务器、大型数据库，存储设备，高性能Web服务器，采用高效率的编程语言比如(Go,Scala)等，当单机容量达到极限时，我们需要考虑业务拆分和分布式部署，来解决大型网站访问量大，并发量高，海量数据的问题。
 
从单机网站到分布式网站，很重要的区别是业务拆分和分布式部署，将应用拆分后，部署到不同的机器上，实现大规模分布式系统。分布式和业务拆分解决了，从集中到分布的问题，但是每个部署的独立业务还存在单点的问题和访问统一入口问题，为解决单点故障，我们可以采取冗余的方式。将相同的应用部署到多台机器上。解决访问统一入口问题，我们可以在集群前面增加负载均衡设备，实现流量分发。
 
负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。
 
1. 负载均衡原理
 
系统的扩展可分为纵向（垂直）扩展和横向（水平）扩展。纵向扩展，是从单机的角度通过增加硬件处理能力，比如CPU处理能力，内存容量，磁盘等方面，实现服务器处理能力的提升，不能满足大型分布式系统（网站），大流量，高并发，海量数据的问题。因此需要采用横向扩展的方式，通过添加机器来满足大型网站服务的处理能力。比如：一台机器不能满足，则增加两台或者多台机器，共同承担访问压力。这就是典型的集群和负载均衡架构，如下图：
 
[负载均衡_负载均衡].png
 
常见的负载均衡方案：
 
 
 
应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理，并返回相应数据。 
 负载均衡设备：将用户访问的请求，根据负载均衡算法，分发到集群中的一台处理服务器。（一种把网络请求分散到一个服务器集群中的可用服务器上去的设备）
 
 
负载均衡的作用（解决的问题）：
 
（1）解决并发压力，提高应用处理性能（增加吞吐量，加强网络处理能力）；
 
（2）提供故障转移，实现高可用；
 
（3）通过添加或减少服务器数量，提供网站伸缩性（扩展性）；
 
（4）安全防护（负载均衡设备上做一些过滤，黑白名单等处理）；
 
2. 负载均衡分类
 
根据实现技术不同，可分为DNS负载均衡，HTTP负载均衡，IP负载均衡，链路层负载均衡等。
 
2.1 DNS负载均衡
 
最早的负载均衡技术，利用域名解析实现负载均衡，在DNS服务器，配置多个A记录，这些A记录对应的服务器构成集群。大型网站总是部分使用DNS解析，作为第一级负载均衡。如下图：
 
[负载均衡DNS].png 
 
优点：
 
（1）使用简单：负载均衡工作，交给DNS服务器处理，省掉了负载均衡服务器维护的麻烦；
 
（2）提高性能：可以支持基于地址的域名解析，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能；
 
缺点：
 
（1）可用性差：DNS解析是多级解析，新增/修改DNS后，解析时间较长；解析过程中，用户访问网站将失败；
 
（2）扩展性低：DNS负载均衡的控制权在域名商那里，无法对其做更多的改善和扩展；
 
（3）维护性差：也不能反映服务器的当前运行状态；支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）
 
实践建议：
 
将DNS作为第一级负载均衡，A记录对应着内部负载均衡的IP地址，通过内部负载均衡将请求分发到真实的Web服务器上。一般用于互联网公司，复杂的业务系统不合适使用。如下图：
 
[负载均衡DNS2].png
 
2.2 IP负载均衡
 
在网络层通过修改请求目标地址进行负载均衡。
 
用户请求数据包，到达负载均衡服务器后，负载均衡服务器在操作系统内核进程获取网络数据包，根据负载均衡算法得到一台真实服务器地址，然后将请求目的地址修改为，获得的真实ip地址，不需要经过用户进程处理。
 
真实服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器，再将数据包源地址修改为自身的ip地址，发送给用户浏览器。如下图：
 
[负载均衡IP方式].png
 
IP负载均衡，真实物理服务器返回给负载均衡服务器，存在两种方式：
 
（1）负载均衡服务器在修改目的ip地址的同时修改源地址。将数据包源地址设为自身盘，即源地址转换（snat）。
 
（2）将负载均衡服务器同时作为真实物理服务器集群的网关服务器。
 
优点：
 
（1）在内核进程完成数据分发，比在应用层分发性能更好；
 
缺点：
 
（1）所有请求响应都需要经过负载均衡服务器，集群最大吞吐量受限于负载均衡服务器网卡带宽；
 
2.3 链路层负载均衡
 
在通信协议的数据链路层修改mac地址，进行负载均衡。
 
数据分发时，不修改ip地址，只修改目标mac地址，配置真实物理服务器集群所有机器虚拟ip和负载均衡服务器ip地址一致，达到不修改数据包的源地址和目标地址，进行数据分发的目的。
 
实际处理服务器ip和数据请求目的ip一致，不需要经过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。也称为直接路由模式（DR模式）。如下图：
 
[负载均衡DR模式].png
 
优点：性能好
 
缺点：配置复杂
 
 
 
实践建议：DR模式是目前使用最广泛的一种负载均衡方式。
 
 
2.4 混合型负载均衡
 
由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异，可以考虑给每个服务器群采用最合适的负载均衡方式，然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务（即把这多个服务器群当做一个新的服务器群），从而达到最佳的性能。将这种方式称之为混合型负载均衡。
 
此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。是目前大型互联网公司，普遍使用的方式。
 
方式一，如下图：
 
[负载均衡_混合模式].png
 
以上模式适合有动静分离的场景，反向代理服务器（集群）可以起到缓存和动态请求分发的作用，当时静态资源缓存在代理服务器时，则直接返回到浏览器。如果动态页面则请求后面的应用负载均衡（应用集群）。
 
方式二，如下图：
 
[负载均衡_混合模式].png
 
以上模式，适合动态请求场景。因混合模式，可以根据具体场景，灵活搭配各种方式，以上两种方式仅供参考。
 
3. 负载均衡算法
 
常用的负载均衡算法有：轮询，随机，最少链接，源地址散列，加权等方式；
 
3.1 轮询
 
将所有请求，依次分发到每台服务器上，适合服务器硬件同相同的场景。
 
 
 
优点：服务器请求数目相同； 
 缺点：服务器压力不一样，不适合服务器配置不同的情况；
 
 
3.2 随机
 
请求随机分配到各个服务器。
 
 
 
优点：使用简单 
 缺点：不适合机器配置不同的场景
 
 
3.3 最少链接
 
将请求分配到连接数最少的服务器（目前处理请求最少的服务器）。
 
 
 
优点：根据服务器当前的请求处理情况，动态分配； 
 缺点：算法实现相对复杂，需要监控服务器请求连接数；
 
 
3.4 Hash（源地址散列）
 
根据IP地址进行Hash计算，得到IP地址。
 
 
 
优点：将来自同一IP地址的请求，同一会话期内，转发到相同的服务器；实现会话粘滞。 
 缺点：目标服务器宕机后，会话会丢失；
 
 
3.5 加权
 
在轮询，随机，最少链接，Hash等算法的基础上，通过加权的方式，进行负载服务器分配。
 
 
 
优点：根据权重，调节转发服务器的请求数目； 
 缺点：使用相对复杂；
 
 
4. 硬件负载均衡
 
采用硬件的方式实现负载均衡，一般是单独的负载均衡服务器，价格昂贵，一般土豪级公司可以考虑，业界领先的有两款，F5和A10。
 
使用硬件负载均衡，主要考虑一下几个方面：
 
（1）功能考虑：功能全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡；
 
（2）性能考虑：一般软件负载均衡支持到5万级并发已经很困难了，硬件负载均衡可以支持
 
（3）稳定性：商用硬件负载均衡，经过了良好的严格的测试，从经过大规模使用，在稳定性方面高；
 
（4）安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙，防DDOS攻击等安全功能；
 
（5）维护角度：提供良好的维护管理界面，售后服务和技术支持；
 
（6）土豪公司：F5 Big Ip 价格：15w~55w不等；A10 价格：55w-100w不等；
 
缺点：
 
（1）价格昂贵；
 
（2）扩展能力差；
 
一般硬件的负载均衡也要做双机高可用，因此成本会比较高。互联网公司一般使用开源软件，因此大部分应用采用软件负载均衡；部分采用硬件负载均衡。比如某互联网公司，目前是使用几台F5做全局负载均衡，内部使用Nginx等软件负载均衡。
 
5 Ngnix负载均衡
 
Ngnix是一款轻量级的Web服务器/反向代理服务器，工作在七层Http协议的负载均衡系统。具有高性能、高并发、低内存使用等特点。是一个轻量级的Http和反向代理服务器。Nginx使用epoll and kqueue作为开发模型。能够支持高达 50,000 个并发连接数的响应。
 
操作系统：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）
 
开发语言：C
 
 
 
并发性能：官方支持每秒5万并发，实际国内一般到每秒2万并发，有优化到每秒10万并发的。具体性能看应用场景。
 
 
5.1 特点
 
（1）模块化设计：良好的扩展性，可以通过模块方式进行功能扩展。
 
（2）高可靠性：主控进程和worker是同步实现的，一个worker出现问题，会立刻启动另一个worker。
 
（3）内存消耗低：一万个长连接（keep-alive）,仅消耗2.5MB内存。
 
（4）支持热部署：不用停止服务器，实现更新配置文件，更换日志文件、更新服务器程序版本。
 
（5）并发能力强：官方数据每秒支持5万并发；
 
（6）功能丰富：优秀的反向代理功能和灵活的负载均衡策略；
 
5.2 功能
 
基本功能：
 
（1）支持静态资源的web服务器。
 
（2）http,smtp,pop3协议的反向代理服务器、缓存、负载均衡；
 
（3）支持FASTCGI（fpm）
 
（4）支持模块化，过滤器（让文本可以实现压缩，节约带宽）,ssl及图像大小调整。
 
（5）内置的健康检查功能
 
（6）基于名称和ip的虚拟主机
 
（7）定制访问日志
 
（8）支持平滑升级
 
（9）支持KEEPALIVE
 
（10）支持url rewrite
 
（11）支持路径别名
 
（12）支持基于IP和用户名的访问控制。
 
（13）支持传输速率限制，支持并发数限制。
 
 
 
Nginx的高并发，官方测试支持5万并发连接。实际生产环境能到2-3万并发连接数。10000个非活跃的HTTP keep-alive 连接仅占用约2.5MB内存。三万并发连接下，10个Nginx进程，消耗内存150M。淘宝tengine团队测试结果是“24G内存机器上，处理并发请求可达200万”。
 
 
5.3 架构
 
5.3.1 基本工作模式
 
[5.3.1 基本工作模式].png
 
一个master进程，生成一个或者多个worker进程。但是这里master是使用root身份启动的，因为nginx要工作在80端口。而只有管理员才有权限启动小于低于1023的端口。master主要是负责的作用只是启动worker，加载配置文件，负责系统的平滑升级。其它的工作是交给worker。那么当worker被启动之后，也只是负责一些web最简单的工作，而其他的工作都是有worker中调用的模块来实现的。
 
模块之间是以流水线的方式实现功能的。流水线，指的是一个用户请求，由多个模块组合各自的功能依次实现完成的。比如：第一个模块只负责分析请求首部，第二个模块只负责查找数据，第三个模块只负责压缩数据，依次完成各自工作。来实现整个工作的完成。
 
他们是如何实现热部署的呢？其实是这样的，我们前面说master不负责具体的工作，而是调用worker工作，他只是负责读取配置文件，因此当一个模块修改或者配置文件发生变化，是由master进行读取，因此此时不会影响到worker工作。在master进行读取配置文件之后，不会立即的把修改的配置文件告知worker。而是让被修改的worker继续使用老的配置文件工作，当worker工作完毕之后，直接当掉这个子进程，更换新的子进程，使用新的规则。
 
5.3.2 sendfile机制
 
Sendfile机制，用户将请求发给内核，内核根据用户的请求调用相应用户进程，进程在处理时需要资源。此时再把请求发给内核（进程没有直接IO的能力），由内核加载数据。内核查找到数据之后，会把数据复制给用户进程，由用户进程对数据进行封装，之后交给内核，内核在进行tcp/ip首部的封装，最后再发给客户端。这个功能用户进程只是发生了一个封装报文的过程，却要绕一大圈。因此nginx引入了sendfile机制，使得内核在接受到数据之后，不再依靠用户进程给予封装，而是自己查找自己封装，减少了一个很长一段时间的浪费，这是一个提升性能的核心点。
 
[5.3.2 sendfile机制].png
 
以上内容摘自网友发布的文章，简单一句话是资源的处理，直接通过内核层进行数据传递，避免了数据传递到应用层，应用层再传递到内核层的开销。
 
目前高并发的处理，一般都采用sendfile模式。通过直接操作内核层数据，减少应用与内核层数据传递。
 
5.3.3 通信模型（I/O复用机制）
 
开发模型：epoll和kqueue。
 
支持的事件机制：kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。
 
支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用数据的数量，错误代码.
 
支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.
 
以上概念较多，大家自行百度或谷歌，知识领域是网络通信（BIO,NIO,AIO）和多线程方面的知识。
 
5.4 均衡策略
 
nginx的负载均衡策略可以划分为两大类：内置策略和扩展策略。内置策略包含加权轮询和ip hash，在默认情况下这两种策略会编译进nginx内核，只需在nginx配置中指明参数即可。扩展策略有很多，如fair、通用hash、consistent hash等，默认不编译进nginx内核。由于在nginx版本升级中负载均衡的代码没有本质性的变化，因此下面将以nginx1.0.15稳定版为例，从源码角度分析各个策略。
 
5.4.1 加权轮询（weighted round robin）
 
轮询的原理很简单，首先我们介绍一下轮询的基本流程。如下是处理一次请求的流程图：
 
[5.4.1加权轮询].png
 
图中有两点需要注意：
 
第一，如果可以把加权轮询算法分为先深搜索和先广搜索，那么nginx采用的是先深搜索算法，即将首先将请求都分给高权重的机器，直到该机器的权值降到了比其他机器低，才开始将请求分给下一个高权重的机器；
 
第二，当所有后端机器都down掉时，nginx会立即将所有机器的标志位清成初始状态，以避免造成所有的机器都处在timeout的状态，从而导致整个前端被夯住。
 
5.4.2 ip hash
 
ip hash是nginx内置的另一个负载均衡的策略，流程和轮询很类似，只是其中的算法和具体的策略有些变化，如下图所示：
 
[5.4.2 ip hash].png
 
5.4.3 fair
 
fair策略是扩展策略，默认不被编译进nginx内核。其原理是根据后端服务器的响应时间判断负载情况，从中选出负载最轻的机器进行分流。这种策略具有很强的自适应性，但是实际的网络环境往往不是那么简单，因此要慎用。
 
5.4.4 通用hash、一致性hash
 
这两种也是扩展策略，在具体的实现上有些差别，通用hash比较简单，可以以nginx内置的变量为key进行hash，一致性hash采用了nginx内置的一致性hash环，可以支持memcache。
 
5.5 场景
 
Ngnix一般作为入口负载均衡或内部负载均衡，结合反向代理服务器使用。以下架构示例，仅供参考，具体使用根据场景而定。
 
5.5.1 入口负载均衡架构
 
[5.5.1 入口负载均衡架构].png
 
Ngnix服务器在用户访问的最前端。根据用户请求再转发到具体的应用服务器或二级负载均衡服务器（LVS）。
 
5.5.2 内部负载均衡架构
 
[5.5.2内部负载均衡].png
 
 
 
LVS作为入口负载均衡，将请求转发到二级Ngnix服务器，Ngnix再根据请求转发到具体的应用服务器。
 
 
5.5.3 Ngnix高可用
 
[5.5.3 Ngnix高可用].png
 
分布式系统中，应用只部署一台服务器会存在单点故障，负载均衡同样有类似的问题。一般可采用主备或负载均衡设备集群的方式节约单点故障或高并发请求分流。
 
Ngnix高可用，至少包含两个Ngnix服务器，一台主服务器，一台备服务器，之间使用Keepalived做健康监控和故障检测。开放VIP端口，通过防火墙进行外部映射。
 
DNS解析公网的IP实际为VIP。
 
6 LVS负载均衡
 
LVS是一个开源的软件，由毕业于国防科技大学的章文嵩博士于1998年5月创立，用来实现Linux平台下的简单负载均衡。LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器。
 
基于IP层的负载均衡调度技术，它在操作系统核心层上，将来自IP层的TCP/UDP请求均衡地转移到不同的服务器，从而将一组服务器构成一个高性能、高可用的虚拟服务器。
 
操作系统：Liunx
 
开发语言：C
 
 
 
并发性能：默认4096，可以修改但需要重新编译。
 
 
6.1 功能
 
LVS的主要功能是实现IP层（网络层）负载均衡，有NAT,TUN,DR三种请求转发模式。
 
6.1.1 LVS/NAT方式的负载均衡集群
 
NAT是指Network Address Translation，它的转发流程是：Director机器收到外界请求，改写数据包的目标地址，按相应的调度算法将其发送到相应Real Server上，Real Server处理完该请求后，将结果数据包返回到其默认网关，即Director机器上，Director机器再改写数据包的源地址，最后将其返回给外界。这样就完成一次负载调度。
 
构架一个最简单的LVS/NAT方式的负载均衡集群Real Server可以是任何的操作系统，而且无需做任何特殊的设定，惟一要做的就是将其默认网关指向Director机器。Real Server可以使用局域网的内部IP(192.168.0.0/24)。Director要有两块网卡，一块网卡绑定一个外部IP地址 (10.0.0.1)，另一块网卡绑定局域网的内部IP(192.168.0.254)，作为Real Server的默认网关。
 
LVS/NAT方式实现起来最为简单，而且Real Server使用的是内部IP，可以节省Real IP的开销。但因为执行NAT需要重写流经Director的数据包，在速度上有一定延迟；
 
当用户的请求非常短，而服务器的回应非常大的情况下，会对Director形成很大压力，成为新的瓶颈，从而使整个系统的性能受到限制。
 
6.1.2 LVS/TUN方式的负载均衡集群
 
TUN是指IP Tunneling，它的转发流程是：Director机器收到外界请求，按相应的调度算法,通过IP隧道发送到相应Real Server，Real Server处理完该请求后，将结果数据包直接返回给客户。至此完成一次负载调度。
 
最简单的LVS/TUN方式的负载均衡集群架构使用IP Tunneling技术，在Director机器和Real Server机器之间架设一个IP Tunnel，通过IP Tunnel将负载分配到Real Server机器上。Director和Real Server之间的关系比较松散，可以是在同一个网络中，也可以是在不同的网络中，只要两者能够通过IP Tunnel相连就行。收到负载分配的Real Server机器处理完后会直接将反馈数据送回给客户，而不必通过Director机器。实际应用中，服务器必须拥有正式的IP地址用于与客户机直接通信，并且所有服务器必须支持IP隧道协议。
 
该方式中Director将客户请求分配到不同的Real Server，Real Server处理请求后直接回应给用户，这样Director就只处理客户机与服务器的一半连接，极大地提高了Director的调度处理能力，使集群系统能容纳更多的节点数。另外TUN方式中的Real Server可以在任何LAN或WAN上运行，这样可以构筑跨地域的集群，其应对灾难的能力也更强，但是服务器需要为IP封装付出一定的资源开销，而且后端的Real Server必须是支持IP Tunneling的操作系统。
 
6.1.3 LVS/DR方式的负载均衡集群
 
DR是指Direct Routing，它的转发流程是：Director机器收到外界请求，按相应的调度算法将其直接发送到相应Real Server，Real Server处理完该请求后，将结果数据包直接返回给客户，完成一次负载调度。
 
构架一个最简单的LVS/DR方式的负载均衡集群Real Server和Director都在同一个物理网段中，Director的网卡IP是192.168.0.253，再绑定另一个IP： 192.168.0.254作为对外界的virtual IP，外界客户通过该IP来访问整个集群系统。Real Server在lo上绑定IP：192.168.0.254，同时加入相应的路由。
 
LVS/DR方式与前面的LVS/TUN方式有些类似，前台的Director机器也是只需要接收和调度外界的请求，而不需要负责返回这些请求的反馈结果，所以能够负载更多的Real Server，提高Director的调度处理能力，使集群系统容纳更多的Real Server。但LVS/DR需要改写请求报文的MAC地址，所以所有服务器必须在同一物理网段内。
 
6.2 架构
 
LVS架设的服务器集群系统有三个部分组成：最前端的负载均衡层（Loader Balancer），中间的服务器群组层，用Server Array表示，最底层的数据共享存储层，用Shared Storage表示。在用户看来所有的应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。
 
LVS的体系架构如图：
 
[LVS的体系架构图].png
 
LVS的各个层次的详细介绍：
 
Load Balancer层：位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。
 
Server Array层：由一组实际运行应用服务的机器组成，Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director Server也可以同时兼任Real Server的角色。
 
Shared Storage层：是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数 据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。
 
从整个LVS结构可以看出，Director Server是整个LVS的核心，目前，用于Director Server的操作系统只能是Linux和FreeBSD，linux2.6内核不用任何设置就可以支持LVS功能，而FreeBSD作为 Director Server的应用还不是很多，性能也不是很好。对于Real Server，几乎可以是所有的系统平台，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。
 
6.3 均衡策略
 
LVS默认支持八种负载均衡策略，简述如下：
 
（1）轮询调度（Round Robin）
 
调度器通过“轮询”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
 
（2）加权轮询（Weighted Round Robin）
 
调度器通过“加权轮询”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
 
（3）最少链接（Least Connections）
 
调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。
 
（4）加权最少链接（Weighted Least Connections）
 
在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
 
（5）基于局部性的最少链接（Locality-Based Least Connections）
 
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接” 的原则选出一个可用的服务器，将请求发送到该服务器。
 
（6）带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
 
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
 
（7）目标地址散列（Destination Hashing）
 
“目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
 
（8）源地址散列（Source Hashing）
 
“源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
 
除具备以上负载均衡算法外，还可以自定义均衡策略。
 
6.4 场景
 
一般作为入口负载均衡或内部负载均衡，结合反向代理服务器使用。相关架构可参考Ngnix场景架构。
 
7 HaProxy负载均衡
 
HAProxy也是使用较多的一款负载均衡软件。HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，是免费、快速并且可靠的一种解决方案。特别适用于那些负载特大的web站点。运行模式使得它可以很简单安全的整合到当前的架构中，同时可以保护你的web服务器不被暴露到网络上。
 
7.1 特点
 
支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
 
配置简单，支持url检测后端服务器状态；
 
做负载均衡软件使用，在高并发情况下，处理速度高于nginx；
 
TCP层多用于Mysql从（读）服务器负载均衡。（对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡）
 
能够补充Nginx的一些缺点比如Session的保持，Cookie引导等工作；
 
7.2 均衡策略
 
支持四种常用算法：
 
（1）roundrobin：轮询，轮流分配到后端服务器；
 
（2）static-rr：根据后端服务器性能分配；
 
（3）leastconn：最小连接者优先处理；
 
（4）source：根据请求源IP，与Nginx的IP_Hash类似。

以前还是小白的时候，总是为服务器的崩溃而感到苦恼。 
 后来学习了负载均衡之后发现源源不够，还能提供更多更完善的服务帮助我们保证网站的稳定性。
 
原理来说我们是通过横向扩展的方式为网站新增业务处理服务器，数据库与业务服务器分离，也可以为数据库做读写分离，文件从业务服务器离出来，单独享用一台服务器。
 
网站压力大的时候我们就横向扩展增加服务器提升处理性能。 但是，我们总不能时时刻刻的都呆在电脑前吧。这时候，我们就需要一个服务来帮助我们管理并监听网站承受的压力。
 
我用户的是阿里云的ECS服务器、RDS数据库、OSS文件存储（做了CDN加速）、SLB负载均衡器。
 
将ECS服务器的ip挂载在SLB服务器下面设置权重等配置信息（SLB可以看成一个请求分发服务器，域名解析的ip更换为SLB 网络分发地址，SLB 根据权重的设置将每次收到请求后会检测目标服务器状态是否正常，正常则将请求交给该服务器处理，否则则将请求交给下一台服务器）。 完成后，我们将n>1台的服务器指向RDS数据库的读写分离地址（RDS读写分离的地址只有一个，服务器通过连上这个地址的服务器后，该地地址的服务器会智能解析该sql 语句是查询还是更新，进而交给设置的读数据库和写数据库处理）。OSS 的域名默认是阿里云域名前缀。但是我们可以通过域名映射将我们自定义域名映射到阿里云OSS 地址域名（这个官网有教程，告诉你怎么设置自定义域名）。
 
上述完成后，我们再在阿里云服务里面添加弹性伸缩服务。弹性伸缩服务需要与负载均衡实例相搭配，它监听的是负载均衡对绑定在它下面服务器的状态监听（也就是SLB实例名称，会给你一个下拉列表选择的）。 
 然后我们需要创建一个系统镜像，该镜像的作用就是：当弹性伸缩服务需要开通新服务器的时候需要这个镜像作为环境。（系统镜像不懂的可以去理解下阿里云里面怎么去生成一个系统镜像）。然后，我们选择弹性伸缩服务开通新一台的服务器所需的配置带宽等信息。就可以了，之后我们进行压力测试。测试结果为：当压力达到一定程度后，弹性伸缩服务自动为我们在SLB负载均衡实例下面添加了新的服务器增强网站处理性能。
 
专业讲解

写作背景
 
随着互联网行业的快速发展，诞生出了许多新兴的业务场景，比如当下比较火爆的网络直播、秒杀抢票、电商抢购、网络游戏等，这些业务场景典型的特点就是高并发、大流量和业务具有波峰波谷，这就要求企业的IT架构具备如下特点：
 流量并发：能够保障平台系统在业务峰值时刻持续稳定运行，客户业务正常访问不受影响；
 
横向扩展：当后端服务器运行负载较高时可以快速横向扩容；
 
负载均衡：不能出现后端服务器“部分忙碌，部分闲置”的情况；
 
无单点故障：能够快速甄别出问题的业务服务器并进行隔离；
 
面对这些需求，传统IT架构很难支撑到位，ZStack云平台的弹性伸缩+负载均衡功能，可以很好的满足高并发场景下云主机的横向扩展、流量负载均衡、自动屏蔽不健康的后端云主机并做到弹性自愈，帮助企业把更多的精力专注业务本身，为企业创造更高价值。
 ZStack弹性伸缩+负载均衡基于VPC路由器实现，用户通过访问VPC路由器提供的虚拟IP来访问后端运行业务的云主机，伸缩策略决定伸缩组中最小/最大云主机数量及弹性扩容和缩容的条件，同时通过健康检查来确认后端云主机的健康状况，以保障客户业务持续稳定的运行。下图是负载均衡和弹性伸缩的示意图：
 
 
（图1 ZStack弹性伸缩+负载均衡逻辑图）
 本文将从以下几个角度介绍如何在实际业务场景中使用ZStack的弹性伸缩和负载均衡功能。
 
一、环境准备
 
VPC路由器/高可用组
 
需要至少一个VPC路由器或者VPC高可用组；负载均衡服务是由ZStack的VPC路由器/VPC高可用组提供的服务，需要先创建VPC路由器或者VPC高可用组，并且确保VPC路由器运行状态正常。
 
 
（图2 ZStack VPC路由器）
 
VPC网络
 
需要至少一个VPC网络（地址段自定义）用于弹性伸缩创建云主机。
 
 
（图3 ZStack VPC网络）
 
云主机镜像
 
需要至少一个镜像用于创建云主机，生产环境中需要把相关业务封装到镜像中并设置开机自启动，通过弹性伸缩出来的云主机业务层也能实现自启动。本次测试环境镜像为Centos7.4，并且封装了Apache服务，在html配置文件中输入ZStack Running。
 
 
（图4 封装了Apahce服务的Centos7.4镜像）
 
二、创建负载均衡
 
创建负载均衡器
 
点击网络服务中的负载均衡器，创建负载均衡器，网络选择公有网络，可以指定IP地址创建或者通过DHCP获取负载均衡器地址，用户通过该公网IP地址来访问后端云主机业务。
 
 
（图5 ZStack负载均衡器）
 2. 创建监听器
 ZStack负载均衡支持四层负载（TCP、UDP）和七层负载（HTTP、HTTPS），创建负载均衡器的时候需要选择相应的协议、端口和负载均衡器。比如公网的80端口负载到内网一组云主机的80端口，实现TCP四层的负载均衡。
 
 
（图6 ZStack负载均衡监听器）
 
三、创建弹性伸缩组
 
创建弹性伸缩组的时候需要定义伸缩组中最小云主机数量、最大云主机数量和起始云主机数量，这些参数需要根据生产环境实际的业务量进行评估，比如在大流量、高并发和波峰波谷的业务场景中，建议把最大云主机数量设置的稍微大一些；选择负载均衡器、监听器以及三层网络。测试环境下最小云主机数量、最大云主机数量和起始云主机数量分别设置为2台、10台和2台。
 选择合适的计算规格和镜像模版，注意模版需要提前封装，一般需要把业务封装进模版并做好开机自启动。
 定义扩容/缩容策略，触发条件支持云主机内存平均使用率和CPU平均使用率两种，通过设置一定的触发条件来自动完成后端云主机的扩容和缩容动作。比如，当后端云主机平均CPU使用率大于70%并且持续1分钟的时候进行扩容，每次新增一个云主机；当后端云主机平均CPU使用率小于30%并持续1分钟的时候进行缩容，每次缩容一台云主机，缩容的时候默认是最新创建的云主机优先删除。
 
 
（图7 创建弹性伸缩策略）
 
 
（图8 创建弹性伸缩策略）
 
 
（图9 创建弹性伸缩策略）
 
 
（图10 创建弹性伸缩策略）
 创建弹性伸缩组，默认是停用状态，需要点击启动。启用后，会按照弹性伸缩组的策略创建云主机。在负载均衡监听器中可以看到云主机的健康状况，并通过访问负载均衡虚拟IP来验证负载均衡效果。
 
 
（图11 启用ZStack弹性伸缩组）
 
 
（图12 通过伸缩组策略创建出来的两台云主机）
 
 
（图13 ZStack负载均衡监听器对云主机健康状况进行检测）
 通过负载均衡虚拟IP访问后端云主机的WEB页面。
 
 
（图14 通过负载均衡VIP访问后端云主机WEB页面）
 
四、验证弹性伸缩效果
 
弹性扩容验证
 对负载均衡后端的云主机运行for i in seq 1 $(cat /proc/cpuinfo |grep "physical id" |wc -l); do dd if=/dev/zero of=/dev/null & done脚本来提升云主机的CPU利用率
 
 
（图15 云主机操作系统中通过top命令打印cpu利用率）
 
 
（图16 通过ZStack UI监控数据来监控云主机CPU变化情况）
 
 
（图17 通过弹性伸缩策略自动创建出来一台云主机）
 负载均衡后端云主机的数量会随着平均CPU使用率的升高增加1个，最终数量上限为伸缩组中规定的最大云主机数量10台。
 2. 弹性缩容验证
 对负载均衡后端的两个云主机执行fg crtl+C ，pkill -9 dd后，云主机CPU的利用率会下降，一段时间后观察弹性缩容的效果。
 
 
（图18 云主机操作系统中通过top命令打印CPU利用率）
 
 
（图 19通过ZStack UI监控数据来监控云主机CPU变化情况，观察弹性伸缩组中云主机数量）
 负载均衡后端云主机的数量会随着平均CPU使用率的下降减少1个，最终数量降至伸缩组规则中规定的最低云主机数量2台。
 用户可以通过查看弹性伸缩记录，以便了解业务云主机流量峰值情况和业务负载情况，方便用户有针对性的调整产品战略。
 
 
（图20 ZStack弹性伸缩组中的伸缩记录）
 另外需要说明的是，云平台在触发弹性扩容和弹性缩容的整个过程中不会影响云主机业务，并且可以优化流量负载，提升用户体验。
 
 
（图21 弹性伸缩过程中通过负载均衡VIP持续访问后端云主机WEB页面效果）
 
结尾
 
ZStack弹性伸缩+负载均衡功能，可以帮助企业优化传统IT架构，通过设置弹性伸缩规则实现横向扩展/减少业务云主机的数量，提升云平台资源整体利用率；ZStack负载均衡支持四层和七层，并且能够做到健康检查，自动隔离不可用的云主机提升业务稳定性和安全性；弹性伸缩+负载均衡可以帮助企业集中精力发展自己的核心业务，最大程度的助力企业创造更广泛的价值！
 
END -

 
 
 
  
 弹性负载均衡（Elastic Load Balance，ELB） 
 
  
  https://support.huaweicloud.com/elb/index.html  
 
  
 
 
  
  弹性负载均衡（Elastic Load Balance，ELB）是将访问流量根据转发策略分发到后端多台弹性云服务器的流量分发控制服务，可以通过流量分发扩展应用系统对外的服务能力，提高应用程序的容错能力。  
 
  
 
 
  
 弹性负载均衡（Elastic Load Balance，简称ELB）是将访问流量根据转发策略分发到后端多台  服务器  的流量分发控制服务。弹性负载均衡可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。 
 
  
   
 
  
 
   
  弹性负载均衡具有以下优势：  
 
   
 高性能 
 集群支持最高1亿并发连接，满足用户的海量业务访问需求。 
 
 高可用 
 采用集群化部署，支持多可用区的同城双活容灾，无缝实时切换。 
 
 灵活扩展 
 根据应用流量自动完成分发，与弹性伸缩服务无缝集成，灵活扩展用户应用的对外服务能力。 
 
 简单易用 
 快速部署ELB，实时生效，支持多种协议、多种调度算法可选，用户可以高效地管理和调整分发策略。 
 
 可靠性 
 仅增强型负载均衡具有，公网私网均支持跨可用区双活容灾，支持一致性Hash，流量分发更均衡。 
 
 运维 
 仅增强型负载均衡具有，支持按监听器粒度监控性能指标，更方便客户业务统计。 
 
   
 
 
   
 
 
   
 弹性负载均衡的类型 
 
   
 弹性负载均衡支持经典型、增强型两种负载均衡。 
 
   
 经典型负载均衡：适用于访问量较小，应用模型简单的web业务。 
 增强型负载均衡：适用于访问量较大的web业务，提供基于域名和URL的路由均衡能力，实现更加灵活的业务转发。 
   
 两者的详细区别请参见  增强型与经典型负载均衡的功能区别  。 
 
  
 
  
 
   
 弹性负载均衡的组件 
 
   
 弹性负载均衡器接受来自客户端的传入流量并将请求转发到一个或多个可用区中的后端  服务器  。 
 
   
 您可以向您的弹性负载均衡器添加一个或多个监听器。监听器使用您配置的协议和端口检查来自客户端的连接请求，并根据您定义的转发策略将请求转发到一个后端服务器组里的后端  服务器  。 
 
   
 每个后端  服务器  组使用您指定的协议和端口号将请求转发到一个或多个后端  服务器  。 
 
   
 您可以开启健康检查功能，对每个后端服务器组配置运行状况检查。当后端某台  服务器  健康检查出现异常时，弹性负载均衡会自动将新的请求分发到其它健康检查正常的后端  服务器  上；而当该后端  服务器  恢复正常运行时，弹性负载均衡会将其自动恢复到弹性负载均衡服务中。 
 
  
 
  
 
     图1   弹性负载均衡组件图    
   

     
  
 
  
 
   
 如何访问弹性负载均衡 
 
   
 可以使用以下方式访问和管理弹性负载均衡： 
 
   
 管理控制台 
 请使用管理控制台方式访问弹性负载均衡。可直接登录管理控制台，从主页选择“弹性负载均衡”。 
 
 查询API 
 通过调用API的方式访问弹性负载均衡，具体操作请参见  《弹性负载均衡API参考》  。 
 
  
 
  
 
 
  
 
 
  
 弹性负载均衡是如何工作的 
 
  
 
 
  
   
 
  
 
   
 您可以在弹性负载均衡服务中创建一个负载均衡器。该负载均衡器会接收来自客户端的请求，并将请求转发到一个或多个可用区的后端  服务器  中进行处理。请求的流量分发与负载均衡器配置的分配策略类型相关。 
 
   
 增强型负载均衡算法，支持以下三种调度算法： 
 
   
 
    
 加权轮询算法：根据后端服务器的权重，按顺序依次将请求分发给不同的服务器。它用相应的权重表示服务器的处理性能，按照权重的高低以及轮询方式将请求分配给各服务器，相同权重的服务器处理相同数目的连接数。常用于短连接服务，例如HTTP等服务。 
 加权最少连接：最少连接是通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法。加权最少连接就是在最少连接数的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权重，使其能够接受相应权值数的服务请求。常用于长连接服务，例如数据库连接等服务。 
 源IP算法：将请求的源IP地址进行Hash运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可以使得对不同源IP的访问进行负载分发，同时使得同一个客户端IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无cookie功能的TCP协议。 
   
 
   

     经典型负载均衡算法，支持以下三种调度算法： 
    
 轮询算法：按顺序把每个新的连接请求分配给下一个服务器，最终把所有请求平分给所有的服务器。常用于短连接服务，例如HTTP等服务。 
 最少连接：通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法，系统把新的连接请求分配给当前连接数目最少的服务器。常用于长连接服务，例如数据库连接等服务。 
 源IP算法：将请求的源IP地址进行Hash运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可以使得对不同源IP的访问进行负载分发，同时使得同一个客户端IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无cookie功能的TCP协议。 
   
 
   
  图1  展示弹性负载均衡器使用加权轮询算法的流量分发流程。假设可用区内有4台权重相同的后端  服务器  ，负载均衡器节点会将25%的客户端流量分发到其可用区中的每一台后端  服务器  。 
 
   
 
      
      
      图1   加权轮询算法流量分发    
    

      
   
 
  
 
  
 
 
  
 
 
  
 
   
 增强型与经典型负载均衡的功能区别 
 
   

   
 
    
 弹性负载均衡有两种不同的负载均衡，分别是增强型负载均衡和经典型负载均衡，便于用户根据不同的应用场景和功能需求选择合适的负载均衡器类型。 
 
    
 经典型负载均衡：适用于访问量较小，应用模型简单的web业务。 
 增强型负载均衡：适用于访问量较大的web业务，提供基于域名和URL的路由均衡能力，实现更加灵活的业务转发。 
    
 增强型负载均衡对比经典型负载均衡，提供了更丰富的HTTP和HTTPS转发能力，同时在转发性能和稳定性上也有较大提升。两者具体的功能差异如  表1  所示。（“√”表示支持，“—”表示不支持。） 
 
    
 
       
       
     
 
        表1   功能对比 
      
 
 功能 
 
 
 经典型负载均衡 
 
 
 增强型负载均衡 
 
 
 支持公网和私网负载均衡 
 
 
 √ 
 
 
 √ 
 
 
 支持四层（TCP/UDP）和七层负载均衡（HTTP/HTTPS） 
 
 
 √（私网类型不支持UDP协议） 
 
 
 √ 
 
 
 支持轮询 /最少连接/源IP 
 
 
 √ 
 
 
 √ 
 
 
 支持会话保持 
 
 
 √ 
 
 
 √ 
 
 
 支持WebSocket协议 
 
 
 √ 
 
 
 √ 
 
 
 支持按域名和URL转发 
 
 
 — 
 
 
 √ 
 
 
 支持HTTP/2 
 
 
 — 
 
 
 √ 
 
 
 支持后端服务器为ECS 
 
 
 √ 
 
 
 √ 
 
 
 支持访问控制（白名单） 
 
 
 — 
 
 
 √ 
 
 
 支持标准OpenStack API 
 
 
 — 
 
 
 √ 
 
 
 支持后端服务器为裸机 
 
 
 — 
 
 
 √ 
 
 
 支持SNI多证书特性 
 
 
 — 
 
 
 √ 
 
 
 支持SSL协议/加密算法可选 
 
 
 √ 
 
 
 — 
 
 
 支持访问日志 
 
 
 — 
 
 
 √ 
 
 
 支持权重 
 
 
 — 
 
 
 √ 
 
 
 支持修改证书内容 
 
 
 — 
 
 
 √ 
 
 
 支持双向认证 
 
 
 — 
 
 
 √ 
 
 
 支持HTTP重定向 
 
 
 — 
 
 
 √ 
 
 
 支持获取弹性公网IP 
 
 
 — 
 
 
 √ 
 
    
 
   
 
  
 
  
 
   

   
 
    
     
 
 公网和私网负载均衡器 
 
 
 
 
      
 
       
 
        
 公网负载均衡器 
 
        
 公网负载均衡器通过公网IP对外提供服务，将来自公网的客户端请求按照指定的负载均衡策略分发到后端  云服务器  进行处理。 
 
        
 对于增强型公网负载均衡，不仅支持公网访问，也支持私网访问。 
 
        
 
           图1   公网负载均衡器    
         

           
        
 
       
 
       
 
        
 私网负载均衡器 
 
        
 私网负载均衡器通过私网IP对外提供服务，将来自同一个VPC的客户端请求按照指定的负载均衡策略分发到后端进行处理。 
 
        
 
           图2   私网负载均衡器    
         

           
        
 
       
 
      
 
    
 
 
    
 
 
    
 应用场景 
 
    

    
   
 
    
 
     
 使用ELB为高访问量业务进行流量分发 
 对于业务量访问较大的业务，可以通过ELB设置相应的转发策略，将访问量均匀的分到多个后端处理。例如大型门户网站，移动应用市场等。 
 
 同时您还可以开启会话保持功能，保证同一个客户请求转发到同一个后端，从而提升访问效率，如  图1  所示。 
 
       
 
          
          
          图1   会话保持流量分发    
        

          
       
 
 使用ELB和AS为潮汐业务弹性分发流量 
 对于存在潮汐效应的业务，结合弹性伸缩服务，可以随时在ELB上添加和移除后端，更好的提升业务的灵活扩展能力，如  图2  所示。例如电商，手游，直播网站等。 
 
       
 
          
          
          图2   灵活扩展    
        

          
       
 
 
 
 使用ELB消除单点故障 
 对于可靠性有较高要求的业务，可以在负载均衡器上添加多个后端  云服务器  。负载均衡器会通过健康检查及时发现并屏蔽有故障的  云服务器  ，并将流量转发到其他正常运行的后端  云服务器  ，确保业务不中断，如  图3  所示。 
 
 例如官网，计费业务，Web业务等。 
 
       
 
          
          
          图3   消除单点故障    
        

          
       
 
 使用ELB跨可用区特性实现业务容灾部署 
 对于可靠性和容灾有很高要求的业务，弹性负载均衡可将流量跨可用区进行分发，建立实时的业务容灾部署。即使出现某个可用区网络故障，负载均衡器仍可将流量转发到其他可用区的后端  云服务器  进行处理，如  图4  所示。 
 
 例如银行业务，警务业务，大型应用系统等。 
 
       
 
          
          
          图4   多可用区部署    
        

          
       
 
    
 
    
 
     
 与其他服务关系 
 
     

     
 
      
 
       
 
          表1   与其他服务之间关系 
        
 
 交互功能 
 
 
 服务名称 
 
 
 相关内容 
 
 
 创建ELB时需要使用虚拟私有云服务创建的弹性公网IP、带宽。 
 
 
 虚拟私有云（Virtual Private Cloud，VPC） 
 
 
  申请弹性公网IP  
 
 
 
 
 当配置了负载均衡服务后，弹性伸缩在添加和移除云服务器时，自动在负载均衡服务中添加和移除云服务器。 
 
 
 弹性伸缩（Auto Scaling，AS） 
 
 
  创建弹性伸缩组  
 
 
 需要统一身份认证提供鉴权。 
 
 
 统一身份认证服务（Identity and Access Management, IAM） 
 
 
  创建用户组并授权  
 
 
 使用云审计服务记录弹性负载均衡服务的资源操作。 
 
 
 云审计服务（Cloud Trace Service，CTS） 
 
 
  查看审计日志  
 
 
 当用户开通了弹性负载均衡服务后，无需额外安装其他插件，即可在云监控查看对应服务的实例状态。 
 
 
 云监控服务（Cloud Eye Service） 
 
 
  查看监控指标  
 
 
 当用户购买了Anti-DDoS服务后，配置了负载均衡器的公网IP，确保了弹性负载均衡服务免受外部攻击，提高安全可靠性。 
 
 
 Anti-DDoS流量清洗服务（Anti-DDoS） 
 
 
  开启Anti-DDoS防护  
 
 
 配置访问日志时需要您对接云日志服务，查看和分析对七层负载均衡HTTP和HTTPS进行请求的详细访问日志记录。 
 
 
 云日志服务（Log Tank Service，LTS） 
 
 
  访问日志  
 
      
 
     
 
     
 
     
 
    
 
    
 
     

     
 
     
 
    
 
    
 
 
   
 
  
 
  
 
 
  
 
 
  
 
 
  
 
 
  
 
 
  
 
 
  

  

  
   About Me   
 
  
 
  ........................................................................................................................  
 
  ● 本文作者：小麦苗，部分内容整理自网络，若有侵权请联系小麦苗删除  
 
  ● 本文在itpub（  http://blog.itpub.net/26736162  ）、博客园（  http://www.cnblogs.com/lhrbest  ）和个人weixin公众号（  xiaomaimiaolhr  ）上有同步更新  
 
  ● 本文itpub地址：  http://blog.itpub.net/26736162   
 
  ● 本文博客园地址：  http://www.cnblogs.com/lhrbest   
 
  ● 本文pdf版、个人简介及小麦苗云盘地址：  http://blog.itpub.net/26736162/viewspace-1624453/   
 
  ● 数据库笔试面试题库及解答：  http://blog.itpub.net/26736162/viewspace-2134706/   
 
  ● DBA宝典今日头条号地址：  http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826   
 
  ........................................................................................................................  
 
  ● QQ群号：  230161599  （满）  、618766405   
 
  ● weixin群：可加我weixin，我拉大家进群，非诚勿扰  
 
  ● 联系我请加QQ好友  （   646634621   ）  ，注明添加缘由  
 
  ● 于 2019-06-01 06:00 ~ 2019-06-30 24:00 在西安完成  
 
  ● 最新修改时间：2019-06-01 06:00 ~ 2019-06-30 24:00  
 
  ● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解  
 
  ● 版权所有，欢迎分享本文，转载请保留出处  
 
  ........................................................................................................................  
 
  ●  小麦苗的微店  ：  https://weidian.com/s/793741433?wfr=c&ifr=shopdetail   
 
  ●  小麦苗出版的数据库类丛书  ：  http://blog.itpub.net/26736162/viewspace-2142121/   
 
  ●  小麦苗OCP、OCM、高可用网络班  ：  http://blog.itpub.net/26736162/viewspace-2148098/   
 
  ●  小麦苗腾讯课堂主页  ：  https://lhr.ke.qq.com/   
 
  ........................................................................................................................  
 
 使用   weixin客户端   扫描下面的二维码来关注小麦苗的weixin公众号（  xiaomaimiaolhr  ）及QQ群（DBA宝典）、添加小麦苗weixin，  学习最实用的数据库技术。  
 
 
 
  ........................................................................................................................  
 
  
  
   
 
  
   
 
  
 
 
  
 
 
  
 
  
 来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26736162/viewspace-2648322/，如需转载，请注明出处，否则将追究法律责任。