CN110287040A - 一种远程调用服务框架的实现系统 - Google Patents

Abstract

一种远程调用服务框架的实现系统，主要包括配置模块、API模块、发送模块、编码模块、解码模块、接收模块等，通过以上几个模块之间的交互和流转，实现消息从请求方到服务方之间的通信。系统基于业界广泛使用的稳定开源NIO框架Netty，提供了基于点对点的同步调用、异步调用和基于CallBack机制的异步调用，为便于维护和沟通交流，该远程调用服务框架被命名为SIF框架。本发明提供了统一的编程模型，简化了调用复杂度，使开发人员更专注于业务逻辑的实现；解决了跨系统联机交易业务日志难以跟踪分析的问题；解决了并发压力过大时需要进行流量控制的问题。

Description

一种远程调用服务框架的实现系统

技术领域

本发明属于Socket通信、RPC调用领域，具体涉及一种远程调用服务框架的实现系统。

背景技术

现在越来越多的公司采用分布式技术来部署应用，应用的部署按功能模块分的越来越细，导致应用的部署量急剧增加，应用间互相交互也越来越频繁。由于系统间的互相调用涉及底层通讯和报文的组装和拆分，各个系统各自实现对技术要求和资源成本是很大的挑战。且各自实现由于没有统一的调用框架对系统间的服务对接难度也会大大增加。目前市面上类似的调用框架要么框架比较复杂对技术和资源投入要求较高，要么封装不够友好使用时仍需要做大量的二次开发。

发明内容

本发明针对现有技术中的不足，提供一种远程调用服务框架的实现系统，该系统基于业界广泛使用的稳定开源NIO框架Netty，提供了基于点对点的同步调用、异步调用和基于CallBack机制的异步调用，为便于维护和沟通交流，该远程调用服务框架被命名为SIF框架。

为实现上述目的，本发明采用以下技术方案：

一种远程调用服务框架的实现系统，其特征在于，分为请求方和服务方，请求方和服务方中均包括配置模块、业务模块、API模块、发送模块、接收模块、编码模块和解码模块，其中，配置模块用于对远程调用服务框架进行初始化配置，服务方的API模块用于提供符合框架规范的接口；请求方的业务模块发送请求参数至请求方的API模块，请求方的API模块对请求参数进行处理，经过请求方的编码模块编码后发送至请求方的发送模块，请求方的发送模块将请求参数封装成符合框架定义要求的报文数据格式并发送至服务方的接收模块，报文经过服务方的解码模块解码后，发送至服务方的业务模块，服务方的业务模块根据报文完成业务的具体处理并生成业务返回参数Map，业务返回参数Map依次经过服务方的编码模块、服务方的发送模块、请求方的接收模块、请求方的解码模块、请求方的API模块后，最终发送至请求方的业务模块。

为优化上述技术方案，采取的具体措施还包括：

进一步地，配置模块的配置方式基于spring风格的xml文件方式，包括配置：服务应用名和服务方IP地址和服务方端口之间的映射，服务方端口，服务应用名，以及服务方和请求方的处理线程数；配置模块在应用启动时使用Spring加载机制自动加载并完成调用服务框架的初始化操作，供后续API模块的直接调用。

进一步地，请求方的API模块提供了统一的编程模型以及供请求方的业务逻辑进行调用的API接口，请求方通过传入请求参数，对服务方所提供的远程服务进行访问，服务方处理完成后返回业务返回参数Map；其中，请求参数中包括服务应用名、服务接口名、业务请求参数Map、访问超时时间，业务返回参数Map中包含通信层连接结果的报文编码及业务参数的数据。

进一步地，请求方和服务方的发送模块用于生成符合框架要求的报文数据格式及通过内部API发送报文，其中，请求方的发送模块的处理逻辑包括：

1)根据请求方的API模块传入的服务接口名映射获取到远程服务器的IP地址及端口后跟远程服务器建立Socket通信连接；

2)为本次请求赋予唯一的跟踪识别号invokeNo，该invokeNo与本次调用的线程进行关联；

3)将请求方的API模块传入的请求参数和跟踪识别号、请求方应用名、请求方IP地址封装成符合框架定义要求的报文数据格式；

4)调用Netty消息发送方法将报文发送到服务方的接收模块完成报文发送。

进一步地，关联生成规则为：首先从线程中去获取，如果获取成功则使用该invokeNo，如果没有获取到则使用工具类生成全局唯一的32位字符串作为invokeNo，并将该invokeNo跟线程进行关联。

