CN112511611B - 节点集群的通信方法、装置、系统及电子设备 - Google Patents
节点集群的通信方法、装置、系统及电子设备 Download PDFInfo
- Publication number
- CN112511611B CN112511611B CN202011300839.9A CN202011300839A CN112511611B CN 112511611 B CN112511611 B CN 112511611B CN 202011300839 A CN202011300839 A CN 202011300839A CN 112511611 B CN112511611 B CN 112511611B
- Authority
- CN
- China
- Prior art keywords
- service
- node
- container unit
- application
- service request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
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/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
- 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
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供了一种节点集群的通信方法、系统、装置、电子设备及计算机可读存储介质;涉及通信技术领域以及云技术领域中的容器技术;方法包括:通过第一节点的网络服务接收针对第一节点的第一服务端口的第一服务请求;其中,第一节点为多个节点中的任一节点;在第一节点运行的至少一个容器单元中,确定与第一服务端口存在映射关系的容器单元,以作为第一容器单元;通过第一容器单元的私有地址信息,将第一服务请求发送至第一容器单元中运行的第一应用服务,以对第一服务请求进行响应处理。通过本申请,能够减小在节点集群中进行通信的性能损耗,提升通信质量。
Description
技术领域
本申请涉及通信技术和云技术,尤其涉及一种节点集群的通信方法、系统、装置、电子设备及计算机可读存储介质。
背景技术
随着通信技术和云技术的快速发展,应用的体量愈加庞大,一个应用往往需要跨机器的多个容器单元来协同支撑。因此,需要通过节点集群来实现对多个容器单元的编排和管理。
对于节点集群,在相关技术提供的方案中,通常是为节点集群中的每个容器单元分配一个私有地址信息,并通过对容器单元发送的服务请求进行封装和解封装,来实现跨节点的容器单元之间的通信。但是,封装和解封装会带来较大的性能损耗,导致节点通信的带宽较小,时延较大。
发明内容
本申请实施例提供一种节点集群的通信方法、系统、装置、电子设备及计算机可读存储介质,能够减小在节点集群中进行通信的性能损耗,在提升通信带宽的同时降低通信时延。
本申请实施例的技术方案是这样实现的:
本申请实施例提供一种节点集群的通信方法,所述节点集群包括多个节点,每个所述节点中运行有网络服务和至少一个容器单元,且每个所述节点中的容器单元的私有地址信息与所述节点的服务端口之间存在映射关系;
所述方法包括:
通过第一节点的网络服务接收针对所述第一节点的第一服务端口的第一服务请求;其中,所述第一节点为所述多个节点中的任一节点;
在所述第一节点运行的至少一个容器单元中,确定与所述第一服务端口存在映射关系的容器单元,以作为第一容器单元;
通过所述第一容器单元的私有地址信息,将所述第一服务请求发送至所述第一容器单元中运行的第一应用服务,以对所述第一服务请求进行响应处理。
本申请实施例提供一种节点集群的通信系统,所述节点集群包括多个节点,每个所述节点中运行有网络服务和至少一个容器单元,且每个所述节点中的容器单元的私有地址信息与所述节点的服务端口之间存在映射关系;
第一节点的网络服务,用于:
接收针对所述第一节点的第一服务端口的第一服务请求;其中,所述第一节点为所述多个节点中的任一节点;
在所述第一节点运行的至少一个容器单元中,确定与所述第一服务端口存在映射关系的容器单元,以作为第一容器单元;
通过所述第一容器单元的私有地址信息,将所述第一服务请求发送至所述第一容器单元中运行的第一应用服务;
所述第一容器单元的第一应用服务,用于:
对接收的所述第一服务请求进行响应处理。
在上述方案中,所述第一容器单元中运行有子网络服务,所述子网络服务包括数据接收队列;
所述第一节点的网络服务,还用于通过所述第一容器单元的私有地址信息,将所述第一服务请求添加至所述数据接收队列中;
所述第一容器单元的子网络服务,用于从所述数据接收队列中获取所述第一服务请求,并发送至所述第一容器单元中运行的第一应用服务。
在上述方案中,所述第一容器单元的子网络服务,还用于从所述数据接收队列中获取针对所述第一容器单元的私有地址信息的第二服务请求,并将所述第二服务请求发送至所述第一容器单元中运行的第一应用服务;
其中,所述第二服务请求的发送方为所述第一节点中区别于所述第一容器单元的第二容器单元。
在上述方案中,当所述第一服务请求为并发的多个服务请求当中的一个时,所述第一节点的网络服务还用于:
分别确定所述多个服务请求各自的优先级;
按照优先级从高到低的顺序,将所述多个服务请求依次添加至所述数据接收队列中;
其中,所述优先级包括发送方的优先级、以及请求的服务类型的优先级中的任意一种。
在上述方案中,所述子网络服务还包括多个数据发送队列;其中,每个所述数据发送队列对应区别于所述第一应用服务的一种应用服务;
所述第一容器单元的第一应用服务,还用于生成针对第二应用服务的第三服务请求,并将所述第三服务请求添加至所述第二应用服务对应的数据发送队列中;
所述第一容器单元的子网络服务,还用于从所述第二应用服务对应的数据发送队列中获取所述第三服务请求,并将所述第三服务请求发送至所述第二应用服务;
其中,所述第二应用服务的运行方包括所述节点集群外的设备、所述第一节点中区别于所述第一容器单元的第二容器单元、以及区别于所述第一节点的第二节点运行的容器单元中的任意一种。
在上述方案中,所述第一容器单元的子网络服务,还用于:
根据所述第二应用服务的标识信息在公有地址服务中进行查询处理,得到与所述第二应用服务的标识信息存在映射关系的第二节点的公有地址信息;
其中,所述公有地址服务存储有应用服务的标识信息与所述应用服务所属节点的公有地址信息之间的映射关系;
其中,所述第二节点的公有地址信息包括所述第二节点的公有地址以及服务端口;
通过所述第二节点的公有地址信息将所述第三服务请求发送至所述第二节点,以使所述第二节点的网络服务将所述第三服务请求发送至所述第二应用服务。
在上述方案中,所述第一节点的网络服务,还用于针对所述第一节点运行的每个容器单元,执行以下处理:
在所述第一节点的多个空闲的服务端口中进行选择操作;
建立所述容器单元的私有地址信息与所述选择操作得到的服务端口之间的映射关系。
在上述方案中,所述第一节点的网络服务,还用于:
获取分配给所述第一节点的私有地址段;其中,所述节点集群中不同节点的私有地址段不同;
针对所述第一节点运行的每个容器单元,执行以下处理:
对所述私有地址段进行选择操作,并将所述选择操作得到的私有地址以及设定服务端口,共同作为所述容器单元的私有地址信息;
其中,为所述第一节点中的不同容器单元选择的私有地址不同。
在上述方案中,所述第一节点的网络服务,还用于当满足以下条件中的至少之一时,将所述第一服务请求发送至所述第一容器单元中运行的第一应用服务:
所述第一容器单元的发送方白名单包括所述第一服务请求的发送方;
所述第一容器单元的请求凭证白名单包括所述第一服务请求中的请求凭证;
对所述第一服务请求的签名验证结果为成功。
在上述方案中,所述第一服务请求的发送方包括以下任意一种:
所述节点集群外的设备、所述节点集群中区别于所述第一节点的节点、区别于所述节点集群的其他节点集群的任意节点。
本申请实施例提供一种节点集群的通信装置,所述节点集群包括多个节点,每个所述节点中运行有网络服务和至少一个容器单元,且每个所述节点中的容器单元的私有地址信息与所述节点的服务端口之间存在映射关系;
所述装置包括:
接收模块,用于通过第一节点的网络服务接收针对所述第一节点的第一服务端口的第一服务请求;其中,所述第一节点为所述多个节点中的任一节点;
确定模块,用于在所述第一节点运行的至少一个容器单元中,确定与所述第一服务端口存在映射关系的容器单元,以作为第一容器单元;
发送模块,用于通过所述第一容器单元的私有地址信息,将所述第一服务请求发送至所述第一容器单元中运行的第一应用服务,以对所述第一服务请求进行响应处理。
本申请实施例提供一种电子设备,包括:
存储器,用于存储可执行指令;
处理器,用于执行所述存储器中存储的可执行指令时,实现本申请实施例提供的节点集群的通信方法。
本申请实施例提供一种计算机可读存储介质,存储有可执行指令,用于引起处理器执行时,实现本申请实施例提供的节点集群的通信方法。
本申请实施例具有以下有益效果:
在通过第一节点的网络服务,接收到针对第一节点的第一服务端口的第一服务请求时,确定与第一服务端口存在映射关系的容器单元以作为第一容器单元,进而将第一服务请求发送至第一容器单元中运行的第一应用服务。如此,在需要请求某个容器单元中的应用服务时,直接将服务请求发送至该容器单元所在节点的特定服务端口即可,无需进行数据的封装和解封装,有效地减少了通信过程中的性能损耗。
附图说明
图1是相关技术提供的节点集群的一个架构示意图;
图2是本申请实施例提供的节点集群的通信系统的一个架构示意图;
图3是本申请实施例提供的结合区块链网络的节点集群的通信系统的一个架构示意图;
图4是本申请实施例提供的服务器的一个架构示意图;
图5A是本申请实施例提供的节点集群的通信方法的一个流程示意图;
图5B是本申请实施例提供的节点集群的通信方法的一个流程示意图;
图5C是本申请实施例提供的数据发送过程的一个流程示意图;
图6是本申请实施例提供的节点集群的通信系统的一个架构示意图;
图7是本申请实施例提供的节点集群内外无法互通的一个示意图;
图8是本申请实施例提供的节点集群内外互通的一个示意图;
图9是本申请实施例提供的代理客户端之间进行通信的一个示意图;
图10是本申请实施例提供的测试结果的一个示意图;
图11是本申请实施例提供的测试结果的一个示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述,所描述的实施例不应视为对本申请的限制,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
在以下的描述中,涉及到“一些实施例”,其描述了所有可能实施例的子集,但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集,并且可以在不冲突的情况下相互结合。
在以下的描述中,所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象,不代表针对对象的特定排序,可以理解地,“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序,以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。在以下的描述中,所涉及的术语“多个”是指至少两个。
除非另有定义,本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的,不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前,对本申请实施例中涉及的名词和术语进行说明,本申请实施例中涉及的名词和术语适用于如下的解释。
1)节点集群:包括多个节点(Node),这里的节点可以是物理机器,也可以是基于虚拟化技术构建的虚拟机(Virtual Machine,VM)。在本申请实施例中,节点集群可以是Kubernetes节点集群,Kubernetes节点集群用于自动部署、扩展和管理多个节点上的容器化(Containerized)应用。其中,容器(Container)是应用程序层的抽象,它将代码及其依赖关系打包在一起,从而屏蔽节点本身的复杂性,使得应用服务在容器的基础上能够方便、快捷地部署。本申请实施例对采用的容器化技术不做限定,例如可以是Docker容器化技术。
2)容器单元(或称容器组):指节点集群中的最小可部署单元,一个容器单元包括一个或多个容器,且所有容器共享同一个网络命名空间,即具有与容器单元相同的地址信息。在本申请实施例中,容器单元用于基于内部的容器,运行特定的应用服务。在Kubernetes节点集群中,容器单元可以是Pod。
3)应用服务:与特定应用相关的服务,一个应用的正常运行往往需要基于多个应用服务之间的相互协作(相互通信)来实现,即应用服务是应用的基础和支撑。例如,某个游戏应用的应用服务可以包括账号数据服务(如用于对账号进行认证,并提供与账号相关的账号数据)及游戏界面服务(如用于提供构成游戏界面的图像素材)等。
4)网络服务:用于为多个应用服务之间的通信提供网络桥梁,即网络服务用于实现数据的接收及发送功能等。在本申请实施例中,在节点层级运行的是网络服务,在容器单元层级(即节点层级的更下一层层级)运行的是子网络服务,可以通过网络服务与子网络服务的协同运作,来实现同一节点集群中跨节点的通信、跨节点集群的通信、以及节点集群与节点集群外的设备(即独立于节点集群的设备)之间的通信。
5)地址信息:可以包括互联网协议(Internet Protocol,IP)地址和服务端口(Port),其中,服务端口是指机器上的网络端口(或称逻辑端口)。在本申请实施例中,地址信息包括私有地址信息和公有地址信息两类,其中,私有地址信息又称虚拟地址信息,仅限于特定的局域网中使用,例如为节点内的容器单元分配的私有地址信息,仅限于在该节点内部使用;而公有地址信息能够在广域网(如互联网)中使用,例如节点集群外的设备可以通过节点集群中某个节点的公有地址信息,来访问该节点。
6)公有地址服务:用于存储应用服务的标识信息与该应用服务所属节点(或者设备)的公有地址信息之间的映射关系,公有地址服务可以由独立于节点集群的服务器或者区块链网络运行。在本申请实施例,每个节点集群可以单独对应一个公有地址服务,或者多个节点集群共享同一个公有地址服务。
7)消息队列(Message Queue,MQ):在消息(数据)的传输过程中进行消息存储(可以是暂时性的消息存储),即用于充当中间人的身份。消息队列可以通过异步处理提高消息传递的性能,降低系统耦合性。在本申请实施例中,消息队列包括数据发送队列和数据接收队列两类,其中,数据发送队列对应数据的发送(Send)操作,即用于存储待发送的数据;数据接收队列对应数据的接收(Receive)操作,即用于存储接收到的数据。
8)虚拟可扩展局域网(Virtual eXtensible Local Area Network,VXLAN):一种覆盖网络(Overlay Network)技术,其原理是将发送方发送的原始数据封装在用户数据报协议(User Datagram Protocol,UDP)数据包中,并通过传输UDP数据包,实现同一VXLAN内的发送方与接收方之间的相互通信。对于UDP数据包的接收方来说,需要对UDP数据包进行解封装,从而得到其中的原始数据。
9)Flannel:针对Kubernetes节点集群的一种网络规划方式,使Kubernetes节点集群的每个节点中的每个容器单元都具有全集群唯一的虚拟IP地址(也称私有IP地址)。同时,基于创建的Flannel虚拟网卡(VXLAN类型的设备)来实现同一VXLAN中的跨节点的通信,通信过程包括数据的封装和解封装。
10)云技术(Cloud Technology):指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术。在本申请实施例中,可以基于云技术来构建节点集群,即节点集群可以部署于云端。
11)区块链(Blockchain):由区块(Block)形成的加密的、链式的交易的存储结构。
12)区块链网络(Blockchain Network):通过共识的方式将新区块纳入区块链的一系列的节点的集合。
对于节点集群,在相关技术提供的方案中,通常是为节点集群中的每个容器单元分配一个私有地址信息,并通过对容器单元发送的服务请求进行封装和解封装,来实现跨节点的通信。作为示例,本申请实施例提供了如图1所示的相关技术提供的节点集群的一个架构图,为了便于理解,以节点集群为Kubernetes节点集群的情况进行示例说明。
在图1中,Kubernetes节点集群包括节点1和节点2。节点1包括用于运行应用程序(APP)前端(Frontend)服务1的容器单元1、以及用于运行APP前端服务2的容器单元2,这里的容器单元1和容器单元2的私有IP地址分别为10.1.15.2和10.1.15.3;节点2包括用于运行APP后端(Backend)服务1的容器单元1、以及用于运行APP后端服务2的容器单元2,这里的容器单元1和容器单元2的私有IP地址分别为10.1.20.2和10.1.20.3。其中,每个节点在启动时,会创建Docker虚拟网桥,Docker虚拟网桥在内核层连通了节点中的其他物理或虚拟网卡,将节点中的所有容器单元都放到同一个虚拟网络中。此外,在节点的容器单元中,还包括虚拟以太网(Virtual Ethernet)设备,虚拟以太网设备主要用于维护命名空间内的私有IP地址(即容器单元的私有IP地址),并实现跨命名空间的通信,因此,虚拟以太网设备总是成对出现的,例如节点1的容器单元1中的veth0以及节点1的容器单元2中的veth1。
在相关技术提供的方案中,主要通过Flannel提供节点集群内的组网能力,具体在每个节点内创建一个Flannel虚拟网卡,用于接收Docker虚拟网桥的数据,还通过维护路由表,对接收到的数据进行封装和转发。在图1中,以节点1中的容器单元2向节点2中的容器单元2发送数据为例,该数据的源IP地址为10.1.15.3,目的IP地址为10.1.20.3。数据从节点1中的容器单元2发出后,经由节点1的Docker虚拟网桥转发到Flannel虚拟网卡,Flannel虚拟网卡对该数据进行封装得到UDP数据包,并发送该UDP数据包,其中,该UDP数据包的源IP地址为192.168.0.100(即节点1的以太网设备eth0所维护的公有IP地址),目的IP地址为192.168.0.200(即节点2的以太网设备eth0所维护的公有IP地址)。节点2在接收到该UDP数据包时,对其解封装,然后将得到的数据通过节点2中的Flannel虚拟网卡和Docker虚拟网桥,路由到节点2中的容器单元2,完成跨节点的容器单元通信。
相关技术提供的方案至少存在以下问题:1)以VXLAN为核心技术的封装和解封装会带来较大的性能损耗,在数据量较大的情况下性能表现极差,尤其是跨节点的容器单元之间的通信;2)由于分配给容器单元的是私有IP地址,导致节点集群外的设备无法通过私有IP地址来访问容器单元,即无法提供节点集群内外的点到点(Peer-to-Peer,P2P)通信能力,对有状态(Stateful)服务的支持能力不足,其中,有状态服务是指需要根据存储的数据响应接收到的请求的服务;3)基于私有IP地址也无法实现不同节点集群之间的数据通信,即多集群能力支持不足。
本申请实施例提供一种节点集群的通信方法、系统、装置、电子设备及计算机可读存储介质,能够减少节点集群的通信过程中的性能损耗,在提升通信带宽的同时降低时延。下面说明本申请实施例提供的电子设备的示例性应用,本申请实施例提供的电子设备可以实施为服务器。
参见图2,图2是本申请实施例提供的节点集群的通信系统100的一个架构示意图,包括节点集群200、服务器300以及客户端410,其中,节点集群200包括节点210-1以及节点210-2,节点210-1包括容器单元1和容器单元2,节点210-2包括容器单元3和容器单元4。对于节点集群200中的每一个节点来说,都运行有一个网络服务;对于节点中的每个容器单元来说,都运行有一个子网络服务。
在本申请实施例中,每个节点中的容器单元的私有地址信息与该节点的某个服务端口之间存在映射关系,节点可以将该映射关系存储在本地,其中,与同一节点中的不同容器单元的私有地址信息存在映射关系的服务端口(这里是指节点的服务端口)不同。以图2为例,对于节点210-1来说,容器单元1的私有地址信息可以与节点210-1的服务端口12345存在映射关系,容器单元2的私有地址信息可以与节点210-1的服务端口12346存在映射关系。为了便于理解,以第一节点(指节点集群200中的任一节点)为节点210-1的情况为例,说明通信过程。
节点210-1的网络服务1在接收到针对节点210-1的第一服务端口的第一服务请求(即该第一服务请求的目的地址信息包括节点210-1的公有IP地址以及第一服务端口)时,在本地存储的多个映射关系中进行查询,得到与第一服务端口存在映射关系的容器单元,以作为第一容器单元,同时,可以得到第一容器单元的私有地址信息。其中,第一服务端口仅为代称,其可以是节点210-1中的任一服务端口。这里,以第一服务端口为12345为例,则确定出的第一容器单元为容器单元1。
然后,网络服务1可以将第一服务请求的目的地址信息,更新为容器单元1的私有地址信息,以将第一服务请求发送至容器单元1中运行的第一应用服务,即应用服务1。其中,子网络服务1可以作为应用服务1的流量代理(数据代理),即网络服务1可以首先将第一服务请求发送至子网络服务1,再由子网络服务1发送至应用服务1,如此,可以避免对应用服务1进行繁琐配置。应用服务1在接收到第一服务请求时,可以对第一服务请求进行响应处理,本申请实施例对响应处理的方式不做限定,例如可以将第一服务请求中携带的数据存储在本地,或者返回第一服务请求所要请求的响应数据,图2中以后者情况进行示例说明。响应数据的返回过程与第一服务请求的发送过程类似,只是发送方和接收方进行了调换。
值得说明的是,在图2中,节点210-1的网络服务1接收到的第一服务请求的发送方可以是节点集群200外的设备,可以是节点集群200中区别于节点210-1的节点(如节点210-2),还可以是其他节点集群中的任一节点。这里所指的节点集群200外的设备可以是服务器或者终端设备,在图2中,以服务器300为例,服务器300在接收到终端设备400中的客户端410发送的调用应用服务1的请求时,生成并发送第一服务请求,该第一服务请求的目的地址信息包括节点210-1的公有IP地址以及节点210-1的服务端口12345。当然,在一些实施例中,终端设备400也可以直接与节点集群200中的节点进行通信。
在图2中,节点集群200可以与独立于节点集群200的设备协同运作,来支撑某个特定的应用的运行。以应用为游戏应用的场景进行举例,服务器300中运行的可以是游戏应用的游戏界面服务,用于在接收到客户端410(如游戏客户端)发送的调用游戏界面服务的请求时,将本地存储的用于构成游戏界面的图像素材作为响应数据,并发送至客户端410,以在客户端410中显示游戏界面。客户端410在接收到针对游戏界面中的账号认证选项的触发操作时,向服务器300发送调用账号数据服务的请求,该请求中携带有用户输入的账号信息。这里,以应用服务1为游戏应用的账号数据服务为例,则服务器300在接收到调用账号数据服务的请求时,生成包括账号信息的第一服务请求,并将第一服务请求发送至网络服务1,以通过子网络服务1转发到应用服务1。应用服务1对第一服务请求中的账号信息进行响应处理,例如对第一服务请求中的账号信息进行认证,若认证成功,则将认证通过的提示、以及本地存储的与该账号信息对应的账号数据(如角色属性数据、技能数据及装备数据等)共同作为响应数据,并按照子网络服务1-网络服务1-服务器300-客户端410的顺序,将响应数据返回到客户端410中进行显示。除了上述示例外,在本申请实施例中,也可以仅通过至少一个节点集群来支撑应用的运行。
在一些实施例中,服务器(如图2中的节点210-1、节点210-2或服务器300)可以是物理服务器,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器,这里的云服务可以包括应用服务。终端设备400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能电视、智能手表等,但并不局限于此。独立于节点集群的设备与节点集群之间可以通过有线或无线通信方式进行直接或间接地连接,本申请实施例中不做限制。
参见图3,图3是本申请实施例提供的结合区块链网络的节点集群的通信系统110的一个可选的架构示意图,包括区块链网络500(区块链网络500包括多个节点,这里示例性地示出了节点510)、认证中心600及电子设备700,电子设备700可以是节点集群中的节点(如图2示出的节点210-1或节点210-2)。其中,认证中心600用于向电子设备700下发数字证书。
区块链网络500的类型是灵活多样的,例如可以为公有链、私有链或联盟链中的任意一种。以公有链为例,任何电子设备例如终端设备和服务器,都可以在不需要授权的情况下接入区块链网络500;以联盟链为例,电子设备在获得授权后可以接入区块链网络500,此时,成为区块链网络500中的一类特殊的节点即客户端节点。需要指出地,客户端节点可以只提供发起交易(例如,用于上链存储数据或查询链上数据)功能,对于区块链网络500的原生节点的功能,例如排序功能、共识服务和账本功能等,客户端节点可以缺省或者有选择性(例如,取决于具体业务需求)地实现。从而,可以将电子设备的数据和业务处理逻辑最大程度迁移到区块链网络500中,通过区块链网络500实现数据和业务处理过程的可信和可追溯。区块链网络500接收来自客户端节点提交的交易,执行交易以更新账本或者查询账本。
在本申请实施例中,区块链网络500可用于提供公有地址服务,即区块链存储有应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系。电子设备700可接入区块链网络500,成为区块链网络500的客户端节点,进而查询存储于区块链中的数据,即实现对公有地址服务的调用,将在后文阐述查询过程。
参见图4,图4是本申请实施例提供的服务器800(例如可以是图2中的节点210-1或节点210-2)的结构示意图,图4所示的服务器800包括:至少一个处理器810、存储器840和至少一个网络接口820。服务器800中的各个组件通过总线系统830耦合在一起。可理解,总线系统830用于实现这些组件之间的连接通信。总线系统830除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图4中将各种总线都标为总线系统830。
处理器810可以是一种集成电路芯片,具有信号的处理能力,例如通用处理器、数字信号处理器(DSP,Digital Signal Processor),或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等,其中,通用处理器可以是微处理器或者任何常规的处理器等。
存储器840可以是可移除的,不可移除的或其组合。示例性的硬件设备包括固态存储器,硬盘驱动器,光盘驱动器等。存储器840可选地包括在物理位置上远离处理器810的一个或多个存储设备。
存储器840包括易失性存储器或非易失性存储器,也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM,Read Only Memory),易失性存储器可以是随机存取存储器(RAM,Random Access Memory)。本申请实施例描述的存储器840旨在包括任意适合类型的存储器。
在一些实施例中,存储器840能够存储数据以支持各种操作,这些数据的示例包括程序、模块和数据结构或者其子集或超集,下面示例性说明。
操作系统841,包括用于处理各种基本系统服务和执行硬件相关任务的系统程序,例如框架层、核心库层、驱动层等,用于实现各种基础业务以及处理基于硬件的任务;
网络通信模块842,用于经由一个或多个(有线或无线)网络接口820到达其他计算设备,示例性的网络接口820包括:蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB,Universal Serial Bus)等。
在一些实施例中,本申请实施例提供的装置可以采用软件方式实现,图4示出了存储在存储器840中的节点集群的通信装置843,其可以是程序和插件等形式的软件,包括以下软件模块:接收模块8431、确定模块8432及发送模块8433,这些模块是逻辑上的,因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
将结合本申请实施例提供的电子设备的示例性应用和实施,说明本申请实施例提供的节点集群的通信方法。
参见图5A,图5A是本申请实施例提供的节点集群的通信方法的一个流程示意图,将结合图5A示出的步骤进行说明。
在步骤101中,第一节点的网络服务接收针对第一节点的第一服务端口的第一服务请求;其中,第一节点为多个节点中的任一节点。
在本申请实施例中,节点集群包括多个节点(这里的多个节点是指至少两个节点),其中,每个节点可以是物理机器(如物理服务器)或者基于虚拟化技术构建的虚拟机。对于每个节点来说,运行有网络服务及至少一个容器单元,其中,网络服务用于控制节点层面的网络通信(即数据收发),例如可以由节点的以太网设备(如网卡)来提供网络服务,当然还可以结合节点中的其他组件(如虚拟网桥等)来共同提供网络服务;容器单元运行有特定的应用服务,不同容器单元运行的应用服务可以是相同或不同的。节点集群可以通过内部运行的应用服务,来支撑一个或多个应用的运行,例如,通过账号数据服务及游戏界面服务,来支撑某个游戏应用的正常运行。
节点集群中的容器单元维护有一个被分配的私有地址信息,该私有地址信息可以包括私有地址(如私有IP地址)及容器单元中的一个服务端口。在本申请实施例中,容器单元的私有地址信息与该容器单元所在节点中特定的服务端口之间存在映射关系,节点可以在本地存储该映射关系,例如以目的地址转换(Destination Network AddressTranslation,DNAT)的形式进行存储,其中,对于同一节点来说,节点中的与不同容器单元的私有地址信息存在映射关系的服务端口不同。这里的映射关系可以人为设定,或通过其他方式自动生成。
这里,以节点集群的多个节点中的任一节点为例,说明数据接收的过程,为了便于区分,将任一节点命名为第一节点。首先,第一节点的网络服务接收针对第一节点的第一服务端口的第一服务请求,即该第一服务请求的目的地址信息包括第一节点的公有地址(如公有IP地址)以及第一服务端口,其中,第一服务端口可以是第一节点中的任意一个服务端口。值得说明的是,第一服务请求的发送方可以包括以下任意一种:节点集群外的设备(即独立于节点集群的设备)、节点集群中区别于第一节点的节点、区别于节点集群的其他节点集群的任意节点。
在步骤102中,第一节点的网络服务在第一节点运行的至少一个容器单元中,确定与第一服务端口存在映射关系的容器单元,以作为第一容器单元。
这里,第一节点存储有内部的容器单元的私有地址信息与第一节点的服务端口之间的映射关系。第一节点的网络服务在接收到针对第一节点的第一服务端口的第一服务请求时,确定与该第一服务端口存在映射关系的容器单元,为了便于区分,将这里确定出的容器单元命名为第一容器单元。同时,也可以确定出第一容器单元的私有地址信息。
举例来说,第一节点存储有运行的容器单元1的私有地址信息10.233.69.7:9017与第一节点的服务端口12345之间的映射关系,还存储有运行的容器单元2的私有地址信息10.233.69.6:9017与第一节点的服务端口12346之间的映射关系。当第一节点的网络服务接收到针对第一节点的服务端口12345(即第一服务端口为12345)的第一服务请求时,第一节点的网络服务将容器单元1作为第一容器单元。
在一些实施例中,步骤102之前,还包括:第一节点的网络服务获取分配给第一节点的私有地址段;其中,节点集群中不同节点的私有地址段不同;针对第一节点运行的每个容器单元,执行以下处理:对私有地址段进行选择操作,并将选择操作得到的私有地址以及设定服务端口,共同作为容器单元的私有地址信息;其中,为第一节点中的不同容器单元选择的私有地址不同。
在本申请实施例中,第一节点的网络服务可以为第一节点中的容器单元分配私有地址信息。首先,第一节点的网络服务可以获取分配给第一节点的私有地址段(相当于一个私有子网),该私有地址段包括多个可分配的私有地址,其中,为节点集群中不同节点分配的私有地址段不同,从而保证不同容器单元的私有地址不会产生冲突,分配规则可以根据实际应用场景进行设定。
然后,针对第一节点中的每个容器单元,第一节点的网络服务对私有地址段进行选择操作,并将选择操作得到的一个私有地址以及设定服务端口,共同作为容器单元的私有地址信息,其中,已被选择过的私有地址不会被再次选择,即为第一节点中的不同容器单元选择的私有地址不同;设定服务端口可以根据实际应用场景进行具体设定,第一节点的不同容器单元中的设定服务端口可以相同,如均为9017,也可以不同。这里的选择操作可以是按照特定顺序进行选择,例如私有地址段为10.1.15.1~10.1.15.7,则可以按照10.1.15.1、10.1.15.2、……、10.1.15.7的顺序依次选择,或者也可以是随机选择。
另外,可以按照第一节点中的容器单元的特定顺序,依次为多个容器单元选择私有地址,例如按照容器单元的创建时间从早到晚的顺序或者人为自定义的顺序,先为第一节点中的容器单元1选择一个私有地址,再为第一节点中的容器单元2选择另一个私有地址。其中,容器单元的顺序也可以是随机确定出的。
值得说明的是,第一节点的网络服务除了为第一节点的容器单元选择私有地址外,还可以为第一节点中的虚拟网桥(如Docker虚拟网桥)选择私有地址,为虚拟网桥选择的私有地址同样位于私有地址段中。其中,第一节点中的虚拟网桥用于负责第一节点中不同容器单元之间的通信、以及第一节点中的容器单元与外界的通信。
通过上述方式,能够实现私有地址的自动选择和自动部署,降低运维成本和难度。另外,在一些实施例中,容器单元的私有地址信息以及虚拟网桥的私有地址也可以手动配置。
在一些实施例中,步骤102之前,还包括:第一节点的网络服务针对第一节点运行的每个容器单元,执行以下处理:在第一节点的多个空闲的服务端口中进行选择操作;建立容器单元的私有地址信息与选择操作得到的服务端口之间的映射关系。
在本申请实施例中,针对第一节点中的每个容器单元,可以人为建立容器单元的私有地址信息与第一节点的某个服务端口(即人为选择的服务端口)之间的映射关系,或者,也可以由第一节点的网络服务进行自动建立。例如,针对第一节点中的每个容器单元,第一节点的网络服务可以在第一节点的多个空闲的服务端口中进行选择操作,并建立容器单元的私有地址信息与选择操作得到的一个服务端口之间的映射关系,其中,空闲的服务端口是指未被占用的服务端口。
这里的选择操作可以是按照服务端口的设定顺序(例如服务端口的端口号数值从小到大的顺序)进行选择,也可以是随机选择。在通过选择操作得到一个服务端口后,可以将该服务端口标记为非空闲,从而保证建立第一节点中不同容器单元的私有地址信息与第一节点的不同服务端口之间的映射关系,有效地避免了服务端口冲突。通过上述方式,能够实现映射关系的自动建立,降低运维成本和难度。
在步骤103中,第一节点的网络服务通过第一容器单元的私有地址信息,将第一服务请求发送至第一容器单元中运行的第一应用服务。
例如,第一节点的网络服务可以将第一服务请求的目的地址信息,更新为第一容器单元的私有地址信息,即是将第一服务请求发送至第一容器单元中运行的应用服务,为了便于区分,将第一容器单元中运行的应用服务命名为第一应用服务。其中,可以通过第一节点的虚拟网桥,将第一服务请求发送至第一应用服务。
值得说明的是,在本申请实施例中,一个容器单元可以运行多个应用服务,即第一容器单元中的第一应用服务的数量可能包括多个。对于该情况,可以获取第一服务请求携带的应用服务的标识信息(如应用服务的名称或其他类型的标识信息),并将第一服务请求发送至第一容器单元中运行的、且与该标识信息对应的第一应用服务。
在一些实施例中,当满足以下条件中的至少之一时,第一节点的网络服务将第一服务请求发送至第一容器单元中运行的第一应用服务:第一容器单元的发送方白名单包括第一服务请求的发送方;第一容器单元的请求凭证白名单包括第一服务请求中的请求凭证;对第一服务请求的签名验证结果为成功。
在本申请实施例中,为了保证通信安全性,可以设定以下三种条件。
1)第一容器单元的发送方白名单包括第一服务请求的发送方。这里,可以预先在第一节点本地,存储第一节点内各个容器单元的发送方白名单,某个容器单元的发送方白名单包括的即是有权访问该容器单元的发送方。第一节点的网络服务在确定出第一容器单元之后,可以将第一服务请求的发送方与第一容器单元的发送方白名单进行匹配。
2)第一容器单元的请求凭证白名单包括第一服务请求中的请求凭证。除了验证发送方之外,本申请实施例还可以通过验证请求凭证,来确定第一服务请求是否安全。这里,同样可以在第一节点本地,存储第一节点内各个容器单元的请求凭证白名单,第一节点的网络服务在确定出第一容器单元之后,将第一服务请求中携带的请求凭证与第一容器单元的请求凭证白名单进行匹配。本申请实施例对请求凭证的具体形式不做限定,例如可以是字符串形式的令牌(Token)。值得说明的是,上述的发送方白名单和请求凭证白名单,可以根据实际应用场景进行具体设定。
3)对第一服务请求的签名验证结果为成功。例如,第一服务请求的发送方对第一服务请求携带的服务数据进行哈希(Hash)处理,得到第一签名,其中,服务数据是指需要第一应用服务进行响应处理的数据,例如上文的账号信息。第一节点的网络服务对于接收到的第一服务请求,同样对其中携带的服务数据进行哈希处理,得到第二签名,并将第一签名与第二签名进行匹配。若第一签名与第二签名相同,则确定对第一服务请求的签名验证结果为成功;若第一签名与第二签名不同,证明第一节点的网络服务接收到的第一服务请求中的服务数据经过了篡改,则确定对第一服务请求的签名验证结果为失败。
在本申请实施例中,可以设定在满足以上任一条件时,由第一节点的网络服务将第一服务请求发送至第一容器单元中运行的第一应用服务;或者,也可以设定在同时满足以上的多个条件,如同时满足条件1)、条件2)及条件3)时,由第一节点的网络服务将第一服务请求发送至第一容器单元中运行的第一应用服务,根据实际的安全性需求而定。通过上述方式,能够有效保障节点集群中的通信安全性。
在步骤104中,第一容器单元的第一应用服务对接收到的第一服务请求进行响应处理。
这里,对第一应用服务进行响应处理的方式不做限定,例如,可以将第一服务请求中携带的数据存储在本地,又例如,可以从本地获取第一服务请求所请求的数据,并将该数据作为响应数据,发送至第一服务请求的发送方。
以第一应用服务为游戏应用中的账号数据服务进行举例说明,则账号数据服务在接收到包括账号信息(如包括账号名称和账号密码)的第一服务请求时,可以对该账号信息进行认证处理(即响应处理)。例如,账号数据服务可以将该账号信息与本地存储的多个有权的账号信息进行匹配,若第一服务请求中的账号信息与某个有权的账号信息相同,则确定匹配成功。然后,账号数据服务可以将本地存储的、与匹配成功的账号信息对应的账号数据作为响应数据,并将响应数据发送至第一服务请求的发送方,如发送至独立于节点集群的终端设备,以在终端设备的图形界面中显示账号数据。
如图5A所示,本申请实施例通过建立节点中的容器单元的私有地址信息与节点的服务端口之间的映射关系,使得节点集群中的通信过程不再需要对数据进行封装和解封装,有效地减少了性能损耗,在提升通信带宽的同时降低了通信时延。从另一角度,本申请实施例能够支持节点集群内外的点对点通信,即节点集群外的设备可以通过访问节点的服务端口,来实现对节点内的容器单元运行的应用服务的访问,同时,也能够支持多节点集群之间的通信,有效满足实际应用场景中的多种通信需求。
在一些实施例中,参见图5B,图5B是本申请实施例提供的节点集群的通信方法的一个流程示意图,图5A示出的步骤103可以通过步骤201至步骤202实现,将结合各步骤进行说明。
在步骤201中,第一节点的网络服务通过第一容器单元的私有地址信息,将第一服务请求添加至数据接收队列中。
在本申请实施例中,节点的容器单元中可以运行子网络服务,该子网络服务用于控制容器单元层面的网络通信(即数据收发)。接下来,以数据接收的情况为例说明子网络服务的功能,其中,子网络服务可以包括数据接收队列,数据接收队列属于消息队列,可以应用先进先出(First Input First Output,FIFO)原则或者其他的消息传递原则。第一节点的网络服务在得到第一容器单元的私有地址信息后,可以基于该私有地址信息,将第一服务请求添加至第一容器单元运行的子网络服务的数据接收队列中。
值得说明的是,当第一容器单元运行有多个第一应用服务时,子网络服务可以包括与多个第一应用服务分别对应的数据接收队列。第一节点的网络服务可以获取第一服务请求中携带的应用服务的标识信息,确定与该标识信息对应的第一应用服务,并将第一服务请求添加至确定出的第一应用服务对应的数据接收队列中。
在步骤202中,第一容器单元的子网络服务从数据接收队列中获取第一服务请求,并发送至第一容器单元中运行的第一应用服务。
这里,第一节点的网络服务负责向第一容器单元的数据接收队列添加第一服务请求,第一容器单元的子网络服务负责从数据接收队列中取出第一服务请求,基于这样的异步通信机制,能够有效地提升传递第一服务请求的成功率,同时有效降低通信压力。第一容器单元的子网络服务可以将获取到的第一服务请求,发送至第一容器单元中运行的第一应用服务,即第一容器单元的子网络服务可以作为第一应用服务的流量代理,用于中转发往第一应用服务的数据、以及由第一应用服务发送的数据(后文进行阐述)。
在一些实施例中,任意步骤之间,还包括:第一容器单元的子网络服务从数据接收队列中获取针对第一容器单元的私有地址信息的第二服务请求,并将第二服务请求发送至第一容器单元中运行的第一应用服务;其中,第二服务请求的发送方为第一节点中区别于第一容器单元的第二容器单元。
在本申请实施例中,第一容器单元除了接收来自第一节点外的发送方发送的第一服务请求之外,还可以接收来自第一节点内的其他容器单元(即第二容器单元)发送的第二服务请求。例如,第二容器单元可以基于第一容器单元的私有地址信息,将第二服务请求添加至第一容器单元运行的子网络服务的数据接收队列中。如此,第一容器单元的子网络服务便可从数据接收队列中获取第二服务请求,并将第二服务请求发送至第一应用服务。通过上述方式,可以实现同一节点内的不同容器单元之间基于私有地址信息的通信。
在一些实施例中,当第一服务请求为并发的多个服务请求当中的一个时,可以通过这样的方式来实现上述的将第一服务请求添加至数据接收队列中:第一节点的网络服务分别确定多个服务请求各自的优先级;按照优先级从高到低的顺序,将多个服务请求依次添加至数据接收队列中;其中,优先级包括发送方的优先级、以及请求的服务类型的优先级中的任意一种。
这里,若第一节点的网络服务同时或在一段时间(如5秒)内接收到多个服务请求(其中包括第一服务请求),则可以分别确定每个服务请求各自的优先级,再按照优先级从高到低的顺序,将多个服务请求依次添加至第一容器单元运行的子网络服务的数据接收队列中,其中,服务请求的优先级能够体现服务请求的重要程度,多个服务请求的最终接收方均为第一容器单元运行的第一应用服务。
本申请实施例提供了服务请求的优先级的两种确定方式,其一是将服务请求的发送方的优先级作为服务请求本身的优先级,发送方的优先级可以根据实际应用场景进行设定,例如,按照优先级从高到低的顺序对多种发送方进行排序,可以得到第一节点中区别于第一容器单元的第二容器单元-节点集群中区别于第一节点的节点-区别于节点集群的其他节点集群中的任意节点-节点集群外的设备,当然,该优先级顺序仅为示例,并不构成对本申请实施例的限定。
第二种方式,是将服务请求所请求的服务类型的优先级作为服务请求本身的优先级。例如,数据响应服务(即要求进行响应处理得到响应数据)的优先级可以高于数据存储服务的优先级;又例如,账号注册服务的优先级可以高于账号注销服务的优先级,均可以根据实际应用场景进行具体设定,其中,数据响应服务、数据存储服务、账号注册服务及账号注销服务是不同的服务类型。
通过上述方式,保证优先级更高的服务请求能够被更快地添加至数据接收队列中,即能够实现对优先级更高的服务请求的优先处理。
如图5B所示,本申请实施例将子网络服务作为第一应用服务的数据接收中转站,在保障第一应用服务能够顺序接收到第一服务请求的同时,能够避免对第一应用服务进行繁琐配置。
在一些实施例中,参见图5C,图5C是本申请实施例提供的数据发送过程的一个流程示意图,将结合示出的步骤进行说明。
在步骤301中,第一容器单元的第一应用服务生成针对第二应用服务的第三服务请求,并将第三服务请求添加至第二应用服务对应的数据发送队列中;其中,第二应用服务的运行方包括节点集群外的设备、第一节点中区别于第一容器单元的第二容器单元、以及区别于第一节点的第二节点运行的容器单元中的任意一种。
这里,以第一节点中的第一容器单元为例,说明数据发送的过程。在本申请实施例中,第一容器单元运行的子网络服务可以包括多个数据发送队列,每一个数据发送队列对应区别于第一应用服务的一种应用服务,其中,区别于第一应用服务的应用服务可以包括:1)节点集群外的设备运行的应用服务;2)第一节点中区别于第一容器单元的第二容器单元运行的应用服务;3)区别于第一节点的第二节点内的容器单元运行的应用服务,这里,第一节点与第二节点可以属于同一节点集群,也可以属于不同的节点集群。
第一容器单元的第一应用服务可以生成针对第二应用服务的服务请求,为了便于区分,将这里生成的服务请求命名为第三服务请求,其中,第二应用服务为区别于第一应用服务的应用服务。然后,第一应用服务在多个数据发送队列中,确定与第二应用服务对应的一个数据发送队列,并将第三服务请求添加至该数据发送队列中。
在步骤302中,第一容器单元的子网络服务从第二应用服务对应的数据发送队列中获取第三服务请求。
这里,第一容器单元的子网络服务作为第一应用服务的流量代理,从第二应用服务对应的数据发送队列中取出第三服务请求,并发送至第二应用服务。根据第二应用服务的不同,第一容器单元的子网络服务发送第三服务请求的方式也存在差异,例如,当第二应用服务为第一节点中区别于第一容器单元的第二容器单元运行的应用服务时,可以直接基于第二应用服务的私有地址信息,将第三服务请求发送至第二容器单元的第二应用服务。
在步骤303中,第一容器单元的子网络服务根据第二应用服务的标识信息在公有地址服务中进行查询处理,得到与第二应用服务的标识信息存在映射关系的第二节点的公有地址信息;其中,公有地址服务存储有应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系;第二节点的公有地址信息包括第二节点的公有地址以及服务端口。
这里,以第二应用服务为第二节点内的容器单元运行的应用服务为例,说明发送第三服务请求的过程。第一容器单元的子网络服务可以根据第二应用服务的标识信息,在公有地址服务中进行查询处理,从而得到与第二应用服务的标识信息存在映射关系的第二节点的公有地址信息。其中,第二应用服务的标识信息可以是第三服务请求中携带的。在本申请实施例中,标识信息用于区分不同的应用服务,对标识信息的具体内容不做限定,例如可以是应用服务的名称等。
公有地址服务存储有节点集群(这里指一个或多个节点集群)中运行的应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系,公有地址服务可以由独立于节点集群的地址服务器提供,也可以由区块链网络提供,对此不做限定。公有地址服务中存储的映射关系可以是由节点集群中的各个节点上传的,值得说明的是,本申请实施例中的映射关系本质上是应用服务的标识信息、应用服务所属容器单元的私有地址信息、以及应用服务所属节点的公有地址信息这三者之间的映射关系,只是在节点中仅需存储应用服务所属容器单元的私有地址信息与该节点的公有地址信息(或者服务端口)之间的映射关系,在公有地址服务中仅需存储应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系,从而能够节省存储资源,当然,在节点及公有地址服务中,也可以存储完整的映射关系。
值得说明的是,第一容器单元的子网络服务可以根据公有地址服务中存储的多个映射关系,来相应地创建多个数据发送队列。
在一些实施例中,可以通过这样的方式来实现上述的第一容器单元的子网络服务根据第二应用服务的标识信息在公有地址服务中进行查询处理,得到与第二应用服务的标识信息存在映射关系的第二节点的公有地址信息:第一容器单元的子网络服务根据第二应用服务的标识信息,在区块链网络提供的公有地址服务中进行查询处理,得到区块链存储的、与第二应用服务的标识信息存在映射关系的第二节点的公有地址信息。
本申请实施例也可结合区块链技术实现,区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。
区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中,用户管理模块负责所有区块链参与者的身份信息管理,包括维护公私钥生成(账号管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等,并且在授权的情况下,监管和审计某些真实身份的交易情况,提供风险控制的规则配置(风控审计);基础服务模块部署在所有区块链节点设备上,用来验证业务请求的有效性,并对有效请求完成共识后记录到存储上,对于一个新的业务请求,基础服务先对接口适配解析和鉴权处理(接口适配),然后通过共识算法将业务信息加密(共识管理),在加密之后完整一致的传输至共享账本上(网络通信),并进行记录存储;智能合约模块负责合约的注册发行以及合约触发和合约执行,开发人员可以通过某种编程语言定义合约逻辑,发布到区块链上(合约注册),根据合约条款的逻辑,调用密钥或者其它的事件触发执行,完成合约逻辑,同时还提供对合约升级注销的功能;运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出,例如:告警、监控网络情况、监控节点设备健康状态等。
在本申请实施例中,区块链可存储应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系,并通过存储的映射关系来提供公有地址服务。下面以电子设备接入区块链网络以实现查询公有地址信息为例,说明区块链网络的示例性应用。
为了便于理解,以图3示出的架构进行说明,电子设备700接入区块链网络500,成为区块链网络500的客户端节点,这里的电子设备700可以是节点集群中的第一节点。第一容器单元的子网络服务在需要查询公有地址信息时,控制电子设备700将包括第二应用服务的标识信息的查询请求以交易形式发送至区块链网络,在交易中指定实现查询操作需要调用的智能合约以及向智能合约传递的参数,交易还携带了电子设备700签署的数字签名(例如,使用电子设备700的数字证书,对交易的摘要进行加密得到),并将交易广播到区块链网络500。其中,数字证书可由电子设备700向认证中心600进行登记注册得到。
区块链网络500中的节点510在接收到交易时,对交易携带的数字签名进行验证,数字签名验证成功后,根据交易中携带的电子设备700的身份标识,确认电子设备700是否是具有交易权限,数字签名和权限验证中的任何一个验证判断都将导致交易失败。验证成功后签署节点510自己的数字签名,并继续在区块链网络500中广播。
区块链网络500中具有排序功能的节点510接收到验证成功的交易后,将交易填充到新的区块中,并广播到区块链网络500中提供共识服务的节点510。
区块链网络500中的提供共识服务的节点510对新区块进行共识过程以达成一致,提供账本功能的节点510将新区块追加到区块链的尾部,并执行新区块中的交易:对于查询公有地址信息的交易,从区块链中查询与第二应用服务的标识信息存在映射关系的第二节点的公有地址信息,并将第二节点的公有地址信息发送至电子设备700中第一容器单元的子网络服务。
在查询之前,可以由电子设备将应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系进行上链,上链过程与上述查询过程类似,差异在于,填充得到的新区块包括的是应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系。由于区块链中的数据具有不可篡改的特性,故通过上述方式,能够保证获取到的第二节点的公有地址信息的准确性。
在步骤304中,第一容器单元的子网络服务通过第二节点的公有地址信息,将第三服务请求发送至第二节点,以使第二节点的网络服务将第三服务请求发送至第二应用服务。
第一容器单元的子网络服务在得到第二节点的公有地址信息后,将该公有地址信息作为第三服务请求的目的地址信息,即是将第三服务请求发送至第二节点。第二节点的网络服务在接收到第三服务请求后,将第三服务请求发送至第二应用服务,该过程与第一节点的网络服务将第一服务请求发送至第一应用服务的过程类似。第二应用服务可以对接收到的第三服务请求进行响应处理。
在一些实施例中,步骤302之后,还包括:第一容器单元的子网络服务根据第二应用服务的标识信息在公有地址服务中进行查询处理,得到与第二应用服务的标识信息存在映射关系的目标设备的公有地址信息;其中,公有地址服务存储有应用服务的标识信息与应用服务所属设备的公有地址信息之间的映射关系;设备的公有地址信息包括设备的公有地址以及服务端口;通过目标设备的公有地址信息,将第三服务请求发送至目标设备,以使目标设备的网络服务将第三服务请求发送至第二应用服务。
在本申请实施例中,第二应用服务也可以是节点集群外的设备运行的应用服务,公有地址服务也可以存储应用服务的标识信息与应用服务所属设备的公有地址信息之间的映射关系。其中,设备的公有地址信息包括设备的公有地址以及服务端口。
第一容器单元的子网络服务在获取到第三服务请求时,可以根据第二应用服务的标识信息在公有地址服务中进行查询处理,得到与第二应用服务的标识信息存在映射关系的设备的公有地址信息,为了便于区分,将这里的设备命名为目标设备。然后,即可通过目标设备的公有地址信息,将第三服务请求发送至目标设备,以使目标设备的网络服务将第三服务请求发送至第二应用服务。值得说明的是,节点集群外的设备运行的应用服务可以无需设置私有地址信息,另外,节点集群外的设备可以运行一个或多个应用服务。通过上述方式,能够有效实现节点集群内到节点集群外的访问,即数据发送。
如图5C所示,本申请实施例将子网络服务作为第一应用服务的数据发送中转站,通过与区别于第一应用服务的不同应用服务分别对应的数据发送队列,保障数据发送的成功率,同时,也能够避免对第一应用服务进行繁琐配置。
下面,将说明本申请实施例在一个实际的应用场景中的示例性应用,为了便于理解,以游戏应用的场景进行示例说明。在游戏应用场景中,一个常见的架构是部分游戏服务位于云端(即节点集群),部分游戏服务位于传统机器(即节点集群外的物理机或虚拟机),针对于此,本申请实施例提供了如图6所示的节点集群的通信系统的一个架构图,在图6中,以Kubernetes节点集群为例,通过服务网格(ServiceMesh)框架来实现Kubernetes节点集群中的通信。服务网格框架包括控制模块(Controller)、映射模块、名称服务以及代理客户端,其中,控制模块用于调用Kubernetes节点集群的接口服务(接口服务可以由API Server组件提供),从而接管Kubernetes节点集群的服务信息(对应上文的应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系)以及实现Kubernetes节点集群中的流量管理,映射模块可以基于Webhook原理实现代理客户端的自动注入(即自动配置)以及映射随机端口;名称服务对应上文的公有地址服务,可以由单独设立的名称服务器(NameServer)提供;代理客户端又称SideCar,用于负责游戏服务的流量代理,还用于实现高性能通信以及服务治理等能力。这里,可以通过控制模块和映射模块的协同运作,并结合节点内的其他组件(如网卡),来提供上文的网络服务;可以通过代理客户端来提供上文的子网络服务。此外,图6中的仪表盘(Dashboard)可以用于显示服务信息或其他信息,便于相关人员对Kubernetes节点集群进行手动调整。
控制模块可以将Kubernetes节点集群中的服务信息透传给名称服务,使名称服务接管Kubernetes节点集群的服务信息。如此,节点集群外的虚拟机中的代理客户端就可以通过名称(即应用服务的标识信息)发现Kubernetes节点集群内的游戏服务对应的公有地址信息,然后发送数据给Kubernetes节点集群内的Pod。同理,节点集群外的虚拟机也可以将自身的服务信息透传给名称服务。
接下来,说明节点集群内的游戏服务访问节点集群外的游戏服务的过程。
1)在Kubernetes节点集群内,游戏服务和代理客户端部署在Pod中。
2)在Kubernetes节点集群外,游戏服务和代理客户端部署在虚拟机中。由于Kubernetes节点集群外的虚拟机中并不存在Pod,因此,将该虚拟机单独作为一个通信对象。
3)Pod和虚拟机都有自己的IP地址,相当于一台真实的机器。
4)每个Pod或者虚拟机中包含一个代理客户端,用于负责游戏服务之间的相互通信。
5)当图6中的游戏服务1需要向游戏服务3发送数据时,游戏服务1先将数据发送给游戏服务1对应的代理客户端(即游戏服务1所在Pod的代理客户端),游戏服务1对应的代理客户端通过名称服务,获取游戏服务3所在虚拟机的IP地址(公有IP地址)和服务端口,然后,根据获取到的IP地址和服务端口发送数据。
6)游戏服务3对应的代理客户端收到数据后,将数据转发给游戏服务3。至此,完成了一次完整的数据发送过程。
但是,Kubernetes节点集群分配给Pod的是私有IP地址,因此,Kubernetes节点集群外的虚拟机无法通过私有IP地址直连Kubernetes节点集群内的Pod。作为示例,本申请实施例提供了如图7所示的节点集群外无法访问节点集群内的示意图,举例来说,在图7中,游戏服务3所在的虚拟机和游戏服务1所在的Pod之间的网络是不通的,游戏服务3对应的代理客户端无法将数据发送给游戏服务1对应的代理客户端。其中,图7示出了容器网络接口(Container Network Interface,CNI)网桥,例如可以是上文的Docker虚拟网桥。另外,图7中示出的“9017”是指Pod的服务端口。
针对该问题,本申请实施例提供了图8所示的Kubernetes节点集群内外互通的示意图,为了便于理解,以游戏服务3对应的代理客户端将数据发送给游戏服务1对应的代理客户端为例,进行说明。
1)当游戏服务1对应的代理客户端启动时,会通过控制模块和映射模块的配合,将游戏服务1所在Pod的PodIP:PodPort(对应上文的容器单元的私有地址信息)与游戏服务1所在节点(即节点1)的NodeIP:NodePort(对应上文的节点的公有地址信息)建立映射关系。这里,游戏服务1对应的代理客户端在名称服务中记录的NodeIP:NodePort可以是9.140.196.94:12345,即在名称服务中存储的映射关系为“游戏服务1:9.140.196.94:12345”。
2)当游戏服务3要访问游戏服务1时,会通过游戏服务3对应的代理客户端查询名称服务,并将数据发送给查询得到的9.140.196.94:12345。
3)当9.140.196.94:12345(即节点1的网卡)收到数据时,会通过DNAT将数据转发给10.233.69.7:9017,即游戏服务1所在的Pod。
4)游戏服务1对应的代理客户端收到数据,并将数据转发给游戏服务1。至此,完成了游戏服务3到游戏服务1的数据发送,在整个过程中,无需经过Flannel虚拟网卡,即无需对数据进行封装和解封装。
其中,图8示出的“12345:9017”是指Pod映射在节点上的服务端口与Pod自身的服务端口之间的映射关系,以此类推。
为了便于理解代理客户端之间的通信模式,本申请实施例提供了如图9所示的代理客户端之间的通信架构图。对于跨机环境而言,代理客户端会为本机(即代理客户端所在的Pod或虚拟机)的每个实例创建一个数据接收队列,创建的数据接收队列被相应的实例独占,其中,实例即为游戏服务。此外,代理客户端还会为远端(即除代理客户端所在的Pod之外的Pod及虚拟机)的每个实例创建一个数据发送队列,创建的每个数据发送队列被相应的远端实例独占。不同代理客户端之间,可以通过图9中示出的传输控制协议(TransmissionControl Protocol,TCP)进行通信,当然,也可以通过其他通信协议进行通信,对此不做限定。
对于数据接收,游戏服务从对应的数据接收队列取出数据即可;对于数据发送,游戏服务可以将待发送的数据添加至某个远端实例对应的数据发送队列,游戏服务对应的代理客户端负责从数据发送队列中取出数据,并发送至该远端实例所在的Pod或虚拟机。
在本申请实施例中,可以通过HostPort方式建立NodePort与PodIP:PodPort之间的IPTABLES规则(即映射关系),HostPort的原理即为Linux操作系统提供的DNAT,但映射关系的建立方式并不限于此。
为了便于理解,结合图8,以步骤形式说明本申请实施例的节点集群外向节点集群内访问的过程。
1)当Kubernetes节点集群外的虚拟机中的代理客户端启动时,监听虚拟机的IP地址和Port,这里以图8中的9.23.151.108:9017(对应上文的节点集群外的设备的公有地址信息)为例。虚拟机中的代理客户端将监听到的IP地址和Port上报给名称服务,即图8中游戏服务3对应的代理客户端在名称服务中记录的信息为9.23.151.108:9017。
2)对于Kubernetes节点集群内的Pod来说,监听PodIP和PodPort,但是上报给名称服务的是Pod所在Node的NodeIP以及该Node中的一个随机的空闲服务端口,即NodeIP:NodePort。这里以游戏服务1所在的Pod为例,上报给名称服务的是9.140.196.94:12345,游戏服务2、4和5同理。
3)由于游戏服务1记录到名称服务的是NodeIP:NodePort,而NodeIP:NodePort是公有地址信息,天然和节点集群外部是互通的。如此,游戏服务3访问游戏服务1时,会直接将数据发往从名称服务中查询得到的9.140.196.94:12345,其中,可以由游戏服务3对应的代理客户端进行数据发送。
4)当9.140.196.94:12345收到数据时,由于9.140.196.94(即节点1)已经配置好了DNAT路由规则,因此,会将数据直接转发给10.233.69.7:9017,从而被游戏服务1对应的代理客户端劫持。然后,游戏服务1对应的代理客户端将劫持到的数据发送给游戏服务1,有效实现了节点集群外到节点集群内的访问。
结合图8,以步骤形式说明本申请实施例的同一节点集群的节点之间的访问过程。
1)这里,以游戏服务1访问游戏服务4为例。首先,游戏服务1对应的代理客户端将数据发往从名称服务中查询得到的9.2.149.137:23456。
2)9.2.149.137:23456收到数据,根据事先配置好的DNAT路由规则,将数据转发给10.233.65.7:9017,从而被游戏服务4对应的代理客户端劫持。然后,游戏服务4对应的代理客户端将劫持到的数据发送给游戏服务4,有效实现了同一节点集群的节点之间的访问。此外,不同节点集群的节点之间的访问过程同理。
通过本申请实施例,至少能够实现以下技术效果:弥补了相关技术提供的ServiceMesh框架只能用在互联网无状态后台系统的缺陷,本申请实施例提供的ServiceMesh框架可以用于强状态高性能的应用场景(如游戏应用场景);相较于相关技术提供的Flannel通信方案,本申请实施例在大数据量下的通信性能的提升在4倍以上;可以支持5000个以上的节点的同时起服上线,能够及时通知到其他实例;能够有效支持有状态服务的通信、以及节点集群中的扩缩容等;能够有效支持节点集群的内外通信、以及多节点集群之间的相互通信。
发明人对相关技术提供的Flannel通信方案以及本申请实施例提供的通信方案进行了对比测试,其中,用于测试的节点(Node)的内核版本为3.10.107-1-tlinux2-0053,Kubernetes版本为v1.14.3-tk8s-v1.1-1,压力测试工具为test-client&&iperf。这里,提供了如图10所示的性能压测的示意图,图10中的测试结果为:
指标 | 物理机到物理机 | 本申请实施例 | Flannel通信方案 |
带宽:Gbit/sec | 9.42 | 9.4 | 2.4 |
平均时延:ms | 30 | 31 | 230 |
平均包大小 | 6.8KB | 6.8KB | 6.8KB |
本申请实施例还提供了如图11所示的进行另一次性能压测的示意图,图11中的测试结果为:
指标 | 物理机到物理机 | 本申请实施例 | Flannel通信方案 |
平均时延:ms | 10 | 10 | 100 |
其中,“物理机到物理机”指的是非云场景的通信方案。根据上述测试数据可以确定,在云场景中,本申请实施例提供的方案的通信质量高于Flannel通信方案的通信质量,甚至能够接近非云场景的通信质量。
下面继续说明本申请实施例提供的节点集群的通信装置843实施为软件模块的示例性结构,在一些实施例中,如图4所示,存储在存储器840的节点集群的通信装置843中的软件模块可以包括:接收模块8431,用于通过第一节点的网络服务接收针对第一节点的第一服务端口的第一服务请求;其中,第一节点为多个节点中的任一节点;确定模块8432,用于在第一节点运行的至少一个容器单元中,确定与第一服务端口存在映射关系的容器单元,以作为第一容器单元;发送模块8433,用于通过第一容器单元的私有地址信息,将第一服务请求发送至第一容器单元中运行的第一应用服务,以对第一服务请求进行响应处理。
在一些实施例中,第一容器单元中运行有子网络服务,子网络服务包括数据接收队列;发送模块8433,还用于:通过第一容器单元的私有地址信息,将第一服务请求添加至数据接收队列中,以使子网络服务从数据接收队列中获取第一服务请求,并发送至第一容器单元中运行的第一应用服务。
在一些实施例中,节点集群的通信装置843还包括:节点内通信模块,用于通过子网络服务,从数据接收队列中获取针对第一容器单元的私有地址信息的第二服务请求,并将第二服务请求发送至第一容器单元中运行的第一应用服务;其中,第二服务请求的发送方为第一节点中区别于第一容器单元的第二容器单元。
在一些实施例中,当第一服务请求为并发的多个服务请求当中的一个时,发送模块8433,还用于:分别确定多个服务请求各自的优先级;按照优先级从高到低的顺序,将多个服务请求依次添加至数据接收队列中;其中,优先级包括发送方的优先级、以及请求的服务类型的优先级中的任意一种。
在一些实施例中,子网络服务还包括多个数据发送队列;其中,每个数据发送队列对应区别于第一应用服务的一种应用服务;节点集群的通信装置843还包括:生成模块,用于通过第一容器单元中运行的第一应用服务,生成针对第二应用服务的第三服务请求,并将第三服务请求添加至第二应用服务对应的数据发送队列中;主动请求模块,用于通过子网络服务从第二应用服务对应的数据发送队列中获取第三服务请求,并将第三服务请求发送至第二应用服务;其中,第二应用服务的运行方包括节点集群外的设备、第一节点中区别于第一容器单元的第二容器单元、以及区别于第一节点的第二节点运行的容器单元中的任意一种。
在一些实施例中,主动请求模块,还用于:根据第二应用服务的标识信息在公有地址服务中进行查询处理,得到与第二应用服务的标识信息存在映射关系的第二节点的公有地址信息;其中,公有地址服务存储有应用服务的标识信息与应用服务所属节点的公有地址信息之间的映射关系;其中,第二节点的公有地址信息包括第二节点的公有地址以及服务端口;通过第二节点的公有地址信息将第三服务请求发送至第二节点,以使第二节点的网络服务将第三服务请求发送至第二应用服务。
在一些实施例中,节点集群的通信装置843还包括:映射关系建立模块,用于针对第一节点运行的每个容器单元,执行以下处理:在第一节点的多个空闲的服务端口中进行选择操作;建立容器单元的私有地址信息与选择操作得到的服务端口之间的映射关系。
在一些实施例中,节点集群的通信装置843还包括:地址段获取模块,用于通过第一节点的网络服务,获取分配给第一节点的私有地址段;其中,节点集群中不同节点的私有地址段不同;地址生成模块,用于针对第一节点运行的每个容器单元,执行以下处理:对私有地址段进行选择操作,并将选择操作得到的私有地址以及设定服务端口,共同作为容器单元的私有地址信息;其中,为第一节点中的不同容器单元选择的私有地址不同。
在一些实施例中,发送模块8433,还用于:当满足以下条件中的至少之一时,将第一服务请求发送至第一容器单元中运行的第一应用服务:第一容器单元的发送方白名单包括第一服务请求的发送方;第一容器单元的请求凭证白名单包括第一服务请求中的请求凭证;对第一服务请求的签名验证结果为成功。
在一些实施例中,第一服务请求的发送方包括以下任意一种:节点集群外的设备、节点集群中区别于第一节点的节点、区别于节点集群的其他节点集群的任意节点。
本申请实施例提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行本申请实施例上述的节点集群的通信方法。
本申请实施例提供一种存储有可执行指令的计算机可读存储介质,其中存储有可执行指令,当可执行指令被处理器执行时,将引起处理器执行本申请实施例提供的方法,例如,如图5A及图5B示出的节点集群的通信方法。
在一些实施例中,计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器;也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中,可执行指令可以采用程序、软件、软件模块、脚本或代码的形式,按任意形式的编程语言(包括编译或解释语言,或者声明性或过程性语言)来编写,并且其可按任意形式部署,包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例,可执行指令可以但不一定对应于文件系统中的文件,可以可被存储在保存其它程序或数据的文件的一部分,例如,存储在超文本标记语言(HTML,Hyper TextMarkup Language)文档中的一个或多个脚本中,存储在专用于所讨论的程序的单个文件中,或者,存储在多个协同文件(例如,存储一个或多个模块、子程序或代码部分的文件)中。
作为示例,可执行指令可被部署为在一个计算设备上执行,或者在位于一个地点的多个计算设备上执行,又或者,在分布在多个地点且通过通信网络互连的多个计算设备上执行。
以上,仅为本申请的实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等,均包含在本申请的保护范围之内。
Claims (13)
1.一种节点集群的通信方法,其特征在于,
所述节点集群包括多个节点,每个所述节点中运行有网络服务和至少一个容器单元,且每个所述节点中的容器单元的私有地址信息与所述节点的服务端口之间存在映射关系;
所述方法包括:
通过第一节点的网络服务接收针对所述第一节点的第一服务端口的第一服务请求;其中,所述第一节点为所述多个节点中的任一节点;
在所述第一节点运行的至少一个容器单元中,确定与所述第一服务端口存在映射关系的容器单元,以作为第一容器单元;其中,所述第一容器单元中运行有子网络服务,所述子网络服务包括数据接收队列;
通过所述第一容器单元的私有地址信息,将所述第一服务请求添加至所述数据接收队列中,以使所述子网络服务从所述数据接收队列中获取所述第一服务请求,并发送至所述第一容器单元中运行的第一应用服务;
其中,所述第一应用服务用于对所述第一服务请求进行响应处理。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
通过所述子网络服务,从所述数据接收队列中获取针对所述第一容器单元的私有地址信息的第二服务请求,并将所述第二服务请求发送至所述第一容器单元中运行的第一应用服务;
其中,所述第二服务请求的发送方为所述第一节点中区别于所述第一容器单元的第二容器单元。
3.根据权利要求1所述的方法,其特征在于,当所述第一服务请求为并发的多个服务请求当中的一个时,所述将所述第一服务请求添加至所述数据接收队列中,包括:
分别确定所述多个服务请求各自的优先级;
按照优先级从高到低的顺序,将所述多个服务请求依次添加至所述数据接收队列中;
其中,所述优先级包括发送方的优先级、以及请求的服务类型的优先级中的任意一种。
4.根据权利要求1所述的方法,其特征在于,
所述子网络服务还包括多个数据发送队列;其中,每个所述数据发送队列对应区别于所述第一应用服务的一种应用服务;
所述方法还包括:
通过所述第一容器单元中运行的第一应用服务,生成针对第二应用服务的第三服务请求,并将所述第三服务请求添加至所述第二应用服务对应的数据发送队列中;
通过所述子网络服务从所述第二应用服务对应的数据发送队列中获取所述第三服务请求,并将所述第三服务请求发送至所述第二应用服务;
其中,所述第二应用服务的运行方包括所述节点集群外的设备、所述第一节点中区别于所述第一容器单元的第二容器单元、以及区别于所述第一节点的第二节点运行的容器单元中的任意一种。
5.根据权利要求4所述的方法,其特征在于,所述将所述第三服务请求发送至所述第二应用服务,包括:
根据所述第二应用服务的标识信息在公有地址服务中进行查询处理,得到与所述第二应用服务的标识信息存在映射关系的第二节点的公有地址信息;
其中,所述公有地址服务存储有应用服务的标识信息与所述应用服务所属节点的公有地址信息之间的映射关系;
其中,所述第二节点的公有地址信息包括所述第二节点的公有地址以及服务端口;
通过所述第二节点的公有地址信息将所述第三服务请求发送至所述第二节点,以使所述第二节点的网络服务将所述第三服务请求发送至所述第二应用服务。
6.根据权利要求1至5任一项所述的方法,其特征在于,所述方法还包括:
针对所述第一节点运行的每个容器单元,执行以下处理:
在所述第一节点的多个空闲的服务端口中进行选择操作;
建立所述容器单元的私有地址信息与所述选择操作得到的服务端口之间的映射关系。
7.根据权利要求1至5任一项所述的方法,其特征在于,所述方法还包括:
通过所述第一节点的网络服务,获取分配给所述第一节点的私有地址段;其中,所述节点集群中不同节点的私有地址段不同;
针对所述第一节点运行的每个容器单元,执行以下处理:
对所述私有地址段进行选择操作,并将所述选择操作得到的私有地址以及设定服务端口,共同作为所述容器单元的私有地址信息;
其中,为所述第一节点中的不同容器单元选择的私有地址不同。
8.根据权利要求1至5任一项所述的方法,其特征在于,所述方法还包括:
当满足以下条件中的至少之一时,将所述第一服务请求发送至所述第一容器单元中运行的第一应用服务:
所述第一容器单元的发送方白名单包括所述第一服务请求的发送方;
所述第一容器单元的请求凭证白名单包括所述第一服务请求中的请求凭证;
对所述第一服务请求的签名验证结果为成功。
9.根据权利要求1至5任一项所述的方法,其特征在于,所述第一服务请求的发送方包括以下任意一种:
所述节点集群外的设备、所述节点集群中区别于所述第一节点的节点、区别于所述节点集群的其他节点集群的任意节点。
10.一种节点集群的通信系统,其特征在于,所述节点集群包括多个节点,每个所述节点中运行有网络服务和至少一个容器单元,且每个所述节点中的容器单元的私有地址信息与所述节点的服务端口之间存在映射关系;
第一节点的网络服务,用于:
接收针对所述第一节点的第一服务端口的第一服务请求;其中,所述第一节点为所述多个节点中的任一节点;
在所述第一节点运行的至少一个容器单元中,确定与所述第一服务端口存在映射关系的容器单元,以作为第一容器单元;其中,所述第一容器单元中运行有子网络服务,所述子网络服务包括数据接收队列;
通过所述第一容器单元的私有地址信息,将所述第一服务请求添加至所述数据接收队列中,以使所述子网络服务从所述数据接收队列中获取所述第一服务请求,并发送至所述第一容器单元中运行的第一应用服务;
所述第一容器单元的第一应用服务,用于:
对接收的所述第一服务请求进行响应处理。
11.一种节点集群的通信装置,其特征在于,
所述节点集群包括多个节点,每个所述节点中运行有网络服务和至少一个容器单元,且每个所述节点中的容器单元的私有地址信息与所述节点的服务端口之间存在映射关系;
所述装置包括:
接收模块,用于通过第一节点的网络服务接收针对所述第一节点的第一服务端口的第一服务请求;其中,所述第一节点为所述多个节点中的任一节点;
确定模块,用于在所述第一节点运行的至少一个容器单元中,确定与所述第一服务端口存在映射关系的容器单元,以作为第一容器单元;其中,所述第一容器单元中运行有子网络服务,所述子网络服务包括数据接收队列;
发送模块,用于通过所述第一容器单元的私有地址信息,将所述第一服务请求添加至所述数据接收队列中,以使所述子网络服务从所述数据接收队列中获取所述第一服务请求,并发送至所述第一容器单元中运行的第一应用服务;
其中,所述第一应用服务用于对所述第一服务请求进行响应处理。
12.一种电子设备,其特征在于,包括:
存储器,用于存储可执行指令;
处理器,用于执行所述存储器中存储的可执行指令时,实现权利要求1至9任一项所述的节点集群的通信方法。
13.一种计算机可读存储介质,其特征在于,存储有可执行指令,用于被处理器执行时,实现权利要求1至9任一项所述的节点集群的通信方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011300839.9A CN112511611B (zh) | 2020-11-19 | 2020-11-19 | 节点集群的通信方法、装置、系统及电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011300839.9A CN112511611B (zh) | 2020-11-19 | 2020-11-19 | 节点集群的通信方法、装置、系统及电子设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112511611A CN112511611A (zh) | 2021-03-16 |
CN112511611B true CN112511611B (zh) | 2021-08-10 |
Family
ID=74958698
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011300839.9A Active CN112511611B (zh) | 2020-11-19 | 2020-11-19 | 节点集群的通信方法、装置、系统及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112511611B (zh) |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115134231B (zh) * | 2021-03-17 | 2024-03-08 | 北京搜狗科技发展有限公司 | 一种通信方法、装置和用于通信的装置 |
CN115150642B (zh) * | 2021-03-31 | 2023-09-22 | 阿里巴巴新加坡控股有限公司 | 通信方法、服务器、电子设备和存储介质 |
CN113422798B (zh) * | 2021-05-11 | 2022-09-16 | 华为技术有限公司 | 一种网络数据传输方法、装置、系统以及计算机 |
CN113364616A (zh) * | 2021-06-01 | 2021-09-07 | 全知科技(杭州)有限责任公司 | 一种基于K8s开发的应用迁移到无网环境的方法 |
CN113364888B (zh) * | 2021-06-30 | 2022-05-31 | 重庆紫光华山智安科技有限公司 | 服务调度方法、系统、电子设备及计算机可读存储介质 |
CN113765816B (zh) * | 2021-08-02 | 2023-12-15 | 阿里巴巴新加坡控股有限公司 | 一种基于服务网格的流量控制方法、系统、设备及介质 |
CN114025370B (zh) * | 2021-11-04 | 2023-08-08 | 杭州朗和科技有限公司 | 数据报文传输方法、介质、系统和计算设备 |
CN114039977B (zh) * | 2021-11-10 | 2024-03-26 | 北京奇艺世纪科技有限公司 | 一种基于边缘计算的应用任务的实现方法、系统及装置 |
CN114157455B (zh) * | 2021-11-16 | 2024-07-12 | 北京达佳互联信息技术有限公司 | 一种数据传输方法、装置、设备以及存储介质 |
CN114827115B (zh) * | 2022-06-01 | 2024-06-28 | 青岛中科曙光科技服务有限公司 | 容器内Web服务的访问方法、装置、电子设备及存储介质 |
CN115037812A (zh) * | 2022-06-06 | 2022-09-09 | 国科华盾(北京)科技有限公司 | 一种面向容器云场景的网络模式数据处理方法 |
CN115002069B (zh) * | 2022-06-24 | 2023-10-31 | 中国电信股份有限公司 | 端口映射方法、装置、电子设备及存储介质 |
US20240152404A1 (en) * | 2022-11-07 | 2024-05-09 | International Business Machines Corporation | Container cross-cluster capacity scaling |
CN115834705B (zh) * | 2022-11-09 | 2024-05-24 | 迈普通信技术股份有限公司 | 认证服务分配方法、节点集群及计算机可读存储介质 |
CN116846946A (zh) * | 2023-06-16 | 2023-10-03 | 泽拓科技(深圳)有限责任公司 | 合并网络连接的通信方法、系统、存储介质及设备 |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100334857C (zh) * | 2004-09-27 | 2007-08-29 | 华为技术有限公司 | 一种环网及其业务实现方法 |
CN105376303B (zh) * | 2015-10-23 | 2018-11-06 | 深圳前海达闼云端智能科技有限公司 | 一种Docker实现系统及其通信方法 |
US10212041B1 (en) * | 2016-03-04 | 2019-02-19 | Avi Networks | Traffic pattern detection and presentation in container-based cloud computing architecture |
US10496987B2 (en) * | 2016-09-13 | 2019-12-03 | Verizon Patent And Licensing Inc. | Containerization of network services |
CN107819802B (zh) * | 2016-09-13 | 2021-02-26 | 华为技术有限公司 | 一种在节点集群中的镜像获取方法、节点设备及服务器 |
CN108737584A (zh) * | 2017-04-19 | 2018-11-02 | 中国移动通信集团山西有限公司 | 容器服务的访问方法、网络地址的解析方法、装置和系统 |
CN110008031B (zh) * | 2018-01-05 | 2022-04-15 | 北京金山云网络技术有限公司 | 设备操作方法、集群系统、电子设备及可读取存储介质 |
CN109032806B (zh) * | 2018-07-30 | 2021-05-14 | 华为技术有限公司 | 容器的服务调度方法和装置 |
CN109508225A (zh) * | 2018-11-15 | 2019-03-22 | 珠海市知安全科技有限公司 | 一种windows操作系统下的应用容器系统 |
CN109582441A (zh) * | 2018-11-30 | 2019-04-05 | 北京百度网讯科技有限公司 | 用于提供容器服务的系统、方法和装置 |
CN110457115A (zh) * | 2019-07-26 | 2019-11-15 | 武汉中海庭数据技术有限公司 | 一种基于Docker的KHB业务发布方法、装置及存储介质 |
CN111181943B (zh) * | 2019-12-24 | 2023-04-18 | 深圳平安医疗健康科技服务有限公司 | 基于业务中台的服务交互方法、装置、计算机设备及计算机存储介质 |
CN111562970B (zh) * | 2020-07-15 | 2020-10-27 | 腾讯科技(深圳)有限公司 | 容器实例的创建方法、装置、电子设备及存储介质 |
CN111953700B (zh) * | 2020-08-18 | 2023-04-07 | 中国工商银行股份有限公司 | 会话保持方法及装置 |
-
2020
- 2020-11-19 CN CN202011300839.9A patent/CN112511611B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN112511611A (zh) | 2021-03-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112511611B (zh) | 节点集群的通信方法、装置、系统及电子设备 | |
CN108650182B (zh) | 网络通信方法、系统、装置、设备及存储介质 | |
CN108650262B (zh) | 一种基于微服务架构的云平台扩展方法及系统 | |
US12047287B2 (en) | Data transmission method and apparatus, network adapter, and storage medium | |
CN106533883B (zh) | 一种网络专线的建立方法、装置及系统 | |
US11075821B2 (en) | Method and apparatus for managing field device based on cloud server | |
US10230588B2 (en) | Dynamically deployable self configuring distributed network management system using a trust domain specification to authorize execution of network collection software on hardware components | |
WO2018095416A1 (zh) | 信息处理方法、装置及系统 | |
US20200374127A1 (en) | Blockchain-powered cloud management system | |
US11750721B2 (en) | Bidirectional command protocol via a unidirectional communication connection for reliable distribution of tasks | |
US20140067914A1 (en) | Computer system and packet transfer method | |
CN112910685B (zh) | 实现对容器网络统一管理的方法及装置 | |
CN104054067A (zh) | 基于减负装置的数据包处理的框架和接口 | |
CN114418574A (zh) | 一种共识和资源传输方法、设备及存储介质 | |
WO2017114363A1 (zh) | 报文处理方法、bng及bng集群系统 | |
CN108462752B (zh) | 一种访问共享网络的方法、系统及vpc管理设备以及可读存储介质 | |
KR101922795B1 (ko) | 사물인터넷 서비스 제공 장치 및 그 방법 | |
CN102571811A (zh) | 用户接入权限控制系统和方法 | |
CN113872933B (zh) | 隐藏源站的方法、系统、装置、设备及存储介质 | |
US11838854B2 (en) | 5G network slicing and resource orchestration using holochain | |
JP2016072793A (ja) | 遠隔会議システム、プログラム、セキュリティサーバ及びアプリケーションサーバ | |
US11743322B2 (en) | Communication device and communication method | |
TW201818699A (zh) | 資料傳輸的方法、設備、裝置及系統 | |
CN113497762A (zh) | 数据报文的传输方法及装置 | |
CN116032691A (zh) | 靶场互联互通方法、电子设备及可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40040998 Country of ref document: HK |