CN111414262B - 一种服务调用方法及装置 - Google Patents

一种服务调用方法及装置 Download PDF

Info

Publication number
CN111414262B
CN111414262B CN202010198841.3A CN202010198841A CN111414262B CN 111414262 B CN111414262 B CN 111414262B CN 202010198841 A CN202010198841 A CN 202010198841A CN 111414262 B CN111414262 B CN 111414262B
Authority
CN
China
Prior art keywords
service
switching gateway
request message
component
provider
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010198841.3A
Other languages
English (en)
Other versions
CN111414262A (zh
Inventor
刘奇峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to CN202010198841.3A priority Critical patent/CN111414262B/zh
Publication of CN111414262A publication Critical patent/CN111414262A/zh
Application granted granted Critical
Publication of CN111414262B publication Critical patent/CN111414262B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services
    • G06F9/548Object oriented; Remote method invocation [RMI]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提出了一种服务调用方法,包括以下步骤:业务交换网关分别和服务消费者、服务提供者建立连接;业务交换网关接收服务消费者或服务提供者发送的消息,业务交换网关将从服务消费者或服务提供者处接收的消息处理后发送给相应的服务提供者或服务消费者。本发明通过引入业务交换网关和相应的过程调用方法,避免了传统方法中可能出现的各类网络问题,也简化和标准化了异构网络服务调用的实现,进一步对业务组件的主备和负荷分担特性也做了基于业务交换网关的实现。

Description

一种服务调用方法及装置
技术领域
本发明申请涉及通信领域,尤其涉及云计算或一般分布式系统中的一种服务调用方法及装置。
背景技术
远程过程调用(RPC,Remote Procedure Call)是一种计算机通信协议,在不需要了解支持通信的网络协议下,允许运行于一台计算机的程序通过网络调用另一台远程计算机的程序。在传统远程服务调用方法中,服务消费者需要获得服务提供者的IP地址和端口号,然后才能发起过程调用,而这个IP地址和端口号可能是用户手动输入或者是从配置文件中获取,再或者从类似etcd、zookeeper这样的中间件动态获取。随着微服务概念的兴起,跨计算节点发起过程调用或者服务访问的软件系统越来越多,通过etcd、zookeeper类似中间件获取服务提供者地址基本成为标准过程。
服务消费者和服务提供者通过etcd、zookeeper这样第三方注册中间件完成互通的方法存在一些问题,比如1)第三方注册中间件检测服务提供者是否健康走的网络通道和消费者调用提供者走的网络通道不同,那就可能出现消费者无法完成过程或服务调用,但第三方注册中间件监测服务提供者一直健康和正常;2)如果服务消费者在IPv4网络中,而服务提供者在IPv6网络中,此时即使消费者能够通过第三方获得提供者地址也无法访问。
发明内容
为解决上述问题,本发明提出了一种服务调用方法,包括以下步骤:
业务交换网关分别和服务消费者、服务提供者建立连接;
业务交换网关接收服务消费者和服务提供者的组件注册请求消息,所述组件注册请求消息包含组件的名称和工作模式信息;所述组件包括服务消费者和服务提供者;
业务交换网关解析组件注册请求消息完成组件注册相关处理后,通过组件注册响应消息向组件发送注册结果,注册成功后的组件注册结果包含组件所对应的端口号;
业务交换网关接收服务提供者发送的服务注册消息,所述服务注册消息包括服务提供者提供的服务的名称和类型;
业务交换网关给服务分配端口号并将服务的相关信息存储到服务信息表中,将端口号对应的端口与服务提供者的关系存储到端口表中;所述服务的相关信息包括名称、类型和端口;
业务交换网关接收和解析服务消费者发送的服务查询消息后,向服务消费者发送服务查询响应;所述服务查询消息包括服务的名称;所述服务查询响应包括服务的名称、类型和端口号;
业务交换网关接收服务消费者发送的服务调用请求消息,所述服务调用请求消息包括服务的端口号和返回标记;
业务交换网关根据服务调用请求消息中的端口号找到对应的服务提供者,将服务调用请求消息转发给服务提供者,服务调用完成;
若返回标记表示的是需要返回,则业务交换网关将服务消费者的端口号封装进服务调用请求消息后再转发给服务提供者;业务交换网关接收服务提供者返回的服务调用响应,根据服务调用响应消息里的服务消费者的端口号找到服务消费者,将服务调用响应消息发送给服务消费者;服务调用完成。
进一步地,所述业务交换网关分别和服务的消费者、提供者建立连接的方式包括进程间通信方式、IPv4的TCP或UDP方式、IPv6的TCP或UDP方式和其他网络协议方式;所述其他网络协议包括蓝牙、Zigbee和EtherCAT;
所述业务交换网关为服务端,服务消费者和提供者为客户端。
进一步地,所述服务的名称是一个字符串,该字符串使用关键词分割成多个子字符串,子字符串对应“区域”、“组织类型”、“组织名称”和“服务名”。
进一步地,服务的类型表示服务的使用方式,所述服务的使用方式包括服务调用参数的封装格式、是否需要返回调用结果、返回的结果的封装格式;
进一步地,服务的类型表示服务对网络的服务质量要求,服务对网络的服务质量要求包括报文的优先级,是否需要可靠连接。
进一步地,所述工作模式信息包括独立模式、主备模式和负荷分担。
进一步地,当所述工作模式信息为独立模式时,则与业务交换网关连接的多个服务提供者的名称不相同。
进一步地,当所述工作模式信息为主备模式时,则与业务交换网关连接的名称相同的服务提供者有两个;业务交换网关根据在组件注册请求消息中携带的主备标记确定主服务提供者和备服务提供者,所述主备标记包括“主”和“备”,主备标记为“主”的服务提供者即为主服务提供者,主备标记为“备”的服务提供者即为备服务提供者,若组件注册请求消息中不携带有主备标记则业务交换网关将先发送组件注册请求消息的组件的主备标记记为“主”,后发送组件注册请求消息的组件为的主备标记记为“备”;业务交换网关将服务调用请求消息发送给主服务提供者。
进一步地,当工作模式信息是负荷分担时,与业务交换网关下连接的同名服务提供者有多个;
业务交换网关维护一张服务负荷分担表,记录服务可以分发给哪些组件;
业务交换网关接收服务提供者的服务调用请求消息后,根据其维护的服务负荷分担表将该服务调用请求消息进行分发;所述服务负担表记载服务提供者和服务提供者所提供的服务。
进一步地,所述业务交换网关与服务提供者之间周期性地护发保活报文,若业务交换网关有若干个保活报文没有收到,则确定对应服务提供者失活;如果该失活的服务提供者的工作模式信息是主备模式且主备标记为“主”,则找将其对应的备服务提供者的主备标记设置为“主”;如果该失活的服务提供者的工作模式信息为负荷分担,则将服务负荷分担表对应的记录,删除对应的该失活的服务提供者和其所提供的服务的记载。
进一步地,还包括业务交换网关与用户接口程序建立连接;业务交换网关接收、解析用户接口程序发送的网关命令请求消息,生成网关命令响应消息后返回给用户接口程序;所述网关命令请求消息用于查询当前业务交换网关连接的服务提供者的名称、状态、工作模式,用于查询与业务交换网关连接的服务提供者和服务消费者已经收发的服务调用请求消息个数和服务调用响应消息个数。
本发明还提供了一种服务调用装置,包括:
与服务消费者和服务提供者建立连接的业务交换网关,所述业务交换网关为单独的软件、软硬件独立的单独物理设备或者虚拟机或容器;
所述业务交换网关包括:
接收模块,用于接收服务消费者或服务提供者发送的消息,
发送模块,用于将从服务消费者或服务提供者处接收的消息处理后发送给相应的服务提供者或服务消费者,
所述服务消费者发送的消息包括组件注册请求消息、服务查询消息和服务调用请求消息;所述服务提供者发送的消息包括组件注册请求消息、服务注册消息和服务调用响应消息;
所述业务交换网关通过上述任一服务调用方法提供服务调用。
本发明与现有技术相比,有益效果在于:
(1)避免了传统方法中可能出现的各类网络问题,如如果服务消费者在IPv4网络中,而服务提供者在IPv6网络中,此时即使消费者能够通过第三方获得提供者地址也无法访问的问题。
(2)简化和标准化了异构网络服务调用的实现。
(3)对业务组件的主备和负荷分担特性做了基于业务交换网关的实现。
附图说明
图1为本发明的组网示例。
图2为本发明的调用过程方法的流程图。
图3为本发明实施例1的组网拓扑。
图4为本发明实施例1的调用过程方法的流程图。
图5为本发明实施例2组网拓扑。
图6为本发明实施例2的调用过程方法的流程图。
图7为本发明实施例3的组网拓扑。
图8为本发明实施例3的调用过程方法的流程图。
图9为本发明实施例4的组网拓扑。
图10为本发明实施例4的调用过程方法的流程图。
图11为本发明实施例5的组网拓扑。
图12为本发明实施例5的调用过程方法的流程图。
图13为本发明实施例6的组网拓扑。
图14为本发明实施例6的调用过程方法的流程图。
具体实施方式
在本公开中参照附图来描述本发明的各方面,附图中示出了许多说明的实施例。本公开的实施例不必定意在包括本发明的所有方面。应当理解,上面介绍的多种构思和实施例,以及下面更加详细地描述的那些构思和实施方式可以以很多方式中任意一种来实施,这是因为本发明所公开的构思和实施例并不限于任何实施方式。另外,本发明公开的一些方面可以单独使用,或者与本发明公开的其他方面的任何适当组合来使用。
本发明申请需要引入业务交换网关,其具体实施时可以是一个软件程序,也可以是软硬件独立的一个物理设备,或者是某个在运行的虚拟机或容器。一般业务交换网关为服务端,而服务消费者和服务提供者则都是作为客户端与其相连。为了方便描述,这里以业务交换网关为一个TCP服务端程序举例,对应的服务消费者和服务提供者则都是TCP客户端程序,其组网图如图1所示:
服务消费者和提供者与业务交换网关建立连接后,通过“组件注册请求/响应消息”、“服务注册请求/响应消息”、“服务查询请求/响应消息”、“服务调用请求/响应消息”、“服务注销请求/响应消息”5类消息与业务交换网关进行交互,完成业务处理。
结合图2,一般消息交互流程如下:
步骤A1:业务交换网关启动,打开TCP服务端口(比如1234);
步骤A2:服务消费者和提供者从用户输入或者配置信息中获得业务交换网关的地址和端口号(比如127.0.0.1:1234),向业务交换网关发起TCP建链请求完成连接;
步骤A3:服务消费者和提供者作为组件,通过TCP连接向业务交换网关发送组件注册请求消息,其中包含组件的名称以及工作模式(默认为独立);业务交换网关解析组件注册请求消息完成组件注册相关处理后,通过组件注册响应消息向组件发送注册结果,注册成功后的注册结果包含组件所对应的端口号;
步骤A4:服务提供者通过TCP连接向业务交换网关发送服务注册请求消息,其中包含服务名称以及类型;
步骤A5:业务交换网关解析服务注册请求消息完成服务注册相关处理后,通过服务注册响应消息向组件发送服务注册结果,注册成功后的注册结果包含服务所对应的端口号;
步骤A6:服务消费者通过TCP连接向业务交换网关发送服务查询请求消息,其中包含服务名称;
步骤A7:业务交换网关解析服务查询请求消息,将查询结果通过服务查询响应消息发送给服务消费者,查询结果包含服务名称、类型、端口号等信息;
步骤A8:服务消费者解析服务查询响应消息,存储服务名称、类型、端口号等信息;当服务消费者需要调用某服务时,根据服务类型完成服务调用请求消息的封装,然后将服务调用请求消息发送给业务交换网关。服务调用请求报文中包含服务端口号(目的端口号)、“返回标记”等信息;
步骤A9:业务交换网关根据服务调用请求消息中的服务端口号找到对应的服务提供者,根据是否有“返回标记”封装服务消费者的端口号(源端口号),将服务调用请求消息转发给服务提供者;
步骤A10:服务提供者解析并处理服务调用请求消息,根据情况确定是否需要生成服务调用响应消息;服务调用响应消息的目的端口号为服务消费者的端口号,服务提供者将服务调用响应消息发送给业务交换网关;
步骤A11:业务交换网关根据服务调用响应消息里面的目的端口号找到服务消费者,将消息发送给服务消费者;
步骤A12:服务消费者接收到服务调用响应消息,完成整个服务调用过程。
实施例1
本实施例描述日志服务基于业务交换网关实现基本功能的方法和流程。
本实施例的组网描述具体如下:
如图3所示,业务交换网关作为一个独立的服务端软件运行在192.168.1.10这台设备上,其打开的TCP服务端口号是1234;应用程序为了调用日志服务,其作为一个TCP客户端与业务交换网关建立TCP连接;日志服务组件为日志服务的提供者,其也作为一个TCP客户端与业务交换网关建立TCP连接。
本实施例的业务描述具体如下:
日志服务组件提供的日志服务名称标识为“my_log”,可输入的参数有应用程序名称、发日志的模块名称、日志级别和日志内容。日志服务没有返回消息,所以服务类型可以是“无返回的服务调用”。应用程序调用“my_log”服务,实际是向业务交换网关发送服务调用请求消息,业务交换网关接收后再将服务调用请求消息发送给日志服务组件,日志服务组件解析并处理服务调用请求消息,即完成一次“my_log”的服务调用。
如图4所示,本实施例的“my_log”服务调用的消息交互流程具体如下:
步骤B1:业务交换网关启动,打开TCP服务端口(比如1234);
步骤B2:日志服务组件和应用程序从用户输入的信息或者配置信息中获得业务交换网关的地址和端口号(比如127.0.0.1:1234),向业务交换网关发起TCP建链请求完成连接;
步骤B3:日志服务组件和应用程序都作为组件,通过TCP连接向业务交换网关发送组件注册请求消息,其中包含组件名称以及工作模式信息(默认为独立);业务交换网关解析组件注册请求消息后完成组件注册的相关处理,并通过组件注册响应消息向组件发送注册结果,注册成功后的注册结果一般包含组件所对应的端口号;
步骤B4:日志服务组件通过TCP连接向业务交换网关发送服务注册请求消息,其中包含服务名称“my_log”以及类型“无返回服务调用”;
步骤B5:业务交换网关解析服务注册请求消息并完成服务注册的相关处理后,通过服务注册响应消息向日志服务组件发送服务注册结果,注册成功后的注册结果包含my_log服务所对应的端口号10001;
步骤B6:应用程序通过TCP连接向业务交换网关发送服务查询请求消息,其中包含服务名称“my_log”;
步骤B7:业务交换网关解析“my_log”服务查询请求消息,将查询结果通过服务查询响应消息发送给服务消费者,查询结果一般包含服务名称——“my_log”、类型——“无返回服务调用”、端口号——“10001”等信息;
步骤B8:应用程序解析服务查询响应消息,存储服务名称“my_log”关联的类型和端口号等。当服务消费者需要调用“my_log”服务时,根据之前存储的信息完成服务调用请求报文的封装,然后将服务调用请求报文发送给业务交换网关。“my_log”的服务调用请求消息中一般有端口号10001,应用程序名称,模块名称,日志级别,日志内容等信息;
步骤B9:业务交换网关根据my_log服务调用请求消息中的端口号10001找到对应的服务提供者——日志服务组件,将服务调用请求消息转发给日志服务组件;
步骤B10:日志服务组件解析并处理my_log服务调用请求消息,将消息中的应用程序名称、模块名称、日志级别、日志内容存储起来。
实施例2
本实施例描述天气预报服务基于业务交换网关实现基本功能的方法和流程。
本实施例的组网描述具体如下:
如图5所示,本实施例的组网结构和实施例1进行改进而来,具体为将实施例1中的日志服务组件替换为天气预报服务组件。
业务交换网关作为一个独立的服务端软件运行在192.168.1.10这台设备上,其打开的TCP服务端口号是1234;应用程序为了调用天气预报服务,其作为一个TCP客户端与业务交换网关建立TCP连接;天气预报服务组件为天气预报服务的提供者,其也作为一个TCP客户端与业务交换网关建立TCP连接。
本实施例的业务描述具体如下:
天气预报服务组件提供的天气预报服务名称标识是“my_weather”,可输入的参数有城市名称、预报日期。该服务有返回消息,所以服务类型是“有返回的服务调用”。应用程序调用“my_weather”服务,实际是向业务交换网关发送服务调用请求消息。业务交换网关再将消息发送给天气预报服务组件,天气预报服务组件解析并处理服务调用请求消息,将预测的天气情况填入服务调用响应消息并发送给业务交换网关,业务交换网关将服务调用响应消息发送给应用程序,应用程序解析服务调用响应消息取出天气预报结果完成本次调用。
结合图6,“my_weather”服务调用的消息交换步骤如下:
步骤C1:业务交换网关启动,打开TCP服务端口(比如1234);
步骤C2:应用程序和天气预报服务组件从用户输入或者配置信息中获得业务交换网关的地址和端口号(比如127.0.0.1:1234),向网关发起TCP建链请求完成连接;
步骤C3:应用程序和天气预报服务组件作为组件,通过TCP连接向业务交换网关发送组件注册请求消息,其中包含组件的名称以及工作模式信息(默认为独立);业务交换网关解析组件注册请求消息并完成组件注册的相关处理后,通过组件注册响应消息向组件发送注册结果,注册成功后的注册结果包含组件所对应的端口号,具体地,应用程序端口号为1002,天气预报服务组件端口号为1003;
步骤C4:天气预报服务组件通过TCP连接向业务交换网关发送服务注册请求消息,其中包含服务名称“my_weather”以及类型“有返回的服务调用”;
步骤C5:业务交换网关解析“my_weather”服务注册请求消息并完成服务注册的相关处理后,通过服务注册响应消息向天气预报服务组件发送服务注册结果,注册结果包含“my_weather”服务所对应的端口号1002;
步骤C6:应用程序通过TCP连接向业务交换网关发送服务查询请求消息,其中包含服务名称“my_weather”;
步骤C7:业务交换网关解析服务查询请求消息,将查询结果通过服务查询响应消息发送给天气预报服务组件,查询结果包含服务名称“my_weather”、类型“有返回的服务调用”和端口号1002;
步骤C8:应用程序解析服务查询响应消息,存储“my_weather”服务对应的名称、类型、端口号等信息。当应用程序需要调用“my_weather”服务时,根据服务类型完成服务调用请求报文的封装,然后将服务调用请求报文发送给业务交换网关。报文中包含服务端口号1002、“返回标记”、“预报的城市”、“预报的日期”等信息;并且设置“返回标记”;
步骤C9:业务交换网关根据服务调用请求消息中的端口号1002找到对应的服务提供者,根据是否有返回标记封装服务消费者的端口号1002,将服务调用请求消息转发给天气预报服务组件;
步骤C10:天气预报服务组件解析并处理服务调用请求消息,根据“预报的城市”与“预报的日期”确定天气预报结果,将天气预报结果封装到服务调用响应消息;服务调用响应消息的目的端口号为服务消费者的端口号即1002端口,天气预报服务组件将服务调用响应消息发送给业务交换网关;
步骤C11:业务交换网关根据服务调用响应消息里面的端口号1002找到应用程序,将消息发送给应用程序;
步骤C12:应用程序接收到服务调用响应消息,从消息中解析出天气预报的结果,完成整个服务调用过程。
实施例3
本实施例描述烟雾监测系统基于业务交换网关实现监测值上报的方法和流程。
本实施例的组网描述具体如下:
如图7所示,本实施例的组网结构具体为,烟雾监测软件和烟雾报警器之间通过业务交换网关进行通信。
业务交换网关作为一个独立的服务端软件运行在192.168.1.10这台设备上,其打开的TCP服务端口号是1234;同时该设备还有IPv6地址2001::1,并接入了IPv6网络。烟雾监测软件运行在IPv4网络中,其作为一个TCPv4客户端与业务交换网关建立TCPv4连接;烟雾报警器在系统中有多个,运行在IPv6网络中,每个报警器作为一个TCPv6客户端与业务交换网关建立TCPv6连接。
本实施例的业务描述具体如下:
烟雾监测软件提供的服务名称标识为“my_smoke”,烟雾报警器周期性地调用“my_smoke”服务,将其自身的位置信息、检测到的烟雾值上报给烟雾监测软件。烟雾报警器调用“my_smoke”服务实际就是向业务交换网关发送服务调用请求消息,业务交换网关再将服务调用请求消息发送给烟雾监测软件,烟雾监测软件解析“my_smoke”服务调用请求消息,根据消息内容和自身配置进行进一步的业务处理。
结合图8,“my_smoke”服务调用的消息交互流程如下:
步骤D1:业务交换网关启动,打开TCP服务端口(比如1234);
步骤D2:烟雾监测软件和烟雾报警器从用户输入或者配置信息中获得业务交换网关的地址和端口号(比如业务交换网关的地址192.168.1.10:1234,端口号为[2001::1]:1234),向业务交换网关发起TCP建链请求完成连接;
步骤D3:烟雾监测软件和烟雾报警器作为组件,通过TCP连接向业务交换网关发送组件注册请求消息,其中包含组件的名称以及工作模式信息(默认为独立);业务交换网关解析组件注册请求消息并完成组件注册的相关处理后,通过组件注册响应消息向组件发送注册结果,注册结果包含组件所对应的端口;
步骤D4:烟雾监测软件通过TCPv4连接向业务交换网关发送服务注册请求消息,其中包含服务名称“my_smoke”以及类型“无返回服务调用”;
步骤D5:业务交换网关解析服务注册请求消息并完成服务注册的相关处理后,通过服务注册响应消息向日志服务组件发送服务注册结果,注册成功后的结果包含my_weather服务所对应的端口号10004;
步骤D6:烟雾报警器通过TCPv6连接向业务交换网关发送服务查询请求消息,其中包含服务名称“my_smoke”;
步骤D7:业务交换网关解析“my_smoke”服务查询请求消息,将查询结果通过服务查询响应消息发送给烟雾报警器,查询结果一般包含服务名称(具体为“my_smoke”)、类型(具体为“无返回服务调用”)和端口号(具体为“10004”);
步骤D8:烟雾报警器解析服务查询响应消息,存储服务名称“my_smoke”关联的类型和端口号等。当烟雾报警器需要调用“my_smoke”服务时,根据之前存储的信息完成服务调用请求报文的封装,然后将服务调用请求报文发送给业务交换网关。
“my_smoke”的服务调用请求消息中一般有端口号10004、烟雾报警器位置、当前烟雾检测值等信息;
步骤D9:业务交换网关根据服务调用请求消息中的端口号10004找到对应的服务提供者——烟雾监测软件,将服务调用请求消息转发给烟雾监测软件;
步骤D10:烟雾监测软件解析并处理“my_smoke”服务调用请求消息,一般是取消息中的当前烟雾检测值根据业务逻辑做进一步处理。
实施例4
本实施例描述天气预报服务基于业务交换网关实现服务组件异常时主备倒换的方法和流程。
本实施例的组网描述具体如下:
如图9所示,业务交换网关作为一个独立的服务端软件运行在192.168.1.10这台设备上,其打开的TCP服务端口号是1234;应用程序为了调用天气预报服务,其作为一个TCP客户端与业务交换网关建立TCP连接;天气预报服务组件A为天气预报服务的提供者,其也作为一个TCP客户端与业务交换网关建立TCP连接;天气预报服务组件B为天气预报服务的另外一个提供者,其也作为一个TCP客户端与业务交换网关建立TCP连接。
本实施例的业务描述具体如下:
天气预报服务组件A与天气预报服务组件B为同一个软件程序的两个运行实例,其运行模式为“主备”。即两个组件提供的服务一样,由业务交换网关确定选取其中一个为“主”,另外一个为“备”。当业务交换网关接收到服务调用请求消息时,将消息转发给“主”组件做相应处理。这里不妨假设天气预报服务组件A为“主”,天气预报服务组件B为“备”,业务交换网关与天气预报服务组件A、业务交换网关与天气预报服务组件B定时互发保活消息,假设连续若干时间内没有收到组件A的保活消息,则将天气预报服务组件A设置为”备“,将天气预报服务组件B设置为主,后续的服务调用请求消息就发送给天气预防服务组件B进行处理。
结合图10,天气预报服务组件A、B的主备状态设置和切换流程如下:
步骤E1:业务交换网关启动,打开TCP服务端口(比如1234);
步骤E2:应用程序和天气预报服务组件A、B从用户输入或者配置信息中获得业务交换网关的地址和端口号(具体地,地址为192.168.1.10,端口号为1234),向网关发起TCP建链请求并完成连接;
步骤E3:应用程序和天气预报服务组件A、B作为组件,通过TCP连接向业务交换网关发送组件注册请求消息,其中包含组件的名称以及工作模式信息;应用程序为“独立”工作模式,天气预报服务组件A、B为一“主”一“备”工作模式;假定组件A先发起注册,则组件A为“主”组件,组件B为“备”组件;
步骤E4:天气预报服务组件A通过TCP连接向业务交换网关发送服务注册请求消息,其中包含服务名称“my_weather”以及类型“有返回的服务调用”;
步骤E5:业务交换网关解析组件A的“my_weather”服务注册请求消息,给“my_weather”服务分配端口号1002,并设置1002端口对应组件为A;
步骤E6:天气预报服务组件B通过TCP连接向业务交换网关发送服务注册请求消息,其中包含服务名称“my_weather”以及类型“有返回的服务调用”;
步骤E7:业务交换网关解析组件B的“my_weather”服务注册请求消息,消息中的信息与当前存储的一致,则返回成功,否则返回失败;
步骤E8:业务交换网关根据配置周期性的发送保活报文给天气预报服务组件A和B;
步骤E9:天气预报服务组件A异常退出;
步骤E10:业务交换网关判断天气预报服务组件A异常,将天气预报服务组件A设置为“备”,将天气预报服务组件B设置为“主”,更新端口1002对应的组件为B。
实施例5
本实施例描述日志服务基于业务交换网关实现服务组件负荷分担的方法和流程。
本实施例的组网描述具体如下:
如图11所示,业务交换网关作为一个独立的服务端软件运行在192.168.1.10这台设备上,其打开的TCP服务端口号是1234;应用程序为了调用日志服务,其作为一个TCP客户端与业务交换网关建立TCP连接;日志服务组件A为日志服务的提供者,其也作为一个TCP客户端与业务交换网关建立TCP连接;日志服务组件B为日志服务的另外一个提供者,其也作为一个TCP客户端与业务交换网关建立TCP连接
结合图12,本实施例的业务描述具体如下:
日志服务组件A与日志服务组件B为同一个软件程序的两个运行实例,其运行模式为“负荷分担”。即两个组件提供的服务一样,当发生日志服务调用时,由业务交换网关根据一定负荷分担配置或算法确定选取其中一个组件完成日志服务的调用。
日志服务组件A、B的状态设置和负荷分担流程如下:
步骤F1:业务交换网关启动,打开TCP服务端口(比如1234);
步骤F2:应用程序和日志服务组件A、B从用户输入或者配置信息中获得业务交换网关的地址和端口号(比如192.168.1.10:1234),向网关发起TCP建链请求完成连接;
步骤F3:应用程序和日志服务组件A、B都作为组件,通过TCP连接向业务交换网关发送组件注册请求消息,其中包含组件的名称以及工作模式信息;应用程序为“独立”工作模式,日志服务组件A、B为“负荷分担”工作模式;
步骤F4:日志服务组件A通过TCP连接向业务交换网关发送服务注册请求消息,其中包含服务名称“my_log”以及类型“无返回的服务调用”;
步骤F5:业务交换网关解析组件A的“my_log”服务注册请求消息,给“my_log”服务分配端口号10006,并创建10006端口对应的负荷分担表,负荷分担表中成员为组件A;
步骤F6:日志服务组件B通过TCP连接向业务交换网关发送服务注册请求消息,其中包含服务名称“my_log”以及类型“无返回的服务调用”;
步骤F7:业务交换网关解析组件B的“my_log”服务注册请求消息,消息中的信息与当前存储的一致,更新10006端口对应的负荷分担表,增加负荷分担表成员组件B;
步骤F8:应用程序通过连接向业务交换网关发送服务查询请求消息,其中包含服务名称“my_log”;
步骤F9:业务交换网关解析“my_log”服务查询请求消息,将查询结果通过服务查询响应消息发送给组件,查询结果一般包含服务名称(具体为“my_log”)、类型(具体为“无返回服务调用”)、端口号(具体为“10006”);
步骤F10:应用程序解析服务查询响应消息,存储服务名称“my_log”关联的类型和端口号等。当应用程序需要调用“my_log”服务时,根据之前存储的信息完成服务调用请求报文的封装,然后将服务调用请求报文发送给业务交换网关。“my_log”的服务调用请求消息中一般有端口号10006、日志组件名称、日志级别和日志内容;
步骤F11:业务交换网关根据服务调用请求消息中的端口号10006找到该服务对应的负荷分担表,则按照配置或算法从负荷分担表中选择一个组件(比如日志服务组件A),将服务调用消息转发给日志服务组件A;
步骤F12:日志服务组件A解析并处理my_log服务调用请求消息,一般是将消息中的应用程序名称、模块名称、日志级别、日志内容进行存储。
实施例6
本实施例描述用户发起的天气预报服务主备组件倒换的方法和流程。
本实施例的组网描述具体如下:
如图13所示,业务交换网关作为一个独立的服务端软件运行在192.168.1.10这台设备上,其打开的TCP服务端口号是1234;应用程序为天气预报服务的调用者,其作为一个TCP客户端与业务交换网关建立TCP连接;天气预报服务组件A与B都为天气预报服务的提供者,都作为TCP客户端与业务交换网关建立TCP连接;用户接口程序作为运维接口方便用户运维系统,也作为TCP客户端与业务交换网关建立TCP连接。
本实施例的业务描述具体如下:
天气预报服务组件A与B都提供服务“my_weather”,但两者实现的版本不同,可以假定组件A的版本比较老,而组件B的版本比较新,用户需要升级天气预报服务组件,通过用户接口程序提供的接口,向业务交换网关发生天气预防服务组件的主备倒换消息,从而完成天气预报服务组件的主备倒换,即组件版本的升级。
结合图14,天气预报服务组件A、B的状态设置和主备倒换流程:
步骤G1:业务交换网关启动,打开TCP服务端口(比如1234);
步骤G2:应用程序和天气预报服务组件A从用户输入或者配置信息中获得业务交换网关的地址和端口号(比如192.168.1.10:1234),向网关发起TCP建链请求并完成连接;
步骤G3:应用程序和天气预报服务组件A都作为组件,通过TCP连接向业务交换网关发送组件注册请求消息,其中包含组件的名称以及工作模式信息;应用程序为“独立”工作模式,天气预报服务组件A为“主备”工作模式;
步骤G4:天气预报服务组件A向业务交换网关发送“my_weather”的服务注册消息;
步骤G5:业务交换网关解析服务注册消息,给“my_weather”服务分配端口10008,并将将服天气预报服务组件A与端口10008关联;即后续应用程序调用“my_weather”服务时,即由天气预报服务组件A提供服务;
步骤G6:启动新的天气预报服务组件B,天气预报服务组件B向网关发起TCP建链请求并完成连接;
步骤G7:天气预报服务组件B向业务交换网关发送组件注册请求,其中包含组件名称和工作模式信息,这里组件名称与工作模式都与天气预报服务组件A相同;
步骤G8:天气预报服务组件B向业务交换网关发送“my_weather”的服务注册消息;
步骤G9:业务交换网关解析服务注册消息,将服天气预报服务组件B与端口10008关联;
步骤G10:用户接口程序启动,向网关发起TCP建链请求并完成连接;
步骤G11:用户接口程序作为“用户接口”向业务交换网关发送接口注册请求消息;
步骤G12:用户通过用户接口程序向业务交换网关发送天气预报服务组件的主备倒换命令;
步骤G13:业务交换网关解析主备倒换命令,将端口10008关联的主组件设置为天气预报服务组件B;即后续应用程序调用“my_weather”服务时,都由天气预报服务组件B提供服务。
本发明还公开了一种服务调用装置,包括:
与服务消费者和服务提供者建立连接的业务交换网关,所述业务交换网关为单独的软件、软硬件独立的单独物理设备或者虚拟机或容器;
所述业务交换网关包括:
接收模块,用于接收服务消费者或服务提供者发送的消息,
发送模块,用于将从服务消费者或服务提供者处接收的消息处理后发送给相应的服务提供者或服务消费者,
所述服务消费者发送的消息包括组件注册请求消息、服务查询消息和服务调用请求消息;所述服务提供者发送的消息包括组件注册请求消息、服务注册消息和服务调用响应消息。
本发明避免了传统方法中可能出现的各类网络问题,如如果服务消费者在IPv4网络中,而服务提供者在IPv6网络中,此时即使消费者能够通过第三方获得提供者地址也无法访问的问题;本发明简化和标准化了异构网络服务调用的实现,对业务组件的主备和负荷分担特性做了基于业务交换网关的实现。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (11)

