一种组件式的数据接口实现方法与系统

技术领域

本发明属于数据交互与数据传输领域，具体涉及组件式的数据接口实现方法与系统。

背景技术

数据接口一般使用Web Service来实现，而Web Service则分为Restful WebService(以下简称Restful)以及Soap Web Service(以下简称Soap)两种。其中Restful因为其高效以及简洁易用的特性，最大限度的利用了Http最初的应用协议设计理念，能够很好的融合当前Web2.0的很多前端技术来提高开发效率，对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。

随着大数据时代的来临，数据交互的需求越来越多，Restful得到越来越广泛的应用。另一方面，伴随着业务复杂度、系统数据量、请求并发量的增加，传统的实现方式已经满足不了业务需求，无论是Soap还是Restful，都是在同一个接口内部顺序执行逻辑代码实现，效率较低，当请求大并发量时，经常出现响应延时，甚至出现响应超时的问题。其次随着业务需求变迁，Restful服务会变得越来越臃肿。特别对多个业务系统需要进行数据交互，并且这些业务系统又不是同一家公司运维的场景，传统的数据接口开发方式会导致接口散乱、调用方式不一致、数据接口服务不能统一管理等问题。

由此可见，现有技术所存在的问题主要体现在负载能力不够以及横向扩展能力不够。近来有人提出基于微服务与中台的技术选择。微服务强调的是分治之法，较大的单体业务要拆分和进一步解耦，即将一个业务拆分成多个服务，让各个服务之间协调执行，共同完成业务；微服务框架的代表有Dubbo以及Spring Cloud，利用框架中的集群通讯机制对服务进行负载均衡、容错、路由等，并且对每个Web Service进行服务化治理、监控。中台更多的是指横向拆分，即共性业务能力的下沉，然后再将服务能力开放给前台应用使用。中台的构建不一定要采用微服务，只要满足共性业务能力下沉，那么也满足中台的要求。

发明内容

本发明提供一种组件式的数据接口实现方法与系统，在不同公司的多个业务系统(即每个业务系统由不同公司开发和维护)需要进行数据接口开发的场景下，能够统一对这些数据接口进行管理、监控，避免了各个业务系统开发标准不统一、服务运行环境与状态不可控的混乱情况，解决了当请求大并发量时数据响应延时甚至超时的问题。

本发明系统采用以下技术方案来实现：一种组件式的数据接口实现系统，包括：

中台服务，用于对接口组件进行统一管理，包括负载均衡、容错、路由；

接口组件，为第三方业务系统提供数据接口服务；

中台服务与接口组件通过RPC调用的方式实现通讯，RPC调用的过程为将调用、编码/解码的过程封装起来，中台服务和接口组件同时实现服务端、客户端；服务端负责使用Rest API方式实现具体的业务逻辑，包括注册、停止、回调、授权、心跳及日志功能；客户端负责按照Rest API方式调用相关业务逻辑，包括注册调用、停止调用、回调调用、授权调用、心跳调用、日志调用。

本发明方法采用以下技术方案来实现：一种组件式的数据接口实现方法，通过中台服务对接口组件进行统一管理，包括负载均衡、容错、路由；通过接口组件为第三方业务系统提供数据接口服务；通过RPC调用的方式实现中台服务与接口组件之间的通讯，RPC调用的过程为将调用、编码/解码的过程封装起来，中台服务和接口组件同时实现服务端、客户端；服务端负责使用Rest API方式实现具体的业务逻辑，包括注册、停止、回调、授权、心跳及日志功能；客户端负责按照Rest API方式调用相关业务逻辑，包括注册调用、停止调用、回调调用、授权调用、心跳调用、日志调用。

由以上技术方案可知，本发明大致分为中台服务以及接口组件两部分，中台服务统一对数据接口进行管理、监控，并进行负载均衡、容错、路由等处理；接口组件提供统一标准的SDK，让各个业务系统可以按照标准快速开发自己业务的接口组件，通过中台服务注册到数据接口集群中，提供给各个业务系统使用，从而实现横向扩展。本发明与现有技术相比，具有如下优点和有益效果：

