普元应用服务器高可靠方案

转载本文请注明出处：微信公众号EAWorld

前言：

伴随着网络带宽的提升和移动终端的普及，现代的web应用平台几乎时时刻刻都在处理着来自用户成千上万的访问请求。在某些特定的场景下（如电商抢购、春运抢火车票等），这些web平台要承受瞬间暴涨的用户访问量。如何在高并发请求的情况下做到服务不瘫痪并且给与用户良好的使用体验，是所有web平台都要面临的挑战。构筑具备高可靠的web平台，是企业避免用户流失的重要手段，是增强自身竞争力的必要环节，具有十分重要的意义。

无论是证券、银行或是政企等，对于信创数字化应用系统，必须尽可能的保证其可以持续的、健康的运行。其中在应用服务器层面的高可靠性，又是重中之重。普元作为国产中间件服务提供商，产品的高可靠性是非常重要的一个特性。本文将介绍普元应用服务器（PAS）的高可靠方案，会以应用高可靠的三层架构方案为切入点，结合实际场景，分别来讲解PAS的高可靠能力。

目 录

01 高可靠架构图

02 服务代理层

03 应用服务器层

04 总结

01

高可靠架构图

首先介绍一下普元应用服务器PAS高可靠方案的架构图。该架构共分为三层，第一层是VIP层，VIP层作为整个应用集群流量的入口，给PLB服务代理层提供高可用的能力；第二层是PLB服务代理层，可以通过六种负载均衡策略、心跳检测机制、故障转移以及反向代理等功能，为应用服务器层提供代理转发和负载均衡的能力，从而保障应用服务器层各实例的高可靠性；第三层是应用服务器层，包括独立实例和集群实例，可以通过分布式session、多数据源管理、防重复提交、全局序列号、应用滚动升级、实例服务自动重启、线程信息分析/查杀等功能，保障应用的高可用性。

02

服务代理层

本章节将从整体架构、负载均衡策略、心跳机制三方面对服务代理层进行介绍。

（一）整体架构

普元服务代理中间件(Primeton LB)是一个轻量级，高性能的负载均衡中间件。服务代理中间件支持HTTP、HTTPS协议，主要具有以下特点：

1.PLB采用的是固定数量的多进程模型，由一个主进程和数量与主机CPU核数相同的工作进程协同处理各种事件。主进程负责工作进程的配置加载、启停等操作；工作进程负责处理具体请求。

2.PLB通过异步非阻塞的方式来处理请求，每个worker进程使用异步非阻塞方式，可以处理多个客户端请求。当某个工作进程接收到客户端的请求以后，调用 IO 进行处理，如果不能立即得到响应，就去处理其他的请求（非阻塞）；而客户端在此期间也无需等待响应，可以去处理其他事情（异步）；当 IO 返回时，就会通知此工作进程；该进程得到通知，暂时挂起当前处理的事务去响应客户端请求。

<1> 服务代理中间件-Master进程模块

Master进程的主要功能有：

1.接受来自外界的信号；

2.向各个worker进程发送信号；

3.监控worker进程的运行状态；

4. worker异常退出，自动重启；

5.支持热更新配置，可以保持运行中平滑更新配置。

<2> 服务代理中间件-Worker进程模块

默认配置下，工作进程的数量与主机 CPU 核数相同，将工作进程与 CPU 绑定，这样可以最大程度发挥多核CPU的处理能力；服务代理中间件每当收到一个客户端请求时，主进程（master）生成一个子进程（worker ）来和客户端建立连接进行交互。使用进程的好处是各个进程之间相互独立，不需要加锁，减少了使用锁对性能造成影响。其次，采用独立的进程，可以让进程互相之间不会影响，如果一个进程发生异常退出时，其它进程正常工作，master 进程则很快启动新的 worker 进程，确保服务部中断，将风险降到最低。

Worker进程的主要功能有：

1.接收、传入并处理来自客户端的连接；

2.提供反向代理及过滤功能；

3.错误日志记录；

4.配置文件解析；

5.事件驱动机制；

