现有技术展现网页一般是基于同步的请求-应答模式,即客户端(可以是计算机或移动终端的浏览器)向服务器发出一个请求(request),服务器收到请求后进行后台处理,这些处理包括但不限于内存运算、Socket读写、文件或数据库读写等,处理完成后服务器向客户端应答(response),应答内容包括但不限于状态码(status code)、应答头(response header)、消息体(response body)等,一次请求-应答处理一般只有1个HTTP主线程,并且是同步进行的。
对于后台处理需要访问多个数据源且无法保证数据源可靠性的应用,如果使用同步请求-应答模式执行,一旦任何一段业务逻辑或数据源出现问题,例如处理性能下降或网络中断,那么都将影响到主线程的应答,轻则相关页面无法显示,重则Web应用服务器前端被大量请求阻塞(因为后台数据源阻塞),导致无法响应任何应答,整个应用程序都不可用。
现有的web应用技术有异步加载的,例如Portal技术,其一般是在主页面框架内嵌入多个子模块(Portlet),子模块可以随主页面框架同步加载,也可以异步加载,但后者一般需要新开启一个HTTP主线程,例如使用HTTP/1.1规范的IFrame技术实现。
如果采用类似IFrame等技术实现的异步加载机制,虽然可以在某种程度上避免整个应用程序不可用,但是仍然不能避免后台出现问题影响前端展现美观和响应速度。同时每个异步加载的模块都需要新开启一个HTTP主线程,会占用Web应用服务器有限的连接数,并且系统开销也会成倍增加,难以应对互联网海量访问的情况。
综上所述,现有技术存在面对海量访问时,无法保证动态实时应答,进而丧失服务体验的问题。
发明内容
针对现有技术中的问题,本发明提供一种Web应用服务方法,包括:A)收到客户端的请求后,建立一个主线程;B)在主线程中,生成所述请求的副本;C)在主线程中,将所述副本分发到所涉及的业务模块,并设置超时响应时间;D)所涉及的业务模块执行请求的业务;E)在主线程中,在所述超时响应时间内等待所涉及的业务模块的执行结果;F)在主线程中,根据所述执行结果和超时情况,向客户端发送应答;G)终止该主线程。
本发明提供一种Web应用服务系统,包括服务端控制器和至少一个业务模块,
所述服务端控制器被配置为用于接收来自客户端的请求,并建立一个主线程,在主线程中:生成所述请求的副本;将所述副本分发到所涉及的业务模块,并设置超时响应时间;在所述超时响应时间内等待所涉及的业务模块的执行结果;根据所述执行结果和超时情况,向客户端发送应答;
所述业务模块被配置为响应于接收到请求的副本而执行业务;
其中,所述服务端控制器被配置为在向客户端发送应答后终止该主线程。
在本发明中,即使后台某个业务模块出现严重问题,只要主线程服务是独立、健康的,则服务响应的及时性、有效性和可用性都能得到保证和控制,并且本方法对系统资源的额外开销很小,能够适应互联网应用海量并发的情况。
而且,一旦某个后台应用模块出了问题无法响应,只要HTTP请求的主线程健康,其它应用模块的响应和整体的服务都不受到影响,保证快速准确的返回,并且前端页面展示的美观也不受到影响。
本发明可以有效的避免因数据源不可靠、程序死锁、外部业务服务调用阻塞等难以控制的因素长时间阻塞Web服务器的HTTP主线程,从而引发页面展示慢、页面无法展示甚至Web服务器资源耗尽等导致宕机、重启的严重问题。能大幅度增强依赖多个数据源、多个外部服务、需要动态展现的Web应用服务的健壮性。
具体实施方式
图1显示了本发明的方法的一个实施例的流程图,该方法包括如下步骤:
A)收到客户端的请求后,建立一个主线程;
一般地,Web服务是通过浏览器进行,因此该请求为HTTP请求,建立的主线程为HTTP线程。
B)在主线程中,生成所述请求的副本;
优选地,分析所述请求涉及的业务模块的数量,然后生成与所涉及的业务模块数量相同的副本。即,该请求涉及多少个业务模块,则生成多少个副本。业务模块是预先定义的,根据具体服务业务而设定。
更优选的,所述业务模块是彼此独立的,也就是说,将Web服务按照功能和数据的交互而划分为独立的业务模块。这里“独立”的含义是业务模块的数据源(例如,包括但不限于关系型数据库)之间互不干扰,任何一个业务模块的数据源崩溃,对其它业务模块的数据源无影响。只要主线程健康,其它没有问题的业务模块就能被正常展现。而且,无论多少业务模块只占用1个HTTP连接,属于这个HTTP连接线程(即主线程)的所有数据(例如内存中的数据)被所有业务模块“共享”。
C)在主线程中,将所述副本分发到所涉及的业务模块,并设置超时响应时间;
优选地,采用异步模式来将所述副本分发到所涉及的业务模块。异步方式分发可以确保不会因为一个业务模块无法收到副本而阻塞整个主线程。设置超时响应时间是为了如果一个独立业务模块出现故障,没有返回任何响应时,主线程可以及时组装应答反馈给客户端,改善用户体验。异步模式分发副本具体可以采用子线程的方式。
D)所涉及的业务模块执行请求的业务;
业务模块在执行业务时会出现三种情况。第一种,业务顺利完成而且在所述超时时间内,则主线程能够收到正确执行结果。第二种,业务顺利完成但时间超过了所述超时时间。第三种,业务模块发生故障卡死,业务没有被顺利执行。后两种情况中,业务模块有可能无法向主线程反馈信息,Web服务则不能及时向客户端响应,产生与现有技术相同的问题。因此,有必要通过如下步骤E)来解决该问题。
E)在主线程中,在所述超时响应时间内等待所涉及的业务模块的执行结果;
主线程在超时响应时间内等待业务模块的反馈,当业务模块出现上述第二、第三种情况时,主线程则不再等待,结束与该业务模块的通信,例如结束子线程。
更有利地,针对不同的业务模块设置不同的超时响应时间。还可以动态决定超时响应时间。
在一种实施方式中,动态决定体现于针对每次的请求重新设置超时响应时间。现实中的情况为,不同的请求所请求的服务复杂性是不同的,在分析完请求所涉及的业务模块时,如果涉及的业务模块数量多,可以将超时响应时间设定的稍长。如果涉及到了业务复杂的业务模块,也可以将超时时间设定的稍长。
在另外一种实施方式中,动态决定体现于,根据业务模块的执行进度而调整超时响应时间。在执行业务过程中,主线程询问业务模块的执行进度,如果判断在超时响应时间的超时阈值(例如超时了原时间的50%)内业务模块能够完成执行进度,则延长超时响应时间。例如在超时响应时间过了1/2时,业务模块的执行进度为40%,则预期超过超时响应时间25%时可完成任务,则将超时响应时间延长,例如延长原时间的1/2。
有利地,主线程中还有检测这些请求副本是否得到成功应答的机制。一种实施方式为,主线程查询业务模块的特定存储区,该存储区存储了业务模块的执行状态,主线程设置定时器,在超时响应时间到达后,判断存储区的状态即可检测请求副本是否得到成功应答。另一种实施方式为,主线程查询业务模块,设定定时器,超时响应时间到达后,业务模块没有返回正确应答,则认为请求副本没有得到成功应答,否则,认为请求副本得到了成功应答。
通过设定超时时间的机制迫使请求在限定的时间内应答,并有效的将后台业务模块的错误、超时、阻塞等问题抛弃(但是,可以保存日志以供后续分析),对前端的页面展示屏蔽后台业务模块的错误,使用户体验不受到影响。
F)在主线程中,根据所述执行结果和超时情况,向客户端发送应答;
当全部请求副本都应答返回或超时时间到达,这两个条件满足任意其一,主线程立即将各个应答副本组装成一个应答向客户端发出。
如果业务模块反馈的是正常响应结果,则主线程生成包括执行结果的应答,发送至客户端。如果在超时时间内未收到业务模块的应答,则主线程生成包括异常信息的应答,发送至客户端。异常信息例如可以是指示“时间超时”的信息。
更具体地,在超时时间内所有请求副本都返回应答副本,则所有应答被组装成1个应答发向客户端。如果超时时间到达,只有部分请求副本返回了应答副本,也组装1个应答,正常地发向客户端,但是没有应答对应的业务模块会被“空内容”应答填充。
优选地,如果在超时后收到了业务模块的执行结果,例如业务模块发生了第二种情况,则可以重新成包括执行结果的应答,发送至客户端。
有利地,主线程还动态决定超时的业务模块的超时反馈内容:对业务模块设置标识;实时建立业务模块与超时响应策略的映射关系,例如业务模块1-超时返回空内容、业务模块2-超时返回静态内容;根据该映射关系,当业务模块超时未反馈应答时,主线程根据该映射关系组装反馈给用户的应答。
G)终止该主线程;
在该请求完成后,主线程应结束,释放线程资源。
在另一方面,本发明提供一种Web应用服务系统,该系统的一个实施例的结构示意图如图2所示。所述系统包括客户端201和Web服务器203,客户端201具有Web浏览器以向Web服务器203发起HTTP请求204。Web服务器203具有服务端控制器202和至少一个业务模块。服务端控制器202接收所述请求204并为该请求创建一个主线程。在该主线程中,服务端控制器202还生成所述请求204的副本,副本的数量与所述请求所涉及的业务模块是数量相同。在图2的实施例中显示了3个业务模块203a、203b、203c,实际中可以根据需要设定业务模块的数量。
要进一步说明的是,业务模块的划分是预先设定的,根据Web应用服务的功能进行。更优选地,业务模块彼此是独立的,也就是说业务模块彼此之间互不干扰。
服务控制器202将生成的请求204的副本205a、205b、205c分别异步地发送到对应的业务模块203a、203b、203c,并设置超时响应时间。所述各业务模块执行请求的业务。服务控制器202在所述超时响应时间内等待所涉及的业务模块的执行结果或超时响应结果,所述执行结果或超时响应结果作为应答副本206a、206b、206c反馈到服务控制器202。服务控制器202根据所述各应答副本206a、206b、206c生成应答207,向客户端201发送应答207。
图3显示了图2的系统的时序图,可以看到,在该Web系统中,所有的请求和应答都是异步地,即使后台某个业务模块出现严重问题,只要HTTP主线程服务是独立、健康的,则Web服务响应的及时性、有效性和可用性都能得到保证和控制。
其中要说明的是,当全部请求副本都应答返回或超时时间到达,这两个条件满足任意其一,主线程立即将各个应答副本组装成一个应答向客户端发出。如图3,在超时时间内3个请求副本都应答返回,则3个应答副本被组装成1个应答发向客户端(207a);如果超时时间到达,只有2个或1个或0个应答返回,1个应答也会被成功组装,正常的发向客户端(207b),但是没有应答的副本对应的子模块会被“空内容”应答填充。