1、本发明采用组件式开发，既解决了当请求大并发量时，数据经常出现响应延时，甚至出现响应超时的问题；又完美实现了不同公司多个业务系统需要进行数据接口开发的协调，统一对这些数据接口进行管理、监控。避免了各个业务系统开发标准不统一、服务运行环境与状态不可控的混乱情况，并且可以无限进行横向扩展。特别适用于政府机构(例如公安局、社保局等)的数据接口开发场景；因为政府机构的项目一般是经过投标，外包出去给第三方公司开发与维护的，随着业务增长，这些项目与外包公司的数量必定会增加，而每个项目的数据都是由它的外包公司维护，而这些数据又不可能直接给别人访问，当项目与项目之间需要做数据交互，就需要进行数据接口的开发。

2、本发明简化了数据接口的开发，只需要开发一个数据组件并注册到服务中心即可。开发数据组件时只需要关心业务逻辑即可，即适用接口组件的SDK，继承一个基础控制器，按业务需求实现各个接口方法，然后配置好接口服务部署的机器码、IP、端口、接口列表即可启动服务。

3、本发明一方面通过中台服务，统一对数据接口信息进行监控、管理；一方面通过微服务，解决了请求并发量大的问题，避免了各个业务系统开发标准不统一的问题，让开发接口变得简单，并可以横向扩展。中台服务与微服务之间的通讯模式使用RPC(Rest API)，业务系统调用接口时职责明确；业务系统首先调用中台服务进行授权，中台服务把授权信息给到接口服务，业务系统才能调用接口服务获取需要的数据。

附图说明

图1是本发明实施例中的数据接口实现系统的结构框图；

图2是本发明实施例中数据组件注册的流程图；

图3是本发明实施例中数据接口授权的流程图；

图4是本发明实施例中API接口组件向第三方业务系统开放的流程图；

图5是本发明实施例中RPC调用的流程图。

具体实施方式

本发明涉及的缩略语和关键术语定义如下：

Restful Web Service，一种架构风格，其核心是面向资源，专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。

SOAP Web Service，一种基于XML协议，主要核心是面向活动，有严格的规范和标准，包括安全、事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。

RPC，指远程过程调用(Remote Procedure Call Protocol)，也就是说两台服务器A、B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

本发明并不使用第三方微服务框架直接进行二次开发，因为微服务对业务拆分，但业务复杂度不会因为拆分而减少，相反还会增加额外的技术成本、协作成本，整体复杂度是升高而不是降低的，开发效率是降低而不是升高的。在本发明的实施过程中，基本上是中台和微服务都会使用到，既按照中台需要将业务进行横向拆分，使共性能力下沉，同时对于下沉的共性能力再按微服务思想进一步拆分为多个业务微服务组件，能力开放以微服务里面常见的轻量API接口方式进行。下面结合实施例及附图对本发明作进一步详细的描述，但本发明的实施方式不限于此。

实施例

如图1，在本实施例中，组件式的数据接口实现系统包括中台服务以及接口组件(即数据组件集群)，中台服务负责对接口组件进行负载均衡、容错、路由等统一管理，接口组件负责对数据接口的实现，中台服务与接口组件通过RPC(Rest API)调用的方式实现通讯。

其中，中台服务基于Spring boot开发，作为数据接口的统一管理、调度服务程序，包括管理模块、通讯模块和API模块，分别具体说明如下：

a)管理模块，即为中台服务的WEB管理后台，主要用于维护业务系统管理、组件管理、接口管理以及API相关日志数据等功能。

业务系统管理提供展示界面以及添加、编辑功能，添加的业务系统数据自动产生一组与其对应的账号(APP ID)、密码，业务系统进行接口授权时使用它们进行授权验证。另外，提供业务系统与接口的关联功能，表示业务系统拥有哪些接口的权限。

组件管理用于提供展示界面以及添加、编辑功能，添加的组件数据自动产生一个随机机器码(唯一且不能修改)，实际的组件服务依靠这个机器码与组件数据匹配注册。接口管理用于提供展示界面，由接口组件向中台服务注册时产生或者更新。

