Load Balance,负载均衡是一个大型网站永远绕不开的话题，相信略懂架构的人都了解负载均衡技术，他同时出现在服务器架构和网络架构之中，针对不同应用场景有软负载均衡和硬负载均衡产品。当单节点类型的站点无法满足业务时，我们就必须拓展服务器数量，由负载均衡提供前端访问能力，将访问流量分摊给后端服务器，而后端的服务器可横向拓展。
经典的负载均衡开源软件有Nginx/Tengine(七层，轻量，本身就是反代Web服务等)、Haproxy(四七层，高负载，会话持久、负载算法丰富等)、LVS(四层，基于IP+TCP)，以上通常配合Keepalive等VRRP完成高可用负载均衡的架构。但需要多出几台服务器来做专用负载均衡的载体，在云上环境，若把负载均衡设计在服务器上，纯纯大怨种了。
因此，云上负载均衡云服务化就相当有优势了，阿里云负载均衡家族ALB\NLB\CLB针对性的提供了七层/四层/七+四三种负载均衡产品。而对于绝大多数互联网应用来说，ALB应用型就可以满足负载均衡的需求了。
一、ALB三种调度算法
负载均衡重要的特性之一就是后端调度算法，ALB应用型负载均衡这里可以看到支持三种算法：
1.加权轮询。经典负载均衡调度WRR，如Haproxy的static-rr、nginx的weight轮询。通过调整后端服务器的权重来分配请求流量，一般后端配置高的权重会设置高一点，而配置相同的云主机权重默认一致即可，均衡分配请求量。
2.加权最小连接数。寻找连接数最小的节点调度WLC，类似nginx的least_conn，自动选择连接数少的后端服务进行分配，谁闲就让谁干活，摸鱼哒咩。
3.一致性哈希。分为源IP和URL参数两种，主要时利用哈希算法计算这两个参数来保证访问目标结构的一致性。
3.1.一致性哈希-源IP。源地址哈希算法SH，也是常见算法，如Nginx的ip_hash，Haproxy的source。主要负责同一个IP客户端访问相同的后端服务，解决Session持久共享的问题。
3.2.一致性哈希-URL参数。类似Nginx的url_hash，通过$uri即URL参数将同一个URL访问分配到同一个后端服务器中，解决后端某台机子为缓存时的应用场景。
二、ALB后端会话保持两种方法
会话保持是构建负载均衡架构需要关注的内容之一，用户可不想一个网站点着点着被调度算法挪走了后端服务，反复的重新登录。虽然在调度算法里有源IP哈希一致性，但是在内网环境下NAT一个公网IP时，负载均衡收到的内网多个用户的请求还是同一个公网IP地址，还是会出现持久化问题。ALB提供了两种会话保持的方法。即植入Cookie和重写Cookie，这两种方法官方手册介绍的比较简明易懂了，我就不赘述了。
1.植入Cookie：客户端第一次访问时，ALB会在返回请求中植入Cookie（即在HTTP/HTTPS响应报文中插入SERVERID），下次客户端携带此Cookie访问，负载均衡服务会将请求定向转发给之前记录到的后端服务器上。
来自 <如何在ALB控制台配置会话保持_负载均衡-阿里云帮助中心>
如图，客户端返回请求被插入了SERVERID，是由ALB给的，还插入了时间戳信息
2.重写Cookie：当ALB发现用户自定义了Cookie，将会对原来的Cookie进行重写，下次客户端携带新的Cookie访问，ALB会将请求定向转发给之前记录的后端服务器。
来自 <如何在ALB控制台配置会话保持_负载均衡-阿里云帮助中心>
需要在后端Web服务上进行配置的修改，通过Set-Cookie头直接插入相应名称的cookie
再测试时，请求Cookie出就带上了名称为HHH_WWW的cookie
熟悉nginx的哥哥们应该知道有个东西叫session_sticky，里面有三种cookie的mode，insert/prefix/rewrite
综合对调度算法和会话保持的体验，ALB应用型负载均衡更类似于云上的Nginx（或者淘自家的Tengine？没有深入接触过听说两者很相似）的负载均衡SaaS版，更加适合原先在本地机房以Nginx构建负载均衡架构的业务上云，用ALB替代Nginx负载均衡。当然ALB的特性优点还有很多，更加适应云原生环境，丰富的业务流量转发策略，出口大流量并可直接接入WAF、DDOS墙，灵活的健康检测策略等等。
三、实践-利用ALB将传统ECS访问流量切换至Serverless集群，实现云原生化改造
假设我现在是这样一个场景：
一家小型的创业型移动电商平台，业务的技术框架大致为CentOS+Nginx+PHP+Mysql+Redis。初期构建采用了云服务的模式，配置了ECS+RDS主从+Redis+OSS的架构，通过域名发布给用户所使用。就如同所有成长中的中小型企业来说，业务访问量逐渐增长，原先架构的缺点也逐步暴露出来。
ALB作为七层应用型负载均衡，是在云上扩展业务能力的最好方式之一，ALB通常的用法需要构建后端ECS云服务器组，几台相同的ECS动态伸缩来提供后端的负载能力。但是这里，我决定让这个“小型电商平台”用ALB完成流量无缝切换，逐步引入Serverless，拥抱云原生。
至于选择FC函数计算而不使用ECS弹性伸缩的原因大致有这几点：
1、单体ECS改造为弹性伸缩组有停机风险。ECS需要创建自定义镜像来作为伸缩组的来源，创建镜像基于快照技术，但在创建镜像时ECS无法正常提供服务，会存在缓存数据不写盘的情况，导致数据不一致甚至不可用。
2、弹性伸缩策略和能力。当出现业务并发高峰时，弹性伸缩的反应时间和策略就是决定业务是否正常的关键。众所周知，发布一个Pod容器是要比发布一台虚拟机快很多，K8S等云原生带来的动态Scale能力是IaaS层无法比拟的。
3、费用。FC函数的计费粒度比ECS更加精细，使用ECS伸缩组的费用总的来说要高与FC函数计算的弹性扩展，包括其他存储等潜在费用。
4、前后端业务配置里没有特点的固定IP地址，且本身支撑服务如数据都是云服务的环境，只需云上网络互通即可。
同时，根据这个电商平台现有访问情况发现，80%的用户是通过手机移动端来进行访问，也就是说出现高并发的访问量是由移动端产生，PC端的访问较少，因此我决定在ALB监听转发策略将移动端的流量切换到FC函数计算中，PC端的访问暂时由ECS继续提供，待运行一段时间并完成后续测试后全面将流量切换到Serverless。
1.准备工作
实践开始之前，需要修改一下代码，直接了当区别的区分谁提供了后端计算服务。
修改Serverless dev相关配置，发布FC应用，这里不是Serverless主场不多做介绍，确保函数正常运行
2.ALB实例创建
先购买一下活动提供的ALB资源包
进入负载均衡的控制台，选择【创建应用型负载均衡】，到开通页面。
ALB的应用场景非常多，可以在后端架构里，也可以在前端供用户访问，在后端内网环境下我们ALB的网络实例类型就要选择私网，但我们这里直接将ALB的网络提供给用户访问，因此选择【公网】。
这里需要注意VPC需要和原本的业务服务器在同一VPC下，分别选用两个可用区，可用区要和原有的后端云服务一起。
最后【确认订单】后【立即开通】即可。
3.ALB后端服务设置
根据规划，规划两个后端服务器组
进入负载均衡的控制台，选择【创建服务器组】，
创建第一个ECS服务器组：选择【服务器组类型】为服务器类型，也就是我们这里的ECS；选择ECS对应的【VPC】
添加后端服务器，选择正在运行业务的ECS即可
配置后端服务器的端口和权限。配置业务的前端访问端口
创建第二个FC函数计算组：选择【服务器组类型】为函数计算类型；直接选择函数计算所在的资源组
添加后端服务器，直接选择对应的FC服务和函数即可，操作非常简便
这样我们完成了ECS和FC函数计算服务器组的配置
4.ALB监听及转发规则设置
最后，创建好的负载均衡实例，进入业务配置向导，分别完成【配置监听】、【选择服务器组】、【审核配置】
这里创建过程有点冗余，就简述带过了。
我这里业务监听继续使用默认80端口协议HTTP，开启所有HTTP头字段功能，设置默认转发为ECS对应的服务器组
添加转发规则
主流手机的客户端访问web服务时，请求头中User-Agent会带Mobile关键字。这里就用这个关键字来设置转发规则，使移动端访问流量切到后端FC业务组中，由FC来实现动态扩容。
接上一步创建监听，点击【转发规则】，创建一条规则
选择条件为【HTTP标头】，配置键值【User-Agent】，设置值为【*Mobile*】
设定转发动作为重定向，重定向域名为Serverless函数计算的域名
5.ALB业务提供域名设置及测试
最后，ALB需要由域名CNAME指向，修改完域名即可全部生效
效果。直观访问，手机访问流量由Serverless承担，PC访问流量由ECS承担，实际上哪个提供的计算服务在用户侧体验应该是无感的。
后续也可以调整监听和策略，全面无缝迁移到FC函数中。
四、ALB实践-传统负载均衡应用场景
既然有免费体验ALB的机会，还是试一下传统的应用场景，即：
ALB后端服务器组为分别在两个可用区的两套ECS云服务器集群，在创建ALB实例的时候选用至少两个可用区的原因也是希望避免业务的单点故障，若一个可用区的集群健康检测出了问题就可以直接踢出并告警。
每个可用区的后端服务器都是多台ECS，运行的为相同的业务代码，使用默认的轮询算法可以分摊请求流量。
简单的设置即可高可用、高性能，跟自己在本地搭建Nginx+Keepalived相比，确实轻松不少
ALB实例上面已经购买好了，过程略略略
直接新创建服务器组，选择【创建服务器组】，
选择【服务器组类型】为服务器类型；选择ECS集群对应的【VPC】；负载调度算法为【加权轮询】
勾选要加入服务的后端ECS云服务器
配置后端ECS监听的端口和权重，权重一致时就是平均轮询，一台一台按顺序均匀的提供服务。
进入到ALB实例中，配置监听，再按步骤添加配置
使用curl测试就能看到经典的轮询算法，每次访问，ALB将每个可用区的每台ECS均匀的响应请求。
其他：
本来想拿PTS打一下网站压测的，突然发现这玩意还挺贵的，试了一下RPS每秒请求1000次，压测1分钟，测试结果是毫无波澜。
每秒1000请求量压测对于固定IP模式的ALB每秒QPS10w真是蚂蚁见大象了，对不起小丑是我自己，测个寂寞
总的来说，ALB的性能和配置流程是良好的。图形化的操作对于我这个以前动不动就敲Nginx负载均衡+反代，或是Haproxy+Keepalived配置.conf文件的苦逼人来说已经很不错了，熟悉nginx负载均衡前后端监听操作的人使用ALB肯定是没有问题的。
