WO2020094021A1 - 一种微服务架构下的通信方法及系统 - Google Patents

一种微服务架构下的通信方法及系统 Download PDF

Info

Publication number
WO2020094021A1
WO2020094021A1 PCT/CN2019/115776 CN2019115776W WO2020094021A1 WO 2020094021 A1 WO2020094021 A1 WO 2020094021A1 CN 2019115776 W CN2019115776 W CN 2019115776W WO 2020094021 A1 WO2020094021 A1 WO 2020094021A1
Authority
WO
WIPO (PCT)
Prior art keywords
session
executor
communication
peer
subscription
Prior art date
Application number
PCT/CN2019/115776
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 中兴通讯股份有限公司
Priority to US17/290,349 priority Critical patent/US20210314406A1/en
Priority to EP19882531.7A priority patent/EP3879787A4/en
Publication of WO2020094021A1 publication Critical patent/WO2020094021A1/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
    • H04L67/141—Setup of application sessions
    • 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/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • an embodiment of the present application provides a communication method under a microservice architecture, including: an executor sends a session registration request message to a communication server; and the executor receives a message returned from the communication server and the executor Information about the peer executive that has a session subscription and publication relationship; the executive subscribes to the communication server or the peer executive for a session instance of a registered session, or the executive subscribes from the communication server or all The peer executor receives the session instance information of the registered session to which the peer executor subscribes; wherein the session registration request message carries at least the information of the executor, the set of sessions to be registered and the session The attribute of any session in the set; the executor is the smallest communication unit under the microservice architecture, the session is a communication connection between microservices, and the session includes at least one session instance.
  • FIG. 6 is another exemplary flowchart of a communication method under a microservice architecture provided by an embodiment of this application.
  • FIG. 9 is another exemplary flowchart of a communication method under a microservice architecture provided by an embodiment of this application.
  • FIG. 11 is a flowchart of yet another example of a communication method under a microservice architecture provided by an embodiment of this application;
  • the communication server may be further adapted to receive a subscription request message sent by any executor, determine the peer executor that has a session subscription publishing relationship with the executor, and subscribe the executor to the The information about the session and the session instance is sent to the determined peer executive body; wherein, the subscription request message carries information about the session and the session instance subscribed by the executive body.
  • executor B subscribes to executor A for sessions and session instances.
  • (sessiontype, sessionInst) represents the subscribed sessions and session instances.
  • (sessiontype, sessionInst) can define a subscription model.
  • the sending entity 31 of the executive body A When the sending entity 31 of the executive body A publishes a communication message, it can use a publishing interface and adopt (sessiontype, sessionInst) as a publishing keyword. Execution A can first match the subscription pattern in the sticky subscription cache 33a according to the publication keyword. If the peer execution body matching the publication keyword is found in the sticky subscription cache 33a, then the matching peer execution body is directly directed to the matched Send a communication message; if no matching peer execution body is found in the sticky subscription cache 33a, then find a peer execution body matching the publication key in the subscription cache 33.
  • a publishing interface and adopt (sessiontype, sessionInst) as a publishing keyword.
  • Execution A can first match the subscription pattern in the sticky subscription cache 33a according to the publication keyword. If the peer execution body matching the publication keyword is found in the sticky subscription cache 33a, then the matching peer execution body is directly directed to the matched Send a communication message; if no matching peer execution body is found in the sticky subscription cache 33a, then find a peer
  • the transmission process of the communication message can refer to the above process. So I won't repeat them here.
  • the executor sends a subscription request message to the communication server, where the subscription request message carries information about the session and session instance to which the executor subscribes; the communication server sends the information about the session and session instance to which the executor subscribes to the peer executor ;or,
  • Step S20 The executor sends a session registration request message to the communication server; where the session registration request message carries at least the information of the executor, the session set to be registered, and the attributes of any session in the session set;
  • Step S23 When the executor publishes the communication message, it determines the counterpart executor receiving the communication message according to the information of the session and the session instance carried in the communication message and the attributes of the session, and sends it to the determined peer executor The communication message.
  • determining the peer executor receiving the communication message may include: the executor subscribes to the sticky subscription Find the peer execution body matching the information of the session and the session instance carried in the communication message; when the execution body finds the matching peer execution body from the sticky subscription cache, the found peer execution body is determined to be received The peer executor of the communication message; when the executor does not find a matching peer executor from the sticky subscription cache, based on the information of the session and session instance carried in the communication message and the attributes of the session, from the subscription cache Select a peer executor that subscribes to the session and session instance as the peer executor that receives the communication message.
  • Step S41 The communication server returns to the executor information about the peer executor that has a session subscription and publishing relationship with the executor;
  • FIG. 8 is an exemplary flowchart of a communication method under a microservice architecture provided by an embodiment of this application. This exemplary embodiment illustrates a session capability registration process and a subscription method of session instances.
  • executive body A and executive body B each register a session. Therefore, the communication server only needs to return executive body A's communication address to executive body B.
  • Executive body B can know between itself and executive body A based on The registered session XYZ has a session subscription and publishing relationship.
  • Step S109 After the registration process of the execution body B is completed, the communication server needs to immediately push the communication address of the execution body B to the execution body A; in this embodiment, the communication server may send a session update (session refresh) to the execution body A Message, so that executive A knows the communication address of executive B.
  • the communication server may send a session update (session refresh) to the execution body A Message, so that executive A knows the communication address of executive B.
  • Step S205 The communication server returns a session registration response (register ack) message to the executive body A.
  • Step S207 After receiving the session registration request message of the executor B, the communication server stores the information carried in the session registration request message of the executor B, and searches for the session subscription and publishing relationship; in this embodiment, the communication server will find the executor A has the publishing capability of session XYZ, and Executive B has the subscription capability of session XYZ. It can be determined that there is a session subscription publishing relationship between Executive A and Executive B based on session XYZ, and then the session subscription publishing relationship can be updated.
  • Step S210 Assume that executor B is the receiving end, and a receiving entity in executor B wants to subscribe to a certain session instance. Since executor B has learned all the peer executors (including executors) related to itself through the registration process A), then executor B can directly broadcast a subscription request (subrequest) message to all relevant peer executors (that is, not through the communication server), and the subscription request message can carry the session type identifier (sessiontype) to which the receiving entity subscribes. ) And one or more session instances (sessionInst).
  • the executive agent A After the executive agent A receives the subscription notification message from the communication server, it can store the information of the session instance that the executive agent B wants to subscribe to in its own subscription cache.
  • the communication method under the microservice architecture provided in this embodiment includes steps S301 to S317.
  • step S101 to step S109 in FIG. 8, so they will not be repeated here.
  • this application does not limit the order of step S301, step S302, and step S303.
  • Step S308 After the registration of the executor B2 is completed, the entity workB2_1 in the executor B2 calls the subscription interface, sub (XYZ,>), where the subscribed session instance is>, indicating that the entity workB2_1 can receive messages of any session instance under the session XYZ . Moreover, the execution body B2 updates its own binding cache, that is, the correspondence between the entity workB2_1, the session XYZ, and the session instance is recorded in the binding cache.
  • Step S315 workA_1 in the executor A then calls the publishing interface to publish the second message, such as pub (XYZ, abc.456, msgdata2).
  • FIG. 11 is another exemplary flowchart of a communication method under a microservice architecture provided by an embodiment of this application.
  • the executive body includes a sticky subscription cache and a sticky binding cache.
  • Step S409 The executor B2 sends a subscription request message to the communication server, which carries information about the session and session instance to be subscribed by the executor B1, such as (XYZ,>).
  • step S415 the executor A inserts the relationship between the session and session instance information (XYZ, abc.123) and the executor B1 as a sticky record into its own sticky subscription cache.
  • the capability description files of executive body A and executive body B can refer to the capability description files of executive body A and executive body B1 in the embodiment shown in FIG. 11, so they will not be repeated here.
  • the communication method provided in this embodiment includes steps S501 to S516.
  • Step S507 The entity workA_1 in the executor A calls the publishing interface to publish the first message, for example, pub (XYZ, sessionInst1, msg1).
  • Step S510 Executive A transmits the first message to Executive B through the socket interface.
  • step S511 the executor A inserts the relationship between the session and session instance information (XYZ, sessionInst1) and the executor B as a sticky record into its own sticky subscription cache.
  • Step S516 After receiving the sticky clear message, the executor A clears all sticky records related to the session XYZ in the sticky subscription cache and the sticky binding cache, and at the same time, locks the executor B in the subscription cache. mark.
  • executor A when executor A continues to send communication messages of other session instances of session XYZ (for example, sessionInst2), when executor B is matched in the subscription cache, executor B is marked with a block tag, so execute Body A will no longer select executive body B, but will select other subscribers who have subscribed to the session.
  • sessionInst2 sessionInst2
  • the second memory 1402 may include memories remotely provided with respect to the second processor 1403, and these remote memories may be connected to the communication server 1401 through a network.
  • Examples of the above network include but are not limited to the Internet, intranet, local area network, mobile communication network, and combinations thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开了一种微服务架构下的通信方法及系统，其中，上述通信方法包括：执行体向通信服务器发送会话注册请求消息，接收通信服务器返回的与该执行体之间存在会话订阅发布关系的对端执行体的信息；其中，会话注册请求消息中至少携带该执行体的信息、待注册的会话集合及会话集合中任一会话的属性；执行体向通信服务器或对端执行体订阅已注册会话的会话实例，或者，执行体从通信服务器或对端执行体接收该对端执行体订阅的已注册会话的会话实例的信息。本申请可以给以微服务架构改造的通信软件提供高性能、低时延的通信方案。

Description

