大业务上云，难免要用到LB。可是，您是否了解LB的来龙去脉？本文浅谈一下LB，从硬件走到软件，他们经历了什么转变。
几年前，刚接触网络的时候，就听过一个称呼：四层交换。
四层交换，顾名思义，就是基于传输层的TCP/UDP协议进行数据交换的，利用端口信息区分报文，可进行数据包过滤、服务质量（QoS）、负载均衡、主机备用连接、统计和报告等。而我们使用最频繁的，便是负载均衡（LB）。
盒子时代，业界最出名的三家四层交换厂商：F5、citrix、radware。至今还称霸着负载均衡的市场。
|
|
|
|
四层交换在负载均衡另有，主要提供三大类负载均衡服务：
l LSLB：Local Server Load Balance
l GSLB：Global Service Load Balance
l LLB：Link Load Balance
LSLB（本地负载均衡）：给本地集群部署的多台服务器提供流量负载分担能力。应用的V-IP在四层交换上，四层交换根据配置的负载均衡算法和会话保持算法分发给后端服务区。
这里提到2个概念，负载均衡算法和会话保持算法
负载均衡算法：即流量到了LB以后，应该分给谁，常见的算法有轮询、最小用户数、最小流量、哈希等
会话保持算法：首包通过负载均衡算法确定发给具体那一台后端以后，要生成session，以指导后续报文转发。而生成的session可以根据配置只记录某些信息，比如只记录源地址而不纪录端口，这样相同的源的不同请求（源port不一样）也会发给相同的后端
GSLB（全局负载均衡）：应用在多站点部署，GSLB可根据访问者的位置，提供就近接入能力。其实GSLB更多地是一种DNS重定向能力。
如图，访问者在广州，要去访问www.huawei.Com，请求本地DNS解析时，DNS通过递归查询发现域名是托管在GSLB的，于是向GSLB发出申请，GSLB通过测试自己到DNS的延迟，识别出来广州站点离用户最近，于是将广州的IP地址返回给用户。用户请求被重定向给广州站点。
LLB（链路负载均衡）：当访问一个应用，有多条线路可以同时到达时，LLB会提供线路优选，根据访问者或者线路的负载情况选择最有线路。常用于优选电信和联通都存在线路接入的场景
这几种负载均衡场景，都是IT行业里最普遍的场景。而F5、Radware、Citrix也是IT界大名鼎鼎的公司。并且随着技术的演进，四层交换设备已经不仅仅只能提供四层的LB，七层的能力已经逐步完善。
可是为何到了云时代以后，他们的名声虽然依旧响亮，但是始终感觉不如从前了呢？而上面的几种功能，在云时代又是如何提供的呢？
再强大的盒子，能支撑的流量也不过百G级别。而在互联网迅速崛起的年代，100G流量根本不算什么，王者荣耀据说流量总和已经达到了800G（小道消息，待考证）。而类似于google的8.8.8.8，对流量和可靠性的需求，根本不是一个盒子可以承担的起的
于是近几年，负载均衡软件蓬勃发展，结合动态路由协议实现anycast等能力后，拓展性和可靠性达到了一个质的飞跃。
LSLB逐步被 HA proxy、LVS、nginx等软件代替，各大互联网公司也纷纷基于开源软件进一步开发加固，做出了自己的LB集群。比如腾讯的TGW，还有阿里的LVS集群等。
而GSLB，其实也只是承担了一个DNS重定向的能力，也逐步被智能DNS解析服务所取代，比如AWS敢于承诺100%可用性的Router53、腾讯的dnspod等。
LLB呢？被运营商提供的BGP线路所取代。传统的LLB还需要每一个运营商1个IP，而BGP直接允许相同的IP在不同的运营商网络里广播，根据BGP协议自己实现就近接入。
当然，云还是比较包容的。盒子可能不太适合大规模服务化，但是给某一些企业使用还是很不错的选择，AWS跟F5合作，可以将F5软件化，部署到VM中，在云的模式下还可以继续提供服务。
资料来源：https://bbs.huaweicloud.com/blogs/caf97cef9bac11e89fc57ca23e93a89f