API相关日志数据包括API授权日志和API访问日志。API授权日志用于提供展示界面，该数据由第三方业务系统向中台发起接口授权时产生日志数据。API访问日志，作为对应API授权日志中的详细日志内容，以远程文件的方式保存在接口组件上，该文件由第三方业务系统向接口组件请求实际的API接口时产生，通过中台服务的通讯模块中日志调用功能向接口组件读取远程文件的内容并展示。

b)通讯模块(中台服务)，用于维护中台服务与数据组件集群之间的通讯，采用RPC(Rest API)实现，提供授权调用、心跳调用、日志调用的访问功能，以及注册、停止、回调的被访问功能。

授权调用，第三方业务系统请求API模块中的授权并通过授权验证逻辑后，调用该功能向数据组件推送相关授权信息，譬如API授权日志、业务系统标识、API接口标识、访问上限、访问时间限制等。

心跳调用，中台服务定时根据组件信息调用该功能向对应的数据组件确认是否有应答，如果有应答，则认为数据组件在线，超时则认为不在线，把状态更新到组件信息中。

日志调用，使用API访问日志标识作为参数，调用该功能读取数据组件中的对应远程日志文件内容。

注册，是数据组件注册(运行)的逻辑，主要是更新数据库的组件、接口数据。根据注册参数调用的参数，按照机器码更新对应的组件IP、端口、状态(在线)等信息，再使用机器码更新接口列表的信息，完成后响应数据组件的注册调用操作。流程如图2所示。

停止，是数据组件停止的逻辑，主要是更新数据库的组件数据。根据机器码更新对应的组件状态(停止)，完成响应数据组件的停止调用。

回调，响应数据组件的回调调用，待扩展功能。

c)API模块(中台服务)，为向第三方业务系统开放的访问接口，主要包括接口授权、接口列表。

接口列表，获取指定第三方业务系统所拥有的数据接口列表，主要是根据业务系统查询关联的组件、接口的数据，然后整理成每个接口一条url地址的列表。

接口授权，指定第三方业务系统与数据接口的授权操作，必须指定授权账号、密码、需要调用的接口。主要是根据账号查询关联的组件，然后验证密码是否正确，如果正确，再查询与组件关联的接口数据，如果需要调用的接口存在，则使用授权调用的方法向数据组件推送授权信息，成功后返回url地址。授权流程如图3。

而接口组件基于Spring boot开发，为第三方业务系统提供数据接口服务，包括通讯模块和API模块。

a)通讯模块(接口组件)，用于维护数据组件与中台服务之间的通讯，采用RPC(Rest API)实现，提供注册调用、停止调用、回调调用的访问功能，以及授权、心跳、日志的被访问功能。

注册调用，接口组件程序启动后调用该功能向服务中心提交当前接口组件的信息，例如机器码、IP、端口、接口列表等，使用Spring boot事件监听器实现。

停止调用，接口组件程序停止前调用该功能向服务中心提交“停止服务”的指令，使用Spring boot事件监听器实现。

回调调用，为待扩展功能，譬如接口组件需要调用或者通知中台服务的操作，均可以使用这个功能进行。

授权，接收中台服务推送过来的授权信息并缓存，缓存信息用于业务系统请求接口时验证权限，完成后响应中台服务的授权调用。

心跳，直接响应中台服务的心跳调用。

日志，根据中台服务提供的API授权日志标识，读取本地API访问日志文件，把文件内容作为信息返回，响应中台服务的日志调用。

b)API模块(接口组件)，为向第三方业务系统开放的访问接口，主要包括授权验证、调用日志、接口逻辑等。流程如图4。

授权验证，使用Spring拦截器实现，继承HandlerInterceptorAdapter并实现preHandle方法，在里面实现权限验证的逻辑。使用请求的授权参数与中台服务授权时推送过来的授权信息进行验证。

调用日志，使用Spring拦截器实现，继承HandlerInterceptorAdapter并实现postHandle方法，在里面写入日志文件，包括调用开始时间、调用结束时间、数据量、请求IP等。

接口逻辑为抽象实现，实现基础控制器，统一控制请求方式、整理请求参数、调用业务逻辑、统一返回值格式。具体的业务逻辑是需要各个业务系统继承基础控制器进行二次开发，实现自己的业务逻辑。