1.一种服务调用方法,其特征在于,包括以下步骤:
业务交换网关分别和服务消费者、服务提供者建立连接;
业务交换网关接收服务消费者和服务提供者的组件注册请求消息,所述组件注册请求消息包含组件的名称和工作模式信息;所述组件包括服务消费者和服务提供者;
业务交换网关解析组件注册请求消息完成组件注册相关处理后,通过组件注册响应消息向组件发送注册结果,注册成功后的组件注册结果包含组件所对应的端口号;
业务交换网关接收服务提供者发送的服务注册消息,所述服务注册消息包括服务提供者提供的服务的名称和类型;
业务交换网关给服务分配端口号并将服务的相关信息存储到服务信息表中,将端口号对应的端口与服务提供者的关系存储到端口表中;所述服务的相关信息包括名称、类型和端口;
业务交换网关接收和解析服务消费者发送的服务查询消息后,向服务消费者发送服务查询响应;所述服务查询消息包括服务的名称;所述服务查询响应包括服务的名称、类型和端口号;
业务交换网关接收服务消费者发送的服务调用请求消息,所述服务调用请求消息包括服务的端口号和返回标记;
业务交换网关根据服务调用请求消息中的端口号找到对应的服务提供者,将服务调用请求消息转发给服务提供者,服务调用完成;
若返回标记表示的是需要返回,则业务交换网关将服务消费者的端口号封装进服务调用请求消息后再转发给服务提供者;业务交换网关接收服务提供者返回的服务调用响应,根据服务调用响应消息里的服务消费者的端口号找到服务消费者,将服务调用响应消息发送给服务消费者;服务调用完成;所述业务交换网关分别和服务的消费者、提供者建立连接的方式包括进程间通信方式、IPv4的TCP或UDP方式、IPv6的TCP或UDP方式和其他网络协议方式;所述其他网络协议包括蓝牙、Zigbee和EtherCAT;服务消费者、服务提供者位于不同的网络中;
所述业务交换网关为服务端,服务消费者和提供者为客户端。
2.根据权利要求1所述的服务调用方法,其特征在于,所述服务的名称是一个字符串,该字符串使用关键词分割成多个子字符串,子字符串对应“区域”、“组织类型”、“组织名称”和“服务名”。
3.根据权利要求1所述的服务调用方法,其特征在于,服务的类型表示服务的使用方式,所述服务的使用方式包括服务调用参数的封装格式、是否需要返回调用结果、返回的结果的封装格式。
4.根据权利要求1所述的服务调用方法,其特征在于,服务的类型表示服务对网络的服务质量要求,服务对网络的服务质量要求包括报文的优先级,是否需要可靠连接。
5.根据权利要求3所述的服务调用方法,其特征在于,所述工作模式信息包括独立模式、主备模式和负荷分担。
6.根据权利要求5所述的服务调用方法,其特征在于,当所述工作模式信息为独立模式时,则与业务交换网关连接的多个服务提供者的名称不相同。
7.根据权利要求5所述的服务调用方法,其特征在于,当所述工作模式信息为主备模式时,则与业务交换网关连接的名称相同的服务提供者有两个;业务交换网关根据在组件注册请求消息中携带的主备标记确定主服务提供者和备服务提供者,所述主备标记包括“主”和“备”,主备标记为“主”的服务提供者即为主服务提供者,主备标记为“备”的服务提供者即为备服务提供者,若组件注册请求消息中不携带有主备标记则业务交换网关将先发送组件注册请求消息的组件的主备标记记为“主”,后发送组件注册请求消息的组件为的主备标记记为“备”;业务交换网关将服务调用请求消息发送给主服务提供者。
8.根据权利要求7所述的服务调用方法,当工作模式信息是负荷分担时,与业务交换网关下连接的同名服务提供者有多个;
业务交换网关维护一张服务负荷分担表,记录服务可以分发给哪些组件;
业务交换网关接收服务提供者的服务调用请求消息后,根据其维护的服务负荷分担表将该服务调用请求消息进行分发;所述服务负担表记载服务提供者和服务提供者所提供的服务。
9.根据权利要求8所述的服务调用方法,其特征在于,所述业务交换网关与服务提供者之间周期性地护发保活报文,若业务交换网关有若干个保活报文没有收到,则确定对应服务提供者失活;如果该失活的服务提供者的工作模式信息是主备模式且主备标记为“主”,则找将其对应的备服务提供者的主备标记设置为“主”;如果该失活的服务提供者的工作模式信息为负荷分担,则将服务负荷分担表对应的记录,删除对应的该失活的服务提供者和其所提供的服务的记载。
10.根据权利要求1所述的服务调用方法,其特征在于,还包括业务交换网关与用户接口程序建立连接;业务交换网关接收、解析用户接口程序发送的网关命令请求消息,生成网关命令响应消息后返回给用户接口程序;所述网关命令请求消息用于查询当前业务交换网关连接的服务提供者的名称、状态、工作模式,用于查询与业务交换网关连接的服务提供者和服务消费者已经收发的服务调用请求消息个数和服务调用响应消息个数。
11.一种服务调用装置,其特征在于,包括:
与服务消费者和服务提供者建立连接的业务交换网关,所述业务交换网关为单独的软件、软硬件独立的单独物理设备或者虚拟机或容器;
所述业务交换网关包括:
接收模块,用于接收服务消费者或服务提供者发送的消息,
发送模块,用于将从服务消费者或服务提供者处接收的消息处理后发送给相应的服务提供者或服务消费者,
所述服务消费者发送的消息包括组件注册请求消息、服务查询消息和服务调用请求消息;所述服务提供者发送的消息包括组件注册请求消息、服务注册消息和服务调用响应消息;
所述业务交换网关通过如权利要求1-10任一所述服务调用方法提供服务调用。
CN202010198841.3A 2020-03-19 2020-03-19 一种服务调用方法及装置 Active CN111414262B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010198841.3A CN111414262B (zh) 2020-03-19 2020-03-19 一种服务调用方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010198841.3A CN111414262B (zh) 2020-03-19 2020-03-19 一种服务调用方法及装置

