WO2021008567A1 - 基于全双工通信协议的请求传输方法及装置 - Google Patents

基于全双工通信协议的请求传输方法及装置 Download PDF

Info

Publication number
WO2021008567A1
WO2021008567A1 PCT/CN2020/102220 CN2020102220W WO2021008567A1 WO 2021008567 A1 WO2021008567 A1 WO 2021008567A1 CN 2020102220 W CN2020102220 W CN 2020102220W WO 2021008567 A1 WO2021008567 A1 WO 2021008567A1
Authority
WO
WIPO (PCT)
Prior art keywords
websocket
target
channel
request
microservice
Prior art date
Application number
PCT/CN2020/102220
Other languages
English (en)
French (fr)
Inventor
尹强
刘有
王和平
黄山
杨峙岳
邸帅
卢道和
Original Assignee
深圳前海微众银行股份有限公司
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 深圳前海微众银行股份有限公司 filed Critical 深圳前海微众银行股份有限公司
Publication of WO2021008567A1 publication Critical patent/WO2021008567A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms

Definitions

  • the invention relates to the field of WebSocket request transmission in the field of financial technology (Fintech), in particular to a request transmission method and device based on a full-duplex communication protocol.
  • Microservices include multiple microservice instances, and the processing of WebSocket requests is completed by a certain microservice instance.
  • the combination of microservices that divide the application by function, as a whole microservice the WebSocket client transmits the WebSocket request to the whole microservice, and then the whole microservice realizes the processing of the WebSocket request.
  • this "one-to-one" WebSocket request transmission method violates the concept of mutual independence, coordination, and cooperation between microservices, and cannot establish correspondence with multiple microservices, resulting in low flexibility in WebSocket request transmission. .
  • the embodiments of the present application provide a request transmission method and device based on a full-duplex communication protocol, which solves the problem of low flexibility of WebSocket request transmission in the prior art.
  • an embodiment of the present application provides a request transmission method based on a full-duplex communication protocol: the target repeater determines at least one target microservice instance corresponding to the first WebSocket request; the at least one target microservice instance is used for processing The WebSocket request; for each target microservice instance in the at least one target microservice instance, the target forwarder sends the first WebSocket request to the first WebSocket channel corresponding to the target microservice instance The target microservice instance; the first WebSocket channel is a transmission channel between the target repeater and the target microservice instance.
  • the target forwarder determines at least one target microservice instance corresponding to the first WebSocket request; the at least one target microservice instance is used to process the WebSocket request, and determines at least one target microservice instance corresponding to the WebSocket request, namely To which target microservice instances the WebSocket request will be sent before forwarding?
  • the target forwarder For each target microservice instance, the target forwarder sends the first WebSocket request to the target microservice instance through the first WebSocket channel corresponding to the target microservice instance
  • the first WebSocket channel is the transmission channel between the target repeater and the microservice corresponding to the target microservice instance, so that the target repeater can request the WebSocket through the first WebSocket channel of each target microservice instance Send to the specified target microservice instance, so that it can communicate and transmit with multiple microservice microservice instances at the same time, which improves the flexibility of WebSocket request transmission.
  • the target repeater before the target repeater sends the first WebSocket request to the target microservice instance through the first WebSocket channel corresponding to the target microservice instance, it further includes: the target repeater It is determined whether the first WebSocket channel corresponding to the target microservice instance has been established; if not, the first WebSocket channel is established between the microservices corresponding to the target microservice instance.
  • the target forwarder determines whether the first WebSocket channel corresponding to the target microservice instance has been established; if not, the first WebSocket channel is established between the microservices corresponding to the target microservice instance Therefore, it can ensure that the target repeater and the target microservice instance can realize the first WebSocket channel in real time, thereby ensuring the reliability of WebSocket request transmission.
  • the method further includes: the target forwarder obtains the first WebSocket request through a second WebSocket channel;
  • the second WebSocket channel is a transmission channel between the client and the target repeater.
  • the target forwarder obtains the first WebSocket request from the client through the second WebSocket channel, thereby providing a method for obtaining the WebSocket request from the client.
  • the method further includes: the target forwarder connects the first WebSocket channel to the The second WebSocket channel binding.
  • the target repeater determines that the second WebSocket channel is disconnected, it disconnects one or more first WebSocket channels bound to the second WebSocket channel.
  • the target forwarder determining at least one target microservice instance corresponding to the first WebSocket request includes: the target forwarder determining at least one target microservice corresponding to the first WebSocket request according to a preset rule; For each target microservice in a target microservice, the target forwarder uses the microservice instance with the smallest load rate among at least one microservice instance of the target microservice as the target microservice instance of the target microservice.
  • the present application provides a WebSocket-based request transmission device, including: a determining module, configured to determine at least one target microservice instance corresponding to a first WebSocket request; and the at least one target microservice instance is configured to process the WebSocket request; processing module for sending the first WebSocket request to the target through the first WebSocket channel corresponding to the target microservice instance for each target microservice instance in the at least one target microservice instance Microservice instance; the first WebSocket channel is a transmission channel with the target microservice instance.
  • the processing module is further configured to: obtain the first WebSocket request through a second WebSocket channel; the second WebSocket channel is a transmission channel between the client and the client.
  • the processing module is further configured to: bind the first WebSocket channel with the second WebSocket channel.
  • the determining module is further configured to: when it is determined that the second WebSocket channel is disconnected, disconnect one or more first WebSocket channels bound to the second WebSocket channel.
  • the processing module is further configured to: after determining that the second WebSocket channel is disconnected, pass one or more first WebSockets bound to the second WebSocket channel according to a preset cycle The channel sends a heartbeat request packet.
  • an embodiment of the present application provides a computer device including a program or instruction, and when the program or instruction is executed, it is used to execute the methods of the first aspect and the embodiments of the first aspect.
  • an embodiment of the present application provides a storage medium including a program or instruction, and when the program or instruction is executed, it is used to execute the method of the foregoing first aspect and each embodiment of the first aspect.
  • FIG. 1 is a schematic diagram of an applicable architecture of a transmission method based on WebSocket requests provided by an embodiment of the application;
  • FIG. 2 is a schematic structural diagram of a target repeater applicable to a transmission method based on WebSocket requests provided by an embodiment of the application;
  • FIG. 3 is a schematic flow diagram of the steps of a transmission method based on WebSocket requests provided by an embodiment of the application;
  • Figure 4 is a schematic structural diagram of a transmission device based on a WebSocket request provided by an embodiment of the application.
  • Microservices advocate dividing a single application into a set of small services, and the services coordinate and cooperate with each other to provide users with ultimate value. Each service runs in its own process, and a lightweight communication mechanism is used between services to communicate with each other.
  • the API Gateway is a server and the only entrance to the system. From the perspective of object-oriented design, it is similar to the appearance model.
  • the API gateway encapsulates the internal architecture of the system and provides a customized API for each client. It may also have other responsibilities, such as authentication, monitoring, load balancing, caching, request fragmentation and management, and static response processing.
  • WebSocket HyperText Markup Language (HTML), in version HTML5, began to provide a full-duplex communication network technology between browser and server, which is an application layer protocol. It is based on Transmission Control Protocol (TCP) and reuses the HTTP handshake channel.
  • HTTP Transmission Control Protocol
  • the gateway API As the only entry point for all microservices, provides unified identity verification, request forwarding, monitoring, and load balancing functions. It is a basic service that all microservice systems must support.
  • the existing gateway APIs on the market cannot fulfill the requirement of a WebSocket client to connect to multiple WebSocket servers in the background through the gateway API. Therefore, multiple independent WebSocket services can only be combined into one service to provide services to the outside world, which violates the promotion of microservices.
  • FIG. 1 it is a schematic diagram of an applicable architecture of a request transmission method based on WebSocket provided by an embodiment of this application.
  • the architecture is based on the runtime library to implement the target transponder.
  • the runtime library can be Spring Cloud Gateway, and the target forwarder is used to establish a WebSocket connection with the client. After the connection is established, it will automatically analyze the client’s WebSocket request and determine which back-end microservice the request should be forwarded to through the rules. The WebSocket request is forwarded to the corresponding back-end microservice instance.
  • a browser and a WebSocket-based WebSocket client are running in the client.
  • the user can click a button in the browser to generate a WebSocket request, and forward the WebSocket request to the target forwarder through the WebSocket client in the client.
  • the target forwarder connects the WebSocket request of the client upwards, and connects the multiple WebSocket microservice instances of the back-end microservice downwards, and can directly send the WebSocket request received from the client to the instance in the WebSocket microservice.
  • the target repeater may also be referred to as a WebSocket routing repeater, a WebSocket request repeater, and so on.
  • each WebSocket microservice has one or more instances.
  • the number of instances in WebSocket microservices and WebSocket microservices is not limited. Only the WebSocket microservices shown in Figure 1 Take services 1 to 3 as an example to illustrate the process.
  • FIG. 2 a schematic structural diagram of a target repeater applicable to a transmission method based on a WebSocket request provided by an embodiment of this application.
  • the ruler includes service discovery and ruler.
  • Service discovery can obtain the list of microservices and microservice instances in the back-end microservices.
  • Service discovery can be implemented through Eureka.
  • Eureka is a service discovery framework and itself is a REST-based service.
  • the ruler can forward the WebSocket request to the back-end microservice instance selected for the client's WebSocket request by using various rules, and then pass it to the target forwarder.
  • FIG. 3 it is a schematic diagram of the process flow of a request transmission method based on WebSocket provided by an embodiment of this application.
  • Step 301 The target forwarder determines at least one target microservice instance corresponding to the first WebSocket request.
  • URL ruler which converts the format of the text frame (TextWebSocketFrame) requested by the client into a JSON format string, for example: " ⁇ 'method':'/api/v1/$ ⁇ service ⁇ /$ ⁇ uriPath ⁇ ', 'data': " ⁇ ”, where method is the actual request uniform resource identifier (URI), the front /api is fixed as an application program interface (API) request, v1 refers to the version of the API, service is the requested service name, and uriPath is The actual request URI of the service, data is the actual request data, and the microservice information can be obtained by parsing the method.
  • URI uniform resource identifier
  • API application program interface
  • the ruler will obtain a list of microservices whose health status is normal from service discovery (such as Eureka), find all microservice instances of the microservice, and then select the corresponding microservice instance. For example, by means of load balancing, one of the instances with the smallest load is selected, and the microservice instance is delivered to the target forwarder.
  • service discovery such as Eureka
  • the target forwarder determines whether the first WebSocket channel corresponding to the target microservice instance has been established; if not, the first WebSocket channel is established between the microservices corresponding to the target microservice instance.
  • the target forwarder determines whether the first WebSocket channel corresponding to the target microservice instance has been established; if not, the first WebSocket channel is established between the microservices corresponding to the target microservice instance Therefore, it can ensure that the target repeater and the target microservice instance can realize the first WebSocket channel in real time, thereby ensuring the reliability of WebSocket request transmission.
  • the target microservice instance; the first WebSocket channel is the transmission channel between the target repeater and the microservice corresponding to the target microservice instance, so that the target repeater can pass through each target microservice instance first WebSocket Channel, send WebSocket requests to the specified target microservice instance, so that it can communicate and transmit with multiple microservice microservice instances at the same time, which improves the flexibility of WebSocket request transmission.
  • the processing module 402 is further configured to: obtain the first WebSocket request through a second WebSocket channel; the second WebSocket channel is a transmission channel between the client and the client.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了基于全双工通信协议的请求传输方法及装置，其中方法为：目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例；针对所述至少一个目标微服务实例中的每个目标微服务实例，所述目标转发器通过所述目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例。上述方法应用于金融科技（Fintech）领域时，目标转发器可以同时与多个微服务的微服务实例进行通信传输，提升了WebSocket请求传输的灵活性。