进一步地，请求方的编码模块对请求参数进行编码，将JavaBean数据编码转成字节流的方式，再发送至请求方的发送模块将其封装成报文数据格式；请求方的解码模块对请求方的接收模块的报文进行解码，将字节流转换成JavaBean再从JavaBean中获取到业务返回参数MAP。

进一步地，请求方和服务方的编码模块在编码时先将JavaBean转成Json字符串，再把Json字符串转换成字节流；请求方和服务方的解码模块在解码时先将字节流转换成Json字符串，再把Json字符串转成JavaBean。

进一步地，请求方和服务方的编码模块在编码时直接把JavaBean序列化为字节流；请求方和服务方的解码模块在解码时把字节流反序列化为JavaBean。

进一步地，服务方的接收模块接收请求方的发送模块发送过来的报文，在服务方的解码模块将报文解码成JavaBean后，服务方的业务模块通过获取报文中服务接口的方法获取到具体的业务处理类，并将业务请求参数Map传递到业务处理类中完成业务的具体处理，在业务处理完成后生成业务返回参数Map，由请求方的接收模块将业务返回参数Map返回到请求方。

进一步地，服务方还包括流控模块，在服务器对每个服务接口设置一个并发的阀值X，即阻塞队列的容量为X，当请求过来后先从阻塞队列中获取一个值，然后进行后续的逻辑处理，当逻辑处理完成后再把该值放置到该队列中；当流量过大时，有些请求因无法获取到队列的值则直接返回流控拒绝。

本发明的有益效果是：

1、提供了统一的编程模型，简化调用复杂度，使开发人员更专注于业务逻辑的实现；

2、解决了跨系统联机交易业务日志难以跟踪分析的问题；

3、解决了并发压力过大时需要进行流量控制的问题。

附图说明

图1是本发明各模块之间的流程交互图。

图2是API接口的示意图。

图3是实施例中业务请求的流程示意图。

具体实施方式

现在结合附图对本发明作进一步详细的说明。

本发明主要包括如下几个模块，统一配置模块、统一调用API模块、发送模块、编/解码模块、接收模块等。通过以上几个模块之间的交互和流转实现消息从请求方(即客户端)到服务方(即服务端)之间的通信，服务方设有提供远程服务的服务器，流程交互见图1。

统一配置模块：

该模块主要用于对远程调用服务框架进行初始化配置，配置方式基于spring风格的xml文件方式，包括配置服务应用名(一般为服务方的应用名)和IP地址和端口的映射，服务方的露出端口，服务应用名及服务方和请求方的处理线程数等，具体配置如下：

该配置会在应用启动时使用Spring加载机制自动加载并完成调用框架服务的初始化操作，供后续API模块的直接调用。

统一API模块：

该模块提供了一种统一的编程模型，以及给请求方的业务逻辑进行调用的API接口，请求方通过传入服务应用名、服务接口名、业务请求参数Map、访问超时时间等请求参数，对该远程服务进行访问，服务方处理完成后返回业务返回参数Map，该业务返回参数Map中包含通信层连接结果的报文编码及业务参数的数据。通过该API的调用请求方完全无需处理跟底层通信相关的建立通信连接、创建通道、通信报文的组装和拆分等操作，使开发人员能更专注于业务逻辑的实现。具体API接口如图2所示。

发送模块：

该模块的主要功能为生成符合框架要求的报文数据格式及通过内部API发送报文。其处理逻辑又分为以下几个步骤：

1、根据统一API传入的服务接口名映射获取到远程服务器的IP地址及端口后跟远程服务器建立Socket通信连接；

2、为本次请求赋予唯一的跟踪识别号invokeNo，该invokeNo与本次调用的线程进行关联，生成规则为：首先从线程中去获取，如果获取成功则使用该invokeNo，如果没有获取到则使用工具类生成全局唯一的32位字符串作为invokeNo，并将该invokeNo跟线程进行关联；

3、将统一API接口传入的请求参数和跟踪识别号、请求方应用名、请求方IP地址等封装成符合框架定义要求的报文数据格式；

4、调用Netty消息发送方法将消息发送到服务提供方完成消息发送。

编/解码模块：

该模块主要是对发送模块和接收模块传送的报文数据格式进行一定的编码或解码，在发送模块发送的消息实际是JavaBean格式的消息，在网络层系统间通信时需要的是字节流的方式，所以我们需要通过报文编码模块把JavaBean数据进行编码转成字节流的方式，在接收模块接收到的原始数据是字节流格式的，需要使用解码模块的功能将字节流转换成JavaBean再从JavaBean中获取到业务返回参数MAP，本服务框架提供了两种方式的编码和解码供业务系统使用。