Publications (2)

Publication Number Publication Date
CN111414262A CN111414262A (zh) 2020-07-14
CN111414262B true CN111414262B (zh) 2024-03-22

Family

ID=71494654

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010198841.3A Active CN111414262B (zh) 2020-03-19 2020-03-19 一种服务调用方法及装置

Country Status (1)

Country Link
CN (1) CN111414262B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112804329A (zh) * 2021-01-13 2021-05-14 广州华多网络科技有限公司 消息中继、交互方法及相应的装置、设备、介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102427451A (zh) * 2011-12-06 2012-04-25 宁波电业局 一种获取服务应用的方法与系统
CN103338267A (zh) * 2013-07-18 2013-10-02 厦门大学 一种SIP和Web服务融合的移动智能社区增值业务平台
WO2014075502A1 (zh) * 2012-11-15 2014-05-22 中兴通讯股份有限公司 一种基于6LoWPAN网络的服务发现方法及装置
CN106060125A (zh) * 2016-05-24 2016-10-26 南京国电南自美卓控制系统有限公司 一种基于数据标签的分布式实时数据传输方法
CN108306917A (zh) * 2017-01-13 2018-07-20 中国移动通信集团江西有限公司 数据处理方法和装置、微服务模块的注册方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102427451A (zh) * 2011-12-06 2012-04-25 宁波电业局 一种获取服务应用的方法与系统
WO2014075502A1 (zh) * 2012-11-15 2014-05-22 中兴通讯股份有限公司 一种基于6LoWPAN网络的服务发现方法及装置
CN103338267A (zh) * 2013-07-18 2013-10-02 厦门大学 一种SIP和Web服务融合的移动智能社区增值业务平台
CN106060125A (zh) * 2016-05-24 2016-10-26 南京国电南自美卓控制系统有限公司 一种基于数据标签的分布式实时数据传输方法
CN108306917A (zh) * 2017-01-13 2018-07-20 中国移动通信集团江西有限公司 数据处理方法和装置、微服务模块的注册方法及装置

