CN116962547A - 基于mq的动态数据网关通信方法 - Google Patents

基于mq的动态数据网关通信方法 Download PDF

Info

Publication number
CN116962547A
CN116962547A CN202311095037.2A CN202311095037A CN116962547A CN 116962547 A CN116962547 A CN 116962547A CN 202311095037 A CN202311095037 A CN 202311095037A CN 116962547 A CN116962547 A CN 116962547A
Authority
CN
China
Prior art keywords
request
data
result
service
return
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.)
Pending
Application number
CN202311095037.2A
Other languages
English (en)
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.)
Ningbo Xinyi Information Technology Co ltd
Original Assignee
Ningbo Xinyi Information Technology Co ltd
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 Ningbo Xinyi Information Technology Co ltd filed Critical Ningbo Xinyi Information Technology Co ltd
Priority to CN202311095037.2A priority Critical patent/CN116962547A/zh
Publication of CN116962547A publication Critical patent/CN116962547A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083Network architectures or network communication protocols for network security for authentication of entities using passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种基于MQ的动态数据网关通信方法,涉及计算机数据处理技术领域,共包括10个步骤,与现有技术相比,提供了基于MQ的动态数据网关通信方法,本申请将http协议和MQ协议相结合,在数据库通讯过程中兼具速度和私密性,解决现有技术中http协议和MQ协议混合通信繁琐、复杂的问题,广泛适用于各种公共服务平台对外通讯的接口,本发明可动态管理对外接口,实现接口转发、拦截、负载均衡等功能。

Description

