LoadBalancing

负载均衡

什么是负载均衡

1. Load balancing refers to efficiently distributing incoming network traffic across a group of backend servers, also known as a server farm or server pool.
2. 通俗来说就是后端服务往往host在多个服务器中，当我们收到大量client发送来的请求时，我们使用load balancer来管理流量，使得请求可以均匀的发送给所有的服务器。我们经常说的反向代理服务器(也就是代理在服务器这一端)的一个很重要的功能就是负载均衡(当然还有其他功能比如缓存，安全保障)。
3. 其实负载均衡一个最著名的用处就是DNS服务器，世界上所有的DNS服务器都会起到负载均衡的作用，但由于DNS服务器的更新可能很慢，所以往往DNS的负载均衡只作为负载均衡的第一步，后面我们还是会使用自己的负载均衡服务器

Layer 4 load balancer vs Layer 7 load balancer

1. 负载均衡器一般分为两种，Layer 4 load balancer和Layer 7 load balancer。Layer 4指的是OSI模型的第四层传输层，也就是说负载均衡器根据TCP/UDP segment进行请求的转发；Layer 7指的是OSI模型的第七层应用层，也就是说负载均衡器根据HTTP/HTTPS message进行请求的转发。
2. Layer 4 load balancer见图： https://github.com/ShiyuLiuColumbia/diagram/blob/main/Layer4LoadBalancing.drawio.png
3. 第四层的负载均衡器是通过转发TCP/UDP segment来达到分发请求的目的的，本质上是通过NAT改写IP datagram header的IP地址以及TCP/UDP segment header的destination port来达到目的的，其原理与我们家用路由器是类似的。由于负载均衡器只起到转发的作用，所以从client到server端我们只建立了一次TCP连接(图中红线)。
4. Layer 4负载均衡器的优点是：1.原理简单 2.高效，因为负载均衡器不会去解析应用层的信息，只需要根据TCP/IP的header进行转发就好了 3.安全，后面的Layer 7负载均衡器中会讲到，假设我们使用的是HTTPS协议，那么我们需要在负载均衡器中对HTTPS消息进行解密，一旦有中间人入侵我们的负载均衡器，那么消息就会被监听 4.Only one TCP connection 缺点是：1.No smart load balancing，由于我们不查看应用层的消息，我们不能根据消息本身对请求的转发进行抉择 2.Sticky per segment，某些HTTP请求可能很大，需要被分成很多的TCP segment，对于这样的请求，Layer 4负载均衡器必须有能力判断他们属于同一个请求，并且被发送到同一台主机上 3.No caching，对于Layer 7的负载均衡器，我们可以对请求进行缓存，比如处理过的HTTP请求缓存在负载均衡器中，当有客户再次请求的时候，直接返回即可，但是Layer 4无法做到这一点
5. Layer 7 load balancer见图：https://github.com/ShiyuLiuColumbia/diagram/blob/main/Layer7LoadBalancing.drawio.png
6. 第七层的负载均衡器是通过转发HTTP/HTTPS message来达到分发请求的目的的，由于我们要检查HTTP/HTTPS请求的具体信息，我们需要建立两次TCP连接，一次是从client到负载均衡器的，一次是从负载均衡器到server的
7. Layer 7负载均衡器的优点是：1.Smart load balancing 2.Caching 3.Great for microservice 缺点是：1.Two TCP connection 2.Expensive(looks at data) 3.如果client使用的是HTTPS协议的话，那么我们需要进行解密(TLS termination)，我们的负载均衡器中需要存有可信任的证书

负载均衡算法

1. 最常用的算法是轮训(round robin)和最小连接数(Least connections)。在亚麻内部，HTTP/HTTPS负载均衡器推荐使用最小连接数算法，因为这个最小连接数的判断是根据HTTP请求来的，每当有新的请求到来的时候，负载均衡求都会把它打到目前HTTP/HTTPS连接最少的服务器。但是对于TCP负载均衡器，使用最小连接数并不推荐，因为这里的连接不再是HTTP/HTTPS连接，而是TCP连接，一台服务器可能建立了大量TCP连接，但其中很多都是空闲的，所以亚麻并不推荐使用最小连接数算法，而是推荐使用轮训。
2. 其他算法还包括诸如完全随机，加权轮训，加权最小连接数等

应用

1. 公司中的实际应用见图：https://github.com/ShiyuLiuColumbia/diagram/blob/main/LoadBalancerInProject.drawio.png
2. 可以看到，load balancer 1和load balancer 3都是用来处理HTTPS请求的，但是load balancer使用的协议是不一样的。load balancer 1使用的是Layer 7 load balancer并且使用TLS加密，所以请求是可以均匀的打到三台服务器上的(使用的算法是least connections)，但是公司不推荐这种做法，因为在load balancer中使用TLS存在很多的问题。load balancer 3使用的是Layer 4 load balancer + Reverse proxy的做法，请求在load balancer不作任何处理，只是进行转发，使用的算法也只是轮训，在Reverser proxy上进行TLS termination后发到Tomcat服务器监听的HTTP endpoint。这里我们在reverse proxy进行TLS termination，而不是把请求直接发到HTTPS endpoint的原因是：由于我们的load balancer使用TCP协议，存在sticky connection的问题，如果我们使用HTTPS endoint监听请求的话，可能出现server端同一时间被建立了大量的TCP连接，其中很多的连接可能都是无意义的idle的，所以是有必要进行TLS termination的。
3. 现在我们分析使用loader balancer 1的HTTPS请求的建立过程：首先，由于请求是HTTPS协议，client端必须有亚马逊的根证书，用来验证load balancer端提供的证书是正确的；其次，load balancer 1中必须要有由亚马逊根证书(或中间证书)签发的证书，用来向client确认load balancer端的可信性，所以我们看到配置VIP HTTPS load balancer的时候，需要绑定redfort生成的由亚马逊根证书(或中间证书)签发的证书；另外在load balancer完成TLS termination，解析完请求并决定该请求应该打到哪个server后，load balancer与server之间也是使用的HTTPS协议，amazon这里的做法是server端提供自签名的证书，load balancer端不会验证证书的正确性，这就导致了可能存在中间人攻击，这也是为什么amazon不推荐使用Layer 7 load balancer+TLS加密这种做法。
4. 现在我们分析使用loader balancer 3的HTTPS请求的建立过程：首先，client端必须有亚马逊的根证书，用来验证Reverse proxy端提供的证书是正确的；其次，Reverse proxy中必须要有由亚马逊根证书(或中间证书)签发的证书，用来向client确认load balancer端的可信性，所以我们看到配置JLBRelay的时候，需要从odin处获取redfort生成的由亚马逊根证书(或中间证书)签发的证书，odin在这里是负责储存并定时生成新证书的。