负载均衡是高可用网络基础架构的的一个关键组成部分，有了负载均衡，我们通常可以将我们的应用服务器部署多台，然后通过负载均衡将用户的请求分发到不同的服务器用来提高网站、应用、数据库或其他服务的性能以及可靠性。
为什么要引入负载均衡
先看一个没有负载均衡机制的web架构：
上图中的架构有什么缺陷了？首先，用户是通过网络直接和web服务器相连，想象一下，如果这个服务器挂了（这种情况随时都可能发生的)，那么用户的请求就会得不到响应，将无法访问该网站，这就是著名的单点故障问题，这肯定是不行的，一般而言，商业上的网站其可靠性需要达到至少4个9，也就是99.99&以上。
其次，即使服务器是正常工作的情况，但是如果很多用户在同一时间内访问服务器，超过了服务器的处理能力，那么会出现响应速度慢甚至无法连接的情况，这也是用户无法接受的。
负载均衡的出现可以很好的解决上面两个问题，通过引入一个负载均衡器和至少两个web 服务器，可以有效的解决上面两个问题。注：通常情况下，所有的后端服务器会保证提供相同的内容，以便用户无论哪个服务器响应，都能收到一致的内容。
如上图架构，现在，即使App 01即使挂了，负载均衡会将用户的请求转发到正常工作的App 02上，这解决了上面的第一个问题；其次，根据业务需要，负载均衡后端的App可以很方便的扩展，这样就能解决第上面的第二个问题。但是，现在单点故障问题转移到了负载均衡器，可以通过引入第二个负载均衡器来缓解，后面还会讲到。
负载均衡如何选择要转发的后端服务器
负载均衡器一般根据两个因素来决定要将请求转发到哪个服务器。
1：确保所选择的后端服务器是正常工作的，能给对用户的请求做出响应；
2：根据预先设置的负载均衡算法从健康服务器池中进行选择。
由于负载均衡器只应当选择能正常做出响应的后端服务器，因此就需要有一种机制能判断它所连的后端服务器是否正常工作。为了监视后台服务器的运行状况，运行状态检查服务会定期尝试使用转发规则定义的协议和端口去连接后端服务器。如果某个服务器没有通过健康检查，就会从健康池中剔除，保证流量不会被转发到该服务器，直到其再次通过健康检查为止。
负载均衡算法
负载均衡算法决定了后端的哪些健康服务器会被选中。下面是几个常用的算法，这里只是简单介绍，不具体研究其算法实现了，后面会专门用一篇文章来总结：
轮询：为第一个请求选择健康池中的第一个后端服务器，然后按顺序往后依次选择，直到最后一个，然后循环。
最小连接：优先选择连接数最少，也就是压力最小的后端服务器，在会话较长的情况下可以考虑采取这种方式。
散列：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器，可以考虑采取这种方式。
最后，想要解决负载均衡器的单点故障问题，可以将第二个负载均衡器连接到第一个上，从而形成一个集群。如下图所示：
当主负载均衡器发生了故障，就需要将用户请求转到第二个负载均衡器。由于 DNS 更改通常会在较长的时间才能生效，因此需要有一种能灵活解决 IP 地址重新映射的方法，比如浮动 IP（floating IP）。这样域名可以保持和相同的 IP 相关联，而 IP 本身则能在服务器之间移动。下面就是一个使用浮动 IP 的负载均衡架构动态示意图：
而现在用到更多的是ELB，比如平安云的解决方案，华为云的解决方案
负载均衡 ELB
负载均衡 (Elastic Load Balancing，ELB) 能有效集成业务系统入口，负载业务流量，提升集群可用性。负载均衡实例类型分为公网型和私网型，公网型主要应用于Web服务或者APP服务在互联网的发布，私网型主要应用于VPC内部系统的相互调用
通用方案
ELB 实例提供服务 IP 地址作为客户端访问的统一接口。ECS是云服务器， 每个 ELB 实例能够配置多个监听器，对同一个服务IP地址提供多个端口的监听服务。每个监听器上能够配置一个特定的服务器资源池，也可以多个监听器指定同一个服务器资源池