Description

基于全双工通信协议的请求传输方法及装置
相关申请的交叉引用
本申请要求在2019年07月18日提交中国专利局、申请号为201910652159.4、申请名称为“基于全双工通信协议的请求传输方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及金融科技(Fintech)领域中的WebSocket请求传输领域，尤其涉及基于全双工通信协议的请求传输方法及装置。
背景技术
随着计算机技术的发展，越来越多的技术(大数据、分布式、区块链(Blockchain)、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变。目前，金融科技领域中，随着微服务的兴起，为实现金融信息的交互，金融业务的使用方一般通过全双工通信协议(WebSocket)客户端发送WebSocket请求，再经由中间件转发WebSocket请求至相应微服务，再通过相应微服务获取服务。
微服务包括多个微服务实例，WebSocket请求的处理由某个微服务实例来完成。然而，目前方法中，把应用程序按功能划分的微服务的组合，作为一个整体的微服务，WebSocket客户端将WebSocket请求传输给这个整体微服务，再由这个整体微服务实现WebSocket请求的处理。显然，这种“一对一”WebSocket请求的传输方式违背了微服务之间彼此独立、相互协调、互相配合的理念，不能与多个微服务建立对应关系，导致WebSocket请求传输的灵活性较低。
发明内容
本申请实施例提供了基于全双工通信协议的请求传输方法及装置，解决了现有技术中WebSocket请求传输的灵活性较低的问题。
第一方面，本申请实施例提供一种基于全双工通信协议的请求传输方法：目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例；所述至少一个目标微服务实例用于处理所述WebSocket请求；针对所述至少一个目标微服务实例中的每个目标微服务实例，所述目标转发器通过所述目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例；所述第一WebSocket通道是所述目标转发器与所述目标微服务实例之间的传输通道。
上述方法下，目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例；所述至少一个目标微服务实例用于处理所述WebSocket请求，确定WebSocket请求对应的至少一个目标微服务实例，即在转发之前WebSocket请求将要发送给哪些目标微服务实例，对于每个目标微服务实例，目标转发器通过目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例；所述第一WebSocket通道是所述目标转发器与所述目标微服务实例对应的微服务之间的传输通道，从而目标转发器可以通过每个目标微服务实例第一WebSocket通道，将WebSocket请求发送至指定的目标微服务实例，从而可以同时与多个微服务的微服务实例进行通信传输，提升了WebSocket请求传输的灵活性。
一种可选实施方式中，所述目标转发器通过所述目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例之前，还包括：所述目标转发器确定是否已建立所述目标微服务实例对应的第一WebSocket通道；若未建立，则与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道。
上述方法中，所述目标转发器确定是否已建立所述目标微服务实例对应的第一WebSocket通道；若未建立，则与所述目标微服务实例对应的微服务 之间建立所述第一WebSocket通道，因此可以保证目标转发器与目标微服务实例能够实时第一WebSocket通道，从而保证了WebSocket请求传输的可靠性。
一种可选实施方式中，所述目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例之前，还包括：所述目标转发器通过第二WebSocket通道获取所述第一WebSocket请求；所述第二WebSocket通道是所述客户端与所述目标转发器之间的传输通道。
上述方法中，所述目标转发器通过第二WebSocket通道从客户端获取所述第一WebSocket请求，从而提供了一种从客户端获取WebSocket请求的方法。
一种可选实施方式中，所述与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道之后，还包括：所述目标转发器将所述第一WebSocket通道与所述第二WebSocket通道绑定。
上述方式下，第一WebSocket通道与第二WebSocket通道绑定，从而二者建立了关联关系，方便后续来自第二WebSocket通道的信息转发通过第一WebSocket通道转发至客户端。
一种可选实施方式中，所述目标转发器确定所述第二WebSocket通道断开时，断开与该第二WebSocket通道绑定的一个或多个第一WebSocket通道。
上述方式下，由于当第二WebSocket通道断开时，目标转发器就不会通过第二WebSocket通道接收WebSocket请求，即便与该第二WebSocket通道绑定的一个或多个第一WebSocket通道存在，也不会有转发WebSocket请求需求，从而及时释放与该第二WebSocket通道绑定的一个或多个第一WebSocket通道，节约资源。
一种可选实施方式中，在所述目标转发器确定所述第二WebSocket通道断开后，所述目标转发器按照预设周期，通过与该第二WebSocket通道绑定的一个或多个第一WebSocket通道发送心跳请求包。
目标转发器按照预设周期，通过与该第二WebSocket通道绑定的一个或 多个第一WebSocket通道发送心跳请求包，从而可长期维护一个或多个第一WebSocket通道不因为空闲被释放，也可以及时知悉一个或多个第一WebSocket通道的状态。
所述目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例，包括：所述目标转发器根据预设规则，确定所述第一WebSocket请求对应的至少一个目标微服务；针对所述至少一个目标微服务中每个目标微服务，所述目标转发器将该目标微服务的至少一个微服务实例中负载率最小的微服务实例，作为该目标微服务的目标微服务实例。
上述方法中，确定所述第一WebSocket请求对应的至少一个目标微服务后，将该目标微服务的至少一个微服务实例中负载率最小的微服务实例，作为该目标微服务的目标微服务实例，从而保证负载最小的微服务实例优先处理第一WebSocket请求，促进了微服务中各微服务实例的负载均衡。
第二方面，本申请提供一种基于WebSocket的请求传输装置，包括：确定模块，用于确定第一WebSocket请求对应的至少一个目标微服务实例；所述至少一个目标微服务实例用于处理所述WebSocket请求；处理模块，用于针对所述至少一个目标微服务实例中的每个目标微服务实例，通过所述目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例；所述第一WebSocket通道是与所述目标微服务实例之间的传输通道。
一种可选实施方式中，所述确定模块还用于：确定是否已建立所述目标微服务实例对应的第一WebSocket通道；若未建立，则与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道。
一种可选实施方式中，所述处理模块还用于：通过第二WebSocket通道获取所述第一WebSocket请求；所述第二WebSocket通道是所述客户端与之间的传输通道。
一种可选实施方式中，所述处理模块还用于：将所述第一WebSocket通道与所述第二WebSocket通道绑定。
一种可选实施方式中，所述确定模块还用于：确定所述第二WebSocket通道断开时，断开与该第二WebSocket通道绑定的一个或多个第一WebSocket通道。
一种可选实施方式中，所述处理模块还用于：在确定所述第二WebSocket通道断开后，按照预设周期，通过与该第二WebSocket通道绑定的一个或多个第一WebSocket通道发送心跳请求包。
一种可选实施方式中，所述确定模块具体用于：所述确定模块具体用于：根据预设规则，确定所述第一WebSocket请求对应的至少一个目标微服务；针对所述至少一个目标微服务中每个目标微服务，将该目标微服务的至少一个微服务实例中负载率最小的微服务实例，作为该目标微服务的目标微服务实例。
上述第二方面及第二方面各个实施例的有益效果，可以参考上述第一方面及第一方面各个实施例的有益效果，这里不再赘述。
第三方面，本申请实施例提供一种计算机设备，包括程序或指令，当所述程序或指令被执行时，用以执行上述第一方面及第一方面各个实施例的方法。
第四方面，本申请实施例提供一种存储介质，包括程序或指令，当所述程序或指令被执行时，用以执行上述第一方面及第一方面各个实施例的方法。
附图说明
图1为本申请实施例提供的一种基于WebSocket请求的传输方法可应用的架构示意图；
图2为本申请实施例提供的一种基于WebSocket请求的传输方法可应用的目标转发器的结构示意图；
图3为本申请实施例提供的一种基于WebSocket请求的传输方法的步骤流程示意图；
图4为本申请实施例提供的一种基于WebSocket请求的传输装置的结构 示意图。
具体实施方式
为了更好的理解上述技术方案，下面将结合说明书附图及具体的实施方式对上述技术方案进行详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互结合。
为方便叙述，首先列出本申请出现的缩略语和名词。
微服务:微服务提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通。
微服务应用程序接口(API)网关:API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
WebSocket：超文本标记语言(Hyper Text Markup Language，HTML)在版本HTML5中，开始提供了一种浏览器与服务器进行全双工通讯网络技术，属于应用层协议。它基于传输控制协议(Transmission Control Protocol，TCP)，并复用HTTP的握手通道。
Spring Cloud Gateway:该项目提供了一个用于在Spring MVC之上构建API网关的库。Spring Cloud Gateway旨在提供一种简单而有效的方式来路由到API，并为他们提供横切关注点。Spring Cloud Gateway具有以下功能：(1)基于Spring Framework 5，Project Reactor和Spring Boot 2.0构建；(2)能够匹配任何请求属性上的路由；(3)Hystrix熔断器集成；(4)Spring Cloud DiscoveryClient集成；(5)请求率限制；(6)路径重写。
随着微服务的兴起，网关API作为所有微服务的唯一入口，提供统一的 身份验证、请求转发、监控、负载均衡功能，是所有微服务体系都必须支持的基础服务。然而市面上已有的网关API，无法完成一个WebSocket客户端通过网关API对接后台多个WebSocket服务器的需求，因此只能将多个彼此独立的WebSocket服务合成一个服务对外提供服务，违背了微服务提倡的将单一应用程序划分成一组小的服务，服务之间彼此独立、相互协调、互相配合的理念。
如图1所示，为本申请实施例提供的一种基于WebSocket的请求传输方法可应用的架构示意图。
该架构基于运行库实现目标转发器。其中，运行库可以为Spring Cloud Gateway，目标转发器用于与客户端建立WebSocket连接，建立连接成功后，会自动分析客户端的WebSocket请求，通过规则判断出请求该转发给哪个后端微服务，从而将WebSocket请求转发给对应的后端微服务实例。
具体地，客户端中运行着浏览器以及基于WebSocket的WebSocket客户端，用户可以在浏览器点击按钮等方式，生成WebSocket请求，并通过客户端中的WebSocket客户端将WebSocket请求转发给目标转发器。
目标转发器，向上对接客户端的WebSocket请求，向下对接后端微服务的多个WebSocket微服务实例，可以直接将从客户端接收到的WebSocket请求发送给WebSocket微服务中的实例。需要说明的是，本申请实施例中，目标转发器还可以称为WebSocket路由转发器、WebSocket请求转发器等。
后端微服务中运行着多个WebSocket微服务，每个WebSocket微服务又有一个或多个实例，WebSocket微服务和WebSocket微服务中的实例个数不限定，仅以图1示出的WebSocket微服务1～3为例说明该过程。
下面基于图1，详细介绍目标转发器，如图2所示，为本申请实施例提供的一种基于WebSocket请求的传输方法可应用的目标转发器的结构示意图。
该架构的整体结构如下：
WebSocket接收器包括WebSocket连接创建器和WebSocket请求处理器。其中，WebSocket连接创建器负责接收客户端的WebSocket创建连接请求，连 接建立后，同时接收WebSocket请求。WebSocket请求处理器接收到的请求处理后，传递给规则器。
规则器包括服务发现和规则器。服务发现可以获取后端微服务中微服务及微服务实例的列表，服务发现具体可以通过Eureka来实现，Eureka是一个服务发现框架，本身是一个基于REST的服务。规则器可以通过使用各种规则，为客户端的WebSocket请求选择的后端微服务实例进行WebSocket请求转发，再传递给目标转发器。
WebSocket传输中心负责建立与后端微服务实例的WebSocket通道，将客户端的请求通过新的WebSocket通道，转发给对应后端微服务实例，同时负责将后端微服务实例实时推送的信息，通过与客户端建立的WebSocket通道，推送给客户端。需要说明的是，本申请实施例中，WebSocket通道与WebSocket连接含义相同。
下面结合本申请实施例提供的基于WebSocket的请求传输方法，详细说明图2示出架构的各个部分。如图3所示，为本申请实施例提供的一种基于WebSocket的请求传输方法的步骤流程示意图。
步骤301：目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例。
至少一个目标微服务实例用于处理WebSocket请求。
步骤302：针对至少一个目标微服务实例中的每个目标微服务实例，目标转发器通过目标微服务实例对应的第一WebSocket通道发送第一WebSocket请求至目标微服务实例。
第一WebSocket通道是目标转发器与目标微服务实例之间的传输通道。
步骤301之前，一种可选实施方式为：
所述目标转发器通过第二WebSocket通道获取所述第一WebSocket请求；所述第二WebSocket通道是所述客户端与所述目标转发器之间的传输通道。
上述方法中，所述目标转发器通过第二WebSocket通道从客户端获取所述第一WebSocket请求，从而提供了一种从客户端获取WebSocket请求的方 法。
在此基础上，目标转发器还可以将所述第一WebSocket通道与所述第二WebSocket通道绑定。上述方式下，第一WebSocket通道与第二WebSocket通道绑定，从而二者建立了关联关系，方便后续来自第二WebSocket通道的信息转发通过第一WebSocket通道转发至客户端。
举例来说，采用图2示出的WebSocket接收器来执行上述可选实施方式，WebSocket接收器可以是Spring Cloud Gateway的一个全局过滤器，用于接收客户端的WebSocket连接请求，创建客户端与Spring Cloud Gateway的WebSocket通信通道。同时，WebSocket接收器会监听该WebSocket通道，将客户端发送过来的请求，获取必要的基本信息(如请求地址、统一资源定位符(URL)和用户名等)，进行简单的封装，传递给规则器进行处理。
步骤301中，可通过图2示出的规则器来选择微服务实例。规则器接收到WebSocket接收器的通知，开始使用规则进行处理。其中，规则器包括URL规则器和自定义规则器。目标转发器可按照以下方式，根据预设规则，确定第一WebSocket请求对应的至少一个目标微服务：
目标转发器提取第一WebSocket请求的至少一个关键字段，并根据预设规则对至少一个关键字段进行解析，获取满足预设规则格式的所述至少一个目标微服务。
具体地，规则器中的URL规则器可以通过一个或多个具体规则确定出需要将WebSocket请求发送给哪些微服务，再在每个微服务中确定具体的目标微服务实例。具体地，可通过将WebSocket请求解析后的结果与正则表达式匹配，来确定至少一个目标微服务实例。
URL规则器，将客户端请求的文本帧(TextWebSocket Frame)的格式转化为JSON格式的字符串，例如：“{‘method’:’/api/v1/${service}/${uriPath}’,’data’:”}”，其中method为实际的请求统一资源标识符(URI)，前面/api固定为应用程序接口(API)请求，v1指API的版本，service为请求的服务名称，uriPath为服务的实际请求URI， data为实际的请求数据，可通过解析method，得到微服务信息。
举例来说，具体过程为：(1)如果客户端请求的文本帧(TextWeb SocketFrame)不符合URL规则器的标准格式，或URL规则器不能解析出微服务信息，这时会加载用户自定义规则器进行解析service，如果所有的自定义规则器都不能解析出service信息，则直接抛出一个解析错误给到客户端；否则直接根据微服务信息进行步骤(2)。
(2)规则器会从服务发现(如Eureka)中，获取健康状态为正常的微服务列表，找到该微服务所有的微服务实例，再选择相应的微服务实例。举例来说，通过负载均衡的方式，选择其中一个负载最小的实例，将该微服务service实例传递给目标转发器。
步骤301一种具体的可选实施方式中，所述目标转发器根据预设规则，确定所述第一WebSocket请求对应的至少一个目标微服务；针对所述至少一个目标微服务中每个目标微服务，所述目标转发器将该目标微服务的至少一个微服务实例中负载率最小的微服务实例，作为该目标微服务的目标微服务实例。
上述方法中，确定所述第一WebSocket请求对应的至少一个目标微服务后，将该目标微服务的至少一个微服务实例中负载率最小的微服务实例，作为该目标微服务的目标微服务实例，从而保证负载最小的微服务实例优先处理第一WebSocket请求，促进了微服务中各微服务实例的负载均衡。
需要说明的是，此处仅以微服务实例的负载率为例说明规则器中的规则，事实上，可以将多方面考虑到规则中，如微服务实例的流量限制等，可通过图2示出的自定义规则器实现。
步骤302之前，一种可选实施方式为：
所述目标转发器确定是否已建立所述目标微服务实例对应的第一WebSocket通道；若未建立，则与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道。
上述方法中，所述目标转发器确定是否已建立所述目标微服务实例对应 的第一WebSocket通道；若未建立，则与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道，因此可以保证目标转发器与目标微服务实例能够实时第一WebSocket通道，从而保证了WebSocket请求传输的可靠性。
图2示出的WebSocket传输中心分为WebSocket管理模块和WebSocket请求转发模块。
上述可选实施方式具体可由WebSocket请求转发模块执行，WebSocket请求转发模块从规则器获取微服务实例信息(一个微服务会有多个实例，每个实例的功能完全相同，一个微服务之所以需要多个实例，是为了保证微服务的高可用和高可靠)，先从WebSocket管理模块中为该客户端和该微服务寻找是否已经存在目标转发器到该微服务的WebSocket通道，如果存在，则直接使用该webSocket连接通道转发客户端请求的文本帧(TextWebSocketFrame)；否则为该客户端和该微服务实例创建一个全新的webSocket通道，并将该新的WebSocket连接和客户端与WebSocket接收器的1对1的WebSocket连接通道进行绑定，保证后端微服务一旦通过该新的WebSocket连接实时推送信息，可以将该信息通过客户端与WebSocket接收器建立的连接通道，回推给客户端。
一种可选实施方式中，所述目标转发器确定所述第二WebSocket通道断开时，断开与该第二WebSocket通道绑定的一个或多个第一WebSocket通道。该可选实施方式可通过WebSocket管理模块执行。
上述方式下，由于当第二WebSocket通道断开时，目标转发器就不会通过第二WebSocket通道接收WebSocket请求，即便与该第二WebSocket通道绑定的一个或多个第一WebSocket通道存在，也不会有转发WebSocket请求需求，从而及时释放与该第二WebSocket通道绑定的一个或多个第一WebSocket通道，节约资源。
一种可选实施方式中，在所述目标转发器确定所述第二WebSocket通道断开后，所述目标转发器按照预设周期，通过与该第二WebSocket通道绑定 的一个或多个第一WebSocket通道发送心跳请求包。该可选实施方式可通过WebSocket管理模块执行。
目标转发器按照预设周期，通过与该第二WebSocket通道绑定的一个或多个第一WebSocket通道发送心跳请求包，从而可长期维护一个或多个第一WebSocket通道不因为空闲被释放，也可以及时知悉一个或多个第一WebSocket通道的状态。
对于上述两种实施方式，具体来说：WebSocket管理模块负责管理客户端与WebSocket接收器的1对1的WebSocket连接通道，和目标转发器与后端微服务实例的1对多WebSocket连接通道。如果客户端与WebSocket接收器的WebSocket连接断开，则WebSocket管理模块会断开所有相关的目标转发器与后端微服务实例的1对多WebSocket连接通道；同时，为了保持所有目标转发器与后端微服务实例的1对多WebSocket连接通道不会因为空闲而被释放，WebSocket管理模块会定时发送心跳请求(PingWebSocketFrame)给对应的后端微服务实例。
步骤301～步骤302方法可支持以下三种方式：1、支持Spring Cloud Gateway一对多路由转发WebSocket请求。2、支持WebSocket请求的负载均衡。3、支持通过规则，自动为WebSocket请求转发给合适的后端服务。
在步骤301～步骤302方法下，目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例；所述至少一个目标微服务实例用于处理所述WebSocket请求，确定WebSocket请求对应的至少一个目标微服务实例，即在转发之前WebSocket请求将要发送给哪些目标微服务实例，对于每个目标微服务实例，目标转发器通过目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例；所述第一WebSocket通道是所述目标转发器与所述目标微服务实例对应的微服务之间的传输通道，从而目标转发器可以通过每个目标微服务实例第一WebSocket通道，将WebSocket请求发送至指定的目标微服务实例，从而可以同时与多个微服务的微服务实例进行通信传输，提升了WebSocket请求传输的灵活性。
如图4所示，为本申请实施例提供的一种基于WebSocket的请求传输装置的结构示意图。
本申请提供一种基于WebSocket的请求传输装置，包括：确定模块401，用于确定第一WebSocket请求对应的至少一个目标微服务实例；所述至少一个目标微服务实例用于处理所述WebSocket请求；处理模块402，用于针对所述至少一个目标微服务实例中的每个目标微服务实例，通过所述目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例；所述第一WebSocket通道是与所述目标微服务实例之间的传输通道。
一种可选实施方式中，所述确定模块401还用于：确定是否已建立所述目标微服务实例对应的第一WebSocket通道；若未建立，则与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道。
一种可选实施方式中，所述处理模块402还用于：通过第二WebSocket通道获取所述第一WebSocket请求；所述第二WebSocket通道是所述客户端与之间的传输通道。
一种可选实施方式中，所述处理模块402还用于：将所述第一WebSocket通道与所述第二WebSocket通道绑定。
一种可选实施方式中，所述确定模块401还用于：确定所述第二WebSocket通道断开时，断开与该第二WebSocket通道绑定的一个或多个第一WebSocket通道。
一种可选实施方式中，所述处理模块402还用于：在确定所述第二WebSocket通道断开后，按照预设周期，通过与该第二WebSocket通道绑定的一个或多个第一WebSocket通道发送心跳请求包。
一种可选实施方式中，所述确定模块401具体用于：所述确定模块401具体用于：根据预设规则，确定所述第一WebSocket请求对应的至少一个目标微服务；针对所述至少一个目标微服务中每个目标微服务，将该目标微服务的至少一个微服务实例中负载率最小的微服务实例，作为该目标微服务的 目标微服务实例。
本申请实施例提供一种计算机设备，包括程序或指令，当所述程序或指令被执行时，用以执行本申请实施例提供的一种WebSocket请求传输方法及任一可选方法。
本申请实施例提供一种计算机可读存储介质，包括程序或指令，当所述程序或指令被执行时，用以执行本申请实施例提供的一种WebSocket请求传输方法及任一可选方法。
最后应说明的是：本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、光学存储器等)上实施的计算机程序产品的形式。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (14)

  1. 基于全双工通信协议的请求传输方法，其特征在于，包括：
    目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例；所述至少一个目标微服务实例用于处理所述WebSocket请求；
    针对所述至少一个目标微服务实例中的每个目标微服务实例，所述目标转发器通过所述目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例；所述第一WebSocket通道是所述目标转发器与所述目标微服务实例之间的传输通道。
  2. 如权利要求1所述的方法，其特征在于，所述目标转发器通过所述目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例之前，还包括：
    所述目标转发器确定是否已建立所述目标微服务实例对应的第一WebSocket通道；若未建立，则与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道。
  3. 如权利要求2所述的方法，其特征在于，所述目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例之前，还包括：
    所述目标转发器通过第二WebSocket通道获取所述第一WebSocket请求；所述第二WebSocket通道是所述客户端与所述目标转发器之间的传输通道。
  4. 如权利要求2所述的方法，其特征在于，所述与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道之后，还包括：
    所述目标转发器将所述第一WebSocket通道与所述第二WebSocket通道绑定。
  5. 如权利要求4所述的方法，其特征在于，还包括：
    所述目标转发器确定所述第二WebSocket通道断开时，断开与该第二WebSocket通道绑定的一个或多个第一WebSocket通道。
  6. 如权利要求4所述的方法，其特征在于，还包括：
    在所述目标转发器确定所述第二WebSocket通道断开后，所述目标转发器按照预设周期，通过与该第二WebSocket通道绑定的一个或多个第一WebSocket通道发送心跳请求包。
  7. 如权利要求1-6任一所述的方法，其特征在于，所述目标转发器确定第一WebSocket请求对应的至少一个目标微服务实例，包括：
    所述目标转发器根据预设规则，确定所述第一WebSocket请求对应的至少一个目标微服务；
    针对所述至少一个目标微服务中每个目标微服务，所述目标转发器将该目标微服务的至少一个微服务实例中负载率最小的微服务实例，作为该目标微服务的目标微服务实例。
  8. 基于全双工通信协议的请求传输装置，其特征在于，包括：
    确定模块，用于确定第一WebSocket请求对应的至少一个目标微服务实例；所述至少一个目标微服务实例用于处理所述WebSocket请求；
    处理模块，用于针对所述至少一个目标微服务实例中的每个目标微服务实例，通过所述目标微服务实例对应的第一WebSocket通道发送所述第一WebSocket请求至所述目标微服务实例；所述第一WebSocket通道是与所述目标微服务实例之间的传输通道。
  9. 如权利要求8所述的装置，其特征在于，所述确定模块还用于：
    确定是否已建立所述目标微服务实例对应的第一WebSocket通道；若未建立，则与所述目标微服务实例对应的微服务之间建立所述第一WebSocket通道。
  10. 如权利要求9所述的装置，其特征在于，所述处理模块还用于：
    通过第二WebSocket通道获取所述第一WebSocket请求；所述第二WebSocket通道是所述客户端与之间的传输通道。
  11. 如权利要求9所述的装置，其特征在于，所述处理模块还用于：
    将所述第一WebSocket通道与所述第二WebSocket通道绑定。
  12. 如权利要求8-11任一所述的装置，其特征在于，所述确定模块具体 用于：
    根据预设规则，确定所述第一WebSocket请求对应的至少一个目标微服务；
    针对所述至少一个目标微服务中每个目标微服务，将该目标微服务的至少一个微服务实例中负载率最小的微服务实例，作为该目标微服务的目标微服务实例。
  13. 一种计算机设备，其特征在于，包括程序或指令，当所述程序或指令被执行时，如权利要求1至7中任意一项所述的方法被执行。
  14. 一种计算机可读存储介质，其特征在于，包括程序或指令，当所述程序或指令被执行时，如权利要求1至7中任意一项所述的方法被执行。