方式一：在编码时先将JavaBean转成Json字符串，再把Json字符串转换成字节流；

在解码时先将字节流转换成Json字符串，再把Json字符串转成JavaBean。

方式二：基于Java序列化和反序列化机制

在编码时直接把JavaBean序列化为字节流；

在解码时把字节流反序列化为JavaBean。

接收模块：

该模块用于服务提供方接收请求方发过来的消息报文，在解码模块将报文解码成JavaBean后，业务模块通过获取报文中的服务接口方法获取到具体的业务处理类，并将业务请求参数Map传递到业务处理类中完成业务的具体处理，在业务处理完成后也由该模块将业务返回参数Map返回到请求方。

业务日志跟踪解决方案：

SIF调用框架通过内嵌的invokeNo机制并结合logback日志打印框架，通过设置专门的ActionAccessLogger的日志名，将invokeNo作为MDC.set方法的参数设置到日志变量中，使logback将该invokeNo打印到该次请求的每一条日志记录中，这样就可以通过invokeNo来搜索到该业务请求经过的系统中打印的所有日志信息。

如图3所示，以某一业务请求为例，该业务请求由最初的请求方app1请求app2，app2收到请求进行相关处理后请求app3，app3处理完请求后返回消息到app2，app2再请求app4，app4处理完请求后返回消息到app2，app2进行处理后返回消息到app1。由此可以看到该业务请求的完成需要app1、app2、app3、app4四个应用配合才能完成。invokeNo详细生成机制为：

1.app1在发送请求时由于app1是最初的请求方即原始请求方，SIF调用框架会自动生成invokeNo，假设生成invokeNo用的随机数为123qwe，则此时invokeNo为123qwe.0即{随机数}+“.0”将该invokeNo发送到app2；

2.app2收到请求后将请求报文中invokeNo即123qwe.0保存到本地线程和logbackMDC中，然后将invokeNo截取最后一位0作为deepNo并保存到本地线程中；

3.app2在发送请求到app3时，线程本地线程中获取到此时的invokeNo，并在invokeNo后拼接上“.{deepNo+1}”，即则此时发送到app3的invokeNo为123qwe.0.1并将该invokeNo发送到app3；

4.app3收到请求后将请求报文中invokeNo即123qwe.0.1保存到本地线程和logback MDC中用于打印日志，该日志记录中带有invokeNo信息；

5.app2在接收到app3的返回报文后，再次发送请求到app4，从本地线程中获取到invokeNo，并在invokeNo后拼接上“.{deepNo+1}”，即此时发送到app4的invokeNo为123qwe.0.2，并将该invokeNo发送到app4；

6.app4收到请求后将请求报文中invokeNo即123qwe.0.2保存到本地线程和logback MDC中用于打印日志，该日志记录中带有invokeNo信息。

通过该生成机制即保障了invokeNo在各个调用请求中日志打印时的联系性和独立性，可以有效的通过关键字的搜索查看整个业务请求的所有日志，及各次调用的日志情况。且能从invokeNo字符串的规则上清晰的看出该日志处于调用链的哪一个层级，有效做到全链路跟踪。

流量控制解决方案：

SIF框架的流控模块支持可配置的接口流量控制，用于保障在流量过大时对服务器进行有效的保护，以避免宕机等严重情况。流量控制的原理是在采用Java中阻塞队列方式即能从队列中获取到数据则可以进行后续的逻辑处理，否则直接返回请求失败。在服务器端对每个服务接口设置一个并发的阀值X即阻塞队列的容量为X，当请求过来后先从阻塞队列中get(获取)一个值，然后进行后续的逻辑处理。当逻辑处理完成后再把该值put(放置)到该队列中。当流量过大时则有些请求因无法获取到队列的值则直接返回流控拒绝。该流控方案可对每个服务接口进行单独配置大大提供了流控配置的灵活性。

需要注意的是，发明中所引用的如“上”、“下”、“左”、“右”、“前”、“后”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。

以上仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，应视为本发明的保护范围。

Claims (10)