本实施例中，使用高效的网络通讯框架io.netty实现Rest API风格的RPC，如图5所示，将调用过程的第2-10步完好地封装起来，也就是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务。中台服务和接口组件都需要同时实现服务端、客户端。服务端主要负责使用Rest API方式实现具体的业务逻辑，譬如注册、停止、回调、授权、心跳、日志这些功能；客户端主要负责按照Rest API的调用方式调用相关业务逻辑，譬如注册调用、停止调用、回调调用、授权调用、心跳调用、日志调用这些功能。

RPC调用过程其实就是一个http/https请求、响应的过程。不同的是根据自己定义的参数、参数格式，依赖http/https协议分别在客户端与服务端封装了它们(客户端、服务端，即本发明的中台服务和接口组件)的通讯模块，包括请求代码与响应代码，让客户端与服务端直接调用。以用户授权的调用情况为例(在授权调用这个场景下，中台服务就是RPC客户端，接口组件就是RPC服务端)，对RPC调用过程详细说明如下：

A、客户端(Client，中台服务)调用客户端通讯模块(Client Stub)中的授权请求方法，并传入参数，如用户授权令牌、组件信息(里面有接口组件的ip、通讯端口等信息)、接口信息列表(对应接口组件的接口信息列表，组件注册时会提交的)。

B、客户端通讯模块(Client Stub)根据接口组件ip、通讯端口、授权调用名称(由客户端与服务端约定好)组装成http/https协议的url，并且使用url创建post请求；然后把用户授权令牌、接口信息列表序列化成json字符串，放进请求体中；再把RPC通讯密钥(由客户端与服务端约定好，在配置文件上)MD5加密一次，放进请求头中；最后，执行post请求通过网络发送消息。

C、服务端通讯模块(Server Stub)进行授权，方法为：服务端接收到post请求后，首先对请求头获取的客户端传递过来的通讯密钥(注意这个传递过来的密钥是已经MD5加密一次的，所以需要把配置文件中的通讯密钥先MD5解密一次，再进行匹配)进行验证，如果不正确，响应请求授权失败；验证通过后从请求体中获取用户授权令牌、接口信息列表的json字符串，并且反序列化成授权数据对象；最后使用授权数据对象作为参数创建授权Handler对象，并放进队列进行调用。

D、服务端(Server，接口组件)实现授权Handler的执行逻辑，主要是把授权数据对象缓存起来，进行统一管理。待用户请求接口时，使用这些数据分别对不同用户、不同接口请求权限验证。先使用用户授权令牌查找缓存，如果能找到其对应的接口信息列表，则把新旧两个接口信息列表合并成新的列表，再把新的列表覆盖到缓存中，如果不能，则直接使用用户授权令牌作为标识，把接口信息列表写入缓存；然后把缓存超时时间设置成120分钟；最后向服务端通讯模块(Server Stub)返回结果。

E、服务端通讯模块(Server Stub)收到返回结果，就把结果组装成响应消息对象，响应对象必要属性包括返回码、返回信息、返回数据，并且把响应消息对象序列化成json字符串，然后向客户端通讯模块(Client Stub)发送响应消息。

F、客户端通讯模块(Client Stub)接收到响应消息的json字符串，先把json字符串反序列化成响应消息对象，然后根据约定响返回码分别组装成调用结果，并且向客户端返回结果。

Rest API风格实现的伪代码为：

基于相同的发明构思，本实施例还提供一种组件式的数据接口实现方法，该方法通过中台服务对接口组件进行统一管理，包括负载均衡、容错、路由；通过接口组件为第三方业务系统提供数据接口服务；通过RPC调用的方式实现中台服务与接口组件之间的通讯，RPC调用的过程为将调用、编码/解码的过程封装起来，中台服务和接口组件同时实现服务端、客户端；服务端负责使用Rest API方式实现具体的业务逻辑，包括注册、停止、回调、授权、心跳及日志功能；客户端负责按照Rest API方式调用相关业务逻辑，包括注册调用、停止调用、回调调用、授权调用、心跳调用、日志调用。

本实施例数据接口实现方法中，RPC调用过程也是如图5所示，与数据接口实现系统中RPC调用过程相同。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。