PCT/CN2020/102220 2019-07-18 2020-07-15 基于全双工通信协议的请求传输方法及装置 WO2021008567A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910652159.4 2019-07-18
CN201910652159.4A CN110381058B (zh) 2019-07-18 2019-07-18 基于全双工通信协议WebSocket的请求传输方法及装置

Publications (1)

Publication Number Publication Date
WO2021008567A1 true WO2021008567A1 (zh) 2021-01-21

Family

ID=68254035

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/102220 WO2021008567A1 (zh) 2019-07-18 2020-07-15 基于全双工通信协议的请求传输方法及装置

Country Status (2)

Country Link
CN (1) CN110381058B (zh)
WO (1) WO2021008567A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114943511A (zh) * 2022-05-17 2022-08-26 黑龙江省芯网科技有限公司 一种政务办公自动化平台及其优化实现方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110381058B (zh) * 2019-07-18 2023-05-16 深圳前海微众银行股份有限公司 基于全双工通信协议WebSocket的请求传输方法及装置
CN110377437A (zh) * 2019-07-19 2019-10-25 深圳前海微众银行股份有限公司 一种微服务间通信方法、计算机设备及存储介质
CN112202872A (zh) * 2020-09-28 2021-01-08 华云数据控股集团有限公司 一种数据转发方法、api网关及消息服务系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106612188A (zh) * 2015-10-21 2017-05-03 中兴通讯股份有限公司 一种基于微服务架构扩展软件功能的方法及装置
CN108206852A (zh) * 2016-12-20 2018-06-26 杭州华为数字技术有限公司 一种微服务框架下的基于会话的服务实例管理方法及设备
CN108418862A (zh) * 2018-01-31 2018-08-17 金蝶软件（中国）有限公司 基于人工智能服务云平台的微服务管理方法和系统
US20190141009A1 (en) * 2017-11-07 2019-05-09 General Electric Company Session moderator for turn-pattern tcp-packet relay with websocket instantiation
CN110381058A (zh) * 2019-07-18 2019-10-25 深圳前海微众银行股份有限公司 基于全双工通信协议WebSocket的请求传输方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10860390B2 (en) * 2017-06-28 2020-12-08 Intel Corporation Microservices architecture
CN107786379A (zh) * 2017-11-15 2018-03-09 四川省龙逸凤集网络科技有限公司 一种基于微服务架构的分层云管理平台
CN107733726B (zh) * 2017-11-29 2021-07-06 新华三云计算技术有限公司 一种服务请求的处理方法及装置
CN109995713B (zh) * 2017-12-30 2020-11-27 华为技术有限公司 一种微服务框架中的服务处理方法及相关设备
CN108924243A (zh) * 2018-07-20 2018-11-30 珠海宏桥高科技有限公司 基于微服务架构的数据分发及处理方法
CN109343829A (zh) * 2018-08-09 2019-02-15 广州瀚信通信科技股份有限公司 一种java语言分布式微服务治理框架
CN109788055B (zh) * 2019-01-11 2021-07-30 武汉虹旭信息技术有限责任公司 一种基于微服务架构的服务治理系统及其方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106612188A (zh) * 2015-10-21 2017-05-03 中兴通讯股份有限公司 一种基于微服务架构扩展软件功能的方法及装置
CN108206852A (zh) * 2016-12-20 2018-06-26 杭州华为数字技术有限公司 一种微服务框架下的基于会话的服务实例管理方法及设备
US20190141009A1 (en) * 2017-11-07 2019-05-09 General Electric Company Session moderator for turn-pattern tcp-packet relay with websocket instantiation
CN108418862A (zh) * 2018-01-31 2018-08-17 金蝶软件（中国）有限公司 基于人工智能服务云平台的微服务管理方法和系统
CN110381058A (zh) * 2019-07-18 2019-10-25 深圳前海微众银行股份有限公司 基于全双工通信协议WebSocket的请求传输方法及装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114943511A (zh) * 2022-05-17 2022-08-26 黑龙江省芯网科技有限公司 一种政务办公自动化平台及其优化实现方法

