架构性能优化《服务器负载均衡》

---

架构性能优化《客户端负载均衡》

浅见！浅见! 浅见！ 架构学习笔记第一篇

---

一、服务端负载均衡

1. 中心化节点问题

Nginx/LVS/HaProxy/F5都是服务器端负载均衡技术，服务端负载均衡的问题是会容易形成中心化节点；
以我们常见的Nginx架构为例，通常以一台Nginx反向代理服务器，作为业务服务器的入口以及承担负载均衡的功能。
这种架构在Nginx服务器发生故障后将会导致整个服务器不可用

2. Nginx VIP高可用

在避免Nginx宕机，我们需要搭建高可用Nginx集群，来避免单点故障导致集群不可用。
采用VIP+KeepAlived来搭建，
VIP是一个通过TCP中的ARP协议实现。其原理：

因为ip地址只是一个逻辑地址，在以太网中MAC地址才是真正用来进行数据传输的物理地址。VIP技术就是申请一个IP比如192.168.1.7，在主服务器运行正常时该IP对应的MAC地址不修改，在发生异常后将IP对应的MAC地址改成备服务器。

这种方案只能在局域网内，如果局域网访问不了也还是造成整个服务器不可用

3. Nginx VIP+DNS高可用

DNS域名解析，其核心功能就是将域名(xxx.com)解析成实际的IP地址。一个域名即可绑定多个IP，且有轮询、就近IP访问等功能具体参考阿里的CDN服务，功能强大也是优化系统的重点。

到此系统架构变得十分复杂，但是还有一个问题动态扩容。该架构下如果想要去扩容VIP集群那必须直接操作重启集群配置。

二、客户端负载均衡

1. 客户端负载均衡

客户端持有服务器ip地址，有效去除中心化，但不支持故障转移与动态扩容

2. 改进客户端负载均衡

添加服务器注册活动，该模块可以根据公司已有技术栈选择如：Redis，Zookeeper，Nacos等。通过注册中心提供给客户端获取实时同步可用列表的IP或域名
简单的实现方案：

• Redis的Hash存储，存储服务器的ip、地址(计算最近服务集群)、是否可用、客户端请求失败获取定时刷取列表即可；

3. 演变客户端负载均衡

并非所有公司都使用前沿技术，该想法主要在最简单实现高可用。该方案使用Redis去做简单的记录可用集群(具体看个人实现)，依赖Redis(通常Redis都是集群搭建)。直接客户端获取可用服务列表，剔除了Nginx，实现高可用服务。缺点在于直接暴露的服务器地址。

–eof–