银企直连的通信方法、装置、计算机设备和存储介质与流程

1.本技术涉及计算机技术领域，特别是涉及一种银企直连的通信方法、装置、计算机设备、存储介质和计算机程序产品。


背景技术：

2.随着互联网信息技术的高速发展，越来越多的企业客户同银行交互的方式从传统的web网银切换到银企直联。银企直联是一种银行系统与企业财务软件系统的无缝连接接入方式，通过网上专线连接使银行和企业的结算中心、财务公司或企业erp实现平滑对接、有机融合。银企直连使企业足不出户，就可以实时查账，实时转账等交易，实现企业在不同银行间的资金管理。
3.传统的银企直连方法，需要设置多个银行的跨行客户端(简称前置机)，企业和各行前置机进行对接，通过企业向前置机发送业务请求以及各行前置机间的通信来完成。
4.然而，传统的银企直连方法，存在银企交互效率不高的问题。


技术实现要素：

5.基于此，有必要针对上述技术问题，提供一种能够提高银企交互效率的银企直连的通信方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。
6.第一方面，本技术提供了一种银企直连的通信方法。所述方法包括：
7.开放应用程序接口api微服务获取目标业务的统一资源定位符url业务请求消息；其中，该url业务请求消息包括企业标识、银行标识、以及该目标业务对应的应用程序接口名称；
8.该开放api微服务调用该api名称对应的应用程序接口，该应用程序接口用于向该银行标识对应的目标服务器发送该url请求消息；
9.该开放api微服务接收该目标服务器发送的业务响应消息，其中，该业务响应消息为该目标服务器根据该url业务请求消息生成的响应消息；
10.该开放api微服务向该企业标识对应的终端发送该业务响应消息。
11.在其中一个实施例中，开放应用程序接口api微服务获取目标业务的统一资源定位符url业务请求消息包括：
12.该开放api微服务接收网关微服务发送的该目标业务的url业务请求消息，其中，该url业务请求消息为该网关微服务接收的该终端所发送的请求消息。
13.在其中一个实施例中，所述银企直连的通信方法还包括：
14.该应用程序接口用于将该url请求消息转换为第一目标格式的请求报文，并向该目标服务器发送该第一目标格式的请求报文。
15.在其中一个实施例中，该银企直连的通信方法还包括：
16.该开放api微服务周期性向该网关微服务发送心跳消息，其中，该心跳消息用于供该网关微服务判断该开放api微服务的工作状态是否正常。
17.在其中一个实施例中，该开放api微服务接收网关微服务发送的该目标业务的url业务请求消息包括：
18.该开放api微服务接收该目标服务器通过核心业务微服务发送的该业务响应消息；
19.其中，该业务响应消息为该核心业务微服务将来自该目标服务器的响应消息，转换为第二目标格式的响应报文后得到的响应消息。
20.在其中一个实施例中，该银企直连的通信方法还包括：
21.该开放api微服务向日志管理微服务发送该url请求消息对应的信息，该url请求消息对应的第一信息用于供该日志管理微服务生成与该url请求消息对应的第一日志记录，该第一信息包括该网关微服务发送该url请求消息的时间、该企业标识、该目标业务的业务标识以及该银行标识。
22.第二方面，本技术还提供了一种银企直连的通信装置。所述装置包括：
23.获取模块，用于获取目标业务的统一资源定位符url业务请求消息；其中，该url业务请求消息包括企业标识、银行标识、以及该目标业务对应的应用程序接口名称；
24.调用模块，用于调用该api名称对应的应用程序接口，该应用程序接口用于向该银行标识对应的目标服务器发送该url请求消息；
25.接收模块，用于接收该目标服务器发送的业务响应消息，其中，该业务响应消息为该目标服务器根据该url业务请求消息生成的响应消息；
26.发送模块，用于向该企业标识对应的终端发送该业务响应消息。
27.第三方面，本技术还提供了一种计算机设备。该计算机设备包括存储器和处理器，该存储器存储有计算机程序，该处理器执行该计算机程序时实现上述任一方法的步骤。
28.第四方面，本技术还提供了一种计算机可读存储介质。该计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一方法的步骤。
29.第五方面，本技术还提供了一种计算机程序产品。该计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述任一方法的步骤。
30.上述银企直连的通信方法、装置、计算机设备、存储介质和计算机程序产品，通过开放应用程序接口api微服务获取目标业务的统一资源定位符url业务请求消息；其中，该url业务请求消息包括企业标识、银行标识、以及该目标业务对应的应用程序接口名称，该开放api微服务调用该api名称对应的应用程序接口，该应用程序接口用于向该银行标识对应的目标服务器发送该url请求消息，该开放api微服务接收该目标服务器发送的业务响应消息，其中，该业务响应消息为该目标服务器根据该url业务请求消息生成的响应消息，该开放api微服务向该企业标识对应的终端发送该业务响应消息，无需设置前置机，就可以完成银企的交互，提高了银企交互的效率。
附图说明
31.图1为本技术实施例中银企直连的通信方法的应用环境图；
32.图2为传统的银企直连的通信方法的流程示意图；
33.图3为本技术实施例提供的一种新银企直连系统；
34.图4为本技术实施例中提供的一种银企直连的通信方法的流程示意图；
35.图5是本技术实施例提供的一种银企直连的通信系统示意图；
36.图6为本技术实施例中提供的新银企直连系统的自动化构建的效果示意图；
37.图7为本技术实施例中提供的新银企直连系统的容器化部署的效果示意图；
38.图8为本技术实施例中提供的新银企直连系统的可视化的效果示意图；
39.图9为本技术实施例中提供的新银企直连系统的日志记录的效果示意图；
40.图10为本技术实施例中提供的一种银企直连的通信装置的结构示意图；
41.图11为本技术实施例中计算机设备的内部结构图。
具体实施方式
42.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
43.图1为本技术实施例中银企直连的通信方法的应用环境图，请参考图1，本技术实施例提供了的银企直连的通信方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信，数据存储系统可以集成在服务器104上，也可以放在云上或其他网络服务器上。终端102可以但不限于是各种计算机、笔记本电脑和平板电脑，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
44.图2为传统的银企直连的通信方法的流程示意图，如图2所示，其中，cbs业务系统指跨银行现金管理平台(cross-bank solution for cash management，cbs)，是招商银行为大型企业集团设计开发的资金管理系统，该系统结合先进的财资管理理念，围绕提升企业精细化管理和快速决策能力，多维度实施系统结构和流程整合，实现真正意义上的全面资金管理、集团现金集中管理。cbc后台指跨银行交换中心(cross-bank for exchange center，cbc)，是处理各个银行直连的后台统一服务处理中心，前台业务后台处理。cbc后台和cbs业务系统均部署在招行的服务器上。招商银行跨银行客户端简称为招行前置机，各银行的跨银行客户端简称为他行前置机，招行前置机用来直联他行前置机，实现交换中心与其他银行的通讯，前置机只是与各个银行通信的通道。其中，以他行前置机为工商银行的前置机为例进行介绍，工商银行的前置机简称为工行前置。
45.传统的方式若企业用户想要完成在不同银行间的灵活资金流动及管理，例如企业用户需要在招商银行和工商银行进行资金管理，必须购买cbs业务系统，并且需要提前在终端上部署、配置招行前置机和工行前置机。若企业用户要查询该企业在工商银行的余额，则企业用户开启终端上部署的招行前置机，登录相关业务接口，由终端向招行前置机发送查询余额的业务请求，招行前置机将该业务请求对应的接口活动信息发送给cbc后台，cbc后台再将此接口活动信息发送给cbs业务系统，其中，接口活动信息用来表示将业务请求的请求报文需要发送给哪个银行的哪台前置机。cbs业务系统根据收到的接口活动信息，找到对应的cbc后台，发送业务请求的请求报文到cbc后台，cbc后台把业务请求的请求报文转换为工商银行的后台服务器可识别的请求报文，然后将转换后的请求报文存储在db2数据库中。招行前置机主动查询到db2数据库中的转换后的请求报文，与工行前置机进行通讯，然后工行前置机返回该查询余额请求的响应信息。招行前置机获取到该响应信息，并将响应信息传输给cbc后台，cbc后台把该响应信息转换为cbs业务系统可识别的响应报文后，并将该响
应报文返回给cbs业务系统，再由cbs业务系统将该响应报文返回给招行前置机。因此传统方式下想要实现银企直联，必须购买cbs业务系统且部署对应的前置机，才能对接不同的银行，对接流程繁琐。
46.传统的方法cbc后台部署在多个服务器集群上，每个终端只能随机使用其中的一台服务器，对每个终端而言，请求的业务和次数也不尽相同，因此可能会出现其中一台服务器较为繁忙，其他服务器处于空闲状态，从而会引起终端随机使用的服务器是比较繁忙的服务器的情况下，该服务器会出现延时响应，导致银企交互效率不高的问题。
47.图3为本技术实施例提供的一种新银企直连系统，如图3所示，结合传统方法的实际应用，并考虑未来的业务拓展，本实施例按图3对新银企直连系统进行划分。网关微服务、可视化用户界面(user interface，ui)微服务、开放api微服务、核心业务微服务、前置交互微服务、日志管理微服务和系统管理微服务部署在不同的服务器上，并均运行在pass平台上，并改用自动部署、扩展和管理容器化应用程序的开源系统kubernetes，简称k8s编排，开源的应用容器引擎docker部署，数据库及关键中间件采用云原生acs，性能更加稳定可靠，可实现资源合理分配，动态扩容，不影响已有系统；与此同时，部署采用自动打包工具jekins搭建的自动化流水线，直接触发即可实现生产的升级，无需人工重启。需要说明的是，各个微服务可以部署在同一台服务器，也可以部署在不同的服务器上。
48.其中，网关微服务用于负载均衡、根据路由配置分发业务请求、动态路由实现灰度发布并实时切换生产流量、熔断限流、鉴权，可以提高系统容灾能力，紧急修复系统缺陷，保证系统平稳运行；可视化ui微服务用于提供用户可见化的管理界面，便于实时查询银企交互状态等信息，提供银企业务配置化管理界面，快速响应用户需求，提供商业智能(business intelligence，bi)可视化界面，便于客户清晰掌握银企对接动态；开放api微服务用于构建统一的业务请求，便于第三方企业资源计划erp(enterprise resource planning，erp)统一、简介地接入；核心业务微服务用于对接不同银行的不同业务，将api微服务构建的统一业务组装转化为银行要求格式；前置交互微服务用于兼容传统方法的前置机交互；日志管理微服务用于记录银企交互日志，记录系统服务运行健康性，便于快速排查银企交互出现的问题；系统后台管理微服务用于提供该银企直连系统的后台运维，便于用户或者运维人员快速定位使用过程中出现的问题，掌握系统运行的状况。本实施例的系统把庞大的单体应用按功能拆分，便于后续快速开发、生产部署、紧急修复生产。需要说明的是，本实施例对新银企直连系统的具体架构和架构内容不做具体限制。
49.图4为本技术实施例中提供的一种银企直连的通信方法的流程示意图，该方法应用于图1所示的应用环境和图3的新银企直连系统中，在一个实施例中，如图4所示，包括以下步骤：
50.s401，开放应用程序接口api微服务获取目标业务的统一资源定位符url业务请求消息；其中，url业务请求消息包括企业标识、银行标识、以及目标业务对应的应用程序接口名称。
51.在本实施例中，终端使用超文本传输协议(hyper text transfer protocol，http)的post方法发送url业务请求消息，其中，url业务请求消息中的企业标识，用来表示发送url业务请求消息的企业的标识，该企业可以通过终端发送url业务请求消息，例如可以是企业在新银企直连系统注册后，该系统给企业颁发的唯一标识。url业务请求消息中的
银行标识，用来表示目标业务对应的银行的标识，例如可以是企业在新银企直连系统系统开通的直联银行名称。url业务请求消息中的目标业务对应的应用程序接口名称，用来表示目标业务对应的应用程序接口的名称，其中，目标业务例如可以是查询余额、历史查询、支付、代发、查询代发、查询明细、查询电子回单、下载电子回单等业务中的任意一种或者多种，需要说明的是，本实施例对目标业务不做具体限制。需要说明的是，开放api微服务可以直接接收由终端发送的url业务请求消息，也可以是终端将url业务请求消息发送给网关微服务，由网关微服务发送给开放api微服务，本实施例对此不做限制。
52.更具体的，url业务请求消息的样式可以为：
[0053]“http://xxx/openapi/business/{enterprise}/{bankerpname}/{servicename}”[0054]
其中，enterprise为企业标识，bankerpname为银行标识，servicename为目标业务对应的应用程序接口名称，xxx为预留标识，可以是域名、ip、端口等形式，本实施例不做具体限制。
[0055]
传统方法必须使用cbs业务系统，并且只能通过套接字socket对接。由于socket对接时，必须走行内专线，维护成本高，同时也由于没有统一的对接参数，也无法提供给第三方erp财务系统对接；且绝大部分的业务交互与cbs业务系统耦合较为严重，不便于面向第三方erp提供简易化对接流程，若需改动某业务的某个分支时，需考虑是否对整个业务链产生影响，降低企业对接的效率。而本实施例的对接方式统一，支持用户使用http或者超文本传输安全协议(hyper text transfer protocol over securesocket layer，https)接入，针对每个银行的每个业务均提供开放的api，每类业务，提供各自的应用程序接口，第三方对接时，只要按照请求规范，即可直接对接，入参出参明确，清晰易懂，可读性与操作性较强；并且本实施例的对接方式无需一定使用cbs业务系统，每项业务与cbs解绑，不与任何业务系统强耦合，便于第三方erp财务系统对按照规范对接。
[0056]
s402，开放api微服务调用api名称对应的应用程序接口，应用程序接口用于向银行标识对应的目标服务器发送url请求消息。
[0057]
在本实施例中，开放api微服务接收到url请求消息后，由于url请求消息携带目标业务对应的应用程序接口名称，因此开放api微服务可以确定api名称对应的应用程序接口，并调用应用程序接口向目标服务器发送对应的请求消息。例如，业务请求消息中，目标业务对应的应用程序接口名称若为查询余额，则api名称对应的应用程序接口为查询余额应用程序接口，因此就可以调用查询余额应用程序接口；业务请求消息中，目标业务对应的银行标识若为工商银行，则该业务请求消息表示企业向工商银行发起查询余额请求，则目标服务器为工商银行对应的后台服务器，进而向工商银行对应的后台服务器发送url请求消息。
[0058]
s403，开放api微服务接收目标服务器发送的业务响应消息，其中，业务响应消息为目标服务器根据url业务请求消息生成的响应消息。
[0059]
在本实施例中，目标服务器例如工商银行对应的后台服务器收到请求消息，则根据请求消息处理此请求，并返回业务响应消息。需要说明的是，该业务响应消息可以是目标服务器直接返回给开放api微服务，也可是目标服务器返回给核心业务微服务，由核心业务微服务进行处理后再返回给开放api微服务，本实施例对此不做限制。
[0060]
s404，开放api微服务向企业标识对应的终端发送业务响应消息。
[0061]
在本实施例中，开放api微服务接收到目标服务器返回的业务响应消息后，并根据业务响应消息中的企业标识，向企业标识对应的终端返回业务响应消息。
[0062]
本实施例中，若用户通过终端向工商银行发起查询余额的业务请求，目标服务器为工商银行的后台服务器。终端发送业务请求消息，该业务请求消息发送给开放api微服务，再由开放api微服务发送给工商银行的后台服务器。其中，该业务请求消息可以由网关微服务发送给开放api微服务，再由开放api微服务发送给核心业务微服务，核心微服务再将该消息发送给工商银行的后台服务器。工商银行的后台服务器对接收到的业务请求进行响应处理，核心业务微服务接收到工商银行的后台服务器返回的业务响应消息，并向终端返回请求成功以及对应的余额参数消息，其中，业务响应消息可以包括请求成功以及对应的余额参数消息。核心业务微服务接收到工商银行的后台服务器返回的业务响应消息后，将该响应消息先发送给开放api微服务，再由开放api微服务发送给终端。
[0063]
本实施例提供的银企直连的通信方法，通过开放应用程序接口api微服务获取目标业务的统一资源定位符url业务请求消息；其中，url业务请求消息包括企业标识、银行标识、以及目标业务对应的应用程序接口名称，开放api微服务调用api名称对应的应用程序接口，应用程序接口用于向银行标识对应的目标服务器发送url请求消息，开放api微服务接收目标服务器发送的业务响应消息，其中，业务响应消息为目标服务器根据url业务请求消息生成的响应消息，开放api微服务向企业标识对应的终端发送业务响应消息。由于无需布置前置机和cbs业务系统，就可以发送业务请求消息并获取到业务响应消息，简化了传统方式的交互链路和部署设备，解决了以往银企直连通信方法由于部署前置机和cbs业务系统造成的响应延时导致银企交互效率较低的问题，提高了银企交互的效率。
[0064]
可选的，上述的s401可以通过如下方式实现：
[0065]
开放api微服务接收网关微服务发送的目标业务的url业务请求消息，其中，url业务请求消息为网关微服务接收的终端所发送的请求消息。
[0066]
为了更清楚的对本实施例提供的银企直连的通信方法进行介绍，在此结合图5进行解释说明。参照图5，图5是本技术实施例提供的一种银企直连的通信系统示意图。在本实施例中，终端发起请求，向网关微服务发送url业务请求消息，网关微服务将url业务请求消息发送给开放api微服务。本实施例中通过网关微服务接收终端发送的url业务请求消息，并将此url业务请求消息发送给开放api微服务，从而完成银企直连的通信，传统的方法，银企交互链路较长，指令的分发、处理、返回的交互均依赖于线程池，而且每个企业只能使用交换中心的某台应用相关的资源，如果该应用的资源耗尽，则该应用上的相关企业银企交互效率都会受到影响。本实施例的方法简化了银企交互链路，指令的交互不再依靠数据库，绝大多数的指令交互均是在缓存中完成，提高了银企交互的效率。
[0067]
可选的，上述的银企直连的通信方法还可以通过如下方式实现：
[0068]
应用程序接口用于将url请求消息转换为第一目标格式的请求报文，并向目标服务器发送第一目标格式的请求报文。
[0069]
在本实施例中，终端发起请求后，开放api微服务调用api名称对应的应用程序接口，并将请求消息转换为第一目标格式的请求报文，并向目标服务器发送。例如，终端请求查询余额，开放api微服务调用查询余额对应的应用程序接口，并将请求消息转换为第一目
标格式的查询余额请求报文。
[0070]
其中，第一目标格式的请求报文包括：
[0071]
采用标准xml的报文格式，首行内容固定，例如可以为《？xml version＝"1.0"encoding＝"utf-8"？》；
[0072]
具有唯一一个根节点，且根节点下存在一个固定部分和一个可变部分，例如为根节点为请求(request)，根节点下仅存在一个固定部分的请求头(requesthead)和一个可变部分的请求体(requestbody)，requesthead节点下的字段固定不变，仅字段值不同；
[0073]
可变部分标签格式一致，例如requsestbody节点下的标签格式一致，仅标签及标签中的字段值不一致。
[0074]
更具体的，固定部分的requesthead可包括业务请求类型、请求id、业务请求时间、业务系统id、同步异步标志等。可变部分的requestbody是根据对应的业务请求传对应的参数，对应的参数可以分为公共参数和扩展参数，公共参数是根据各个银行总结而来，适用于所有银行，是必填项，扩展参数适用于少数银行的特殊要求，非必填项。本实施例对具体的参数形式和内容不作具体限制。
[0075]
在本实施例中，由于将url请求消息转换为第一目标格式的请求报文，规范了请求报文的样式，入参出参明确，清晰易懂，提高了银企交互的效率，报文格式符合市场主流风格，便于第三方erp统一、简介地接入，也便于后续市场化运行，加速企业的数字化转型。
[0076]
可选的，上述的银企直连的通信方法还可以通过如下方式实现：
[0077]
开放api微服务周期性向网关微服务发送心跳消息，其中，心跳消息用于供网关微服务判断开放api微服务的工作状态是否正常。
[0078]
在本实施例中，开放api微服务周期性向网关微服务发送心跳消息，例如可以为5ms向网关微服务发送一次心跳消息，若网关微服务在一个预设时间内未接收心跳消息，例如5min，则网关微服务会判断开放api微服务已经不在线，即工作状态不正常，则后续终端发送的业务请求消息，网关微服务不再将业务请求消息发送给此开放api微服务。更具体的，请参照图5，本实施例中新银企直连系统的每个微服务均会向网关微服务发送心跳消息，且由于本实施例中各个微服务采用容器化部署，当网关微服务检测到其中一个微服务例如开放api微服务状态不正常，就可以快速切换到状态正常的开放api微服务微服务中。
[0079]
在本实施例中，由于开放api微服务周期性向网关微服务发送心跳消息，网关微服务根据心跳消息判断开放api微服务的工作状态是否正常，提高了本方法的容灾能力，保证业务的平稳运行，由于本实施例中各个微服务采用容器化部署，构建统一化集群，单微服务宕机也不影响业务的操作，提高了银企交互的效率。
[0080]
可选的，上述的s403可以通过如下方式实现：
[0081]
开放api微服务接收目标服务器通过核心业务微服务发送的业务响应消息；
[0082]
其中，业务响应消息为核心业务微服务将来自目标服务器的响应消息，转换为第二目标格式的响应报文后得到的响应消息。
[0083]
在本实施例中，目标服务器对终端的业务请求作出响应后，会对核心业务微服务发送该业务响应消息，核心业务微服务将该业务相应消息转换为第二目标格式的响应报文后，再将响应报文发送给开放api微服务。
[0084]
其中，第二目标格式的响应报文要求包括：
[0085]
采用标准xml的报文格式，首行内容固定，例如可以为《？xml version＝"1.0"encoding＝"utf-8"？》；
[0086]
具有唯一一个根节点，且根节点下存在一个固定部分和一个可变部分，例如为根节点为响应(response)，根节点下仅存在一个固定部分的响应头(responsehead)和一个可变部分的响应体(responsebody)，responsehead节点下的字段固定不变，仅字段值不同；
[0087]
可变部分标签格式一致，例如responsebody节点下的标签格式一致，仅标签及标签中的字段值不一致。
[0088]
更具体的，固定部分的responsehead可包括业务请求id、业务响应时间、请求响应码等。可变部分responsebody是根据对应的业务请求传对应的参数，对应的参数可以分为公共参数和扩展参数，公共参数是根据各个银行总结而来，适用于所有银行，是必填项，扩展参数适用于少数银行的返回的特殊字段，非必填项。本实施例对具体的参数形式和内容不作具体限制。
[0089]
在本实施例中，由于将业务相应消息为第二目标格式的响应报文，由于各个银行的对接协议和响应消息样式不一样，会造成无法解析响应报文或者解析时间过长问题，降低银企交互效率，而本实施例规范了请求报文的样式，入参出参明确，清晰易懂，提高了银企交互的效率，报文格式符合市场主流风格，便于第三方erp统一、简介地接入，也便于后续市场化运行。
[0090]
可选的，上述的银企直连的通信方法还可以通过如下方式实现：
[0091]
开放api微服务向日志管理微服务发送url请求消息对应的信息，url请求消息对应的第一信息用于供日志管理微服务生成与url请求消息对应的第一日志记录，第一信息包括网关微服务发送url请求消息的时间、企业标识、目标业务的业务标识以及银行标识。
[0092]
在本实施例中，每当终端发起请求，开放api微服务会接收到对应的url业务请求消息，例如当终端发起查询余额请求，开放api微服务接收到此查询余额请求，向日志管理微服务发送该查询余额请求对应的第一信息，第一信息包括该查询余额请求的银行标识、企业标识、目标业务、该请求的请求时间等，日志管理微服务根据第一信息生成对应的第一日志记录，并将第一日志记录进行存储。同样的，开放api微服务接收到返回的响应报文也会根据返回的响应消息中的响应时间、目标业务、企业标识、目标服务器等生成日志记录，日志管理微服务将两条记录的请求和响应对应起来进行存储。后续用户需要查看日志，会通过终端发起查询日志的请求，网关微服务接收到此请求，并向日志管理微服务发送此请求，日志管理微服务将会从对应存储中获取日志记录返回。更具体的，当月的日志采用内嵌式存储系统(embedded storage，es)存储，其它日志采用es与hadoop数据库(hadoop database，hbase)结合存储。需要说明的是，本实施例对具体的储存方式和位置不做具体限制。
[0093]
传统的方法因为采用db2数据库存储银企交互日志，由于db2资源难以申请，难以扩展，因此只能记录支付及部分重要的交互日志，不便于开发运维定位问题。在本实施例中，由于银企业务交互日志全链路追踪，请求和响应均进行记录，搭建完整链路记录，便于后续的查看和运维；当月的日志采用es存储，其它日志采用es与hbase结合存储，存储链路及性能也得到了极大提升。
[0094]
图6为本技术实施例中提供的新银企直连系统的自动化构建的效果示意图，图7为
本技术实施例中提供的新银企直连系统的容器化部署的效果示意图，图8为本技术实施例中提供的新银企直连系统的可视化的效果示意图，图9为本技术实施例中提供的新银企直连系统的日志记录的效果示意图。如图6～图9所示，图6～图9均为新银企直连系统基于可视化ui微服务对用户展示的操作界面，其中，超级直联为该系统的应用名称，图6中的各个模块就是各个微服务，例如“open_st”为开放api微服务，可以看出通过最右侧的启停按钮，可以快捷方便地对各个微服务进行一键启动或停止，且并不影响其他微服务的运行，因此可以实现实时动态扩容和动态部署，该系统可以根据业务量增长情况，实时扩容，提高银企的交互效率，同时只需一键触发流水线即可完成升级发布。而传统的方法cbc后台采用虚拟机部署，升级时需人工停机升级后再逐个应用升级，因此也无法实时动态扩容，无法快速扩充资源。图7即展示一个微服务具体的容器化部署中运行状态良好。图8为该系统展示为终端用户的bi可视化界面，用户可以根据展示的图表数据，清晰的获知业务的处理情况，例如图表801，展示出终端用户利用本实施例的通信方法，通过本实施例提供的新银企直连系统，对各个银行的业务类型处理了多少笔业务，比如对招商银行(china merchants bank，cmb)银行进行查询业务1000笔，对中国银行(bank of china，boc)银行进行查询业务5000笔，对工商银行(industrial and commercial bank of china，icbc)银行进行查询业务1000笔，用户可实时查看银企交互的概况及细节，清晰掌握交互动态。图9为展示一个业务日志的日志记录可视化界面，传统的方式无法提供bi可视化界面，用户无法直观看到银企交互的细节。而新系统提供bi可视化界面，可实时监控银企交互的概况及细节。终端用户可以在操作界面中可以根据业务类别、请求时间等条件查询到对应的日志记录，如可以查询到用户在2021年11月2日20点08分36秒进行了查询余额的操作，该查询操作正常进行请求但是返回失败，原因是该用户在对应银行没有账户。需要说明的是，图6～图9仅为效果展示，本实施例并不限制具体的展示内容和样式。
[0095]
应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
[0096]
基于同样的发明构思，本技术实施例还提供了一种用于实现上述所涉及的银企直连的通信方法的银企直连的通信装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个银企直连的通信装置实施例中的具体限定可以参见上文中对于银企直连的通信方法的限定，在此不再赘述。
[0097]
参照图10，图10为本技术实施例中提供的一种银企直连的通信装置的结构示意图，该装置1000包括：获取模块1001、调用模块1002、接收模块1003和第一发送模块1004，各个模块为开放api微服务的模块，开放api微服务可以部署在服务器中，其中：
[0098]
获取模块1001，用于获取目标业务的统一资源定位符url业务请求消息；其中，url业务请求消息包括企业标识、银行标识、以及目标业务对应的应用程序接口名称。
[0099]
调用模块1002，用于调用api名称对应的应用程序接口，应用程序接口用于向银行
标识对应的目标服务器发送url请求消息。
[0100]
接收模块1003，用于接收目标服务器发送的业务响应消息，其中，业务响应消息为目标服务器根据url业务请求消息生成的响应消息。
[0101]
第一发送模块1004，用于向企业标识对应的终端发送业务响应消息。
[0102]
本实施例提供的银企直连的通信装置，通过获取目标业务的统一资源定位符url业务请求消息；其中，url业务请求消息包括企业标识、银行标识、以及目标业务对应的应用程序接口名称，调用api名称对应的应用程序接口，应用程序接口用于向银行标识对应的目标服务器发送url请求消息，接收目标服务器发送的业务响应消息，其中，业务响应消息为目标服务器根据url业务请求消息生成的响应消息，向企业标识对应的终端发送业务响应消息，需布置前置机和cbs业务系统，就可以发送业务请求消息并获取到业务响应消息，简化了传统方式的交互链路和部署设备，解决了以往银企直连通信方法由于部署前置机和cbs业务系统造成的响应延时导致银企交互效率较低的问题，提高了银企交互的效率。
[0103]
可选的，获取模块1001，具体用于开放api微服务接收网关微服务发送的目标业务的url业务请求消息，其中，url业务请求消息为网关微服务接收的终端所发送的请求消息。
[0104]
可选的，应用程序接口用于将url请求消息转换为第一目标格式的请求报文，并向目标服务器发送第一目标格式的请求报文。
[0105]
可选的，银企直连的通信装置1000还包括：
[0106]
第二发送模块，用于周期性向网关微服务发送心跳消息，其中，心跳消息用于供网关微服务判断开放api微服务的工作状态是否正常。
[0107]
可选的，接收模块1003，具体用于接收目标服务器通过核心业务微服务发送的业务响应消息；
[0108]
其中，业务响应消息为核心业务微服务将来自目标服务器的响应消息，转换为第二目标格式的响应报文后得到的响应消息。
[0109]
可选的，银企直连的通信装置1000还包括：
[0110]
第三发送模块，用于向日志管理微服务发送url请求消息对应的信息，url请求消息对应的第一信息用于供日志管理微服务生成与url请求消息对应的第一日志记录，第一信息包括网关微服务发送url请求消息的时间、企业标识、目标业务的业务标识以及银行标识。
[0111]
上述银企直连的通信装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
[0112]
图11为本技术实施例中计算机设备的内部结构图，在本实施例中，提供了一种计算机设备，该计算机设备可以是终端，也可以为服务器，其内部结构图可以如图11所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过wifi、移动蜂窝网络、nfc(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种银企直连的通信方法。该
计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
[0113]
本领域技术人员可以理解，图11中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
[0114]
在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述实施例提供的银企直连的通信方法的步骤。其实现原理和技术效果与上述方法实施例类似，在此不再赘述。
[0115]
在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述实施例提供的银企直连的通信方法的步骤。其实现原理和技术效果与上述方法实施例类似，在此不再赘述。
[0116]
在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述实施例提供的银企直连的通信方法的步骤。其实现原理和技术效果与上述方法实施例类似，在此不再赘述。
[0117]
需要说明的是，本技术所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。
[0118]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read-only memory，rom)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(reram)、磁变存储器(magnetoresistive random access memory，mram)、铁电存储器(ferroelectric random access memory，fram)、相变存储器(phase change memory，pcm)、石墨烯存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器等。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。本技术所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本技术所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。
[0119]
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
[0120]
以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保
护范围。因此，本技术的保护范围应以所附权利要求为准。