Also Published As

Publication number Publication date
CN110381058A (zh) 2019-10-25
CN110381058B (zh) 2023-05-16

Similar Documents

Publication Publication Date Title
WO2021008567A1 (zh) 基于全双工通信协议的请求传输方法及装置
US10686850B2 (en) Enterprise client-server system and methods of providing web application support through distributed emulation of websocket communications
US10547703B2 (en) Methods and systems for caching content valid for a range of client requests
US10404820B2 (en) Systems and methods for controlling cacheability and privacy of objects
CN102546794B (zh) 浏览器客户端与后端服务器直通的方法、网关和通信系统
Lampesberger Technologies for web and cloud service interaction: a survey
US20170070457A1 (en) Multiplexed demand signaled distributed messaging
US20150280980A1 (en) Method and apparatus for dynamic provisioning of communication services
CN109756559B (zh) 面向嵌入式机载系统分布式数据分发服务的构建及使用方法
US8825811B2 (en) Connection management and optimization for services delivered over networks
CN113132376A (zh) 媒体数据处理方法及装置、系统、电子设备和存储介质
CN104169901A (zh) 用于多播通信的内容传送机制
CN103401946B (zh) Http上传加速方法和系统
WO2010133097A1 (zh) 微技系统的数据共享方法、服务器以及数据共享系统
CN103139051A (zh) 一种基于Websocket协议的即时通讯方法
US8966107B2 (en) System and method of streaming data over a distributed infrastructure
WO2011113265A1 (zh) 一种实现数据共享访问的方法、装置及系统
CN109510748B (zh) 节点及节点交互方法和系统
US10044788B2 (en) Native client multimedia redirection
WO2020233400A1 (zh) 通信方法、通信系统、云节点和可读存储介质
CN113132745B (zh) 直播服务系统、方法、服务器
US9253124B2 (en) Techniques for sending and relaying information over broadcast and non-broadcast communications media
CN108471375B (zh) 一种消息处理方法、装置及终端
JP6089363B2 (ja) ネットワーク通信システム、サーバプッシュ通信制御サーバ、クライアント端末、サーバプッシュ通信制御方法、情報処理方法、およびプログラム
CA2593877A1 (en) Automatic mobile device configuration

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20840947

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20840947

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 13.05.2022)