一种微服务架构下的通信方法及系统 技术领域
本申请涉及但不限于通信技术领域，尤指一种微服务架构下的通信方法及系统。
背景技术
在移动通信领域，目前的移动网络架构是为语音通信以及常规的MBB(Mobile Broadband，移动宽带)业务而设计的，而且经历了3GPP(Third Generation Partnership Project，第三代合作伙伴计划)各个版本的升级，网元众多、接口复杂，其灵活性不足以支撑5G(the 5th Generation mobile communication technology，第五代移动通信技术)时代的多业务场景。另一方面，5G要求能适应不同类型的业务，比如视频业务、web业务、车联网业务等，因此也要求具备新业务的快速上线，快速部署。
5G的网络架构将是由业务驱动的，架构设计原则基于如何更灵活、高效地满足不同业务对移动网络的需求。在底层物理设施的SDN(Software Defined Network，软件定义网络)、NFV(Network Function Virtualization，网络功能虚拟化)技术支撑下，5G网络实现了核心网络的全面云化，在最新的3GPP标准中，对5G的核心网架构已经明确，在控制面确立了面向服务的框架。
云化的软件结构与传统的软件架构有很大的不同。传统的软件架构称为单体应用(Monolithic)，表现为业务系统的各个模块是紧耦合的关系，各个模块运行在一个进程中，每次升级都要重启整个应用进程，如果某个模块有问题，则可能导致整个系统无法正常启动。云化的软件结构则要求软件的组织不再是一个单体的软件，软件按不同的维度划分为各类服务，服务又可以细化为各种微服务，即所谓的微服务架构。微服务架构是将业务系统中的不同模块以微服务的形式进行拆分，每个微服务都是自治的，对外发布标准的API(Application Programming Interface，应用程序编程接 口)，这样一个庞大的单体进程就可以拆成互相独立的微小进程，而容器技术的兴起，更促进了微服务架构的发展。
随着5G业务和网络的发展要求，各个通信网元的软件采用微服务的软件架构成为一种必然的趋势。业界目前已经有了很多具有影响力的开源微服务架构平台，但都诞生于互联网领域。在将通信软件进行微服务改造时，由于通信领域自身一些特点的约束，导致已有的微服务系统很难适应。微服务架构下的通信方法目前流行的有RPC(Remote Procedure Call，远程过程调用)、rabbitmq消息队列等方式，但是在应用到通信领域下都不能很好地解决寻址、时延、负载均衡以及保证通信上下文一致等问题。
发明内容
本申请实施例提供了一种微服务架构下的通信方法及系统，可以给以微服务架构改造的通信软件提供高性能、低时延的通信方案。
一方面，本申请实施例提供了一种微服务架构下的通信方法，包括：执行体向通信服务器发送会话注册请求消息；所述执行体接收所述通信服务器返回的与所述执行体之间存在会话订阅发布关系的对端执行体的信息；所述执行体向所述通信服务器或所述对端执行体订阅已注册会话的会话实例，或者，所述执行体从所述通信服务器或所述对端执行体接收所述对端执行体订阅的已注册会话的会话实例的信息；其中，所述会话注册请求消息中至少携带所述执行体的信息、待注册的会话集合及所述会话集合中任一会话的属性；所述执行体为微服务架构下的最小通信单位，所述会话为微服务之间的通信连接，所述会话包括至少一个会话实例。
另一方面，本申请实施例提供了一种微服务架构下的通信方法，包括：通信服务器根据至少一个执行体发送的会话注册请求消息，确定不同执行体之间的会话订阅发布关系；所述通信服务器向所述执行体返回与所述执行体之间存在会话订阅发布关系的对端执行体的信息；所述通信服务器接收任一执行体发送的携带所述执行体订阅的会话和会话实例的信息的订阅请求消息后，确定与所述执行体之间存在会话订阅发布关系的对端执行 体；所述通信服务器将所述执行体订阅的会话和会话实例的信息发送给所述对端执行体；其中，所述执行体为微服务架构下的最小通信单元；所述会话注册请求消息中至少携带所述执行体的信息、所述执行体待注册的会话集合及所述会话集合中任一会话的属性；所述会话为微服务之间的通信连接，所述会话包括至少一个会话实例。
再一方面，本申请实施例提供了一种微服务架构下的通信系统，包括：通信服务器以及至少两个执行体；其中，所述执行体为微服务架构下的最小通信单位，一个微服务对应一个或多个执行体；任一所述执行体适于向所述通信服务器发送会话注册请求消息，接收所述通信服务器返回的与所述执行体之间存在会话订阅发布关系的对端执行体的信息；所述执行体还适于向所述通信服务器或所述对端执行体订阅已注册会话的会话实例，或者，从所述通信服务器或所述对端执行体接收所述对端执行体订阅的已注册会话的会话实例的信息；其中，所述会话注册请求消息中至少携带所述执行体的信息、所述执行体待注册的会话集合及所述会话集合中任一会话的属性；所述会话为微服务之间的通信连接，所述会话包括至少一个会话实例。
再一方面，本申请实施例提供了一种通信设备，包括：第一存储器和第一处理器，所述第一存储器设置为存储微服务架构下的通信程序，所述通信程序被所述第一处理器执行时实现上述执行体侧的微服务架构下的通信方法的步骤。
再一方面，本申请实施例提供了一种通信服务器，包括：第二存储器和第二处理器，所述第二存储器设置为存储微服务架构下的通信程序，所述通信程序被所述第二处理器执行时实现上述通信服务器侧的微服务架构下的通信方法的步骤。
此外，本申请实施例还提供了一种计算机可读介质，存储有微服务架构下的通信程序，所述通信程序被处理器执行时实现上述执行体侧的微服务架构下的通信方法的步骤。
在本申请实施例中，执行体向通信服务器发送会话注册请求消息，接收通信服务器返回的与该执行体之间存在会话订阅发布关系的对端执行体的信息；执行体向通信服务器或对端执行体订阅已注册会话的会话实例，或者，执行体从通信服务器或对端执行体接收对端执行体订阅的已注册会话的会话实例的信息；其中，会话注册请求消息中至少携带该执行体的信息、待注册的会话集合以及会话集合中任一会话的属性。在本申请实施例中提出了会话和会话实例的概念，通过两阶段的发现过程(包括会话能力注册过程和会话实例的订阅过程)，实现微服务应用到通信系统时，便于找到对端地址和定位到呼叫实例。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。
图1为本申请实施例提供的微服务架构下的通信系统的示意图；
图2为本申请实施例提供的微服务架构下的通信系统的一种实施流程示例图；
图3为本申请实施例提供的微服务架构下的通信系统的另一种实施流程示例图；
图4为本申请实施例提供的一种微服务架构下的通信方法的流程图；
图5为本申请实施例提供的微服务架构下的通信方法的一种示例流程图；
图6为本申请实施例提供的微服务架构下的通信方法的另一种示例流 程图；
图7为本申请实施例提供的另一种微服务架构下的通信方法的流程图；
图8为本申请实施例提供的微服务架构下的通信方法的一种示例流程图；
图9为本申请实施例提供的微服务架构下的通信方法的另一种示例流程图；
图10为本申请实施例提供的微服务架构下的通信方法的再一种示例流程图；
图11为本申请实施例提供的微服务架构下的通信方法的再一种示例流程图；
图12为本申请实施例提供的微服务架构下的通信方法的再一种示例流程图；
图13为本申请实施例提供的一种通信设备的示意图；
图14为本申请实施例提供的一种通信服务器的示意图。
具体实施方式
下面将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例提供了一种微服务架构下的通信方法及系统，可以适用于分布式通信系统，给以微服务架构改造的通信软件提供高性能、低时延的通信方案。
图1为本申请实施例提供的一种微服务架构下的通信系统的示意图。如图1所示，本实施例提供的微服务架构下的通信系统包括：通信服务器 12以及至少两个执行体(比如，执行体10a和执行体10b)。
其中，执行体为微服务架构下的最小通信单元，一个微服务可以对应一个或多个执行体。在实际实现时，执行体可以为进程或者容器。然而，本申请对此并不限定。在图1中以执行体10a和10b为容器为例，在执行体10a和10b内可以分别部署应用(APP，Application)。
在通信系统中，用户发起的流程可能包含多条消息，而每一类流程都可以抽象成一个会话。在本申请实施例中，会话(Session)可以为微服务之间的通信连接，会话可以被发布，也可以被订阅。一个会话可以包括多个会话实例。比如，通信系统和用户相关，多个用户可以发起同一个会话，即一个特定用户发起的一个会话为一个会话实例。其中，会话实例的表示形式可以是字符串形式，也可以是整数。如果会话实例采用字符串形式表示，可以支持“aaa.bbb.ccc”之类的格式，使得表示更丰富，其中也可以采用通配符(比如*、>等)，例如：aaa.bbb.*。其中，在进行会话实例匹配时，通配符越多，精确度越低，优先级越低；反之，精确度越高，优先级越高。
其中，会话可以采用会话类型标识表示，且会话可以包括以下一项或多项属性：会话作用域(比如，微服务范围内；网元范围内)、会话负载均衡类型(比如，轮询、粘滞、广播)、实例匹配规则(比如，精确匹配；模糊匹配)。
在本实施例中，任一执行体(比如，订阅者和发布者)适于向通信服务器发送会话注册请求消息，并接收通信服务器返回的与该执行体之间存在会话订阅发布关系的对端执行体的信息；其中，会话注册请求消息中至少携带该执行体的信息、待注册的会话集合及会话集合中任一会话的属性。该执行体还适于向通信服务器或对端执行体订阅已注册会话的会话实例；或者，该执行体还适于从通信服务器或对端执行体接收该对端执行体订阅的已注册会话的会话实例的信息。
在一示例性实施方式中，待注册的会话集合可以包括以下至少之一： 能发布的会话集合、能订阅的会话集合。上述会话集合中可以包括一个或多个会话。
在一示例性实施方式中，当任一执行体向通信服务器注册的会话集合中包括至少两个会话时，该执行体还可以适于接收通信服务器返回的该执行体与对端执行体之间建立会话订阅发布关系所依据的已注册会话的信息(比如，已注册会话的会话类型标识)。
在一示例性实施方式中，通信服务器可以适于根据接收到的会话注册请求消息，确定不同执行体之间的会话订阅发布关系。其中，通信服务器可以根据不同执行体的会话注册请求消息中携带的待注册的会话集合，分析出不同执行体之间的会话订阅分布关系，并保存分析出的会话订阅发布关系。
在一示例性实施方式中，通信服务器还可以适于接收任一执行体发送的订阅请求消息，确定与该执行体之间存在会话订阅发布关系的对端执行体，并将该执行体订阅的会话和会话实例的信息发送给所确定的对端执行体；其中，订阅请求消息携带该执行体订阅的会话和会话实例的信息。
在一示例性实施方式中，任一执行体还适于在发布通信消息时，根据通信消息携带的会话和会话实例的信息以及该会话的属性，确定接收该通信消息的对端执行体，并向所确定的对端执行体发送该通信消息。
下面参照图1以执行体10a为例说明会话能力注册和会话实例订阅过程。在一示例性实施方式中，执行体10a可以根据预设的能力描述文件确定自身能发布的会话集合、能订阅的会话集合以及会话集合中任一会话的属性，然后向通信服务器12发送会话注册请求消息，其中，会话注册请求消息可以携带执行体10a的信息(比如，网络协议(IP，Internet Protocol)地址和端口号等通信地址信息)、执行体10a能发布的会话集合、执行体10a能订阅的会话集合以及会话集合中任一会话的属性(比如，会话负载均衡类型以及实例匹配规则)。
通信服务器12收到执行体10a的会话注册请求消息后，通过解析会 话注册请求消息可以获知执行体10a能发布和能订阅的会话，通过分析可以知道执行体10a与哪些已进行会话注册的执行体订阅或发布了相同的会话，从而得出执行体10a与其他执行体之间的会话订阅发布关系，并保存分析出的会话订阅发布关系。然后，通信服务器12可以向执行体10a返回会话注册响应消息，其中可以携带与执行体10a之间存在会话订阅发布关系的对端执行体的信息(比如，执行体10b的通信地址)。其中，当执行体10a向通信服务器12注册的会话集合中包括至少两个会话时，通信服务器12向执行体10a返回的会话注册响应消息中可以携带与执行体10a之间存在会话订阅发布关系的对端执行体(比如，执行体10b)的信息、以及执行体10a与该对端执行体之间建立会话订阅发布关系所依据的已注册会话的信息(比如，已注册会话的会话类型标识)。
在执行体10a完成会话能力注册之后，执行体10a(比如，作为订阅者)可以使用订阅(sub)接口向通信服务器12发送订阅请求消息，其中，订阅请求消息中可以携带执行体10a订阅的已注册会话的会话实例的信息(比如，会话类型标识和会话实例)。换言之，通过订阅请求消息，执行体10a可以告知通信服务器12自己去订阅某个会话(执行体10a已经向通信服务器12注册的会话集合中的某一个会话)下面的某个会话实例，即表示自己要接收某个会话下面某个会话实例的通信消息。其中，订阅请求消息中携带的会话类型标识(sessiontype)和会话实例(sessionInst)可以定义一个订阅模式。对于订阅模式，会话实例越精确，优先级越高；比如，abc.123.456比abc.123.*的优先级高，abc.123.*的优先级比>的优先级高。同时，执行体10a(作为订阅者，即接收者)可以将本执行体内订阅该会话和会话实例的实体的信息、订阅的会话类型标识以及会话实例插入到自己的绑定缓存(bindcache)中。
通信服务器12收到执行体10a的订阅请求消息后，查询保存的会话订阅发布关系，得到执行体10a订阅的会话的所有发布方(即发送方)，并将执行体10a订阅的会话实例的信息通过订阅通知(subNotify)消息推送到所有发布方(比如，包括执行体10b)。其中，通信服务器12仅仅用 来分析和管理执行体的会话订阅发布关系，执行体之间的通信消息并不通过通信服务器12进行传输，而是由执行体之间直接传输。以执行体10b为执行体10a订阅的会话实例的发布方为例，执行体10b可以将接收到的执行体10a的通信地址、执行体10a订阅的会话和会话实例的信息插入到自己的订阅缓存(subcache)中。
本实施例提出了会话和会话实例的概念，在单软体架构改造成微服务的过程中，通过两个阶段的发现过程(包括会话能力注册过程、会话实例的订阅过程)，使得微服务应用到通信系统时，便于找到对端地址和定位到呼叫实例。
图2为本申请实施例提供的微服务架构下的通信系统的一种实施流程示例图。在本示例性实施例中，执行体A和执行体B已完成会话能力注册和会话实例的订阅过程，即实现了执行体A和执行体B双方的发现，执行体A和执行体B可以开始收发通信消息。
如图2所示，执行体A可以包括订阅缓存(subcache)23和绑定缓存(bindcache)24，执行体B可以包括订阅缓存27和绑定缓存28。执行体A的订阅缓存23中可以存储向执行体A订阅会话和会话实例的对端执行体的信息(比如，通信地址)、该对端执行体订阅的会话和会话实例的信息；执行体A的绑定缓存24中可以存储执行体A内的实体与订阅的会话和会话实例的匹配关系，即记录哪些实体订阅了哪个会话下面的哪个会话实例。执行体B的订阅缓存27中可以存储向执行体B订阅会话和会话实例的对端执行体的信息、该对端执行体订阅的会话和会话实例的信息；执行体B的绑定缓存28中可以存储执行体B内的实体与订阅的会话和会话实例的匹配关系。
下面以执行体A为发布者，执行体B为订阅者为例进行说明。执行体B在订阅过程中向执行体A订阅了会话和会话实例，比如以(sessiontype，sessionInst)表示订阅的会话和会话实例。(sessiontype，sessionInst)可以定义一个订阅模式。
执行体A的发送实体21在发布通信消息时，可以使用发布(pub)接口并以(sessiontype，sessionInst)作为发布关键字；其中，会话实例(sessionInst)可以不支持通配特性。执行体A可以根据发布关键字在订阅缓存23中匹配订阅模式；其中，匹配过程可以包括：按照发布关键字中的会话类型标识(sessiontype)对应的实例匹配规则(比如，精确匹配或模糊匹配)，在订阅缓存(subcache)中查找与发布关键字匹配的记录；如果匹配到多个订阅模式，则取具有最高优先级的订阅模式；对于订阅模式，会话实例越精确，优先级越高，比如：abc.123.456的优先级比abc.123.*的优先级高，abc.123.*的优先级比>的优先级高；如果同等优先级的订阅模式有多个，则可以采用发布关键字中的会话类型标识(sessiontype)对应的会话负荷均衡类型(比如，轮询或随机)，选取到唯一的一个订阅者(即接收者)。在本示例性实施例中，以选取的唯一的一个订阅者为执行体B为例，执行体A可以向执行体B发送通信消息。
执行体B接收到通信消息后，可以从消息头中解析出会话和会话实例的信息，比如，sessiontype和sessionInst；然后，执行体B在绑定缓存28中匹配订阅模式，选取到唯一的一个接收实体(比如，接收实体26)，并将接收到的通信消息投递给选出的接收实体。其中，执行体B可以根据本地预设的选取策略(比如，轮询或随机)，在绑定缓存28中选取唯一的一个接收实体接收通信消息。本申请对于上述选取策略并不限定。
同样地，执行体B作为发布者(比如，由发送实体25发布通信消息)，执行体A作为接收者(比如，由接收实体22接收通信消息)时，通信消息的传输流程可以参照上述过程，故于此不再赘述。
本实施例通过会话的属性设置，可以在通信消息的发送过程中实现接收端的匹配，从而优化负载均衡，无需由上层业务考虑类似消息通信的范围控制、消息通信的负载均衡、消息如何表示等方面，大大降低了上层业务的复杂度；在微服务的弹性伸缩等流程中，业务就可以只需要关心策略，实际的实施对业务透明化。
图3为本申请实施例提供的微服务架构下的通信系统的另一种实施流程示例图。在本示例性实施例中，执行体A和执行体B已完成会话能力注册和会话实例的订阅过程，即实现了执行体A和执行体B双方的发现，执行体A和执行体B可以开始收发通信消息。
其中，执行体A可以包括以下四类缓存：订阅缓存33、绑定缓存34、粘滞订阅缓存(subcacheAff)33a、粘滞绑定缓存(bindcacheAff)34a。其中，粘滞订阅缓存33a对应订阅缓存33，指向执行体(比如，执行体B)；粘滞绑定缓存34a对应绑定缓存34，指向执行体内的实体(比如，执行体A内的接收实体32)。执行体B可以包括以下四类缓存：订阅缓存37、绑定缓存38、粘滞订阅缓存37a、粘滞绑定缓存38a。
其中，执行体A的订阅缓存33中可以存储向执行体A订阅会话和会话实例的对端执行体的信息(比如，通信地址)、该对端执行体订阅的会话和会话实例的信息(比如，sessiontype和sessionInst)；执行体A的绑定缓存34中可以存储执行体A内的实体与订阅的会话和会话实例的匹配关系，即记录哪些实体订阅了哪个会话下面的哪个会话实例。执行体B的订阅缓存37中可以存储向执行体B订阅会话和会话实例的对端执行体的信息、该对端执行体订阅的会话和会话实例的信息；执行体B的绑定缓存38中可以存储执行体B内的实体与订阅的会话和会话实例的匹配关系。
下面以执行体A为发布者，执行体B为订阅者为例进行说明。执行体B在订阅过程中向执行体A订阅了会话和会话实例，比如以(sessiontype，sessionInst)表示订阅的会话和会话实例。(sessiontype，sessionInst)可以定义一个订阅模式。
执行体A的发送实体31在发布通信消息时，可以使用发布接口并采用(sessiontype，sessionInst)作为发布关键字。执行体A可以根据发布关键字先在粘滞订阅缓存33a中匹配订阅模式，如果在粘滞订阅缓存33a中查找到发布关键字匹配的对端执行体，则直接向匹配到的对端执行体发送通信消息；如果在粘滞订阅缓存33a中查不到匹配的对端执行体，则在订 阅缓存33中查找发布关键字匹配的对端执行体。
在本示例性实施例中，以执行体A没有在粘滞订阅缓存33a中匹配到订阅模式为例进行说明。执行体A以通信消息所携带的(sessiontype，sessionInst)作为发布关键字，按照sessiontype对应的实例匹配规则在订阅缓存33中进行订阅模式匹配，可以获得订阅者集合(即对端执行体的集合)；然后，执行体A根据sessiontype所对应的会话负载均衡类型(比如，轮询或随机)，从匹配到的订阅者集合中选择一个唯一的订阅者(比如，执行体B)，并向该订阅者发送通信消息。同时，执行体A会在粘滞订阅缓存33a中生成一条粘滞记录，其中记录选择出的订阅者的信息(subInfo)(比如，执行体B的通信地址)、会话及会话实例的信息；比如，采用(subInfo，sessiontype，sessionInst)的形式记录在粘滞订阅缓存33a中。
执行体B(订阅者)收到通信消息后，以通信消息中携带的(sessiontype，sessionInst)作为关键字，在粘滞绑定缓存38a中查找匹配的实体，如果查找到则投递给查找到的实体(即执行体B内的上层实体)，如果没有查到匹配的实体，则在绑定缓存38中查找匹配的实体。其中，执行体B可以根据本地预设的选取策略(比如，轮询或随机)，在绑定缓存38中选取唯一的一个接收实体接收通信消息。本申请对于上述选取策略并不限定。
在本示例性实施例中，以执行体B没有在粘滞绑定缓存38a中查找到匹配的实体为例进行说明。执行体B以通信消息所携带的(sessiontype，sessionInst)作为关键字，在绑定缓存38进行订阅模式匹配，选择一个唯一的执行体B内的接收实体(比如，接收实体36)，并将通信消息派发给选出的接收实体。同时，执行体B会在粘滞绑定缓存38a中生成指向选出的接收实体36的一条粘滞记录，即在粘滞绑定缓存38a中增加选出的接收实体36与会话和会话实例的匹配关系。在本示例性实施例中，执行体B(订阅者)还可以将发送通信消息的执行体A的通信地址、该通信消息携带的会话和会话实例的信息作为一条粘滞记录插入自己的粘滞订阅缓存37a中，比如，采用(pubInfo(执行体A的通信地址)，sessiontype， sessionInst)的形式记录在粘滞订阅缓存37a。之后，如果执行体B需要给执行体A返回通信消息，可以直接查询自己的粘滞订阅缓存37a，找到执行体A后直接发送通信消息。
同样地，执行体B作为发布者(比如，由发送实体35发布通信消息)，执行体A作为接收者(比如，由接收实体32接收通信消息)时，通信消息的传输流程可以参照上述过程，故于此不再赘述。
本实施例中，通过粘滞机制，不仅支持了微服务之间的通信解耦，同时将会话实例和相关的消息序列关联起来，这样用户级通信中用户上下文在一定时间内的消息交互过程中保持了一致。
图4为本申请实施例提供的一种微服务架构下的通信方法的流程图。本实施例提供的通信方法可以由执行体实施。关于执行体、会话及会话实例的说明可以参照上述通信系统中的描述，故于此不再赘述。
如图4所示，本实施例提供的微服务架构下的通信方法包括以下步骤：
步骤S10、执行体向通信服务器发送会话注册请求消息；其中，会话注册请求消息中至少携带执行体的信息、待注册的会话集合以及会话集合中任一会话的属性；
步骤S11、执行体接收通信服务器返回的与该执行体之间存在会话订阅发布关系的对端执行体的信息；
步骤S12、执行体向通信服务器或对端执行体订阅已注册会话的会话实例；或者，执行体从通信服务器或对端执行体接收该对端执行体订阅的已注册会话的会话实例的信息。
本实施例中，执行体通过步骤S10和S11完成会话能力注册，通过步骤S12完成会话实例的订阅过程；通过会话能力注册和实例订阅过程，执行体可以发现对端执行体，并可以定位到会话实例，然后执行体可以直接与发现的对端执行体进行消息传输。
其中，当执行体作为订阅者时，在步骤S12，执行体可以向通信服务器或对端执行体订阅已注册会话的会话实例；当执行体作为发布者时，在 步骤S12，执行体可以从通信服务器或对端执行体接收该对端执行体订阅的已注册会话的会话实例的信息。
在一示例性实施方式中，在步骤S12中，执行体向通信服务器或对端执行体订阅已注册会话的会话实例，可以包括：
执行体向通信服务器发送订阅请求消息，其中，订阅请求消息中携带该执行体订阅的会话和会话实例的信息；由通信服务器将该执行体订阅的会话和会话实例的信息发送给对端执行体；或者，
执行体广播订阅请求消息给对端执行体；其中，订阅请求消息中携带该执行体订阅的会话和会话实例的信息。
在一示例性实施方式中，在步骤S10之后，本实施例提供的通信方法还可以包括：执行体接收通信服务器返回的该执行体与对端执行体之间建立会话订阅发布关系所依据的已注册会话的信息。比如，当执行体向通信服务器注册的会话集合中包括至少两个会话时，通信服务器可以向执行体返回以下信息：与该执行体之间存在会话订阅发布关系的对端执行体的信息、该执行体与该对端执行体之间建立会话订阅发布关系所依据的已注册会话的信息(比如，已注册会话的会话类型标识)。
在一示例性实施方式中，在步骤S12之后，本实施例提供的通信方法还可以包括：执行体在发布通信消息时，根据通信消息携带的会话和会话实例的信息以及会话的属性，确定接收该通信消息的对端执行体，并向所确定的对端执行体发送该通信消息。
在一示例性实施方式中，在步骤S12之后，本实施例提供的通信方法还可以包括：执行体接收到通信消息后，根据该通信消息携带的会话和会话实例的信息，确定在该执行体内接收该通信消息的实体，并向所确定的实体投递该通信消息。
图5为本申请实施例提供的微服务架构下的通信方法的一种示例流程图。本实施例中，以执行体为通信消息的发布者(即发送者)为例进行说明。如图5所示，本实施例提供的微服务架构下的通信方法包括以下步骤：
步骤S20、执行体向通信服务器发送会话注册请求消息；其中，会话注册请求消息中至少携带执行体的信息、待注册的会话集合以及会话集合中任一会话的属性；
步骤S21、执行体接收通信服务器返回的与该执行体之间存在会话订阅发布关系的对端执行体的信息；
步骤S22、执行体从通信服务器或对端执行体接收该对端执行体订阅的已注册会话的会话实例的信息；
步骤S23、执行体在发布通信消息时，根据该通信消息携带的会话和会话实例的信息以及该会话的属性，确定接收该通信消息的对端执行体，并向所确定的对端执行体发送该通信消息。
在一示例性实施方式中，执行体可以包括订阅缓存，用于存储向该执行体订阅已注册会话的会话实例的对端执行体的信息、对端执行体订阅的会话和会话实例的信息；
在步骤S23中，根据通信消息携带的会话和会话实例的信息以及该会话的属性，确定接收该通信消息的对端执行体，可以包括：执行体根据通信消息携带的会话和会话实例的信息以及该会话的属性，从订阅缓存中选择订阅该会话和会话实例的一个对端执行体，作为接收该通信消息的对端执行体。
在一示例性实施方式中，执行体还可以包括粘滞订阅缓存；其中，从订阅缓存中选择订阅该会话和会话实例的一个对端执行体，作为接收该通信消息的对端执行体之后，本实施例的通信方法还可以包括：在粘滞订阅缓存中增加该通信消息携带的会话和会话实例的信息与对端执行体的匹配关系。
在一示例性实施方式中，在步骤S23中，根据通信消息携带的会话和会话实例的信息以及该会话的属性，确定接收该通信消息的对端执行体，可以包括：执行体从粘滞订阅缓存中查找与该通信消息携带的会话和会话实例的信息匹配的对端执行体；当执行体从粘滞订阅缓存查找到匹配的对 端执行体，则确定查找到的对端执行体为接收该通信消息的对端执行体；当执行体没有从粘滞订阅缓存查找到匹配的对端执行体，则根据该通信消息携带的会话和会话实例的信息以及该会话的属性，从订阅缓存中选择订阅该会话和会话实例的一个对端执行体，作为接收该通信消息的对端执行体。
在一示例性实施方式中，会话的属性可以包括：会话负载均衡类型、实例匹配规则；其中，根据通信消息携带的会话和会话实例的信息以及该会话的属性，从订阅缓存中选择订阅该会话和会话实例的一个对端执行体，作为接收该通信消息的对端执行体，可以包括：根据通信消息携带的会话的实例匹配规则，从订阅缓存中查找订阅该会话和会话实例的对端执行体；根据该会话的会话负载均衡类型，从查找到的对端执行体中选择一个作为接收该通信消息的对端执行体。然而，本申请对此并不限定。在其他实现方式中，会话的属性可以包括：会话负载均衡类型或者实例匹配规则；比如，执行体从订阅缓存中查找对端执行体时，可以根据会话负载均衡类型或者实例匹配规则选择一个对端执行体来接收通信消息。
图6为本申请实施例提供的微服务架构下的通信方法的另一种示例流程图。本实施例中，以执行体为通信消息的订阅者(即接收者)为例进行说明。如图6所示，本实施例提供的微服务架构下的通信方法包括以下步骤：
步骤S30、执行体向通信服务器发送会话注册请求消息；其中，会话注册请求消息中至少携带执行体的信息、待注册的会话集合以及会话集合中任一会话的属性；
步骤S31、执行体接收通信服务器返回的与该执行体之间存在会话订阅发布关系的对端执行体的信息；
步骤S32、执行体向通信服务器或对端执行体订阅已注册会话的会话实例；
步骤S33、执行体接收到通信消息后，根据该通信消息携带的会话和 会话实例的信息，确定在该执行体内接收该通信消息的实体，并向所确定的实体投递该通信消息。
在一示例性实施方式中，执行体可以包括绑定缓存，用于存储执行体内的实体与订阅的会话和会话实例的匹配关系；
其中，根据通信消息携带的会话和会话实例的信息，确定在执行体内接收所述通信消息的实体，可以包括：执行体根据通信消息携带的会话和会话实例的信息，从绑定缓存中查找订阅该会话和会话实例的实体，并从查找到的实体中选择一个作为接收该通信消息的实体。
在一示例性实施方式中，执行体还可以包括粘滞绑定缓存；其中，在根据通信消息携带的会话和会话实例的信息，从绑定缓存中查找订阅该会话和会话实例的实体，并从查找到的实体中选择一个作为接收该通信消息的实体之后，本实施例的通信方法还可以包括：执行体在粘滞绑定缓存中增加从绑定缓存内查找到的实体与该会话和会话实例的匹配关系，作为一条粘滞记录。
在一示例性实施方式中，根据通信消息携带的会话和会话实例的信息，确定在执行体内接收通信消息的实体，可以包括：执行体接收到携带会话和会话实例的信息的通信消息后，从粘滞绑定缓存中查找与该会话和会话实例匹配的实体；当执行体在粘滞绑定缓存中查找到匹配的实体，则确定查找到的实体为接收该通信消息的实体；当执行体在粘滞绑定缓存中没有查找到匹配的实体，则根据该通信消息携带的会话和会话实例的信息，从绑定缓存中查找订阅该会话和会话实例的实体，并从查找到的实体中选择一个作为接收该通信消息的实体。
在一示例性实施方式中，执行体还可以包括粘滞订阅缓存；其中，执行体在粘滞绑定缓存中增加从绑定缓存内查找到的实体与会话和会话实例的匹配关系后，本实施例的通信方法还可以包括：执行体在粘滞订阅缓存中增加通信消息携带的会话和会话实例的信息与发送该通信消息的对端执行体的匹配关系，作为粘滞订阅缓存中的一条粘滞记录；当粘滞订阅 缓存内该会话相关的粘滞记录的数量大于预设的粘滞配额，执行体清除粘滞订阅缓存和粘滞绑定缓存中该会话相关的粘滞记录，并通知对端执行体清除该会话相关的粘滞记录。
图7为本申请实施例提供的另一种微服务架构下的通信方法的流程图。本实施例提供的通信方法可以由通信服务器实施。关于执行体、会话及会话实例的说明可以参照上述通信系统中的描述，故于此不再赘述。
如图7所示，本实施例提供的微服务架构下的通信方法包括以下步骤：
步骤S40、通信服务器根据至少一个执行体发送的会话注册请求消息，确定不同执行体之间的会话订阅发布关系；其中，会话注册请求消息中至少携带执行体的信息、执行体待注册的会话集合及会话集合中任一会话的属性；
步骤S41、通信服务器向该执行体返回与该执行体之间存在会话订阅发布关系的对端执行体的信息；
步骤S42、通信服务器接收任一执行体发送的订阅请求消息后，确定与该执行体之间存在会话订阅发布关系的对端执行体；其中，订阅请求消息携带该执行体订阅的会话和会话实例的信息；
步骤S43、通信服务器将该执行体订阅的会话和会话实例的信息发送给对端执行体。
在一示例性实施方式中，在步骤S40之后，本实施例提供的通信方法还可以包括：通信服务器向任一执行体返回该执行体与对端执行体之间建立会话订阅发布关系所依据的已注册会话的信息。
在一示例性实施方式中，会话的属性可以包括以下至少一项：会话负载均衡类型、实例匹配规则。
下面通过多个示例性实施例对本申请实施例提供的微服务架构下的通信方法及系统进行说明。
图8为本申请实施例提供的微服务架构下的通信方法的一种示例流程 图。本示例性实施例说明会话能力注册过程和会话实例的一种订阅方式。
如图8所示，本实施例提供的微服务架构下的通信方法包括步骤S101至步骤S112。
步骤S101、执行体A在上电初始化时，读取预先配置的能力描述文件，其中，能力描述文件可以是json(JavaScript Object Notation，JS对象简谱)格式。
例如，执行体A的能力描述文件可以包括以下内容：
Figure PCTCN2019115776-appb-000001
步骤S102、执行体B在上电初始化时，读取预先配置的能力描述文件，其中，能力描述文件可以是json格式。
例如，执行体B的能力描述文件可以包括以下内容：
Figure PCTCN2019115776-appb-000002
其中，本申请对于步骤S101和步骤S102的先后顺序并不限定。
步骤S103、执行体A向通信服务器发送会话注册请求(register request)消息，其中可以携带执行体A的通信地址(例如可以包括IP地址和端口号(PORT))、能订阅的会话(比如，会话XYZ)、能发布的会话(比如，会话XYZ)以及会话XYZ的属性。
步骤S104、通信服务器收到执行体A的会话注册请求消息后，查找自身存储的会话订阅发布关系。
本实施例中，由于此时没有其它执行体在已注册状态，因此，执行体A没有关联方，即没有对端执行体；通信服务器可以把执行体A的会话注册请求消息中携带的信息进行保存，并更新存储的会话订阅发布关系。
步骤S105、通信服务器给执行体A返回会话注册响应(register ack) 消息。
步骤S106、执行体B向通信服务器发送会话注册请求消息，其中可以携带执行体B的通信地址(可以包括IP地址和端口号)、能发布的会话(比如，会话XYZ)、能订阅的会话(比如会话XYZ)以及会话XYZ的属性。
步骤S107、通信服务器收到执行体B的会话注册请求消息后，存储会话注册请求消息中携带的信息，并查找会话订阅发布关系；在本实施例中，通信服务器会发现执行体A拥有会话XYZ的发布能力，而执行体B拥有会话XYZ的订阅能力，则可以确定执行体A和执行体B之间基于会话XYZ存在会话订阅发布关系，然后可以更新存储的会话订阅发布关系。
步骤S108、通信服务器给执行体B返回注册响应消息，其中，注册响应消息中可以携带执行体A的通信地址。
在本实施例中，执行体A和执行体B分别注册了一个会话，因此，通信服务器向执行体B返回执行体A的通信地址即可，执行体B可以知道自己与执行体A之间基于已注册的会话XYZ存在会话订阅发布关系。
在其他实施例中，当执行体B注册了多个会话时，通信服务器需要向执行体B返回执行体A的通信地址以及与执行体A之间存在关系的会话的信息(比如，会话类型标识)，如此一来，执行体B可以知道自己与执行体A之间基于已注册的哪个会话存在会话订阅发布关系。
步骤S109、通信服务器在执行体B的注册过程完成后，需要将执行体B的通信地址立即推送给执行体A；在本实施例中，通信服务器可以给执行体A发送会话更新(session refresh)消息，这样执行体A知道了执行体B的通信地址。
通过上述步骤，完成了执行体A和执行体B在通信服务器的会话能力注册过程。
步骤S110、假定执行体B是接收端，执行体B中的某一接收实体要订阅某一会话实例，则执行体B可以调用订阅接口发送订阅请求(sub  request)消息给通信服务器，订阅请求消息中可以携带该接收实体要订阅的会话类型标识以及一个或多个会话实例。
步骤S111、通信服务器接收执行体B的订阅请求消息，查询存储的会话订阅发布关系，得到执行体B的对端执行体(即执行体A)的通信地址。
步骤S112、通信服务器通过订阅通知(sub notify)消息将执行体B要订阅的会话实例的信息推送给执行体A。执行体A收到通信服务器的订阅通知消息后，可以将执行体B要订阅的会话实例的信息存储到自己的订阅缓存中。
通过上述过程完成了会话能力注册和会话实例的订阅过程，执行体A和执行体B之间可以传输通信消息。
图9为本申请实施例提供的微服务架构下的通信方法的另一种示例流程图。本示例性实施例说明会话能力注册过程和会话实例的另一种订阅方式。
如图9所示，本实施例提供的微服务架构下的通信方法包括步骤S201至步骤S210。
步骤S201、执行体A在上电初始化时，读取预先配置的能力描述文件，其中，能力描述文件可以是json格式。
例如，执行体A的能力描述文件可以包括以下内容：
Figure PCTCN2019115776-appb-000003
Figure PCTCN2019115776-appb-000004
步骤S102、执行体B在上电初始化时，读取预先配置的能力描述文件，其中，能力描述文件可以是json格式。
例如，执行体B的能力描述文件可以包括以下内容：
Figure PCTCN2019115776-appb-000005
Figure PCTCN2019115776-appb-000006
其中，本申请对于步骤S201和步骤S202的先后顺序并不限定。
步骤S203、执行体A向通信服务器发送会话注册请求(register request)消息；其中，注册请求消息中可以携带执行体A的通信地址(比如包括IP地址和端口号)、能订阅的会话(比如，会话XYZ)、能发布的会话(比如，会话XYZ)以及会话XYZ的属性。
步骤S204、通信服务器收到执行体A的会话注册请求消息后，查找自身存储的会话订阅发布关系。
本实施例中，由于此时没有其它执行体在已注册状态，因此，执行体A没有关联方，即没有对端执行体；通信服务器可以把执行体A的会话注册请求消息中携带的信息进行保存，并更新存储的会话订阅发布关系。
步骤S205、通信服务器给执行体A返回会话注册响应(register ack)消息。
步骤S206、执行体B向通信服务器发送会话注册请求消息，其中可以携带执行体B的通信地址(可以包括IP地址和端口号)、能发布的会话(比如，会话XYZ)、能订阅的会话(比如会话XYZ)以及会话XYZ的属性。
步骤S207、通信服务器收到执行体B的会话注册请求消息后，存储执行体B的会话注册请求消息中携带的信息，并查找会话订阅发布关系；在本实施例中，通信服务器会发现执行体A拥有会话XYZ的发布能力，而执行体B拥有会话XYZ的订阅能力，则可以确定执行体A和执行体B之间基于会话XYZ存在会话订阅发布关系，然后可以更新会话订阅发布关系。
步骤S208、通信服务器给执行体B返回会话注册响应消息，其中，会话注册响应消息中可以携带执行体A的通信地址。
步骤S209、通信服务器在执行体B的注册过程完成后，需要将执行体B的通信地址立即推送给执行体A；在本实施例中，通信服务器可以给 执行体A发送会话刷新(session refresh)消息，这样执行体A知道了执行体B的通信地址。
通过上述步骤，完成了执行体A和执行体B在通信服务器的会话能力注册过程。
步骤S210、假定执行体B是接收端，执行体B中的某一接收实体要订阅某一会话实例，由于执行体B已经通过注册流程知道了与自己相关的所有对端执行体(包括执行体A)，则执行体B可以直接广播订阅请求(sub request)消息给所有相关的对端执行体(即不通过通信服务器)，订阅请求消息中可以携带该接收实体要订阅的会话类型标识(sessiontype)以及一个或多个会话实例(sessionInst)。
其中，执行体A收到通信服务器的订阅通知消息后，可以将执行体B要订阅的会话实例的信息存储到自己的订阅缓存中。
通过上述过程完成了会话能力注册和会话实例的订阅过程，执行体A和执行体B之间可以传输通信消息。
图10为本申请实施例提供的微服务架构下的通信方法的另一种示例流程图。本示例性实施例中，执行体没有设置粘滞订阅缓存，执行体注册的会话的属性包括会话负载均衡类型，且会话负载均衡类型为轮询。
如图10所示，本实施例提供的微服务架构下的通信方法包括步骤S301至步骤S317。
步骤S301、执行体A执行会话能力注册流程。
步骤S302、执行体B1执行会话能力注册流程。
步骤S303、执行体B2执行会话能力注册流程。
需要说明的是，执行体A、执行体B1及执行体B2的会话能力注册流程可以参照图8中的步骤S101至步骤S109的描述，故于此不再赘述。而且，本申请并不限定步骤S301、步骤S302及步骤S303的先后顺序。
步骤S304、执行体B1注册完成后，执行体B1中的实体workB1_1 调用订阅接口，sub(XYZ，>)，这里订阅的会话实例是>，表示实体workB1_1可以接收会话XYZ下的任何会话实例的消息。而且，执行体B1更新自己的绑定缓存，即在绑定缓存中记录实体workB1_1、会话XYZ以及会话实例的对应关系。
步骤S305、执行体B1向通信服务器发送订阅请求消息，其中携带执行体B1要订阅的会话和会话实例的信息，比如(XYZ，>)。
步骤S306、通信服务器接收执行体B1的订阅请求消息后，根据会话类型标识XYZ查询会话订阅发布关系，发现有1个相关的发送者即执行体A，向执行体A发送订阅通知消息，将执行体B1的信息(比如，通信地址)以及执行体B1要订阅的会话和会话实例的信息，比如以(XYZ，>，B1)的格式，推送给执行体A。
步骤S307、执行体A接收到订阅通知消息后，在自己的订阅缓存中记录执行体B1及执行体B1订阅的会话XYZ和会话实例。
步骤S308、执行体B2注册完成后，执行体B2中的实体workB2_1调用订阅接口，sub(XYZ，>)，这里订阅的会话实例是>，表示实体workB2_1可以接收会话XYZ下的任何会话实例的消息。而且，执行体B2更新自己的绑定缓存，即在绑定缓存中记录实体workB2_1、会话XYZ以及会话实例的对应关系。
步骤S309、执行体B2向通信服务器发送订阅请求消息，其中携带执行体B2要订阅的会话和会话实例的信息，比如(XYZ，>)。
步骤S310、通信服务器接收执行体B2的订阅请求消息后，根据会话类型标识XYZ查询会话订阅发布关系，发现有1个相关的发送者即执行体A，向执行体A发送订阅通知消息，将执行体B2的信息(比如，通信地址)以及执行体B2要订阅的会话和会话实例的信息，比如以(XYZ，>，B2)的格式，推送给执行体A。
步骤S311、执行体A接收到订阅通知消息后，在自己的订阅缓存中记录执行体B2及执行体B2订阅的会话XYZ和会话实例。
步骤S312、执行体A中的实体workA_1调用发布接口发布第一消息，比如pub(XYZ，abc.123，msgdata1)。
步骤S313、执行体A根据发布接口中携带的会话和会话实例的信息(XYZ，abc.123)查询订阅缓存；由于执行体B1和B2订阅的会话实例是>，所以只要能匹配到会话类型标识XYZ就可以，执行体A能在订阅缓存中找到2个订阅方即执行体B1和执行体B2；由于会话XYZ的会话负载均衡类型是轮询策略，则执行体A可以选择执行体B1作为对端执行体。
步骤S314、执行体A通过socket接口发送第一消息给执行体B1。
步骤S315、执行体A中的workA_1再调用发布接口发布第二消息，比如pub(XYZ，abc.456，msgdata2)。
步骤S316、执行体A根据发布接口中携带的会话和会话实例的信息(XYZ，abc.456)查询订阅缓存；由于执行体B1和B2订阅的会话实例是>，所以只要能匹配到会话类型标识XYZ就可以，执行体A能在订阅缓存中找到2个订阅方即执行体B1和执行体B2，由于会话负载均衡类型是轮询策略，且在步骤S313中执行体A已经选择过执行体B1，因此，这一次执行体A可以选择执行体B2作为对端执行体。
步骤S317、执行体A通过socket接口发送第二消息给执行体B2。
需要说明的是，本实施例中，对于执行体B1和执行体B2订阅会话实例的先后顺序并不限定。
图11为本申请实施例提供的微服务架构下的通信方法的另一种示例流程图。本示例性实施例中，执行体包括粘滞订阅缓存和粘滞绑定缓存。
在本示例性实施例中，执行体A和执行体B1、B2的能力描述文件可以是json格式。
例如，执行体A的能力描述文件可以包括：
Figure PCTCN2019115776-appb-000007
Figure PCTCN2019115776-appb-000008
例如，执行体B1、B2的能力描述文件分别可以包括：
Figure PCTCN2019115776-appb-000009
Figure PCTCN2019115776-appb-000010
如图11所示，本实施例提供的微服务架构下的通信方法包括步骤S401至步骤S422。
步骤S401、执行体A执行会话能力注册流程。
步骤S402、执行体B1执行会话能力注册流程。
步骤S403、执行体B2执行会话能力注册流程。
需要说明的是，执行体A、执行体B1及执行体B2的会话能力注册流程可以参照图8中的步骤S101至步骤S109的描述，故于此不再赘述。而且，本申请并不限定步骤S401、步骤S402及步骤S403的先后顺序。
步骤S404、执行体B1注册完成后，执行体B1中的实体workB1_1调用订阅接口，sub(XYZ，>)，这里订阅的会话实例是>，表示实体workB1_1可以接收会话XYZ下的任何会话实例的消息。而且，执行体B1更新自己的绑定缓存，即在绑定缓存中记录实体workB1_1、会话XYZ以及会话实例的对应关系。
步骤S405、执行体B1向通信服务器发送订阅请求消息，其中携带执行体B1要订阅的会话和会话实例的信息，比如(XYZ，>)。
步骤S406、通信服务器收到执行体B1的订阅请求消息后，根据会话类型标识XYZ查询会话订阅发布关系，发现有1个相关的发送者即执行体A，然后，通信服务器向执行体A发送订阅通知消息，将执行体B1的信息(比如，通信地址)以及执行体B1要订阅的会话和会话实例的信息，比如(XYZ，>，B1)，推送给执行体A。
步骤S407、执行体A接收到订阅通知消息后，在自己的订阅缓存中记录执行体B1及执行体B1订阅的会话XYZ和会话实例。
步骤S408、执行体B2注册完成后，执行体B2中的实体workB2_1 调用订阅接口，sub(XYZ，>)，这里订阅的会话实例是>，表示实体workB2_1可以接收会话XYZ下的任何会话实例的消息。而且，执行体B2更新自己的绑定缓存，即在绑定缓存中记录实体workB2_1、会话XYZ以及会话实例的对应关系。
步骤S409、执行体B2向通信服务器发送订阅请求消息，其中携带执行体B1要订阅的会话和会话实例的信息，比如(XYZ，>)。
步骤S410、通信服务器收到执行体B2的订阅请求消息，根据会话类型标识XYZ查询会话订阅发布关系，发现有1个相关的发送者即执行体A，向执行体A发送订阅通知消息，将执行体B2的信息(比如，通信地址)以及执行体B2要订阅的会话和会话实例的信息，比如以(XYZ，>，B2)的格式，推送给执行体A。
步骤S411、执行体A接收到订阅通知消息后，在自己的订阅缓存中记录执行体B2及执行体B2订阅的会话XYZ和会话实例。
步骤S412、执行体A中的实体workA_1调用发布接口发布第一消息，比如，pub(XYZ，abc.123，msg1)。
步骤S413、执行体A根据发布接口中携带的会话和会话实例的信息(XYZ，abc.123)查询订阅缓存；由于执行体B1和B2订阅的会话实例是>，所以只要能匹配到会话类型标识XYZ就可以，执行体A能在订阅缓存中找到2个订阅方即执行体B1和执行体B2；由于会话XYZ的会话负载均衡类型是轮询策略，则执行体A可以选择执行体B1作为对端执行体。
步骤S414、执行体A通过socket接口发送第一消息给执行体B1。
步骤S415、执行体A会把会话和会话实例的信息(XYZ，abc.123)和执行体B1的关系作为一条粘滞记录插入到自己的粘滞订阅缓存中。
步骤S416、执行体B1收到第一消息后，解开消息头，获得会话和会话实例的信息(XYZ，abc.123)以及发送方(即执行体A)的通信地址，将这些信息插入到自己的粘滞订阅缓存中；执行体B1查询自己的绑定缓 存，在绑定缓存中查找与第一消息携带的会话和会话实例的信息匹配的接收实体；在本实施例中，执行体B1在绑定缓存中查找到实体workB1_1，并将第一消息投递给实体workB1_1，同时将实体workB1_1与第一消息携带的会话和会话实例的信息作为一条粘滞记录插入到执行体B1的粘滞绑定缓存中。
步骤S417、执行体B1需要给执行体A1返回第二消息，可以通过调用发布接口发送第二消息，比如，pub(XYZ，abc.123，msg2)。
步骤S418、执行体B1根据发布接口中携带的会话和会话实例的信息(XYZ，abc.123)查询自己的粘滞订阅缓存，查找到匹配的对端执行体(即执行体A)的通信地址，则执行体B1可以直接将第二消息发送给执行体A，不用执行在订阅缓存中根据轮询策略进行匹配的流程。
步骤S419、执行体B1通过socket接口发送第二消息给执行体A。
步骤S420、执行体A通过调用发布接口发布第三消息，比如，pub(XYZ，abc.123，msg3)。
步骤S421、由于在步骤S415中，执行体A在自己的粘滞订阅缓存中记录了(XYZ，abc.123)和执行体B1的关系，因此，执行体A通过查询自己的粘滞订阅缓存，可以找到执行体B1的通信地址。
步骤S422、执行体A通过socket接口发送第三消息给执行体B1。
需要说明的是，本实施例中，对于执行体B1和执行体B2订阅会话实例的先后顺序并不限定。
图12为本申请实施例提供的微服务架构下的通信方法的另一种示例流程图。本示例性实施例中，执行体包括粘滞订阅缓存和粘滞绑定缓存，且通过粘滞配额限制了粘滞订阅缓存和粘滞绑定缓存中会话XYZ下面的会话实例的个数。
在本示例性实施例中，执行体A和执行体B的能力描述文件可以参照图11所示实施例内执行体A和执行体B1的能力描述文件，故于此不再赘述。
如图12所示，本实施例提供的通信方法包括步骤S501至步骤S516。
步骤S501、执行体A执行会话能力注册流程。
步骤S502、执行体B执行会话能力注册流程。
需要说明的是，执行体A和执行体B的会话能力注册流程可以参照图8中的步骤S101至步骤S109的描述，故于此不再赘述。而且，本申请并不限定步骤S501和步骤S502的先后顺序。
步骤S503、执行体B在注册完成后，执行体B调用订阅接口，sub(XYZ，>，quota)，其中订阅的会话实例是>，表示可以接收会话XYZ下的任何会话实例的消息，quota表示粘滞配额；说明执行体B可以订阅会话XYZ下面的任何会话实例，但是会话实例的数量有限制，最多不能超过quota表示的数目。
步骤S504、执行体B向通信服务器发送订阅请求消息，其中携带执行体B要订阅的会话和会话实例的信息，比如(XYZ，>，quota)。
步骤S505、通信服务器收到执行体B的订阅请求消息，根据会话类型标识XYZ查询会话订阅发布关系，发现有1个相关的发送者即执行体A，然后，通信服务器向执行体A发送订阅通知消息，将执行体B的地址信息以及执行体B要订阅的会话和会话实例的信息，比如以(XYZ，>，quota，B)的形式，推送给执行体A。
步骤S506、执行体A接收到订阅通知消息后，在自己的订阅缓存中记录执行体B及执行体B订阅的会话XYZ和会话实例。
步骤S507、执行体A中的实体workA_1调用发布接口发布第一消息，比如，pub(XYZ，sessionInst1，msg1)。
步骤S508、执行体A根据发布接口中携带的会话和会话实例的信息(XYZ，sessionInst1)作为关键字，在粘滞订阅缓存中查找关键字匹配的对端执行体；如果在粘滞订阅缓存中查找到匹配的对端执行体，则直接发送第一消息给该对端执行体；如果查不到，则执行步骤S509。
在本示例性实施例中，以执行体A在粘滞订阅缓存中没有查到关键字匹配的对端执行体为例进行说明。
步骤S509、执行体A在订阅缓存中查找关键字匹配的对端执行体；本实施例中，由于执行体B订阅的会话实例为>，因此执行体A在订阅缓存中可以选择执行体B作为接收端。
步骤S510、执行体A通过socket接口将第一消息传输给执行体B。
步骤S511、执行体A会把会话和会话实例的信息(XYZ，sessionInst1)和执行体B的关系作为一条粘滞记录插入到自己的粘滞订阅缓存中。
步骤S512、执行体B收到第一消息后，以第一消息中携带的会话和会话实例的信息(XYZ，sessionInst1)作为关键字，在自己的粘滞绑定缓存中查找关键字匹配的上层实体；如果查找到，则将第一消息投递给本执行体的上层实体；如果查不到，则从绑定缓存查找关键字匹配的上层实体。其中，执行体B以第一消息携带的会话和会话实例的信息(XYZ，sessionInst1)作为关键字，在绑定缓存中查找关键字匹配的上层实体，将查找到的本执行体内的上层实体作为接收实体，将第一消息传递给该接收实体；同时，执行体B可以将确定的接收实体与第一消息携带的会话和会话实例的信息的匹配关系作为一条粘滞记录插入到执行体B的粘滞绑定缓存中。
步骤S513、执行体B可以将第一消息的发送者的信息(pubInfo，即执行体A的信息)与第一消息携带的会话和会话实例的信息，比如，以(pubInfo，XYZ，sessionInst1)的形式，作为一条粘滞记录插入到自己的粘滞订阅缓存中。
步骤S514、执行体B判断自己的粘滞订阅缓存中会话XYZ下，粘滞记录的数量是否超过了quota，如果粘滞记录的数量超过quota，则调用粘滞清除接口清除粘滞订阅缓存和粘滞绑定缓存中会话XYZ相关的所有粘滞记录。
步骤S515、执行体B向执行体A发送粘滞清除消息，通知执行体A 清除会话XYZ相关的所有粘滞记录。
步骤S516、执行体A接收到粘滞清除消息后，清除粘滞订阅缓存和粘滞绑定缓存中会话XYZ相关的所有粘滞记录，同时会在订阅缓存中将执行体B打上锁定(block)标记。
本实施例中，执行体A继续发送会话XYZ的其他会话实例(比如，sessionInst2)的通信消息时，在订阅缓存中匹配到执行体B时，由于执行体B被打上了block标记，因此，执行体A不会再选择执行体B，而是选择其它订阅了该会话的订阅者。
本申请实施例所提供的微服务架构下的通信方法及系统，可以给以微服务为架构的通信软件提供一个高性能、低时延的通信平台。本申请实施例提出了会话和会话实例的概念，通过会话实例来区分同一个会话中的多个呼叫。在单软体架构改造成微服务的过程中，通过两个阶段的发现过程(包括会话能力注册过程以及会话实例的订阅过程)，不仅找到了对端地址，还定位到了呼叫实例。而且，业务通过会话的属性设置，然后通过消息收发的匹配，可以达到发送时的选择和均衡；在微服务的弹性伸缩等流程中，业务可以只需要关心策略，实际的实施对业务透明化。而且，本申请实施例中提出的粘滞机制(即设置粘滞订阅缓存和粘滞绑定缓存)，不仅支持了微服务之间的通信解耦，同时将会话实例和相关的消息序列关联起来，这样用户级通信中用户上下文在一定时间内的消息交互过程中保持了一致。另外，还可以通过设置粘滞配额来限制会话实例的处理数目。
图13为本申请实施例提供的通信设备的示意图。如图13所示，本申请实施例提供一种通信设备1301，包括：第一存储器1302和第一处理器1303，第一存储器1302适于存储微服务架构下的通信程序，该通信程序被第一处理器1303执行时实现上述实施例提供的通信方法的步骤，比如图4或图5或图6所示的步骤。本领域技术人员可以理解，图13中示出的结构，仅仅是与本申请方案相关的部分结构的示意图，并不构成对本申请方案所应用于其上的通信设备1301的限定，通信设备1301可以包括比 图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
其中，第一处理器1303可以包括但不限于微处理器(MCU，Microcontroller Unit)或可编程逻辑器件(FPGA，Field Programmable Gate Array)等的处理装置。第一存储器1302可设置为存储应用软件的软件程序以及模块，如本实施例中的通信方法对应的程序指令或模块，第一处理器1303通过运行存储在第一存储器1302内的软件程序以及模块，从而执行各种功能应用以及数据处理，比如实现本实施例提供的通信方法。第一存储器1302可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些示例中，第一存储器1302可包括相对于第一处理器1303远程设置的存储器，这些远程存储器可以通过网络连接至通信设备1301。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
图14为本申请实施例提供的通信服务器的示意图。如图14所示，本申请实施例提供一种通信服务器1401，包括：第二存储器1402和第二处理器1403，第二存储器1402适于存储微服务架构下的通信程序，该通信程序被第二处理器1403执行时实现上述实施例提供的通信方法的步骤，比如图7所示的步骤。本领域技术人员可以理解，图14中示出的结构，仅仅是与本申请方案相关的部分结构的示意图，并不构成对本申请方案所应用于其上的通信服务器1401的限定，通信服务器1401可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
其中，第二处理器1403可以包括但不限于微处理器(MCU，Microcontroller Unit)或可编程逻辑器件(FPGA，Field Programmable Gate Array)等的处理装置。第二存储器1402可设置为存储应用软件的软件程序以及模块，如本实施例中的通信方法对应的程序指令或模块，第二处理器1403通过运行存储在第二存储器1402内的软件程序以及模块，从而执行各种功能应用以及数据处理，比如实现本实施例提供的通信方法。第二存储器1402可包括高速随机存储器，还可包括非易失性存储器，如一个 或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些示例中，第二存储器1402可包括相对于第二处理器1403远程设置的存储器，这些远程存储器可以通过网络连接至通信服务器1401。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
此外，本申请实施例还提供一种计算机可读介质，存储有微服务架构下的通信程序，该通信程序被处理器执行时实现上述实施例提供的通信方法的步骤，比如，图4至图7中任一实施例所述的步骤。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
工业实用性
如上所述，本发明实施例提供的一种微服务架构下的通信方法及系统 具有以下有益效果：可以给以微服务架构改造的通信软件提供高性能、低时延的通信方案。

