【阿里云ALB应用型负载均衡】功能体验 & 利用ALB进行Serverless与ECS分流

2023-04-11 3002

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： Load Balance,负载均衡是一个大型网站永远绕不开的话题，相信略懂架构的人都了解负载均衡技术，他同时出现在服务器架构和网络架构之中，针对不同应用场景有软负载均衡和硬负载均衡产品。当单节点类型的站点无法满足业务时，我们就必须拓展服务器数量，由负载均衡提供前端访问能力，将访问流量分摊给后端服务器，而后端的服务器可横向拓展。

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访问，负载均衡服务会将请求定向转发给之前记录到的后端服务器上。

来自 <https://help.aliyun.com/document_detail/446969.html>

如图，客户端返回请求被插入了SERVERID，是由ALB给的，还插入了时间戳信息

2.重写Cookie：当ALB发现用户自定义了Cookie，将会对原来的Cookie进行重写，下次客户端携带新的Cookie访问，ALB会将请求定向转发给之前记录的后端服务器。

来自 <https://help.aliyun.com/document_detail/446969.html>

需要在后端Web服务上进行配置的修改，通过Set-Cookie头直接插入相应名称的cookie

再测试时，请求Cookie出就带上了名称为HHH_WWW的cookie

熟悉nginx的哥哥们应该知道有个东西叫session_sticky，里面有三种cookie的mode，insert/prefix/rewrite

综合对调度算法和会话保持的体验，ALB应用型负载均衡更类似于云上的Nginx（或者淘自家的Tengine？没有深入接触过听说两者很相似）的负载均衡版，更加适合原先在本地机房以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。