CN112351106A - 一种含事件网格的服务网格平台及其通信方法 - Google Patents

Abstract

本发明公开了一种含事件网格的服务网格平台，包括若干主机节点、数据面板、事件网格消息面板及服务网格控制面板；数据面板包括若干边车代理，边车代理分为事件边车代理和服务边车代理，事件边车代理和服务边车代理运行于主机节点上；服务边车代理用于实现服务网格的微服务间的网络通信的控制；服务网格控制面板用于实现接收用户配置生成路由规则、分发路由规则到边车代理、分发事件通信策略及遥测数据收集；事件边车代理与事件通信微服务成对出现且相互对应；事件网格消息面板用于管理事件边车代理及事件通信微服务。本发明的服务网格平台可实现高效异步通信并有效解决基于事件驱动的交互通信问题。

Description

一种含事件网格的服务网格平台及其通信方法

技术领域

本发明涉及云计算技术领域，特别涉及一种含事件网格的服务网格平台及其通信方法。

背景技术

服务网格的术语为Service Mesh，是一个用于处理服务到服务相互通信的专用基础设施层，它负责通过包含现代云原生应用的复杂服务拓扑来安全可靠地传递请求。服务网格技术是目前最具生产力的前沿技术之一，它作为微服务和云原生架构的基础技术和架构模式正变得越来越流行。服务网格主要是网络基础设施组件，它使企业可以从基于微服务的应用程序中卸掉网络通信逻辑，以便企业可以完全专注于服务的业务逻辑。在构建微服务架构的基础平台的过程中，采用服务网格技术可以进一步提升系统的整体性能，降低研发和运营成本。服务网格可以作为微服务技术架构的基础设施层，可以使网络通信变得更加灵活、更加可靠和更加快速。服务网格技术受到谷歌、微软、IBM、红帽、Pivotal等行业巨头公司的大力推动，并能与Kubernetes容器平台、OpenShift云开发平台和VMware公司的Pivotal Container Service企业级容器平台等云计算平台进行集成。

尽管服务网格技术可以很好地支持同步的RESTful API交互模式和常规的请求-响应的交互模式，但服务网格技术领域当前的流行实现(Istio，Linkerd，Consul等解决方案)仅能满足微服务之间的请求-响应风格的同步通信，而不支持异步通信模式，也不支持基于事件驱动的通信模式。而要在服务网格中实现事件处理，需要做复杂的、专门的处理，且事件处理的效率取决于具体的业务模型，难以保证高效；业界还有一种解决方案是将事件服务集群独立于服务网格，也即在服务网格之外解决事件驱动的交互通信，这种方式下事件服务集群就相当于信息孤岛，很容易成为IT Legacy遗留系统，也不利于企业实施ITIL。目前业界也没有一种通用且高效的解决方案来解决服务网格中的任意节点的事件流的异步通信问题。

发明内容

本发明的目的是克服上述背景技术中不足，提供一种含事件网格的服务网格平台及其通信方法，可实现高效异步通信并有效解决基于事件驱动的交互通信问题。

为了达到上述的技术效果，本发明采取以下技术方案：

一种含事件网格的服务网格平台，包括若干主机节点、数据面板、事件网格消息面板及服务网格控制面板；所述若干主机节点之间相互进行组网连接共同构成网状通信网格；所述数据面板包括若干边车代理，所述边车代理分为事件边车代理和服务边车代理，所述事件边车代理和服务边车代理运行于所述主机节点上；所述服务边车代理用于实现所有服务网格的微服务间的网络通信的控制；所述服务网格控制面板用于实现接收用户配置生成路由规则、分发路由规则到边车代理、分发事件通信策略及遥测数据收集；所述事件边车代理与事件通信微服务成对出现且相互对应，相互对应的事件边车代理与事件通信微服务部署在同一主机节点；所述事件网格消息面板用于管理事件边车代理及事件通信微服务；其中，主机节点可以由容器(如Docker容器或其它容器)或虚拟机或物理服务器或含OS的运行环境的实现，事件边车代理、服务边车代理则都可由运行于主机节点上的软件模块实现，以守护进程或后台服务的方式运行在主机节点的OS上，服务边车代理可通过通用的策略和遥测中心Mixer来实现控制所有微服务间的网络通信，在本发明的技术方案中，服务网格控制面板与服务边车代理的功能及实现均为现有技术，故不再赘述其具体工作原理及实现过程。