Claims (23)

  1. 一种微服务架构下的通信方法，包括：
    执行体向通信服务器发送会话注册请求消息；其中，所述会话注册请求消息中至少携带所述执行体的信息、待注册的会话集合及所述会话集合中任一会话的属性；所述执行体为微服务架构下的最小通信单位，所述会话为微服务之间的通信连接，所述会话包括至少一个会话实例；
    所述执行体接收所述通信服务器返回的与所述执行体之间存在会话订阅发布关系的对端执行体的信息；
    所述执行体向所述通信服务器或所述对端执行体订阅已注册会话的会话实例；或者，所述执行体从所述通信服务器或所述对端执行体接收所述对端执行体订阅的已注册会话的会话实例的信息。
  2. 根据权利要求1所述的方法，其中，所述方法还包括：
    所述执行体在发布通信消息时，根据所述通信消息携带的会话和会话实例的信息以及所述会话的属性，确定接收所述通信消息的对端执行体，并向所确定的对端执行体发送所述通信消息。
  3. 根据权利要求2所述的方法，其中，所述执行体包括订阅缓存，用于存储向所述执行体订阅已注册会话的会话实例的对端执行体的信息、所述对端执行体订阅的会话和会话实例的信息；
    所述根据所述通信消息携带的会话和会话实例的信息以及所述会话的属性，确定接收所述通信消息的对端执行体，包括：
    所述执行体根据所述通信消息携带的会话和会话实例的信息以及所述会话的属性，从所述订阅缓存中选择订阅所述会话和会话实例的一个对端执行体，作为接收所述通信消息的对端执行体。
  4. 根据权利要求3所述的方法，其中，所述执行体还包括粘滞订阅缓存；
    所述从所述订阅缓存中选择订阅所述会话和会话实例的一个对端 执行体，作为接收所述通信消息的对端执行体之后，所述方法还包括：
    在所述粘滞订阅缓存中增加所述通信消息携带的会话和会话实例的信息与所述对端执行体的匹配关系。
  5. 根据权利要求4所述的方法，其中，所述根据所述通信消息携带的会话和会话实例的信息以及所述会话的属性，确定接收所述通信消息的对端执行体，包括：
    所述执行体从所述粘滞订阅缓存中查找与所述通信消息携带的会话和会话实例的信息匹配的对端执行体；
    当所述执行体从所述粘滞订阅缓存查找到匹配的对端执行体，则确定所述查找到的对端执行体为接收所述通信消息的对端执行体；
    当所述执行体没有从所述粘滞订阅缓存查找到匹配的对端执行体，则根据所述通信消息携带的会话和会话实例的信息以及所述会话的属性，从所述订阅缓存中选择订阅所述会话和会话实例的一个对端执行体，作为接收所述通信消息的对端执行体。
  6. 根据权利要求3至5中任一项所述的方法，其中，所述会话的属性包括：会话负载均衡类型、实例匹配规则；
    所述根据所述通信消息携带的会话和会话实例的信息以及所述会话的属性，从所述订阅缓存中选择订阅所述会话和会话实例的一个对端执行体，作为接收所述通信消息的对端执行体，包括：
    根据所述通信消息携带的会话的实例匹配规则，从所述订阅缓存中查找订阅所述会话和会话实例的对端执行体；根据所述会话的会话负载均衡类型，从查找到的对端执行体中选择一个作为接收所述通信消息的对端执行体。
  7. 根据权利要求1所述的方法，其中，所述方法还包括：
    所述执行体接收到通信消息后，根据所述通信消息携带的会话和会话实例的信息，确定在所述执行体内接收所述通信消息的实体，并 向所确定的实体投递所述通信消息。
  8. 根据权利要求7所述的方法，其中，所述执行体包括绑定缓存，用于存储所述执行体内的实体与订阅的会话和会话实例的匹配关系；
    所述根据所述通信消息携带的会话和会话实例的信息，确定在所述执行体内接收所述通信消息的实体，包括：
    所述执行体根据所述通信消息携带的会话和会话实例的信息，从所述绑定缓存中查找订阅所述会话和会话实例的实体，并从查找到的实体中选择一个作为接收所述通信消息的实体。
  9. 根据权利要求8所述的方法，其中，所述执行体还包括粘滞绑定缓存；
    所述执行体根据所述通信消息携带的会话和会话实例的信息，从所述绑定缓存中查找订阅所述会话和会话实例的实体，并从查找到的实体中选择一个作为接收所述通信消息的实体之后，所述方法还包括：
    所述执行体在所述粘滞绑定缓存中增加从所述绑定缓存内查找到的所述实体与所述会话和会话实例的匹配关系，作为一条粘滞记录。
  10. 根据权利要求9所述的方法，其中，所述根据所述通信消息携带的会话和会话实例的信息，确定在所述执行体内接收所述通信消息的实体，包括：
    所述执行体接收到携带会话和会话实例的信息的通信消息后，从所述粘滞绑定缓存中查找与所述会话和会话实例匹配的实体；
    当所述执行体在所述粘滞绑定缓存中查找到匹配的实体，则确定所述查找到的实体为接收所述通信消息的实体；
    当所述执行体在所述粘滞绑定缓存中没有查找到匹配的实体，则根据所述通信消息携带的会话和会话实例的信息，从所述绑定缓存中查找订阅所述会话和会话实例的实体，并从查找到的实体中选择一个作为接收所述通信消息的实体。
  11. 根据权利要求9所述的方法，其中，所述执行体还包括粘滞订阅缓存；
    所述执行体在所述粘滞绑定缓存中增加从所述绑定缓存内查找到的所述实体与所述会话和会话实例的匹配关系后，所述方法还包括：
    所述执行体在所述粘滞订阅缓存中增加所述通信消息携带的会话和会话实例的信息与发送所述通信消息的对端执行体的匹配关系，作为所述粘滞订阅缓存中的一条粘滞记录；
    当所述粘滞订阅缓存内所述会话相关的粘滞记录的数量大于预设的粘滞配额，则所述执行体清除所述粘滞订阅缓存和所述粘滞绑定缓存中所述会话相关的粘滞记录，并通知所述对端执行体清除所述会话相关的粘滞记录。
  12. 根据权利要求1所述的方法，其中，所述执行体向所述通信服务器或所述对端执行体订阅已注册会话的会话实例，包括：
    所述执行体向所述通信服务器发送订阅请求消息，其中，所述订阅请求消息中携带所述执行体订阅的会话和会话实例的信息；由所述通信服务器将所述执行体订阅的会话和会话实例的信息发送给所述对端执行体；或者，
    所述执行体广播订阅请求消息给所述对端执行体；其中，所述订阅请求消息中携带所述执行体订阅的会话和会话实例的信息。
  13. 根据权利要求1所述的方法，其中，所述执行体向通信服务器发送会话注册请求消息之后，所述方法还包括：
    所述执行体接收所述通信服务器返回的所述执行体与所述对端执行体之间建立所述会话订阅发布关系所依据的已注册会话的信息。
  14. 一种微服务架构下的通信方法，包括：
    通信服务器根据至少一个执行体发送的会话注册请求消息，确定不同执行体之间的会话订阅发布关系；其中，所述执行体为微服务架 构下的最小通信单元；所述会话注册请求消息中至少携带所述执行体的信息、所述执行体待注册的会话集合及所述会话集合中任一会话的属性；所述会话为微服务之间的通信连接，所述会话包括至少一个会话实例；
    所述通信服务器向所述执行体返回与所述执行体之间存在会话订阅发布关系的对端执行体的信息；
    所述通信服务器接收任一执行体发送的订阅请求消息后，确定与所述执行体之间存在会话订阅发布关系的对端执行体；其中，所述订阅请求消息携带所述执行体订阅的会话和会话实例的信息；
    所述通信服务器将所述执行体订阅的会话和会话实例的信息发送给所述对端执行体。
  15. 根据权利要求14所述的方法，其中，所述通信服务器根据至少一个执行体发送的会话注册请求消息，确定不同执行体之间的会话订阅发布关系之后，所述方法还包括：所述通信服务器向所述执行体返回所述执行体与所述对端执行体之间建立所述会话订阅发布关系所依据的已注册会话的信息。
  16. 根据权利要求14所述的方法，其中，所述会话的属性包括以下至少一项：会话负载均衡类型、实例匹配规则。
  17. 一种微服务架构下的通信系统，包括：通信服务器以及至少两个执行体；其中，所述执行体为微服务架构下的最小通信单位，一个微服务对应一个或多个执行体；
    任一所述执行体适于向所述通信服务器发送会话注册请求消息，接收所述通信服务器返回的与所述执行体之间存在会话订阅发布关系的对端执行体的信息；其中，所述会话注册请求消息中至少携带所述执行体的信息、所述执行体待注册的会话集合及所述会话集合中任一会话的属性；所述会话为微服务之间的通信连接，所述会话包括至少一个会话实例；
    所述执行体还适于向所述通信服务器或所述对端执行体订阅已注册会话的会话实例，或者，从所述通信服务器或所述对端执行体接收所述对端执行体订阅的已注册会话的会话实例的信息。
  18. 根据权利要求17所述的通信系统，其中，所述通信服务器适于根据接收到的会话注册请求消息，确定不同执行体之间的会话订阅发布关系。
  19. 根据权利要求17所述的通信系统，其中，所述通信服务器适于接收任一执行体发送的订阅请求消息，确定与所述执行体之间存在会话订阅发布关系的对端执行体；其中，所述订阅请求消息携带所述执行体订阅的会话和会话实例的信息；所述通信服务器还适于将所述执行体订阅的会话和会话实例的信息发送给所述对端执行体。
  20. 根据权利要求17所述的通信系统，其中，所述执行体还适于在发布通信消息时，根据所述通信消息携带的会话和会话实例的信息以及所述会话的属性，确定接收所述通信消息的对端执行体，并向所确定的对端执行体发送所述通信消息。
  21. 一种通信设备，包括：第一存储器和第一处理器，所述第一存储器设置为存储微服务架构下的通信程序，所述通信程序被所述第一处理器执行时实现如权利要求1至13中任一项所述的通信方法的步骤。
  22. 一种通信服务器，包括：第二存储器和第二处理器，所述第二存储器设置为存储微服务架构下的通信程序，所述通信程序被所述第二处理器执行时实现如权利要求14至16中任一项所述的通信方法的步骤。
  23. 一种计算机可读介质，存储有微服务架构下的通信程序，所述通信程序被处理器执行时实现如权利要求1至13中任一项所述的通信方法的步骤。