基于MQ的动态数据网关通信方法
技术领域
本发明涉及计算机数据处理技术领域,尤其涉及一种MQ动态网关通信方法。
背景技术
MQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),作为除Modbus外最常用的协议之一,因其基于发布/订阅的模式,具有资源消耗少、效率高的优势,从而受到行业内的广泛使用。MQTT网关是一个可以在两个以上的节点之间通信的新型网关。MQTT网关可以将信号分别与主机与服务器之间的通信分离出来。MQTT网络节点之间通过互连来实现双向通信。在正常情况下,这两个节点的通信是通过一个或者多个互连(即LSI/LRL)的连接进行的,即 HTPC (Hyper-to-PC)交换信息的方式。这两种形式的互连使用一个串行通信协议 RTMQ来实现,这样就可以用RTMQT-based接口与其他网络节点进行通信。因为整个网络并不是并行的(通过 MQTT网关可以实现并行数据交换),因此当需要使用多个节点时就需要通过多个互连网关去完成通信。
网络上对外提供接口多数以http请求为主,因此主要流程为:第三方发起请-网关根据不同的请求地址判断启用的拦截器(可动态配置不同接口启用不同的拦截器)-拦截器执行-MQ通过不同的请求地址转发到不同的路由-后台服务监听对应业务的路由处理业务,返回结果发送至MQ(相同服务监听同一个路由地址可以起到负载均衡的作用)-拦截器执行返回结果相关操作-将结果返回给第三方。但是MQ属于发布订阅模式,MQ监听业务处理的返回结果的线程与第三方发起的http请求的线程不是同一个,属于不同的技术体系,http请求属于同步操作,一个请求需要一个对应的执行结果,而MQ监听返回结果属于被动监听,与http请求分属不同线程,这使得整个通讯流程非常繁琐、复杂,并出现延迟。
发明内容
本发明针对现有技术中的不足,提供了基于MQ的动态数据网关通信方法,本申请将http协议和MQ协议相结合,在数据库通讯过程中兼具速度和私密性,解决现有技术中http协议和MQ协议混合通信繁琐、复杂的问题,广泛适用于各种公共服务平台对外通讯的接口,本发明可动态管理对外接口,实现接口转发、拦截、负载均衡等功能。
为了解决上述技术问题,本发明通过下述技术方案得以解决:基于MQ的动态数据网关通信方法,包括以下几个步骤:步骤1:第三方通过http协议向网关发送调用接口请求,第三方调用接口前需要进行身份验证;步骤2:网关接收到请求后封装请求信息,封装完请求信息后需要执行前置插件,需要执行的插件以平台的对应资源请求的配置为准,执行完前置功能插件以后,将封装的请求信息序列化通过MQ发送给业务端服务;步骤3:MQ发送成功后,判断当前请求为异步请求还是同步请求,如果是异步请求需要返回请求ID作为结果以便第三方通过请求ID查询执行结果,如果是同步请求则需要堵塞当前线程等待MQ返回业务端的执行结果,请求ID作为线程等待的锁对象;步骤4:业务端监听MQ对应的请求信息,业务端收到MQ请求信息后执行对应的业务操作,业务端服务可以同时部署多个监听统一MQ队列实现业务的负责均衡来减轻服务压力提高执行效率,如果同一个业务端服务同时提供多个资源的服务,那么需要实现多个MQ的监听器监听多个不同的队列,不同的队列分别绑定不同的MQ路由;步骤5:业务端执行完结果后封装结果数据,然后通过MQ发送回网关;步骤6:网关监听来自MQ的业务端返回结果,执行对应资源的后置插件,可通过插件对返回结果进行处理;步骤7:执行完后置插件后,将结果信息放入到数据池中;步骤8:返回数据放入数据池后,通过请求ID唤醒对应的http请求线程,请求ID在返回结果中获取;步骤9:http请求线程被唤醒后,通过请求ID获取数据池中的返回结果;步骤10:将获取到的数据返回给第三方。
优选的,上述技术方案中,在步骤1中,第三方需要在平台进行注册获取相应appKey和appSecret,然后通过appKey和appSecret调用token接口获取token,第三方发送调用接口请求时需在请求头中带上token,平台根据token判断第三方是否具有权限调用相关接口。
优选的,上述技术方案中,在步骤2中,封装的字段主要有:请求ID-messageId、请求地址-url、请求方式-method、请求头-headers、请求体-body。
优选的,上述技术方案中,在步骤2中,封装的请求信息序列化通过MQ的topic模式发送,MQ的路由地址为资源编码-resourceCode。
优选的,上述技术方案中,在步骤5中,封装的结果数据主要有:消息ID、返回数据,其中消息ID可以在请求信息中找到。
优选的,上述技术方案中,在步骤6中,插件对返回结果可进行如下处理:数据脱敏、数据加密、数据缓存、日志记录,具体需要执行哪些插件可通过平台针对不同的资源一一配置。
优选的,上述技术方案中,在步骤7中,当前监听MQ返回结果执行线程和http请求线程不是同一个,无法直接将返回数据传给http请求线程,需要公共的数据池暂存返回结果。
优选的,上述技术方案中,在步骤9中,如果等待超时还未被唤醒,那么将无法获取到返回结果,因为数据没有被存入数据池中,获取返回结果后,删除数据池中的返回数据释放存储空间。
HTTP是一种无状态协议,即服务器不保留与客户交易时的任何状态。客户与服务器之间的HTTP连接是一种一次性连接,它限制每次连接只处理一个请求,当服务器返回本次请求的应答后便立即关闭连接,下次请求再重新建立连接。故服务器不会让一个连接处于等待状态,及时地释放连接可以大大提高服务器的执行效率。但HTTP协议是纯文本协议,没有任何加密措施。通过HTTP协议传输的数据都可以在网络上被完全监听。因为在访问部分数据库时需要采用更具私密性的MQ协议,但是MQ协议适用于分布式计算环境或异构系统之中,MQ协议中消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走,通过消息队列,应用程序可独立地执行。但是MQ协议访问数据库时速度慢,因此本申请采用HTTP和MQ结合的方式访问数据库,在整个通讯的过程中既能保证访问的速度,又能保证数据传输的私密。
在本申请中主要通讯结构包括数据开放平台(以下简称平台)和数据网关(以下简称网关)。平台的主要功能是实现对外服务提供对外接口资源(本质是http请求)的管理,例如:教育行业的数据开放平台可以提供学校教师学生等信息查询的接口、医疗行业数据开放平台提供医生医院病患的信息等等。各行各业都可以建设自己的平台,网关作为平台的核心技术实现提供了权限认证、负载均衡、路由、数据脱敏等功能(插件模式,可以通过上传功能包扩展或更新插件)。网关的功能插件部分依赖平台的实现支持,网关提供标准化的接口,不同平台可以有不同的接口实现为网关提供需要的数据,例如:平台实现应用管理功能,网关的权限认证插件通过标准接口判断是否是非法应用是否有权限访问当前资源接口等等。网关接收到第三方请求以后会将请求信息封装(请求地址、请求头、请求体等信息),发送封装好的请求数据到MQ,请求线程开始堵塞等待结果。对应的服务监听到MQ发送的请求后执行对应的业务服务,将返回结果封装后发送给MQ。网关程序监听到返回结果后将结果存放到数据池中(一般使用redis作为数据池来提高性能,请求ID作为key,结果作为值),唤醒之前等待的请求线程。请求线程从数据中获取服务执行结果(请求ID在之前封装请求时已经自动生成,返回结果中包含请求ID),获取到结果后返回给第三方。
本申请可用于平台对外开放接口,动态管理对外接口,实现接口转发、拦截、负载均衡等功能,可通过配置拦截器实现对外接口动态功能,例如:对外接口需要实现加解密或数据脱敏,可以动态配置接口A启用改拦截器,接口B不启用,通过上传软件包的方式可以扩展已有的拦截器。
与现有技术相比,提供了基于MQ的动态数据网关通信方法,本申请将http协议和MQ协议相结合,在数据库通讯过程中兼具速度和私密性,解决现有技术中http协议和MQ协议混合通信繁琐、复杂的问题,广泛适用于各种公共服务平台对外通讯的接口,本发明可动态管理对外接口,实现接口转发、拦截、负载均衡等功能。
具体实施方式
实施例1:一种基于MQ的动态数据网关通信方法,包括以下几个步骤。
步骤1:第三方请求为http协议,调用接口需要先通过oauth2客户端模式进行身份认证。其中OAuth(开放授权)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。
具体为:第三方应用需在平台中注册获取appKey-公匙(相当于账号)和appSecret-私匙(相当于密码),调用获取token的接口获取token-令牌(过期失效),调用接口时需要在请求头中带上token,平台会根据token判断应用是否有权限调用接口(在权限验证拦截器中执行权限验证)。具体步骤如下:1. 向第三方服务器请求授权时,带上AppKey和AppSecret(需存在服务器端);2. 第三方服务器验证AppKey和AppSecret在DB中有无记录;3. 如果有,生成一串唯一的字符串(token令牌),返回给服务器,服务器再返回给客户端;4. 客户端下次请求敏感数据时带上token令牌。
平台有接口资源的管理功能,不同的资源配置有不同的url地址。这里网关需要提供一个通用接口以接收所有对外的资源接口,以上实现可以接收所有/api/open开头的http请求,根据接口资源编码(resourceCode)定位访问的对外接口,例如:/api/open/queryPeople,资源编码为queryPeople查询人员信息。
步骤2:接收到请求以后网关需要封装请求信息以便序列化,序列化是将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间,对象将其当前状态写入到临时或持久性存储区。以后,可以通过从存储区中读取或反序列化对象的状态,重新创建该对象。本申请中通过JSON进行序列化,JSON 是存储和交换文本信息的语法。
JSON序列化后传输,封装的字段主要有:请求ID(messageId,UUID自动生成)、请求地址(url)、请求方式(method)、请求头(headers,Map类型)、请求体(body)。封装完请求信息以后需要执行前置(执行业务操作前)插件,需要执行的插件以平台的对应资源请求的配置为准,例如:权限验证、日志记录、数据加密等等(实现方式类似java的责任链模式)。执行完前置功能插件以后,将封装的请求信息序列化通过MQ发送给业务端服务,这里通过MQ的topic模式发送,MQ的路由地址为资源编码(resourceCode)。Topic模式是MQ中direct模式上的一种叠加,增加了模糊路由RoutingKey的模式,Direct模式,叫直连,也就是完整匹配方式,需要RoutingKey和BindingKey完全一致,相当于点对点的发送。
步骤3:由于MQ发送成功后,判断当前请求为异步请求(数据上报类的请求可以用异步提高性能)还是同步请求(查询类接口需要同步请求),如果是异步请求需要返回请求ID作为结果以便第三方应用通过请求ID查询执行结果,如果是同步类型的请求需要堵塞当前线程等待MQ返回业务端的执行结果,MQ监听结果执行的线程和当前http请求的线程不是同一个,请求ID作为线程等待的锁对象。
其中,异步:两个通信应用之间可以不用同时在线等待,任何一方只需各自处理自己的业务,比如发送方发送消息以后不用登录接收方的响应,可以接着处理其他的任务。也就是说发送方和接收方都是相互独立存在的,发送方只管方,接收方只能接收,无须去等待对方的响应。
其中,同步:两个通信应用服务之间必须要进行同步,两个服务之间必须都是正常运行的。发送程序和接收程序都必须一直处于运行状态,并且随时做好相互通信的准备。发送程序首先向接收程序发起一个请求,称之为发送消息,发送程序紧接着就会堵塞当前自身的进程,不与其他应用进行任何的通信以及交互,等待接收程序的响应,待发送消息得到接收程序的返回消息之后会继续向下运行,进行下一步的业务处理。
步骤4:业务端服务作为业务执行提供的服务,监听MQ对应的请求信息,收到MQ请求信息后执行对应的业务操作。业务端服务可以同时部署多个监听统一MQ队列实现业务的负责均衡来减轻服务压力提高执行效率。如果同一个业务端服务同时提供多个资源的服务,那么需要实现多个MQ的监听器,监听多个不同的队列,不同的队列分别绑定不同的MQ路由(资源编码)。
MQ监听原理:1、消费者和Broker建立TCP连接;2、消费者和Broker建立通道;3、消费者监听指定的Queue(队列);4、当有消息到达Queue时Broker默认将消息推送给消费者5、消费者接收到消息。
步骤5:业务端执行完结果后封装结果数据,包括:消息ID、返回数据,其中消息ID可以在请求信息中找到,将封装后的结果执行序列化(JSON方式),然后通过MQ发送回平台。
步骤6:平台网关监听来自MQ的业务端返回结果,执行对应资源的后置(业务端返回结果后)插件,可通过插件对返回结果进行处理,例如:数据脱敏、数据加密、数据缓存、日志记录等,需要执行哪些插件可通过平台针对不同的资源一一配置。
步骤7:执行完后置插件后,将结果信息放入到数据池中,这里选择redis,效率高,设定过期时间防止数据冗余,请求ID作为key,因为当前监听MQ返回结果执行的线程和之前堵塞的http请求的线程不是同一个,无法直接将返回数据传给http请求线程,所以需要公共的数据池暂存返回结果。
Redis是一个开源的高性能键值对存储数据库,具有快速、可靠的特点。它支持多种数据结构,包括字符串、哈希表、列表、集合和有序集合等,能够满足不同应用场景的需求。在分布式系统中,数据的存储和访问往往是分散在不同的节点之间的,需要一种分布式数据存储方案,Redis提供了一种分布式结构资源池的实现方案,以支持分布式环境下的数据存储和访问。Redis的分布式结构资源池实现的核心是利用主从节点或者集群节点之间的数据同步来实现数据的分布式存储和访问。当客户端向主节点或集群节点发送写入请求时,节点会先将数据写入自己的数据库中,然后再将数据同步到对应的从节点或集群节点中。当客户端向主节点或集群节点发送读取请求时,节点会优先从自己的数据库中读取数据,如果自己没有则从对应的从节点或集群节点中读取数据。这种方式可以保证数据的实时同步和高可用性。
步骤8:返回数据放入数据池后,通过请求ID唤醒对应的http请求线程,请求ID在返回结果中获取。
步骤9:http请求线程被唤醒后,通过请求ID获取数据池中的返回结果,如果等待超时还未被唤醒,那么将无法获取到返回结果,因为数据没有被存入数据池中,获取返回结果后,删除数据池中的返回数据释放存储空间。
步骤10:将获取到的数据返回给第三方应用。

