聊聊负载均衡Loadbalance
大家好啊，我是你们的逗比大师Raynor啊。这次我们聊的话题就选负载均衡吧！
负载均衡，其实大家可以搜到很多相关的文章。负载均衡，顾名思义，就是分摊负载，避免负载集中，从而导致服务出现问题的一种机制。
其实我不太想聊负载均衡的机制啊，或者说原理啊这类的。没意义，毕竟常规技术，文章太多。而硬件负载均衡对常规运维、普通公司来说价格太高。所以，我们聊点我们常用的一些负载均衡的实际应用吧。
Nginx
Nginx做负载均衡的一个比较麻烦的点在于，对于线上的nginx做的负载均衡来说，一般做修改的话只做增量添加和配置文件注销操作，切忌做删除操作，以免因为误删而导致的人为故障产生。
这里有个疑问：任何服务器对请求的接受都是存在上限的。不管是长链接、短链接，包括请求转发，都是会存在一个上限。但是负载均衡理论上也是运维最常用来扛负载的。举个栗子来说，假设服务器，请求接受的上限在1000，一个nginx后端接了两个服务实例在两台不同的服务器上。这个时候，如果有1500的并发请求打过来，我们一定会遇到504的情况。作为运维，如何避免这种情况呢？
我们先来聊另外一种负载均衡
DNS
DNS其实也可以当做一种负载均衡。任何一个DNS的A记录里都可以做权重配置，而A记录也可以添加很多条。也就是说，可以通过DNS调度请求的具体落点服务器。使用DNS进行负载均衡，其实我觉得对于大部分公司来说都是可行的。只是比较麻烦而且坑点比较多的是，如果使用自建DNS服务，配置文件较大且内容较多的时候，重载DNS服务有一定风险。而使用外部提供的DNS服务的时候，对于这部分的权限管理需要严格处理，避免事故产生。另外，使用DNS做负载均衡，容易出现请求落点不均衡的问题。这个也和DNS的一些机制有关。只是相对来说出现概率比较低，但是在高并发的时候就容易对业务产生实际影响了。
回过来说前面的一个问题。我们可以加2台nginx服务器，连接后端2个实例。也就是如图所示的这样
然后把这2个nginx服务器的IP加到域名的A记录中。
利用DNS+nginx的机制，实现请求的双重调度。这样，对于运维来说，只需要知道服务的预估并发请求量，就可以配置对应的负载均衡，实现请求落点均衡。
另外一点是，nginx本身可以通过多层配置转发，来实现nginx负载集群这样的一种模式。主要的话方便进行一些流量清洗等之类的操作，同时提供高并发和DDoS的防护等。
LVS和HAProxy
LVS具体的一些文档其实都可以查的到，在这边我不打算多说什么。只是，作为早期的负载均衡技术，像是硬件负载均衡、现在常用的nginx反向代理等其实都可以看作是LVS的衍生发展。当然，LVS也有自己的相对优势，比如调度算法可能更多一些等。不过目前相对来说应该不算主流了。
HAProxy严格意义上其实不能算是一个比较常规的负载均衡，更多的应用应该都还是用在保活性上(即保证服务存活)。一般来说，HAProxy后端接服务的多个实例，当第一个实例不工作的时候会基于iplist，请求后面第二第三个实例，进行轮询的请求。对于高并发的话其实并不能很好的进行处理。
其实，说了那么多，负载均衡的本质，就是均摊请求，避免单一服务实例接受到的请求过多。只要能实现这个目的，用什么工具，用什么方法技术，都可以。
目前负载均衡不仅仅使用在对外服务的高并发解决方案上。基于近些年流行的微服务架构，负载均衡也被广泛应用在服务架构内部，对于服务与服务之间的交互上增加负载均衡，配置上内网域名，这样在服务之间请求的时候会更便利，配置管理也会简单很多，也能在服务负载过高的时候快速平行扩容。
另外，在kubernetes(其实我很讨厌k8s这么个写法说法，就感觉很low(个人喜好))里有service的概念，其实就是在kubernetes内的负载均衡。本质上其实也是利用类似微服务的这种架构模式，即LB接RS，然后访问LB。对于服务开发外的人来说，服务的内在是黑盒，只需要关注这个服务是否提供正常服务即可。
希望文章对各位有帮助，如有不足之处还请提出，请各位看官多多包涵，提点提点。下一期打算聊个非技术类的内容了。聊聊两性关系？用计算机的一些原理来聊两性关系？应该还是挺有意思的吧
求关注求分享~