PCT/CN2019/115776 2018-11-05 2019-11-05 一种微服务架构下的通信方法及系统 WO2020094021A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/290,349 US20210314406A1 (en) 2018-11-05 2019-11-05 Communication Method and System under Micro-Service Architecture
EP19882531.7A EP3879787A4 (en) 2018-11-05 2019-11-05 COMMUNICATION PROCEDURES AND SYSTEM UNDER MICRO-SERVICE ARCHITECTURE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811306618.5 2018-11-05
CN201811306618.5A CN111147534B (zh) 2018-11-05 2018-11-05 一种微服务架构下的通信方法及系统

Publications (1)

Publication Number Publication Date
WO2020094021A1 true WO2020094021A1 (zh) 2020-05-14

Family

ID=70515602

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/115776 WO2020094021A1 (zh) 2018-11-05 2019-11-05 一种微服务架构下的通信方法及系统

Country Status (4)

Country Link
US (1) US20210314406A1 (zh)
EP (1) EP3879787A4 (zh)
CN (1) CN111147534B (zh)
WO (1) WO2020094021A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112732229A (zh) * 2020-12-31 2021-04-30 中山大学 一种基于微服务架构的多语言学习系统

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2586913B (en) * 2020-06-05 2021-11-10 Iotech Systems Ltd Data processing
CN111935103B (zh) * 2020-07-22 2023-04-07 河南信大网御科技有限公司 执行体服务功能递归拟态化系统及方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160112475A1 (en) * 2014-10-21 2016-04-21 Twilio, Inc. System and method for providing a micro-services communication platform
CN106411933A (zh) * 2016-11-15 2017-02-15 深圳市彬讯科技有限公司 一种可进行服务治理与语言调用的轻量级rpc框架
CN106453288A (zh) * 2016-09-29 2017-02-22 上海和付信息技术有限公司 一种支持异步模式的分布式微服务框架系统及其实现方法
CN107635022A (zh) * 2016-07-18 2018-01-26 华为软件技术有限公司 跨内外网服务访问方法和装置
CN108206852A (zh) * 2016-12-20 2018-06-26 杭州华为数字技术有限公司 一种微服务框架下的基于会话的服务实例管理方法及设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060253455A1 (en) * 2005-05-05 2006-11-09 Microsoft Corporation Extensible type-based publication / subscription services
CN1972279B (zh) * 2005-11-25 2010-08-11 华为技术有限公司 一种会话发起协议资源事件包获取方法
US7793140B2 (en) * 2007-10-15 2010-09-07 International Business Machines Corporation Method and system for handling failover in a distributed environment that uses session affinity
CN106612188A (zh) * 2015-10-21 2017-05-03 中兴通讯股份有限公司 一种基于微服务架构扩展软件功能的方法及装置
WO2018005613A1 (en) * 2016-06-28 2018-01-04 Solano Labs, Inc. Systems and methods for efficient distribution of stored data objects
CN106790567A (zh) * 2016-12-27 2017-05-31 东华互联宜家数据服务有限公司 业务支撑系统和方法
CN108650262B (zh) * 2018-05-09 2020-12-01 聚龙股份有限公司 一种基于微服务架构的云平台扩展方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160112475A1 (en) * 2014-10-21 2016-04-21 Twilio, Inc. System and method for providing a micro-services communication platform
CN107635022A (zh) * 2016-07-18 2018-01-26 华为软件技术有限公司 跨内外网服务访问方法和装置
CN106453288A (zh) * 2016-09-29 2017-02-22 上海和付信息技术有限公司 一种支持异步模式的分布式微服务框架系统及其实现方法
CN106411933A (zh) * 2016-11-15 2017-02-15 深圳市彬讯科技有限公司 一种可进行服务治理与语言调用的轻量级rpc框架
CN108206852A (zh) * 2016-12-20 2018-06-26 杭州华为数字技术有限公司 一种微服务框架下的基于会话的服务实例管理方法及设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3879787A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112732229A (zh) * 2020-12-31 2021-04-30 中山大学 一种基于微服务架构的多语言学习系统

