前言
水平扩展是扩展服务性能的常用方式。当服务由单机应用变为多机时，每台服务器怎么均衡的分担负载（请求/数据）是我们需要解决的新问题。负载均衡就是用来处理该问题的。
常见的负载均衡算法
介绍目前主流的负载均衡方案前，先简单介绍下常用的负载均衡算法，对此部分不感兴趣的可以直接看下面的章节。
随机负载均衡
请求随机打到各服务器，当请求量足够大时可以认为负载是均衡的。用于请求的负载均衡。
轮询负载均衡
请求轮询依次打到各服务器。用于请求的负载均衡。
负载因子hash负载均衡
公式为 num=hash(key)%n.
key是请求体的某个属性。比如：ip，userId等等
n是服务数量或者未来某个时间段内期望扩展到的服务数量
num是处理该请求的服务编号，从0开始。
一般用于含有相同负载因子的请求打到同一台服务器。
请求/数据负载均衡均可使用该算法。
一致性hash负载均衡
假如原本n台服务，当扩展一台服务后，hash负载均衡会有n/(n+1)的请求miss。
一致性hash算法可以将miss率降到1/(n+1)。一致性hash算法参考：https://www.cnblogs.com/xrq730/p/5186728.html
静态权重负载均衡
有时候由于各服务器配置不相同，我们并不想请求完全均匀地打到各服务器。可以给各服务器配置权重，权重大的路由到的几率就大些。
动态权重负载均衡
静态负载均衡不能根据各服务实际的负载情况调整路由策略。动态权重负载均衡算法就是为了解决此问题。比如，初始各服务负载权重一致，随着系统运行，有些服务超时，有些服务报错，算法自动地把相应的服务权重降低。当服务恢复正常后，权重再自动恢复。
负载均衡方案
提到负载均衡中间件，相信很多人都能想到Nginx。对运维了解更多一些的小伙伴也会说出LVS，f5。这三者的主要区别在于作用的层级不一样。Nginx是软件级别的，LVS是操作系统级别的，f5是硬件级别的。越往后性能越好，成本也越高，配置也越复杂。
Nginx负载均衡
对于大部分公司来说，下图这种方案是最常见的。
据说nginx单机QPS能扛到10000左右，对于大部分公司这种架构也足够支撑公司业务。美中不足的是现在Nginx还是单体的，Nginx也做成高可用那就完美了。
Nginx+KeepAlived实现Nginx的高可用，这应该是大多数公司的最终架构了。
LVS/f5负载均衡
上面的架构最多能支持QPS为10000左右的业务，如果业务量再大就撑不住了。
LVS据说QPS能扛10W。
终极负载均衡方案
根据上面两种方案的演进思路，业务量再扛不住就再加一层性能更好的f5，实现LVS的水平扩展。那f5也扛不住了呢？按这种思路下去能支持的业务量理论上总有个极限。
水平扩展才是解决性能问题的根本方案，我们需要设计一个服务端性能能无限扩展的方案，其实也就是说服务端流量入口处能无限扩展的方案
有没有理论上可以无限扩展的方案呢？其实这种技术很早就有了——DNS轮询技术。简单来说就是一个域名对应多个ip，当有域名换ip的请求来时轮询依次返回某个ip。我们熟知的云服务商都支持这种配置。我们知道的拥有特大流量业务的公司比如百度，谷歌也都是基于此方案演化和丰富的。
但是DNS轮询技术也有一些看起来很致命的缺点：
非高可用：DNS只负责域名解析ip，这个ip对应的服务是否可用，DNS是不保证的，依然会返回不可用的ip。
扩容非实时：DNS解析有一个生效周期。
DNS轮询技术是我们的杀手锏，倘若我们的业务真能达到这个规模，这些缺点也显得不足为道了。