1.一种远程调用服务框架的实现系统，其特征在于，分为请求方和服务方，请求方和服务方中均包括配置模块、业务模块、API模块、发送模块、接收模块、编码模块和解码模块，其中，配置模块用于对远程调用服务框架进行初始化配置，服务方的API模块用于提供符合框架规范的接口；请求方的业务模块发送请求参数至请求方的API模块，请求方的API模块对请求参数进行处理，经过请求方的编码模块编码后发送至请求方的发送模块，请求方的发送模块将请求参数封装成符合框架定义要求的报文数据格式并发送至服务方的接收模块，报文经过服务方的解码模块解码后，发送至服务方的业务模块，服务方的业务模块根据报文完成业务的具体处理并生成业务返回参数Map，业务返回参数Map依次经过服务方的编码模块、服务方的发送模块、请求方的接收模块、请求方的解码模块、请求方的API模块后，最终发送至请求方的业务模块。

2.如权利要求1所述的一种远程调用服务框架的实现系统，其特征在于：配置模块的配置方式基于spring风格的xml文件方式，包括配置：服务应用名和服务方IP地址和服务方端口之间的映射，服务方端口，服务应用名，以及服务方和请求方的处理线程数；配置模块在应用启动时使用Spring加载机制自动加载并完成调用服务框架的初始化操作，供后续API模块的直接调用。

3.如权利要求1所述的一种远程调用服务框架的实现系统，其特征在于：请求方的API模块提供了统一的编程模型以及供请求方的业务逻辑进行调用的API接口，请求方通过传入请求参数，对服务方所提供的远程服务进行访问，服务方处理完成后返回业务返回参数Map；其中，请求参数中包括服务应用名、服务接口名、业务请求参数Map、访问超时时间，业务返回参数Map中包含通信层连接结果的报文编码及业务参数的数据。

4.如权利要求3所述的一种远程调用服务框架的实现系统，其特征在于：请求方和服务方的发送模块用于生成符合框架要求的报文数据格式及通过内部API发送报文，其中，请求方的发送模块的处理逻辑包括：

1)根据请求方的API模块传入的服务接口名映射获取到远程服务器的IP地址及端口后跟远程服务器建立Socket通信连接；

2)为本次请求赋予唯一的跟踪识别号invokeNo，该invokeNo与本次调用的线程进行关联；

3)将请求方的API模块传入的请求参数和跟踪识别号、请求方应用名、请求方IP地址封装成符合框架定义要求的报文数据格式；

4)调用Netty消息发送方法将报文发送到服务方的接收模块完成报文发送。

5.如权利要求4所述的一种远程调用服务框架的实现系统，其特征在于：关联生成规则为：首先从线程中去获取，如果获取成功则使用该invokeNo，如果没有获取到则使用工具类生成全局唯一的32位字符串作为invokeNo，并将该invokeNo跟线程进行关联。

6.如权利要求1所述的一种远程调用服务框架的实现系统，其特征在于：请求方的编码模块对请求参数进行编码，将JavaBean数据编码转成字节流的方式，再发送至请求方的发送模块将其封装成报文数据格式；请求方的解码模块对请求方的接收模块的报文进行解码，将字节流转换成JavaBean再从JavaBean中获取到业务返回参数MAP。

7.如权利要求1所述的一种远程调用服务框架的实现系统，其特征在于：请求方和服务方的编码模块在编码时先将JavaBean转成Json字符串，再把Json字符串转换成字节流；请求方和服务方的解码模块在解码时先将字节流转换成Json字符串，再把Json字符串转成JavaBean。

8.如权利要求1所述的一种远程调用服务框架的实现系统，其特征在于：请求方和服务方的编码模块在编码时直接把JavaBean序列化为字节流；请求方和服务方的解码模块在解码时把字节流反序列化为JavaBean。

9.如权利要求4所述的一种远程调用服务框架的实现系统，其特征在于：服务方的接收模块接收请求方的发送模块发送过来的报文，在服务方的解码模块将报文解码成JavaBean后，服务方的业务模块通过获取报文中服务接口的方法获取到具体的业务处理类，并将业务请求参数Map传递到业务处理类中完成业务的具体处理，在业务处理完成后生成业务返回参数Map，由请求方的接收模块将业务返回参数Map返回到请求方。

10.如权利要求1所述的一种远程调用服务框架的实现系统，其特征在于：服务方还包括流控模块，在服务器对每个服务接口设置一个并发的阀值X，即阻塞队列的容量为X，当请求过来后先从阻塞队列中获取一个值，然后进行后续的逻辑处理，当逻辑处理完成后再把该值放置到该队列中；当流量过大时，有些请求因无法获取到队列的值则直接返回流控拒绝。