进一步地，所述事件边车代理之间相互通信连接且构成网状结构；且事件边车代理与操作系统环境不相关；事件边车代理在运行时为动态变化的，如当单个事件边车代理出现宕机故障时其它事件边车代理可以实时动态调整路由，从而确保事件消息的交付；且所有主机节点上的事件边车代理共同构成事件通信网络。

进一步地，所述事件通信微服务在部署时即先在事件边车代理中完成事件消息的注册，并将注册信息写入事件注册表，具体是将其处理的事件消息的事件类型记录在事件注册表中，所述事件注册表优选为存储于内存中的表状数据结构。

进一步地，所述事件边车代理用于实现事件消息的转发和路由，具体包括：

事件边车代理首先获取最新收到的事件消息的元数据，其中，获取的元数据至少包括事件名、事件类型、事件的通信策略、事件参数等信息；

事件边车代理根据事件消息的元数据检索事件注册表，确定收到的事件消息对应的事件微服务集群；

事件边车代理根据负载均衡原则分配处理事件消息的事件微服务集群的最终节点，并在事件消息的元数据中添加最终节点的事件边车代理即到目标事件边车代理的节点ID；

事件边车代理将事件消息路由到目标事件边车代理；

目标事件边车代理接收事件消息并核对元数据中记录的节点ID是否为自己的节点ID，若是，则将事件消息转发至与其对应的事件通信微服务进行处理。

进一步地，事件边车代理根据所述事件消息的元数据中记录的事件的通信策略决定是否返回结果信息。

进一步地，所述事件的通信策略包括：发布-订阅的通信策略、服务端推送事件SSE(Server-Sent Events)的通信策略、恰好一次的通信策略(exactly once)、最多一次的通信策略(at most once)、至少一次的通信策略(at least once)。

进一步地，所述事件边车代理会将接收到的事件请求在事件日志表中完成记录并更新事件日志表，所述事件日志表中至少包含以下数据：事件ID、事件名、事件类型、事件的通信策略、事件参数、事件描述、处理的事件通信微服务、目标事件边车代理的节点ID。

进一步地，事件边车代理还用于实现：将更新后的事件日志表和/或事件注册表向多个主机节点广播同步；多种事件通信策略的实现功能；监测数据的上报功能，如根据预先配置的监测策略，将对应的事件通信微服务的运行情况的数据上报至指定服务器节点。

进一步地，所述事件边车代理用于实现：实施事件日志分类帐及记录事件日志，其中，事件日志分类帐可以作为数据存储进行访问，以进行事件后的分析及机器学习及事件重放或作为事件源使用，且在某些情况下，事件日志分类帐还可以用作服务网格中业务应用系统的真实记录。

进一步地，记录事件日志的模式包括永久模式(permanent)、仅追加模式(append-only)、不可变模式(immutable)。

同时，本发明还公开了一种含事件网格的服务网格平台的事件通信方法，由上述的一种含事件网格的服务网格平台实现，包括以下步骤：

A.开放的任一主机节点的事件边车代理接收客户端发出的事件请求及其元数据；所述事件请求的元数据至少包括以下信息：事件名、事件类型、事件的通信策略、事件参数；其中，客户端可以是智能终端设备如手机、平板，还可以是浏览器等软件；

B.收到事件请求的事件边车代理根据事件消息的元数据检索事件注册表，确定收到的事件消息对应的事件微服务集群，实际中，若未检索到则先放置并等待人工进行确认，由人工核对该事件消息是否正确，若不正确即可直接丢弃，若正确则说明需要对事件通信微服务的功能进行升级调整，并将事件消息转至升级后的事件通信微服务处理；