Claims (8)

1.基于MQ的动态数据网关通信方法,其特征在于,包括以下几个步骤:
步骤1:第三方通过http协议向网关发送调用接口请求,第三方调用接口前需要进行身份验证;
步骤2:网关接收到请求后封装请求信息,封装完请求信息后需要执行前置插件,需要执行的插件以平台的对应资源请求的配置为准,执行完前置功能插件以后,将封装的请求信息序列化通过MQ发送给业务端服务;
步骤3:MQ发送成功后,判断当前请求为异步请求还是同步请求,如果是异步请求需要返回请求ID作为结果以便第三方通过请求ID查询执行结果,如果是同步请求则需要堵塞当前线程等待MQ返回业务端的执行结果,请求ID作为线程等待的锁对象;
步骤4:业务端监听MQ对应的请求信息,业务端收到MQ请求信息后执行对应的业务操作,业务端服务可以同时部署多个监听统一MQ队列实现业务的负责均衡来减轻服务压力提高执行效率,如果同一个业务端服务同时提供多个资源的服务,那么需要实现多个MQ的监听器监听多个不同的队列,不同的队列分别绑定不同的MQ路由;
步骤5:业务端执行完结果后封装结果数据,然后通过MQ发送回网关;
步骤6:网关监听来自MQ的业务端返回结果,执行对应资源的后置插件,可通过插件对返回结果进行处理;
步骤7:执行完后置插件后,将结果信息放入到数据池中;
步骤8:返回数据放入数据池后,通过请求ID唤醒对应的http请求线程,请求ID在返回结果中获取;
步骤9:http请求线程被唤醒后,通过请求ID获取数据池中的返回结果;
步骤10:将获取到的数据返回给第三方。
2.根据权利要求1所述的基于MQ的动态数据网关通信方法,其特征在于,在步骤1中,第三方需要在平台进行注册获取相应appKey和appSecret,然后通过appKey和appSecret调用token接口获取token,第三方发送调用接口请求时需在请求头中带上token,平台根据token判断第三方是否具有权限调用相关接口。
3.根据权利要求1所述的基于MQ的动态数据网关通信方法,其特征在于,在步骤2中,封装的字段主要有:请求ID-messageId、请求地址-url、请求方式-method、请求头-headers、请求体-body。
4.根据权利要求1所述的基于MQ的动态数据网关通信方法,其特征在于,在步骤2中,封装的请求信息序列化通过MQ的topic模式发送,MQ的路由地址为资源编码-resourceCode。
5.根据权利要求1所述的基于MQ的动态数据网关通信方法,其特征在于,在步骤5中,封装的结果数据主要有:消息ID、返回数据,其中消息ID可以在请求信息中找到。
6.根据权利要求1所述的基于MQ的动态数据网关通信方法,其特征在于,在步骤6中,插件对返回结果可进行如下处理:数据脱敏、数据加密、数据缓存、日志记录,具体需要执行哪些插件可通过平台针对不同的资源一一配置。
7.根据权利要求1所述的基于MQ的动态数据网关通信方法,其特征在于,在步骤7中,当前监听MQ返回结果执行线程和http请求线程不是同一个,无法直接将返回数据传给http请求线程,需要公共的数据池暂存返回结果。
8.根据权利要求1所述的基于MQ的动态数据网关通信方法,其特征在于,在步骤9中,如果等待超时还未被唤醒,那么将无法获取到返回结果,因为数据没有被存入数据池中,获取返回结果后,删除数据池中的返回数据释放存储空间。
CN202311095037.2A 2023-08-29 2023-08-29 基于mq的动态数据网关通信方法 Pending CN116962547A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311095037.2A CN116962547A (zh) 2023-08-29 2023-08-29 基于mq的动态数据网关通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311095037.2A CN116962547A (zh) 2023-08-29 2023-08-29 基于mq的动态数据网关通信方法