Also Published As

Publication number Publication date
CN111147534A (zh) 2020-05-12
US20210314406A1 (en) 2021-10-07
EP3879787A1 (en) 2021-09-15
EP3879787A4 (en) 2021-10-13
CN111147534B (zh) 2022-12-16

Similar Documents

Publication Publication Date Title
CN109618005B (zh) 调用服务器的方法和代理服务器
WO2020094021A1 (zh) 一种微服务架构下的通信方法及系统
US10708376B2 (en) Message bus service directory
WO2019095889A1 (zh) 通过nrf进行nf发现的方法、设备及可读存储介质
CN101356769B (zh) 一种在对等内容分布云中的一节点上形成分组的方法
WO2019128682A1 (zh) 融合消息系统及消息处理方法
US20120323990A1 (en) Efficient state reconciliation
EP3041198B1 (en) Finding services in a service-oriented architecture (soa) network
JP2020537449A (ja) 通信ネットワークにおけるサービス登録
WO2014067311A1 (zh) 资源订阅方法及装置
CN113452592B (zh) 混合云架构下的跨云数据访问方法及装置
JP2023535562A (ja) ネットワーク機能発見サービス向上を提供するための方法、システムおよびコンピュータ読取可能媒体
US10873640B2 (en) Information exchange method and server
CN110753129A (zh) 消息传输方法、系统、装置、设备及计算机可读存储介质
US11647100B2 (en) Resource query method and apparatus, device, and storage medium
JP2013542681A (ja) コンテンツ中心のネットワーク環境でグループ変更に関する情報を用いるコンテンツ共有方法及び装置
CN108965359B (zh) 通信方法、通信装置、可读介质和电子设备
CN110933188A (zh) 远程服务的调用方法、系统、服务器及存储介质
CN114650291A (zh) 订阅信息处理方法及装置、服务节点、存储介质
WO2017032110A1 (zh) 一种应用消息的处理系统、方法及应用设备
WO2020098284A1 (zh) 一种通信方法、客户端设备及服务端设备
WO2017113302A1 (zh) 一种媒体服务代理的方法、设备及系统
CN114422591B (zh) 点对点通信方法、数据通信系统、计算机设备、存储介质
US20210409931A1 (en) Serverless core network architecture
US20170353818A1 (en) Method for deleting notification resource, and common service entity

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: 19882531

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019882531

Country of ref document: EP

Effective date: 20210607