C.事件边车代理根据负载均衡原则分配处理事件消息的事件微服务集群的最终节点，并在事件消息的元数据中添加最终节点的事件边车代理即到目标事件边车代理的节点ID；实际中，事件微服务集群中一般对应有若干的主机节点及若干部署于主机节点上的事件边车代理及事件通信微服务处理，则在具体分配时可根据负载均衡的分配原则将当前的事件请求分配至事件微服务集群下负载最小的事件通信微服务对应的事件边车代理，若所有事件通信微服务的负载均相同，则随机分配；

D.事件边车代理将事件消息路由到目标事件边车代理；

E.目标事件边车代理接收事件消息并核对元数据中记录的节点ID是否为自己的节点ID，若是，则将事件消息转发至与其对应的事件通信微服务进行处理。

作为优选的后续步骤，在完成事件请求的处理后，与处理该事件请求的事件通信微服务对应的事件边车代理还可根据事件消息的事件类型，决定是否将处理结果按原路返回，如若属于纯上报型的事件请求则不用返回处理结果；

同时，根据事件请求的事件类型，与处理该事件请求的事件通信微服务对应的事件边车代理还可以与客户端建立通道模式的通信方式。

进一步地，所述事件边车代理在将收到的事件请求转与其对应的事件通信微服务处理前还包括对事件消息进行验证，且仅通过验证的事件消息才转事件通信微服务处理，未验证通过的则直接丢弃。

本发明与现有技术相比，具有以下的有益效果：

在本发明的含事件网格的服务网格平台及其通信方法中，其事件网格对事件驱动的应用程序来说就像服务网格对RESTful应用程序一样：可实现架构层使一个应用程序中的事件能够被任何其他应用程序动态路由和接收，且无论这些应用程序部署在何处(可部署在没有云的环境或私有云或公共云均可)，且事件网格是由相互连接的事件代理程序网络所创建和启用的，同时，在本发明的技术方案中，作为服务网格的补充，事件网格和服务网格都可以在应用程序之间实现更好的通信，并通过将某些功能置于网络和应用程序之间的某个层中，使应用程序更加专注于业务逻辑。因此，本发明的事件网格使企业能够支持事件驱动的架构，从最小的微服务部署，到受服务治理、健壮、安全和架构合理的方式将应用程序扩展到混合云，提供了动态、实时地集成旧应用程序、数据存储、现代微服务、SaaS、IoT和移动设备的功能。本发明的事件网格为应用程序开发人员和架构师提供了一个基础，可以在需要构建和部署它们的任何地方构建和部署分布式事件驱动的应用程序，最终实现更好地开展微服务的服务治理，减少运维人员的数量，提升DevOps的效率，并且业务模块与服务治理实现了完全的解耦，云计算平台的系统架构更加可靠，能够大幅度降低企业私有云、混合云建设的成本。

附图说明

图1是本发明的含事件网格的服务网格平台的示意图。

图2是本发明的含事件网格的服务网格平台中事件网格的通讯示意图。

具体实施方式

下面结合本发明的实施例对本发明作进一步的阐述和说明。

实施例：

实施例一：

一种含事件网格的服务网格平台，如图1所示，包括若干主机节点、数据面板、事件网格消息面板及服务网格控制面板。

具体的，若干主机节点之间相互进行组网连接共同构成网状通信网格；数据面板包括若干边车代理，边车代理分为事件边车代理和服务边车代理，事件边车代理和服务边车代理运行于主机节点上；服务边车代理用于实现所有服务网格的微服务(如包括RESTAPI服务、RPC服务等)间的网络通信的控制；服务网格控制面板用于实现接收用户配置生成路由规则、分发路由规则到边车代理、分发事件通信策略及遥测数据收集；事件边车代理与事件通信微服务成对出现且相互对应，相互对应的事件边车代理与事件通信微服务部署在同一主机节点；事件网格消息面板用于管理事件边车代理及事件通信微服务，包括：事件边车的注册和管理，事件注册表的监控，事件网格的动态调整等。

其中，服务网格控制面板、服务边车代理及对应的服务网格的微服务即构成服务网格，对应的，事件网格消息面板、事件边车代理及对应的事件通信微服务即构成事件网格。