Also Published As

Publication number Publication date
CN111414262A (zh) 2020-07-14

Similar Documents

Publication Publication Date Title
US7330470B2 (en) Router and sip server
US7630313B2 (en) Scheduled determination of network resource availability
US7054327B2 (en) Method of providing quality of service (QOS) to voice applications in routed IP networks
CN113810438B (zh) 服务算力资源的调度、请求方法、节点设备及终端
US20040153549A1 (en) Internet communication system
US20030227880A1 (en) Applying session services based on packet flows
US20040243712A1 (en) Internet communication system, internet communication method, session management server, radio communication device, communication relay server, and program
EP2077024B1 (en) Communication system
US8799478B2 (en) Web services and session initiation protocol endpoint for converged communication over internet protocol networks
CN111414262B (zh) 一种服务调用方法及装置
US20130223431A1 (en) Processing Requests
US7181535B1 (en) Addressing method and name and address server in a digital network
KR20050048927A (ko) 디지털 홈서비스 분배 관리 시스템 및 이 시스템의 관리방법
JP4088175B2 (ja) 交換ネットワークシステム及びその電話交換装置
US7215747B2 (en) Method and apparatus for producing information regarding the operation of a networked system
JP4230797B2 (ja) 交換ネットワークシステム及びその電話交換装置
CN117376428A (zh) 一种网元管理方法、装置及设备
CN116915691A (zh) 一种算力路由方法、装置、设备及存储介质
JP2002009940A (ja) インテリジェントネットワークにおける通信制御方法および装置
Colin et al. IST-2001-37385 6HOP D3. 2
JP2006173869A (ja) Ip電話における呼接続方法並びにip電話システム及び端末
KR20040022058A (ko) 인터넷폰에서 시간 정보 설정 방법
JP2002109194A (ja) セールス及びサポート・システム及びセールス及びサポート方法
JP2002064556A (ja) 通信網の品質クラス識別システム
JPH10247947A (ja) 回線制御装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant