在上一节课中我们已经熟悉了云服务器,但是单台云服务器的性能、可用性都有很大的限制,在面对整体业务来扩展性能、提升可用性时就需要通过负载均衡来实现。我们一起来看看负载均衡Load Banlance吧。

1. 典型三层架构

        Web应用典型三层架构的作用是按照上下层逻辑进行解耦,展示层、逻辑层、数据库层各司其职,除三层应用架构外,还有一层是数据库。在程序开发上更容易实现各个组件的调整、更新,在业务架构上更容易实现扩展和高可用。这三层系统组件均可独立部署到相同或不同的云主机中,组件之间互相调用即可。


  • 展现层,用户访问和浏览的PC端、移动端界面通常由HTML、JS、CSS组成。
  • 逻辑层,应用系统的逻辑操作,如用户登录、商品下单、游戏登录、课程学习等逻辑。
  • 数据库层,对数据库的连接、关闭、CRUD增删改查操作,一般通过数据库封装DAO作为接口来操作。

2. 负载均衡

7天7项云服务 | 02-负载均衡Load Banlance_负载均衡

图  负载均衡示意图

        如下图所示,负载均衡通过VServer监听前端请求,统一纳管后端的服务节点RealServer,并根据均衡算法转发到服务节点,服务节点并不直接面向用户端,方便进行扩展。负载均衡自身没有判断系统负载或业务压力的功能,可通过自动伸缩或脚本的方式来添加云主机、物理云主机等资源到后端节点中,或者移除资源。添加服务节点后,负载均衡会按照均衡算法重新分配任务,缩容移除服务节点时会按照设定策略的顺序依次移除。

VServer

        VServer需要配置监听的端口、负载均衡算法、会话保持、健康检查策略等参数,另外对于7层的HTTPS服务还需要绑定SSL证书。VServer的作用就是接入请求、按照均衡算法分发流量、实现健康检查等,负载均衡的大部分功能都由VServer提供。后端服务节点也称为RealServer,承载VServer分发的流量,后端服务节点支持虚拟的云主机、物理服务器、打通网络的混合架构中的本地服务器,后端服务节点需要通过绑定的操作来挂载到负载均衡VServer中。

健康检查

        VServer中的健康检查机制会监测服务器的状态,确认健康检查状态为“失败”时会将该服务节点从后端服务节点中移除,故障解除后需手动或通过程序重新挂载,并不会自动重新挂载。负载均衡后端服务节点支持健康检查机制,只对健康检查状态为“正常”的服务节点分配请求。健康检查方式有两种:端口检查和HEAD检查,通过心跳包来判断后端服务节点是否“正常运行”,通过端口检查只能检测出端口是否可通信,不能检测Apache、nginx等服务器是否启动、应用能否正确访问;HEAD检查需要配置HTTP检查路径,如“http://www.example.com/index.php”,需要后端服务节点支持HEAD请求,并且返回200响应码视为可正常访问。



提示


负载均衡的端口检查和HEAD检查两种方式均不能准确监控应用是否正常运行,更多应用运行监测指标和云主机监控指标可通过“云监控告警”服务来实现。


        如下图所示。当云主机作为服务节点绑定到负载均衡之后,默认健康检查状态是“失败”,因为这时负载均衡还没完成连续三次请求为“正常”的状态检查,所以是“失败”的状态。只有连续三次请求为“正常”,才会变更服务节点(云主机)的状态为“正常”,当连续三次请求为“失败”时,才会变更服务节点(云主机)的状态为“失败”。如果仅有一次或连续两次检测到与当前结果相反的状态,考虑到可能是网络连接故障等原因或偶然的请求成功,所以不作为变更的依据,连续三次的请求结果相同才可作为参考依据。


7天7项云服务 | 02-负载均衡Load Banlance_云主机_02

图  负载均衡健康检查机制


        对于健康检查状态为“失败”的云主机,负载均衡会将这些云主机从可用云主机列表中移除,用户的请求不再转发给这些云主机处理。这是个“温处理”的过程,也就是这些云主机不会被分配新的请求,但是会在处理完成已经分配的任务后再进行移除。如果云主机发生严重故障,导致当前任务还未处理完成,会丢失当前任务的状态和数据,这就需要前端应用具有请求重试机制和结果检查机制。如果云主机状态恢复正常,连续三次健康检查状态为“正常”后会按照负载均衡算法分配新的流量到该云主机。

        负载均衡会通过健康检查机制检测后端的云主机是否能够正常连通,健康检查失败时会将该云主机从后端的云主机中移除,该云主机不再被分配任务,云主机恢复后健康检查状态也会恢复正常。

无状态服务Stateless Service

        负载均衡为业务高可用提供了最基础的机制,有几方面要注意,每个服务节点中要保持无状态,状态数据包括用户登录Token、任务处理结果、触发的任务事件、任务源数据、中间状态数据、处理结果数据等,这些状态数据都要和云主机进行解耦,保证云主机不存储状态数据。负载均衡的轮询、加权轮询、最小连接数均衡算法在没有开启会话保持功能时,连续的、同一用户的请求不一定会分配到同一台云主机中进行处理,云主机就无法获取状态数据。如果将状态数据保存在云主机本地,则其他云主机无法获取这些数据,在该云主机发生故障时保存的数据也会丢失。

        所有云主机都保持无状态,将状态数据存在Redis中而不是云主机本地。如果云主机发生故障时任务已经处理完成并将数据写入Redis,则云主机故障不会影响应用高可用,健康检查机制会将其从后端服务节点中移除;如果云主机故障时任务还未处理完成,还未将状态数据保存到Redis中,应用程序会通过重试机制再次请求,负载均衡会按照均衡算法分配请求到云主机并重新加载数据进行处理。