具体的，主机节点可以由容器(如Docker容器或其它容器)或虚拟机或物理服务器或含OS的运行环境的实现，事件边车代理、服务边车代理则都可由运行于主机节点上的软件模块实现，以守护进程或后台服务的方式运行在主机节点的OS上，服务边车代理可通过通用的策略和遥测中心Mixer来实现控制所有微服务间的网络通信，在本发明的技术方案中，服务网格控制面板与服务边车代理的功能及实现均为现有技术，故不再赘述。

具体的，如图2所示，事件边车代理之间相互通信连接且构成网状结构；且事件边车代理与操作系统环境不相关；事件边车代理在运行时为动态变化的，如当单个事件边车代理出现宕机故障时其它事件边车代理可以实时动态调整路由，从而确保事件消息的交付；且所有主机节点上的事件边车代理共同构成事件通信网络。

事件通信微服务在部署时即先在事件边车代理中完成事件消息的注册，并将注册信息写入事件注册表，具体是将其处理的事件消息的事件类型记录在事件注册表中，事件注册表优选为存储于内存中的表状数据结构。

本实施例中，事件边车代理主要用于实现事件消息的转发和路由，具体包括：

事件边车代理首先获取最新收到的事件消息的元数据，其中，获取的元数据至少包括事件名、事件类型、事件的通信策略、事件参数等信息；

事件边车代理根据事件消息的元数据检索事件注册表，确定收到的事件消息对应的事件微服务集群；一般是通过事件类型数据在事件注册表中进行检索；对于检索不到的事件消息，本实施例中是将其单独作为一个类别，记录到事件日志表中。

实际中，若未检索到则先放置并等待人工进行确认，由人工核对该事件消息是否正确，若不正确即可直接丢弃，若正确则说明需要对事件通信微服务的功能进行升级调整，并将事件消息转至升级后的事件通信微服务处理，并在事件注册表及事件日志表中进行相应的更新及记录。

事件边车代理根据负载均衡原则分配处理事件消息的事件微服务集群的最终节点，并在事件消息的元数据中添加最终节点的事件边车代理即到目标事件边车代理的节点ID；由于属于同一事件微服务集群的事件通信微服务其处理的事件类型可能相同，因此，利用事件类型在事件注册表中进行检索时，其检索出的结果为集群，此时，即需要根据相应的负载均衡原则(比如轮循法、最小连接法、加权最小连接法等)确定最佳的处理该时间消息的事件通信微服务，若所有事件通信微服务的负载相同或有多个负载较小的事件通信微服务，则可随机分配。

事件边车代理将事件消息路由到目标事件边车代理；由目标事件边车代理接收事件消息并核对元数据中记录的节点ID是否为自己的节点ID，若是，则将事件消息转发至与其对应的事件通信微服务进行处理。同时，作为优选，事件边车代理在事件消息处理完后还可根据事件消息的元数据中记录的事件的通信策略决定是否返回结果信息。

本实施例中，事件的通信策略包括：发布-订阅的通信策略、服务端推送事件SSE(Server-Sent Events)的通信策略、恰好一次的通信策略(exactly once)、最多一次的通信策略(at most once)、至少一次的通信策略(at least once)，具体策略内容为现有技术，此处不再赘述。

为了进一步完善事件消息的管理，本实施例中，事件边车代理会将接收到的事件请求在事件日志表中完成记录并更新事件日志表，事件日志表中至少包含以下数据：事件ID、事件名、事件类型、事件的通信策略、事件参数、事件描述、处理的事件通信微服务、目标事件边车代理的节点ID。

具体的，事件日志表记录的事件日志的模式包括永久模式(permanent)、仅追加模式(append-only)、不可变模式(immutable)。

同时，在事件日志表和事件注册表有更新时，事件边车代理还用于实现：将更新后的事件日志表和事件注册表向多个主机节点广播同步；多种事件通信策略的实现功能；监测数据的上报功能，如根据预先配置的监测策略，将对应的事件通信微服务的运行情况的数据上报至指定服务器节点。