6.以及plb所支持的所有功能。

（二）负载均衡策略

下面介绍PLB支持的六种负载均衡策略。用户可以根据自己的场景，选择合适的负载均衡策略，从而达到最好的高可用效果。这六种负载均衡策略以及其使用场景主要为：

1.轮询模式：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

使用场景：此策略适合服务器配置相当，无状态且短平快的服务使用。

2.加权轮询：通过对集群节点设置不同的权重来指定轮询的几率，权重与访问比率成正比，权重越高分配到需要处理的请求越多，可以与least_conn和ip_hash结合使用。

使用场景：此策略比较适合服务器的硬件配置差别比较大的情况。

3.IP_HASH：指定负载均衡器按照基于客户端IP的分配方式，这个方法确保了相同的客户端的请求一直发送到相同的服务器，以保证session会话。这样每个访客都固定访问一个后端服务器。

使用场景：假设一个极端的场景，用户需要分片上传文件到服务器下，然后再由服务器将分片合并，这时如果用户的请求到达了不同的服务器，那么分片将存储于不同的服务器目录中，导致无法将分片合并，使用IP_HASH便可以解决这个问题。

4.URL_HASH：按访问url的hash结果来分配请求。使每个url定向到同一个后端服务器。

使用场景：有一个服务器集群A，需要对外提供文件下载，由于文件上传量巨大，没法存储到服务器磁盘中，所以用到了第三方云存储来做文件存储。服务器集群A收到客户端请求之后，需要从云存储中下载文件然后返回，为了省去不必要的网络带宽和下载耗时，在服务器集群A上做了一层临时缓存（缓存一个月）。由于是服务器集群，所以同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。此场景便可以使用URL_HASH。

5.sticky：即会话亲和，同一个客户端请求会分配到同一个后端服务器。

使用场景：将用户的session存入cookie里，当用户分配到不同的服务器时，先判断服务器是否存在该用户的session，如果没有就先把cookie里面的sessoin存入该服务器，实现session会话保持，通过cookie我们就可以保证同一个用户的一个时间段内的请求会发送到同一个后端服务器上，从而实现了会话亲和。

6.least_conn：把请求转发给连接数较少的后端服务器。

使用场景：我们知道轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同。这有个前提，就是每个请求所占用的后端时间要差不多，如果有些请求占用的时间很长，会导致其所在的后端负载较高。在这种场景下，通过同一个算法，把请求转发给连接数较少的后端，能够达到更好的负载均衡效果。

（三）心跳机制

前面介绍了PLB的负载均衡功能，那如果集群中某个节点down掉了，同时有一个请求正好分配到该个节点，就会导致服务不可用，这时候该怎么办呢？服务代理中间件提供了心跳检测机制，通过心跳检测间隔时间配置，实现定期向后端节点发送心跳请求，从而判断节点是否可用，如果不可用则会将其剔除集群节点列表，实现故障切换转移，从而保证服务的高可用。

03

应用服务器层

普元应用服务器PAS目前通过分布式session、多数据源管理、防重复提交、全局序列号支持、应用滚动升级、实例服务自动重启、线程信息分析/查杀七个功能来保障应用在运行期的高可靠性。

（一）分布式session

在通过集群机制保持平台高可靠性的前提下，为了改善高并发请求环境中 Session 持久化造成的性能瓶颈，同时避免大集群情况下 Session 同步带来的网络风暴风险，PAS引入了“分布式 Session 存储”的技术，使用(普元分布式缓存中间件)PMDB持久化 Session 数据，大大提高了应用服务器在高并发、大集群情形下的性能表现。

（二）多数据源管理

传统的应用系统中，通常会使用普通的jdbc数据源，而jdbc数据源是通过JNDI查找的单一数据源实现的，应用在使用JNDI的数据源的数据库请求时都会发到单一数据源指定的唯一数据库上去。假设随着用户量的迅速增长，并发量变大，导致数据库的压力过大，或者因为某些不可抗拒原因导致数据库服务器停机，都有可能造成数据源不可用等单点故障，导致业务出现问题。为了解决这一问题，普元应用服务器PAS的多数据源管理可以提供如下两种高可靠的保障：