外网负载均衡需绑定EIP

        EIP(Elastic IP)也是云计算中常用的服务,是云服务商提供的固定IPv4地址,只要费用充足并进行续费,已经分配给你的IP地址就不会变动,虽然现在IPv4地址已经向各大运营商分配完成。

        用户购买EIP后可以绑定到云服务器、负载均衡、NAT网关中,提供外部访问的接口。EIP计费方式包括按照固定带宽计费、按照流量计费以及其他动态计费方式,比如我们购买5M上限的带宽,最多只能用到5M,这就是固定带宽计费。不过这样的计费方式对电商、游戏等业务场景不太友好,有一些流量突发的情况,不希望因为设置了5M的带宽而丢掉一些请求,所以可以设置按照流量进行计费,消耗掉多少EIP网络流量就收多少钱。不过这种对于个人站长等用户来说不太适合,网络流量平时都不大,万一有人恶意攻击造成较大的访问流量、又没有合适的安全防护能力,就会造成消耗的EIP流量过多,超出预期,这样还是选择按照固定带宽计费比较好。所以这两种计费方式并没有好坏,只有适合的场景。

        创建EIP之后不建议直接绑定到云服务器中,而建议绑定到负载均衡中,通过负载均衡再绑定云主机,这样后续在扩展云服务器的时候直接添加到负载均衡的后端节点中就行了,不用更换原来的EIP地址。而且负载均衡还有一定的安全防护能力,也有SSL证书卸载的功能,都比将EIP直接绑定到云服务器上要好。

3. 通过负载均衡实现可用区级别高可用

        一个庞大的系统是由很多组件和子任务模块组成的,任何一个组件和子任务模块如果运行在单台服务器中都会形成单点,这些关键子业务如果停服可能会导致整个系统级别的服务不可用。例如,电商平台用户登录界面的图片验证码、游戏业务中的系统负载监控告警功能,如果这类子业务运行在单台服务器中遇到故障宕机,则会直接影响电商平台的用户登录,并使游戏业务不能根据系统负载告警动态扩展。

        要避免单点故障,实现最基础的高可用,可选择将同一个应用和子任务部署在2台及2台以上的云主机上。多台服务器共同承担业务压力,此时不仅降低了单台服务器的压力,还避免了云主机的单点,通过云主机级别的冗余保障有一台服务器宕机也不会影响整体业务的连续性。将多台服务器部署在同一个可用区内,还是会形成可用区级别的单点,应选择将多台服务器在该地域的多个可用区中分散创建。

        云计算中的可用区的设置为业务实现同地域高可用提供了便利,将部署业务的云主机分布在一个地域内的多个可用区中,可避免单台云主机宕机、单个可用区网络中断等单点问题,且在这个过程中并不会增加额外的成本。

7天7项云服务 | 02-负载均衡Load Banlance_数据_03

图  可用区级别高可用

        如上图所示,同一个地域的不同可用区实现高可用部署的流程如下。

  1. 在部署业务时,在一个地域内至少选择两个可用区,参照典型三层架构(包括展示层、逻辑层、数据库层),展示层和逻辑层云主机均保持无状态(Stateless)。可通过持续集成与发布平台部署应用,也可以选择将云主机应用和数据制作为镜像并复制到其他可用区中来创建云主机。
  2. 展示层、逻辑层的云主机需要保持无状态,即状态数据不保存在云主机中,状态数据适合选用Key-Value形式的Redis数据库进行存储和读写,Redis运行在内存中,提供高性能的读取操作。所有保持无状态的云主机将状态数据写入Redis中,即便其中的云主机宕机,导致正在处理的任务失败,业务中的重试逻辑也会重新将任务分配到其他云主机中,数据不会丢失;如果将业务的状态数据保存在服务器上,则会出现云主机A宕机后其状态数据丢失,云主机B无法获得该状态,从而造成功能紊乱。
  3. 展示层、逻辑层通过负载均衡实现流量均衡和统一的接入访问,前端用户通过负载均衡的内网IP或EIP进行请求访问,后端服务节点由分布在该地域的不同可用区的多台云主机组成,用户无须关注具体由哪个后端服务节点提供服务,负载均衡屏蔽了云主机的单点故障。
  4. 云数据库在一个可用区是主库,在另外一个可用区中为从库,通过设置可实现主从数据库同步,两个可用区之间默认通过内网通信,具有极低的延迟,该地域的所有可用区的云主机均写入主库中,读操作则选择云主机所在的可用区中的从库。

4. 延伸思考

  • 负载均衡只能在单个地域提供服务,如何跨地域提供负载均衡服务
  • 负载均衡是否能够按照域名或者URL进行流量分发
  • 负载均衡有哪些均衡算法,如何按照这些算法进行流量的分配

5. 动手实验

  • 选择一个云平台,创建负载均衡实例,在云服务商的负载均衡实例界面进行截图。
  • 创建两台云服务器,并部署Web页面(两台云服务器中的Web页面需略有差别),在浏览器中访问绑定在负载均衡上的EIP地址,多次刷新页面能够访问到两台云服务器上提供的Web页面,分别进行截图。
  • 模拟其中一台云服务器宕机,继续刷新多次访问绑定在负载均衡上的EIP地址,查看访问到的Web界面,并进行截图。