一种提供数据服务的处理系统及方法 【技术领域】
本申请涉及网络数据服务技术， 特别涉及一种提供数据服务的处理系统及方法。背景技术 下面先对技术术语进行简要说明。
反向代理 (Reverse Proxy) ： 在客户端 - 服务器架构的系统中位于服务器一侧的 真实服务之前的转发服务， 可用于服务侧负载均衡、 客户端请求过滤转发等用途。
拒绝服务 (Denial ofService) ： 一种网站故障现象， 表现为用户无法与网站正常 建立连接。针对网站进行的攻击行为或网站内部服务故障都有可能引起该现象。
Web 前端服务 (Web Front-end Service) ： 网站分层架构角色之一， 作用为 ： 直接 接受外部用户的 HTTP(Hypertext Transfer Protocol， 超文本传送协议 ) 连接， 综合使用内 部服务处理用户请求， 向外部用户发送 HTTP 形式的响应结果。
慢速交互 (Slow Interaction) ： 指客户端 - 服务器架构中由于网络故障或攻击行 为等原因造成请求或响应数据以远低于正常水平的速率进行传输的现象。
I/O 复用服务模型 (I/O Multiplexing Service Model) ： 一种通用网络服务模型， 将网络连接的状态变化表述为事件， 由不断产生的事件驱动业务逻辑循环运行， 多个网络 连接可以在同一循环内同时进行处理。该模型具备很好的并发连接处理能力， 且对慢速交 互过程有很强的耐受能力 ； 在该模型中业务逻辑需要显式拆分为状态机， 开发难度较高。
线程服务模型 (Threading Service Model) ： 一种通用网络服务模型， 为每个网络 连接分配一个服务线程， 服务线程内部逻辑阻塞等待网络连接传入请求数据， 进行顺序处 理并响应结果， 网络连接断开时服务线程得到释放， 可被分配处理其他传入的网络连接。 该 模型允许业务逻辑以自然的顺序流程表述， 开发难度不大 ； 在该模型中服务线程数量有限， 并发处理和慢速交互耐受能力受到较大限制， 容易产生拒绝服务 (DoS) 问题。
大型网站的 Web 前端访问量大、 受关注程度高， 会经由各种不同的复杂网络环境 向用户提供服务。 为了简化 Web 前端难度， 提高开发效率， 会大量使用主要代表为 PHP( 一种 新型的 CGI(Common Gateway Interface， 公共网关接口 ) 网络程序编写语言 ) 的脚本类语 言实现前端业务逻辑， 此时一般会配合使用 Apache 结合内置 PHP 解释器或 Nginx/Lighttpd 结合 FastCGI(FastCommon Gateway Interface， 快速公共网关接口， 是一种改进的 CGI 协 议 ) 方式运行的 PHP 解释器的实现方式。由于此类线程型服务模型自身的限制， 单个前端 服务线程同时只能服务于一个用户连接。受到前端服务器资源的限制， 每台服务器上能够 启用的服务线程数量是有限的， 当外部网络出现问题或网站遭受慢速连接攻击时， 很容易 出现所有服务线程被耗尽导致无法为新的用户连接提供服务的情况 ； 即使对外网络环境正 常， 若前端处理逻辑本身调用的外部接口就需要消耗较长时间， 也同样会因为短时间内服 务线程耗尽产生拒绝服务的现象。
目前， 对于由外部网络问题或攻击行为造成的大量慢速连接的一般处理方法是增 加一级反向代理 (Reverse Proxy)， 使用基于 I/O 复用服务模型的轻量级 Web 服务器 ( 例
如 Nginx 或 Lighttpd) 作为反向代理充当用户连接缓冲， 仅将发送了完整请求的用户连接 转发到原有 Apache 前端服务上进行正常的业务处理。由于基于 I/O 复用的轻量级 Web 服 务器对于大量慢速连接具有极佳的耐受能力， 这种方案可以很好地解决此类慢速连接引起 的拒绝服务问题。
现有增加一级反向代理的方案虽然能解决由于外部网络问题或攻击行为产生的 慢速连接引起的拒绝服务问题， 但是， 该方案的不足在于 ： 对于前端处理逻辑中本身就需要 调用耗时较长的外部接口而引起的拒绝服务则没有任何改进效果。 发明内容 本申请所解决的技术问题在于提供了一种提供数据服务的处理系统及方法， 用以 解决在前端处理逻辑中因需要调用耗时较长的外部接口而引起的拒绝服务的问题。
本申请实施例中提供了一种提供数据服务的处理系统， 包括 ：
前端服务初始逻辑模块， 用于在接收到用户的提供数据服务的业务请求后， 确定 提供业务的过程中是否需调用外部接口 ； 在需要调用外部接口时， 基于调用外部接口的位 置将业务拆分为初始逻辑业务与后续逻辑业务， 所述初始业务逻辑为调用外部接口位置前 的逻辑业务， 所述后续业务逻辑为调用外部接口位置后的逻辑业务 ； 并对初始逻辑业务进 行处理后向反向代理服务器返回分段响应处理结果 ；
反向代理服务器， 用于根据分段响应结果的请求调用外部接口， 在调用的外部接 口返回响应结果后， 将分段响应结果与调用外部接口返回的响应结果提供给前端服务后续 逻辑模块 ；
前端服务后续逻辑模块， 用于将分段响应结果与调用外部接口返回的响应结果整 合成提供给用户的数据服务结果后返回反向代理服务器 ；
反向代理服务器还用于向用户返回数据服务结果。
较佳地， 所述前端服务初始逻辑模块进一步用于返回包括 ： 传递给所述前端服 务后续逻辑模块的上下文状态数据、 委托所述反向代理服务器进行慢速服务的请求、 以及 慢速服务请求完成后要调用的所述前端服务后续逻辑模块的逻辑地址的分段响应处理结 果；
所述反向代理服务器进一步用于根据所述委托所述反向代理服务器进行慢速服 务的请求调用外部接口， 在调用的外部接口返回响应结果后， 将响应结果同所述上下文状 态数据按所述前端服务后续逻辑模块的逻辑地址提供给前端服务后续逻辑模块。
较佳地， 所述前端服务后续逻辑模块进一步用于根据响应结果同所述上下文状态 数据按用户请求的业务类型整合成提供给用户的数据服务结果。
较佳地， 所述前端服务后续逻辑模块进一步用于将数据服务结果以超文本传送协 议 HTTP 响应形式返回反向代理服务器。
较佳地， 所述前端服务初始逻辑模块进一步用于在提供业务的过程中， 当调用的 接口平均响应时间在 ms 级以上时， 确定提供业务的过程中需调用外部接口。
本申请实施例中还提供了一种提供数据服务的处理方法， 包括如下步骤 ：
在接收到用户的提供数据服务的业务请求后， 确定提供业务的过程中是否需调用 外部接口 ；
在需要调用外部接口时， 基于调用外部接口的位置将业务拆分为初始逻辑业务与 后续逻辑业务， 所述初始业务逻辑为调用外部接口位置前的逻辑业务， 所述后续业务逻辑 为调用外部接口位置后的逻辑业务 ；
对初始逻辑业务进行处理， 并向反向代理服务器返回分段响应处理结果 ；
反向代理服务器根据分段响应结果的请求调用外部接口 ；
在调用的外部接口返回响应结果后， 将分段响应结果与调用外部接口返回的响应 结果整合成提供给用户的数据服务结果 ；
向用户返回数据服务结果。
较佳地， 所述分段响应处理结果包括 ： 传递给前端服务后续逻辑的上下文状态数 据、 委托所述反向代理服务器进行慢速服务的请求、 以及慢速服务请求完成后要调用的前 端服务后续逻辑的地址 ；
反向代理服务器根据分段响应结果的请求调用外部接口时， 是根据所述委托所述 反向代理服务器进行慢速服务的请求调用外部接口的 ；
在调用的外部接口返回响应结果后， 将分段响应结果与调用外部接口返回的响应 结果整合成提供给用户的数据服务结果， 是将响应结果同所述上下文状态数据按所述前端 服务后续逻辑的地址提供给前端服务后续逻辑。 较佳地， 将分段响应结果与响应结果整合成提供给用户的数据服务结果， 是前端 服务后续逻辑根据响应结果同所述上下文状态数据按用户请求的业务类型整合成提供给 用户的数据服务结果。
较佳地， 将数据服务结果以 HTTP 响应形式返回反向代理服务器。
较佳地， 在提供业务的过程中， 在确定提供业务的过程中是否需调用外部接口时， 当调用的接口平均响应时间在 ms 级以上时， 确定提供业务的过程中需调用外部接口。
本申请有益效果如下 ：
在本申请实施例提供的技术方案中， 在接收到用户的提供数据服务的业务请求 后， 首先需要确定提供业务的过程中是否需调用外部接口 ； 在确定需要调用外部接口时， 则 开始分段， 即： 基于调用外部接口的位置将业务拆分为初始逻辑业务与后续逻辑业务 ；
然后， 对初始逻辑业务进行处理， 并向反向代理服务器返回分段响应处理结果 ； 而 反向代理服务器根据分段响应结果的请求调用外部接口 ； 并在调用的外部接口返回响应 结果后， 将分段响应结果与调用外部接口返回的响应结果整合成提供给用户的数据服务结 果。
由于在本申请提供的技术方案中引入了分段反向代理， 将原本在前端逻辑中阻塞 进行的慢速服务请求委托给分段反向代理进行， 而在 Web 前端服务中将处理逻辑切分成多 段， 通过前置额外的代理服务处理阻塞操作并将这些分段的处理逻辑联系在一起， 从而避 免了前端逻辑被阻塞， 使得前端服务能够连续处理新请求而不用浪费时间在等待外部服务 请求的响应上。
附图说明
图 1 为本申请实施例中提供数据服务的处理系统结构示意图 ； 图 2 为本申请实施例中提供数据服务处理的原理示意图 ；图 3 为本申请实施例中提供数据服务的处理系统实施流程示意图 ； 图 4 为本申请实施例中提供数据服务的处理方法实施流程示意图 ； 图 5 为本申请实施例中现有技术的前端处理的时序示意图 ； 图 6 为本申请实施例中采用分段式反向代理处理的时序示意图。具体实施方式
下面结合附图对本申请的具体实施方式进行说明。
发明人在发明过程中注意到 ： 现有增加一级反向代理的方案虽然能解决由于外部 网络问题或攻击行为产生的慢速连接引起的拒绝服务问题， 但是， 对于前端处理逻辑中本 身就需要调用耗时较长的外部接口而引起的拒绝服务则没有任何改进效果。
例如， 对于前端处理逻辑中本身就需要调用耗时较长的外部接口这样的业务有 ：
前端生成用户个人信息等动态响应页面时需通过数据库接口从后端数据库获取 必要数据。 一般情况下数据库获取数据过程的耗时都大于 5ms， 而前端得到数据后生成页面 过程的耗时为 us 级， 因此等待外部数据库接口返回数据的耗时远大于前端生成页面的耗 时； 前端对外提供 HTTP API(Application Program Interface， 应用编程接口 ) 服务 时， 对每个 API 请求的处理都要调用一个或多个不同的内部 HTTP API。 每个内部 HTTPAPI 的 耗时从 2-100ms 不等， 而前端对它们的结果进行解析处理并生成最终响应的耗时为 us 级， 因此等待内部 HTTP API 返回数据的耗时远大于前端得到数据后产生 API 响应的耗时。
基于此， 本申请实施例提供的技术方案针对这种情况， 提出了分段反向代理 (Staged Reverse Proxy) 的概念， 利用 I/O 复用型轻量级 Web 服务器本身对慢速连接的良 好处理能力， 实现了将原本在前端脚本内进行的外部接口调用委托给分段反向代理 ( 使用 轻量级 Web 服务器实现 ) 处理的通用方案， 使得前端服务程序不必浪费大量时间在等待外 部接口返回结果上， 而可以持续不断地处理新的用户连接， 能够显著提高前端服务的并发 吞吐量并避免拒绝服务情况的产生。下面对具体实施方式进行说明。
图 1 为提供数据服务的处理系统结构示意图， 如图所示， 在系统中可以包括 ：
前端服务初始逻辑模块 101， 用于在接收到用户的提供数据服务的业务请求后， 确 定提供业务的过程中是否需调用外部接口 ； 在需要调用外部接口时， 基于调用外部接口的 位置将业务拆分为初始逻辑业务与后续逻辑业务， 所述初始业务逻辑为调用外部接口位置 前的逻辑业务， 所述后续业务逻辑为调用外部接口位置后的逻辑业务 ； 并对初始逻辑业务 进行处理后向反向代理服务器返回分段响应处理结果 ；
反向代理服务器 102， 用于根据分段响应结果的请求调用外部接口， 在调用的外部 接口返回响应结果后， 将分段响应结果与调用外部接口返回的响应结果提供给前端服务后 续逻辑模块 ；
前端服务后续逻辑模块 103， 用于将分段响应结果与调用外部接口返回的响应结 果整合成提供给用户的数据服务结果后返回反向代理服务器 ；
反向代理服务器 102 还用于向用户返回数据服务结果。
前端服务初始逻辑模块与前端服务后续逻辑模块的划分是从逻辑功能上来划分 的， 其与物理实体的关系在实施中可以是 ： 由前端服务初始逻辑模块与前端服务后续逻辑
模块共同构成一台物理上的前端服务器 ； 当然也可以是两台或者多台服务器分别来执行前 端服务初始逻辑模块与前端服务后续逻辑模块的功能， 共同构成一个前端服务器系统。
实施中， 需要确保前端服务初始逻辑模块与前端服务后续逻辑模块中没有包含慢 速外部服务 ( 以下简称慢速服务 ) 调用， 因为这些调用耗时比剩余的业务逻辑处理耗时长 得多， 因此应该没有包含慢速业务， 否则无法以分段的方式来使反向代理提升性能。当这 些条件满足时， 便可以基于慢速外部服务接口调用位置来拆分初始逻辑和后续逻辑。慢速 外部服务接口在实施中主要可以包括数据库、 HTTP API 等平均响应时间在 ms 级以上的接 口。 以慢速服务接口为界， 调用接口之前的业务逻辑为初始逻辑， 接口返回结果后的业务逻 辑为后续逻辑。具体实施中， 当后续逻辑中也含有慢速服务接口调用时， 依然可以按此原 则将其继续拆分为新的初始逻辑和后续逻辑。那么， 可见， 通过上述方案， 慢速服务接口调 用本身则替换为对分段反向代理返回中间响应结果及后续逻辑路径， 由分段反向代理将拆 分开的多片业务逻辑串联起来运行。图 2 为提供数据服务处理的原理示意图， 如图所示， 将 原始前端逻辑处理的业务进行拆分， 拆分成初始逻辑部分 (init_logic) 与后续逻辑部分 (next_logic)， 图中 SRP 表示外部接口。则由图可见， 则有 ：
一个用户包括了需要调用外部 HTTP 接口的、 要求提供数据服务的业务请求示意 为：
//... 初始逻辑 ... // 调用外部 HTTP 接口 Resp ＝ http_request(API_url) //... 后续逻辑 ( 使用调用结果 resp)... 则分拆分为初始逻辑部分处理的业务示意为 ： //... 初始逻辑 ... // 响应中间结果， 要求 SRP 调用 HTTP 接口 // 继续执行后续逻辑 srp_request(API_url， ’ /next_logic’ ， ctx) 然后外部接口 SRP 返回响应结果给后续逻辑部分， 后续逻辑部分执行的业务示意为： // 还原初始逻辑传递的上下文数据 (resp， ctx) ＝ srp_parse()
//... 后续逻辑 ( 使用调用结果 resp)...
在上述处理过程中， 由反向代理服务器处理的是中间调用外部 HTTP 接口的响应 结果， 反向代理服务器要从中提取数据库 /HTTP API 请求目标、 维持逻辑状态的上下文数据 以及后续逻辑代码的位置， 并据此发起对慢速外部服务的请求并在获得响应数据后能够正 确地调用前端服务后续逻辑模块执行后续逻辑的继续处理。
实施中， 业务逻辑中不需要同外部服务交互的部分都是由前端服务初始逻辑模块 与前端服务后续逻辑模块构成的前端服务自行处理的。数据库 /HTTPAPI 请求由反向代理 服务器发送到慢速服务后在慢速服务一侧进行处理， 分段反向代理本身只是等待慢速服务 返回响应结果。
实施中， 前端服务初始逻辑模块还可以进一步用于返回包括 ： 传递给所述前端服 务后续逻辑模块的上下文状态数据、 委托所述反向代理服务器进行慢速服务的请求、 以及 慢速服务请求完成后要调用的所述前端服务后续逻辑模块的逻辑地址的分段响应处理结
果； 则反向代理服务器还可以进一步用于根据所述委托所述反向代理服务器进行慢 速服务的请求调用外部接口， 在调用的外部接口返回响应结果后， 将响应结果同所述上下 文状态数据按所述前端服务后续逻辑模块的逻辑地址提供给前端服务后续逻辑模块。
实施中， 前端服务后续逻辑模块还可以进一步用于根据响应结果同所述上下文状 态数据按用户请求的业务类型整合成提供给用户的数据服务结果。
实施中， 前端服务后续逻辑模块还可以进一步用于将数据服务结果以 HTTP 响应 形式返回反向代理服务器。
实施中， 前端服务初始逻辑模块还可以进一步用于在提供业务的过程中， 当调用 的接口平均响应时间在 ms 级以上时， 确定提供业务的过程中需调用外部接口。
为了更好的理解上述实施， 下面以实例进行说明。
图 3 为提供数据服务的处理系统实施流程示意图， 则如图所示， 系统在提供数据 服务时可以包括如下步骤 ：
步骤 301、 用户通过浏览器向网站前端发起 HTTP 服务请求 ；
步骤 302、 反向代理服务器处理用户的 HTTP 服务请求， 将请求数据收集完整后转 发到处理前端处理逻辑初始部分的前端服务初始逻辑模块 ；
步骤 303、 前端服务初始逻辑模块对用户请求进行处理， 若需要使用其他慢速服务 的结果， 则以 HTTP 格式传回一个分段响应结果， 其中含有三部分信息 ： 传递给前端服务后 续逻辑模块的上下文状态数据、 委托反向代理服务器进行慢速服务的请求、 以及慢速服务 请求完成后要调用的前端服务后续逻辑模块逻辑地址 ；
步骤 304、 反向代理服务器收到前端服务初始逻辑模块返回的分段响应结果， 将上 下文状态数据保存下来， 同时向慢速服务发起请求， 等待其响应结果 ；
步骤 305、 慢速服务向反向代理服务器返回响应结果 ；
步骤 306、 反向代理服务器将慢速服务的响应结果同之前保存的上下文状态数据 整合后， 向前端服务后续逻辑模块地址发起新的处理请求 ；
步骤 307、 前端服务后续逻辑模块根据反向代理服务器传入的上下文数据以及慢 速服务响应结果， 完成用户请求的处理， 并以 HTTP 响应形式返回最终结果 ；
步骤 308、 反向代理服务器将最终结果以 HTTP 响应形式转发给用户的浏览器， 完 成用户连接的处理。
在步骤 302 时反向代理接收到完整的用户请求数据后才向真正的前端服务转发 请求， 保证了前端服务不会被慢速连接所阻塞， 这一点特性同通用的反向代理方案相同 ； 但 是在步骤 303-307 中， 原本在前端逻辑中阻塞处理的慢速服务请求被交给了分段反向代理 进行， 本来会浪费在阻塞等待慢速服务响应上的前端处理资源现在可以被释放出来处理其 他的用户请求， 同时分段反向代理也不会被慢速服务所阻塞， 从而实现了总吞吐量的显著 提高。
基于同一发明构思， 本申请实施例中还提供了一种提供数据服务的处理方法， 由 于该方法解决问题的原理与一种提供数据服务的处理系统相似， 因此该方法的实施可以参 见系统的实施， 重复之处不在赘述。
图 4 为提供数据服务的处理方法实施流程示意图， 如图所示， 在提供数据服务的
过程中可以包括如下步骤 ：
步骤 401、 在接收到用户的提供数据服务的业务请求后， 确定提供业务的过程中是 否需调用外部接口 ；
步骤 402、 在需要调用外部接口时， 基于调用外部接口的位置将业务拆分为初始逻 辑业务与后续逻辑业务， 所述初始业务逻辑为调用外部接口位置前的逻辑业务， 所述后续 业务逻辑为调用外部接口位置后的逻辑业务 ；
步骤 403、 对初始逻辑业务进行处理， 并向反向代理服务器返回分段响应处理结 果；
步骤 404、 反向代理服务器根据分段响应结果的请求调用外部接口 ；
步骤 405、 在调用的外部接口返回响应结果后， 将分段响应结果与响应结果整合成 提供给用户的数据服务结果 ；
步骤 406、 向用户返回数据服务结果。
实施中， 分段响应处理结果可以包括 ： 传递给前端服务后续逻辑的上下文状态数 据、 委托所述反向代理服务器进行慢速服务的请求、 以及慢速服务请求完成后要调用的前 端服务后续逻辑的地址 ； 则， 在反向代理服务器根据分段响应结果的请求调用外部接口时， 可以是根据所 述委托所述反向代理服务器进行慢速服务的请求调用外部接口的 ；
在调用的外部接口返回响应结果后， 将分段响应结果与响应结果整合成提供给用 户的数据服务结果， 可以是将响应结果同所述上下文状态数据按所述前端服务后续逻辑的 地址提供给前端服务后续逻辑。
实施中， 将分段响应结果与响应结果整合成提供给用户的数据服务结果， 可以是 前端服务后续逻辑根据响应结果同所述上下文状态数据按用户请求的业务类型整合成提 供给用户的数据服务结果。
实施中， 可以将数据服务结果以 HTTP 响应形式返回反向代理服务器。
实施中， 在提供业务的过程中， 在确定提供业务的过程中是否需调用外部接口时， 可以是当调用的接口平均响应时间在 ms 级以上时， 确定提供业务的过程中需调用外部接 口。
为了进一步的理解上述提供数据服务的处理系统与方法的技术方案， 以开放平台 对外提供的用户信息查询服务 (HTTP API 形式 ) 为例结合现有技术的方案再进行说明。
现有技术的处理方案， 该服务的原始业务逻辑为 ： 收到用户信息查询请求时， 根据 密钥等信息验证请求是否合法， 若验证未通过则拒绝服务 ； 验证通过时， 开放平台服务调用 HTTP 形式的后台用户信息系统接口查询对应用户的公开信息， 并基于用户查询请求中指定 的格式将这些信息转换为 XML 或 JSON 格式响应给用户， 从而完成一次查询请求的处理。
在采用本申请实施例所提供的技术方案， 在采用分段式的反向代理之后， 业务逻 辑变为 ：
分段反向代理 ： 收到用户信息查询 HTTP 请求， 向前端服务发起对初始逻辑代码位 置的 HTTP 请求转发查询数据。
前端服务 ( 初始逻辑部分 ) ： 从查询请求解析出密钥等验证信息， 检查请求是否合 法； 若请求非法则直接响应错误信息， 否则构造中间结果 ( 包括后台用户信息系统查询的
URL、 查询请求中指定的响应格式 ( 即上下文数据 ) 和前端服务后续逻辑代码的位置 ) 作为 响应。
反向代理 ： 接收前端服务初始逻辑的响应结果， 若响应是错误信息则以其作为最 终响应结束查询请求的处理过程 ； 若响应是中间结果， 则将其暂时缓存起来， 从中提取出后 台用户信息系统查询 URL 后对该 URL 发起 HTTP 请求。
慢速服务 ( 即后台用户信息系统 ) ： 收到分段反向代理发送的 HTTP 查询请求， 查 找数据库中的用户数据并响应给分段反向代理。
反向代理 ： 后台用户信息系统发起的 HTTP 请求返回响应数据时， 从之前缓存的中 间结果中提取响应格式和后续逻辑代码位置， 向前端服务发起对后续逻辑代码位置的 HTTP 请求， 并发送后台用户信息系统的响应数据和查询请求指定的响应格式作为请求体。
前端服务 ( 后续逻辑部分 ) ： 从请求中提取出响应格式和后台用户信息系统的响 应数据， 构造出指定格式的最终响应结果返回给分段反向代理。
反向代理 ： 接收前端服务后续逻辑的响应结果， 将其作为最终响应结束查询请求 的处理过程。
进一步的， 为了更好的了解上述提供数据服务的处理系统与方法的技术方案， 下 面从原理上来说明本申请实施例提供的技术方案的技术效果。 在本申请实施例提供的技术方案中， 前端逻辑要在所有涉及慢速服务调用的地方 拆分， 故总的分段数为 n+1(n 为原前端逻辑中所有慢速服务调用次数 )， 并不总是 2 段。拆 分逻辑后， 等待慢速服务响应的职责从前端服务转移到了分段反向代理， 因此前端服务上 原被浪费在等待上的时间可以用来继续处理新的客户请求， 总体来看请求吞吐量就有了明 显的提升， 但从每个请求自己的处理时间来看是没有变化的。
图 5 为现有技术的前端处理的时序示意图， 图中是以单个服务线程为例进行示意 的， 则如图所示， 在按现有技术方式， 不使用分段式的反向代理时， 前端服务的连续请求处 理时序如图所示为 ：
每个请求的总处理时间为 T ＝ Tc1+Tw+Tc2， 这里 Tc1 为外部服务请求前的业务逻 辑处理耗时， Tw 为等待外部服务请求响应耗时， Tc2 为外部服务请求后的业务逻辑处理耗 时， 且有 Tw ＞＞ Tc1 或 Tc2。易知这种理想时序情况下的请求吞吐量就是 QPS1 ＝ 1/T( 次 / 秒 )， 由于存在其他开销， 实际情况下的最大吞吐量会略低于该理论值。
图 6 为采用分段式反向代理处理的时序示意图， 图中仍以单个服务线程为例进行 示意， 则使用分段反向代理时， 前端服务的连续请求处理时序如图所示为 ：
此时每个请求的总处理时间仍然是 T ＝ Tc1+Tw+Tc2。但对图中下侧的前端服 务来说， 在这种理想时序情况下的请求吞吐量变为了 QPS2 ＝ 1/(Tc1+Tc2)( 次 / 秒 )， 而 QPS2 ∶ QPS1 ＝ T:(Tc1+Tc2) ＝ T:(T-Tw)。若以 Tw 为 ms 级、 Tc1 和 Tc2 为 us 级的标准量 级估计， 则 QPS2 ∶ QPS1 约为 1000 ∶ 1， 因此采用分段反向代理后可以极大地增加总请求吞 吐量。达到这种效果的关键之处在于分段反向代理是 I/O 复用结构， 可以并发进行大量连 接的响应等待而不消耗太多资源， 这样才能将大量前端服务返回的中间响应结果交给它， 使前端服务能够连续处理新请求而不用浪费时间在等待外部服务请求的响应上。
在实际的实施过程中， 为了在已有前端服务中应用本申请实施例提供的技术方 案， 需要对原来的前端服务代码进行少量修改， 在涉及到同慢速服务交互的部分将前端代
码人为切断为两段 ： 上半段结束时按照方案定义的分段响应结果格式返回上下文数据、 慢 速服务请求数据以及下半段代码位置 ； 下半段从请求数据中解析出上下文数据恢复现场， 并根据慢速服务请求数据继续完成用户请求的处理。 考虑到前端处理逻辑中涉及慢速服务 请求的地方通常较少， 需要进行这种代码修改的工作量一般是可以接受的。
同时， 在应用本申请实施例中提供的技术方案时， 前端处理逻辑的实现语言并不 仅限于 PHP， 实际上只要具备解析 HTTP 请求并以 HTTP 格式返回分段响应结果的能力， 任 何计算机语言都可以使用， 这也说明本申请实施例提供的技术方案也是一种通用性解决方 案。
实施中， 为了达到更好的实施效果， 分段反向代理部分还可以使用基于 C 语言实 现的 I/O 复用轻量级 Web 服务器 ( 例如 Nginx 或 Lighttpd)， 以最小化反向代理带来的处理 开销。实际的前端服务可以使用普通线程型 Web 服务器 ( 例如 Apache) 或轻量级 I/O 复用 Web 服务器和 FastCGI 方式运行的语言解释器实现处理逻辑 ； 使用操作系统提供的其他 I/ O 复用接口 ( 例如 FreeBSD 的 kqueue 或 Linux 的 epoll) 自行实现分段反向代理服务器全 部逻辑。
由上述说明可见， 由于在本申请提供的技术方案中引入了分段反向代理的角色， 将原本在前端逻辑中阻塞进行的慢速服务请求委托给分段反向代理进行。在 Web 前端服务 中将处理逻辑切分成多段， 通过前置额外的代理服务处理阻塞操作并将这些分段的处理逻 辑联系在一起， 从而避免了前端逻辑被阻塞， 使得前端服务能够连续处理新请求而不用浪 费时间在等待外部服务请求的响应上。 本领域内的技术人员应明白， 本申请的实施例可提供为方法、 系统、 或计算机程序 产品。因此， 本申请可采用完全硬件实施例、 完全软件实施例、 或结合软件和硬件方面的实 施例的形式。而且， 本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机 可用存储介质 ( 包括但不限于磁盘存储器、 CD-ROM、 光学存储器等 ) 上实施的计算机程序产 品的形式。
本申请是参照根据本申请实施例的方法、 设备 ( 系统 )、 和计算机程序产品的流程 图和 / 或方框图来描述的。应理解可由计算机程序指令实现流程图和 / 或方框图中的每一 流程和 / 或方框、 以及流程图和 / 或方框图中的流程和 / 或方框的结合。可提供这些计算 机程序指令到通用计算机、 专用计算机、 嵌入式处理机或其他可编程数据处理设备的处理 器以产生一个机器， 使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生 用于实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能 的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特 定方式工作的计算机可读存储器中， 使得存储在该计算机可读存储器中的指令产生包括指 令装置的制造品， 该指令装置实现在流程图一个流程或多个流程和 / 或方框图一个方框或 多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上， 使得在计 算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理， 从而在计算机或 其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和 / 或方框图 一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例， 但本领域内的技术人员一旦得知了基本创造 性概念， 则可对这些实施例作出另外的变更和修改。 所以， 所附权利要求意欲解释为包括优 选实施例以及落入本申请范围的所有变更和修改。
显然， 本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精 神和范围。这样， 倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围 之内， 则本申请也意图包含这些改动和变型在内。