1.故障转移：可以在基于数据库主从的模式下，应用主数据源发生故障，自动将数据源连接到备库上。

2.负载均衡：在数据库集群的模式下，通过配置一定的负载策略，将数据处理通过不同的数据源分配到指定的数据库上进行操作。

（三）防重复提交

在实际的生产环境下，由于客户端的网络抖动，快速操作，网络通信或者服务器响应慢等原因，导致同样的请求多次访问到服务端，造成资源浪费、甚至是数据发生错误等问题。为了解决这一问题，普元应用服务器PAS中运用了防重检查控制，充分保障进入到PAS中的每一个请求都是有效的，一方面将PAS有限的处理能力用到正确的请求上，另一方面也能有效的保障业务请求的重复提交导致业务的数据不一致性。

（四）全局序列号

现阶段绝大多数的应用系统都是分布式架构，而在一些相对较为复杂的分布式架构系统中，无论是生成数据ID、消息ID、链路追踪traceid或日志记录的标识id，往往都需要使用唯一标识，因此在应用中需要一个生成全局唯一ID的系统或组件是非常有必要的。普元应用服务器PAS默认提供了基于雪花算法的序列号组件，保证在上百万的并发场景下生成的ip唯一，该功能通过开发接口的方式供应用来使用。

（五）应用滚动升级

应用滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，以达到不停机升级应用的目的。PAS的应用滚动升级是在应用程序部署在多个实例上时，通过在应用重新部署过程中添加步长的设置，使得应用在升级过程中分批升级应用实例，从而不会因为升级过程，导致应用停止对外服务。

（六）实例服务自动重启

在我们的生产环境中，服务实例因为某些因素导致异常宕机的情况不可避免，这时就需要管理员手动去重新启动该服务实例，这就会对整体应服务的可用性带来一定的挑战。为了解决这一问题，普元应用服务器PAS支持实例服务自动重启功能。我们可以对需要自动重启的实例进行自动重启配置，设置重启相关的参数。当PAS所在机器重启或者实例出现异常挂掉时，能够被健康检测扫描到，并且进行启动。若启动失败根据配置的重试时间进行重试，若重试仍然失败，可以向配置的邮件发送邮件，通知相关管理人员，从而可以最大限度的保证各个实例节点能够持续、健康的提供服务。

（七）线程信息分析/查杀

客户端向服务端发起请求时，应用服务器给该请求分配一个线程来处理该次请求，为了减少频繁创建线程的开销，普元应用服务器PAS使用自定义线程池的方式来处理请求，从而提高资源的利用率。在某些极端的场景下，大量的慢请求涌入服务端，导致线程池的工作线程被占满，后面再来的请求就会堆积在线程池的队列中，导致服务不可用。为了解决这一问题，PAS支持请求连接线程池线程信息分析以及查杀功能，PAS支持在独立实例、集群实例下对自定义线程池中的线程进行管理，如果发现阻塞的线程，我们可以通过查看当前线程池的线程信息、线程栈信息。对其进行分析，找到被阻塞住的线程，并且可以手动去停止该线程，从而防止线程池因为过多的阻塞线程导致服务不可用。

04

总结

上文主要介绍了plb负载均衡中间件的核心架构、6个负载均衡策略和心跳检测机制以及普元应用服务器pas中间件的7个高可用功能。

通过中间件这些能力在最大程度上保障应用在运行期的高可靠性，从而可以为用户提供更为优质的服务。当然高可靠特性只是plb和pas的一部分功能，关于plb和pas更多的内容，敬请关注本公众号后续更多的文章。

关于作者：少韦，现任普元信创军团工程师，长期致力于IT技术研究，微服务架构设计和开发等工作。擅长springboot、springcloud、elasticsearch、kafka等技术。先后参加普云应用服务器PAS、普元应用开发平台EOS 、政企项目的研发工作。

关于EAWorld

全栈赋能信创，共创数智未来！