服务负载均衡设计与实践

1. 服务无状态化定义
   1 冗余部署多个模块(进程)完全对等
   2 请求提交到冗余部署的任一模块，处理结果一样
   3 模块不存储业务的上下文信息
   4 仅根据每次请求携带数据进行相应的业务处理

2. 狭义负载均衡
   硬件
   1 F5
   2 A10
   3 Radware
   
   软件
   1 LVS  4层
   2 Nginx 7层
   3 HAProxy 4层或7层
   
   反向代理 VS 正向代理  从用户角度，无感知的是反向代理，比如Nginx，正向代理比如VPN

3. 广义负载均衡
   
   完整的故障处理恢复机制                                   
   1 故障自动发现       -》注册中心
   2 故障服务自动摘除   -》服务熔断机制
   3 请求自动重试
   4 服务恢复自动发现

 

假设：使用zookeeper(Eureka原理基本相似)作为注册中心，监听每个业务模块， ip:port:servicename，每个业务逻辑模块引入zk客户端。

APP和网关使用http通信，一旦进到server端，网关层和业务逻辑层如果使用http短链接，则性能较差，一般使用tcp长连接。默认开启多个长连接加到连接池。

如果某个业务逻辑层挂掉，因为zk客户端和server端建立了心跳，假设每3秒检测一次心跳，一旦zk检测不到心跳，就会将该业务逻辑层踢掉，将tcp连接从连接池踢掉即可。

如果业务逻辑层假死，但是心跳仍在，zk服务器则没办法发现问题。此时，需要使用服务熔断机制(也可以使用Hystrix)，通过网关层来处理。

比如，网关发往业务逻辑层的请求响应结果，可以写到一个队列，然后开启一个线程对队列进行扫描，计算错误比例，如果达到设置的错误比，则将该业务逻辑层节点熔断。

熔断处理：

1 jstack堆栈信息2次+，理论上打印两次(间隔几秒)，堆栈信息应该是不一样的，如果打印2次以上，堆栈信息一致，可能是循环问题导致

2 kill该业务逻辑层节点
3 sleep6秒后重启该服务  ，等待6秒是因为心跳检测时3秒