作为优选，本实施例中，事件边车代理用于实现：实施事件日志分类帐，事件日志分类帐可以作为数据存储进行访问，以进行事件后的分析及机器学习及事件重放或作为事件源使用，且在某些情况下，事件日志分类帐还可以用作服务网格中业务应用系统的真实记录。

实施例二

一种含事件网格的服务网格平台的事件通信方法，由实施例一的一种含事件网格的服务网格平台实现，包括以下步骤：

步骤1.开放的任一主机节点的事件边车代理接收客户端发出的事件请求及其元数据；事件请求的元数据至少包括以下信息：事件名、事件类型、事件的通信策略、事件参数；其中，客户端可以是智能终端设备如手机、平板，还可以是浏览器等软件。

步骤2.收到事件请求的事件边车代理根据事件消息的元数据检索事件注册表，确定收到的事件消息对应的事件微服务集群，实际中，若未检索到则先放置并等待人工进行确认，由人工核对该事件消息是否正确，若不正确即可直接丢弃，若正确则说明需要对事件通信微服务的功能进行升级调整，并将事件消息转至升级后的事件通信微服务处理。

步骤3.事件边车代理根据负载均衡原则分配处理事件消息的事件微服务集群的最终节点，并在事件消息的元数据中添加最终节点的事件边车代理即到目标事件边车代理的节点ID；实际中，事件微服务集群中一般对应有若干的主机节点及若干部署于主机节点上的事件边车代理及事件通信微服务处理，则在具体分配时可根据负载均衡的分配原则将当前的事件请求分配至事件微服务集群下负载最小的事件通信微服务对应的事件边车代理，若所有事件通信微服务的负载均相同，则随机分配。

步骤4.事件边车代理将事件消息路由到目标事件边车代理。

步骤5.目标事件边车代理接收事件消息并核对元数据中记录的节点ID是否为自己的节点ID，若是，则将事件消息转发至与其对应的事件通信微服务进行处理。

作为优选，事件边车代理在将收到的事件请求转与其对应的事件通信微服务处理前还包括对事件消息进行验证，且仅通过验证的事件消息才转事件通信微服务处理，未验证通过的则直接丢弃。

步骤6.在完成事件请求的处理后，与处理该事件请求的事件通信微服务对应的事件边车代理还可根据事件消息的事件类型，决定是否将处理结果按原路返回，如若属于纯上报型的事件请求则不用返回处理结果。

同时，作为优选，根据事件请求的事件类型，与处理该事件请求的事件通信微服务对应的事件边车代理还可以与客户端建立通道模式的通信方式。

综上可知，本发明的含事件网格的服务网格平台及其通信方法，使企业的云计算平台能够支持事件驱动的架构，从最小的微服务部署，到受服务治理、健壮、安全和架构合理的方式将应用程序扩展到混合云。它提供了动态、实时地集成旧应用程序，数据存储，现代微服务，SaaS，IoT和移动设备的功能。事件网格为应用程序开发人员和架构师提供了一个基础，可以在需要构建和部署它们的任何地方构建和部署分布式事件驱动的应用程序，并且为企业用户通过使用本发明实施例提供的解决方案来构建了一套含事件网格的服务网格平台，可以更好地开展微服务的服务治理，减少运维人员的数量，提升DevOps的效率，并且业务模块与服务治理实现了完全的解耦，云计算平台的系统架构更加可靠，能够大幅度降低企业私有云、混合云建设的成本。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。

Claims (10)

1.一种含事件网格的服务网格平台，其特征在于，包括若干主机节点、数据面板、事件网格消息面板及服务网格控制面板；

所述若干主机节点之间相互进行组网连接共同构成网状通信网格；所述数据面板包括若干边车代理，所述边车代理分为事件边车代理和服务边车代理，所述事件边车代理和服务边车代理运行于所述主机节点上；

所述服务边车代理用于实现服务网格的微服务间的网络通信的控制；

所述服务网格控制面板用于实现接收用户配置生成路由规则、分发路由规则到边车代理、分发事件通信策略及遥测数据收集；