Publications (1)

Publication Number Publication Date
CN116962547A true CN116962547A (zh) 2023-10-27

Family

ID=88451422

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311095037.2A Pending CN116962547A (zh) 2023-08-29 2023-08-29 基于mq的动态数据网关通信方法

Country Status (1)

Country Link
CN (1) CN116962547A (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005032155A2 (en) * 2003-08-28 2005-04-07 Tekelec Methods and systems for providing wireless local area network-base transceiver station (wlan-bts) gateway
CN109271259A (zh) * 2018-08-15 2019-01-25 深圳壹账通智能科技有限公司 企业服务总线系统、数据处理方法、终端及存储介质
CN109298950A (zh) * 2018-08-15 2019-02-01 深圳壹账通智能科技有限公司 企业服务总线系统、数据处理方法、终端及存储介质
CN111580995A (zh) * 2020-05-12 2020-08-25 南京甄视智能科技有限公司 基于mqtt异步通信场景下的分布式云平台与物联网智能终端的同步通信方法与系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005032155A2 (en) * 2003-08-28 2005-04-07 Tekelec Methods and systems for providing wireless local area network-base transceiver station (wlan-bts) gateway
CN109271259A (zh) * 2018-08-15 2019-01-25 深圳壹账通智能科技有限公司 企业服务总线系统、数据处理方法、终端及存储介质
CN109298950A (zh) * 2018-08-15 2019-02-01 深圳壹账通智能科技有限公司 企业服务总线系统、数据处理方法、终端及存储介质
CN111580995A (zh) * 2020-05-12 2020-08-25 南京甄视智能科技有限公司 基于mqtt异步通信场景下的分布式云平台与物联网智能终端的同步通信方法与系统

Similar Documents

Publication Publication Date Title
US8176189B2 (en) Peer-to-peer network computing platform
US20180167476A1 (en) Meta broker for publish-subscribe-based messaging
US9749445B2 (en) System and method for updating service information for across-domain messaging in a transactional middleware machine environment
US20070192326A1 (en) Distributed session failover
EP1987657B1 (en) Scalable wireless messaging system
JP4575980B2 (ja) コンピュータシステムにおける通信のための方法、システム、及びコンピュータプログラム
US20030126196A1 (en) System for optimizing the invocation of computer-based services deployed in a distributed computing environment
US7716290B2 (en) Send by reference in a customizable, tag-based protocol
US8352619B2 (en) Method and system for data processing
US20110035413A1 (en) Diameter bus communications between processing nodes of a network element
US10536560B2 (en) System and method for implementing augmented object members for remote procedure call
US20080208959A1 (en) Hanging request system and method for client/server communication
CN114448686B (zh) 一种基于微服务的跨网络通信装置与方法
CN103827830A (zh) 用于在事务性中间件机器环境中防止单点瓶颈的系统和方法
CN112181681A (zh) 一种远程调用方法、装置、计算机设备及存储介质
CN113630366A (zh) 一种物联网设备接入方法及系统
CN116962547A (zh) 基于mq的动态数据网关通信方法
CN111490997A (zh) 任务处理方法、代理系统、服务系统和电子设备
CN115516842A (zh) 编排代理服务
US20090300212A1 (en) Heuristics processing
CN114338692B (zh) 一种基于分片集群扩容的数据平衡方法与设备
CN115208739B (zh) 跨多网络区对接方法及安全运维区对接单向网络区的方法
CN117155904A (zh) 一种服务注册方法
JP2007334724A (ja) メッセージバスを有するプロセスおよび制御システム
KR20220063503A (ko) 메시지 교환 방식을 이용한 계층화된 IoT 서비스 시스템

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