详谈负载均衡（微服务架构下的高可用挑战）

• 微服务架构是由一系列职责单一的细粒度服务构成的分布式网络结构&＃xff0c;服务之间通过轻量级机制进行通信&＃xff0c;这时候必然会引入一个服务注册发现问题&＃xff0c;也就是说服务提供房需要注册通过服务地址&＃xff0c;服务的调用方要能发现目标服务。
• 同时服务提供方一般会以集群的方式提供服务&＃xff0c;也就引入了负载均衡和健康检查的问题。

一、互联网架构发展历程

二、集中式LB服务发现

• 在服务消费者和服务提供者之间有一个独立的LB
• LB上所有的服务的地址的映射表&＃xff0c;通常由运维配置注册
• 当服务消费方调用某个目标服务的时候&＃xff0c;它向LB发起请求&＃xff0c;由LB以某个策略做负载均衡后将请求转发到目标服务
• LB一般具有健康检查能力&＃xff0c;能自动摘除不健康的实例
• 服务消费方通过DNS找到LB
• 集中式主要存在的问题是存在单点故障&＃xff0c;所有流量都走LB&＃xff0c;LB很容易成为瓶颈
  

三、进程内LB服务发现

• 进程内LB方案将LB的功能以库的形式集成到服务消费方的进程里
• 服务注册表配合支持服务的自注册和自发现&＃xff0c;服务提供方启动时&＃xff0c;首先将服务地址注册到服务注册表&＃xff08;同时定期报心跳以表明服务的存活状态&＃xff09;
• 服务消费方要访问某个服务的时候&＃xff0c;它通过内置的LB组件向服务注册表查询目标服务地址列表&＃xff0c;然后以某种负载策略选择目标服务地址
• 这一个方案对服务注册表的可用性要求很高&＃xff0c;一般采用能满足高可用分布式一致组件&＃xff08;zookeeper,consul,etcd&＃xff09;来实现。
• 进程内LB是一种分布式模式&＃xff0c;LB和服务发现能力被分割到每一个服务消费者内部&＃xff0c;同时服务消费方和服务提供方之间是一直调用&＃xff0c;没有额外开销&＃xff0c;性能较好。该方案以客户库(Client Library)的方式集成到服务调用方进程里头&＃xff0c;如果企业内有多种不同的语言栈&＃xff0c;就要配合开发多种不同的客户端&＃xff0c;有一定的研发和维护成本。
• 一旦客户端跟随服务调用方发布到生产环境中&＃xff0c;后续如果要对客户库进行升级&＃xff0c;势必要求服务调用方修改代码并重新发布&＃xff0c;所以该方案的升级推广有不小的阻力。
  

四、独立LB进程服务发现

• 针对进程内LB模式不足的情况的一种折中方案
• 与上个方案的不同之处&＃xff0c;将LB和服务发现功能从进程内拆出来&＃xff0c;变成主机上的一个独立进程&＃xff0c;主机上的一个或是多个服务要访问目标服务的时候&＃xff0c;他们都通过同一个主机上的独立的LB进程做服务发现或是负载均衡
• LB独立进程可以进一步同消费服务能力解耦&＃xff0c;以独立集群的方式来提供负载均衡的能力
• 可以称为真正的软负载
• 该方案也是一种分布式方案&＃xff0c;没有单点问题&＃xff0c;一个LB进程挂了只影响该主机上的服务调用方
• 服务调用方和LB之间是进程内调用&＃xff0c;性能好。
• 同时&＃xff0c;该方案还简化了服务调用方&＃xff0c;不需要为不同语言开发客户库&＃xff0c;LB的升级不需要服务调用方改代码。
  

五、负载均衡

• 系统的扩展分为垂直扩展和水平扩展
  &＃x1f525; 横向&＃xff1a;优雅终止&＃xff0c;优雅启动
  &＃x1f525; 纵向&＃xff1a;从单机角度增加硬件处理能力
• 负载均衡的作用&＃xff08;解决问题&＃xff09;
  &＃x1f37a; 并发压力
  &＃x1f37a; 故障转移
  &＃x1f37a; 通过增加或是减少服务&＃xff0c;提高服务的伸缩性
  &＃x1f37a; 安全防护&＃xff1a;白名单

&＃xff08;1&＃xff09;DNS负载均衡

最早的负载均衡技术&＃xff0c;利用域名解析实现负载均衡&＃xff0c;在DNS服务器&＃xff0c;配置多个A记录&＃xff0c;这些A记录对应的服务器构成集群。

&＃xff08;2&＃xff09;负载均衡技术&＃xff08;类比LVS&＃xff09;

【1】NAT&＃xff08;网络地址转换&＃xff09;

网络地址转换通常是通过修改数据包的源地址或目标地址来控制数据包的转发行为。

【2】新建TCP连接&＃xff08;NAT的优化&＃xff09;

为记录原始客户端ip地址&＃xff0c;负载均衡功能不仅需要进行数据包的源目标地址修改&＃xff0c;同时要记录原始客户端IP地址&＃xff0c;基于简单的NAT无法满足此需求&＃xff0c;于是衍生出了基于传输层协议的负载均衡的另一种方案—TCP/UDP Termination方案

【3】DR&＃xff08;直接路由&＃xff0c;链路层负载均衡&＃xff09;

• 在通信协议的数据链路层修改MAC地址进行负载均衡
• 数据分发的时候&＃xff0c;不修改IP地址&＃xff0c;修改目标MAC地址&＃xff0c;配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致&＃xff0c;达到不需改数据包的源地址和目标地址&＃xff0c;进行数据分发的目的。
• 实际处理服务器IP和数据请求目的IP一致。不需要经过负载均衡服务器进行地址转换&＃xff0c;可将响应数据包直接返回给用户浏览器&＃xff0c;可以有效避免负载均衡器网卡称为瓶颈&＃xff0c;也称为直接路由&＃xff08;DR模式&＃xff09;

【4】TUN&＃xff08;隧道技术&＃xff09;

• 负载均衡中常用的是隧道技术是IP over IP&＃xff0c;其原理是保持原始数据包IP头不变&＃xff0c;在IP头外层增加额外的IP包头后转发给上游服务器。额外IP包头肯定是 源负载均衡器ip -> 上游服务器实际网卡IP
• 上游服务器接受IP数据包&＃xff0c;解开外层IP包头后&＃xff0c;剩下的是原始数据包
• 同样的&＃xff0c;原始数据包中的目标IP地址&＃xff08;负载均衡器的IP&＃xff09;要配置在上游服务器中某个虚拟网卡上&＃xff0c;上游服务器处理完数据请求后&＃xff0c;响应包通过这个虚拟网卡到达网关&＃xff0c;网关直接返回给客户端。