所述事件边车代理与事件通信微服务成对出现且相互对应，相互对应的事件边车代理与事件通信微服务部署在同一主机节点；

所述事件网格消息面板用于管理事件边车代理及事件通信微服务。

2.根据权利要求1所述的一种含事件网格的服务网格平台，其特征在于，所述事件边车代理之间相互通信连接且构成网状结构；且事件边车代理与操作系统环境不相关；事件边车代理在运行时为动态变化的；所有主机节点上的事件边车代理共同构成事件通信网络。

3.根据权利要求1所述的一种含事件网格的服务网格平台，其特征在于，所述事件通信微服务在部署时即先在事件边车代理中完成事件消息的注册，并将注册信息写入事件注册表，具体是将其处理的事件消息的事件类型记录在事件注册表中。

4.根据权利要求3所述的一种含事件网格的服务网格平台，其特征在于，所述事件边车代理用于实现事件消息的转发和路由，具体包括：

事件边车代理首先获取最新收到的事件消息的元数据，其中，获取的元数据至少包括事件名、事件类型、事件的通信策略、事件参数等信息；

事件边车代理根据事件消息的元数据检索事件注册表，确定收到的事件消息对应的事件微服务集群；

事件边车代理根据负载均衡原则分配处理事件消息的事件微服务集群的最终节点，并在事件消息的元数据中添加最终节点的事件边车代理即到目标事件边车代理的节点ID；

事件边车代理将事件消息路由到目标事件边车代理；

目标事件边车代理接收事件消息并核对元数据中记录的节点ID是否为自己的节点ID，若是，则将事件消息转发至与其对应的事件通信微服务进行处理。

5.根据权利要求4所述的一种含事件网格的服务网格平台，其特征在于，所述事件通信策略包括发布-订阅的通信策略、服务端推送事件SSE的通信策略、恰好一次的通信策略、最多一次的通信策略、至少一次的通信策略。

6.根据权利要求4所述的一种含事件网格的服务网格平台，其特征在于，所述事件边车代理会将接收到的事件消息在事件日志表中完成记录并更新事件日志表，所述事件日志表中至少包含以下数据：事件ID、事件名、事件类型、事件的通信策略、事件参数、事件描述、处理的事件通信微服务、目标事件边车代理的节点ID。

7.根据权利要求6所述的一种含事件网格的服务网格平台，其特征在于，所述事件边车代理还用于实现：将更新后的事件日志表和/或事件注册表向多个主机节点广播同步；多种事件通信策略的实现功能；监测数据的上报功能；以及在完成事件消息处理后根据所述事件消息的元数据中记录的事件的通信策略决定是否返回结果信息。

8.根据权利要求6所述的一种含事件网格的服务网格平台，其特征在于，所述事件边车代理还用于实现：实施事件日志分类帐，且事件日志表的事件日志模式包括永久模式、仅追加模式、不可变模式。

9.一种含事件网格的服务网格平台的事件通信方法，由权利要求1-8中任一所述的一种含事件网格的服务网格平台实现，其特征在于，包括以下步骤：

A.开放的任一主机节点的事件边车代理接收客户端发出的事件请求及其元数据；所述事件请求的元数据至少包括以下信息：事件名、事件类型、事件的通信策略、事件参数；

B.收到事件请求的事件边车代理根据事件消息的元数据检索事件注册表，确定收到的事件消息对应的事件微服务集群；

C.事件边车代理根据负载均衡原则分配处理事件消息的事件微服务集群的最终节点，并在事件消息的元数据中添加最终节点的事件边车代理即到目标事件边车代理的节点ID；

D.事件边车代理将事件消息路由到目标事件边车代理；

E.目标事件边车代理接收事件消息并核对元数据中记录的节点ID是否为自己的节点ID，若是，则将事件消息转发至与其对应的事件通信微服务进行处理。

10.根据权利要求9所述的一种含事件网格的服务网格平台的事件通信方法，其特征在于，所述事件边车代理在将收到的事件消息转与其对应的事件通信微服务处理前还包括对事件消息进行验证，且仅通过验证的事件消息才转事件通信微服务处理。

Images