CN114077501A - 管理微服务架构系统的方法、电子设备和计算机可读介质 - Google Patents

Abstract

本公开提供了一种用于对微服务架构的系统进行管理的方法，包括：在具有显示器、一个或多个处理器和存储器的电子设备处：根据系统接收到的对一个或多个应用程序接口API的来自客户端的请求所经过的链路的信息，确定系统中被调用的各个节点以及与所述链路对应的、所调用的各个节点之间的连接关系，应用程序接口由部署在节点上的微服务提供；在显示器上显示图形用户界面，所述图形用户界面包括系统中的被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。本公开还提供了对应的电子设备和非暂时性计算机可读介质。

Description

管理微服务架构系统的方法、电子设备和计算机可读介质

技术领域

本公开涉及管理微服务架构系统的方法、电子设备和计算机可读介质。

背景技术

在计算机软件领域，传统的应用采用单体服务架构，即，将所有的功能模块打包到一起并放在一个容器中运行。然而，这种单体服务架构存在局限性。具体来说，这种单体服务架构的应用会随着业务需求的不断迭代以及扩展功能的追加最终成为一个复杂、没有灵活性的庞然大物，进行维护和更新会变得越来越困难。此外，如果企业已经具有多个单体服务架构的应用，这些应用之间会存在资源的重复和浪费，并且难以相互联系。此外，随着企业的业务发展，需要按照业务领域来划分和提供服务。基于这些考虑，提出了微服务架构。微服务架构将单体应用按照业务领域拆分为多个高内聚低耦合的微服务，每个微服务独立运行，分别开发、部署和维护，服务间采用接口来相互通信。因此，微服务架构增强了可用性、扩展性、减少单个微服务的调整对整个平台的影响。然而，微服务架构的应用的管理更加复杂，因此存在对用于对微服务架构的系统进行管理的需求。

发明内容

本公开的目的是提供一种用于对微服务架构的系统进行管理的方法、系统和计算机可读介质。

根据本公开的一个示例性实施例，提供了一种用于对微服务架构的系统进行管理的方法，包括：在具有显示器、一个或多个处理器和存储器的电子设备处：根据系统接收到的对一个或多个应用程序接口API的来自客户端的请求所经过的链路的信息，确定系统中被调用的各个节点以及与所述链路对应的、所调用的各个节点之间的连接关系，应用程序接口由部署在节点上的微服务提供；在显示器上显示图形用户界面，所述图形用户界面包括系统中的被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。

根据本公开的另一个示例性实施例，提供了一种电子系统，包括：存储器，被配置为存储一系列计算机可执行指令；和处理器，被配置为执行一系列计算机可执行指令，其中，一系列计算机可执行指令在由处理器执行时使处理器执行根据本公开的实施例的方法的步骤。

根据本公开的在一个示例性实施例，提供了一种具有存储在其上的指令的非暂时性计算机可读介质，该指令在由处理器执行时使处理器执行根据本公开的实施例的方法的步骤。

根据下文给出的详细描述，本公开的进一步的适用范围将变得显而易见。然而，应当理解，详细说明和具体示例虽然指示了本公开的优选实施例，但是仅以说明的方式给出，因为在本公开的精神和范围内的各种改变和修改对于本领域技术人员而言将是显而易见的。

附图说明

通过以下结合附图对示例性实施例的详细描述，本发明的上述和其他方面以及优点将变得显而易见，所述附图以示例的方式示出了本发明的原理。注意，附图不一定按比例绘制。

图1示出了根据本公开的示例性实施例的微服务架构的系统的示意图。

图2是示出了根据本公开的实施例的用于对微服务架构的系统进行管理的方法的流程图。

图3是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图4是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图5是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图6是示出了根据本公开的实施例的用于对微服务架构的系统进行管理的方法的流程图。

图7是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图8是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图9是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图10是示出了根据本公开的实施例的用于对微服务架构的系统进行管理的方法的流程图。

图11是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图12是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图13是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图14是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图15是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图16是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图17是根据本公开的实施例的在显示器上的图形用户界面的示意图。

图18是根据本公开的示例性实施例的电子设备的示意图。

具体实施方式

在以下详细描述中，阐述了许多具体细节以提供对所描述的示例性实施例的透彻理解。然而，对于本领域的技术人员将显而易见的是，可以在没有一些或所有这些具体细节的情况下实施所描述的实施例。在其他示例性实施例中，未详细描述众所周知的结构或处理步骤，以避免不必要地使本公开的概念模糊。

图1示出了根据本公开的示例性实施例的微服务架构的系统的示意图。如图1所示，在微服务架构的系统100中，具有应用程序接口(API)网关节点101-102、微服务节点103-106、数据库节点107、微服务发现和管理节点108和网络防火墙109。

API网关节点101-102用于对系统100中的所有微服务提供统一的服务入口，使得微服务对于系统外是透明的。此外，API网关节点101-102还可以对提供相同微服务的多个节点进行负载均衡和服务分流，并提供安全、过滤、流量控制等管理功能。图中示出了两个API网关节点101和102，但是本领域技术人员可以理解，API网关节点也可以为一个或者多于两个。微服务节点103-106上部署了微服务，并提供对应的API。微服务节点103-106可以是单个或多个物理或虚拟主机上部署的微服务实例，也可以是分别部署到对应的容器中的微服务实例。容器技术例如为Docker技术和Solaris Zone技术等。在本公开的实施例中，每个微服务节点上部署一个微服务，并且该微服务可以具有一个或多个API。本领域技术人员可以明白，根据系统中部署的微服务的个数以及每个微服务的副本的个数，微服务节点的数目可以为几个到几十个，甚至上百个。

在图1的示例中，假设微服务节点103和微服务节点104上部署了相同的微服务，也就是说，二者互为备份。假设微服务节点103和微服务节点104上微服务都为微服务1，并且二者的应用程序接口都为API 1。另外，假设微服务节点105和106上部署的微服务彼此不同，并且与微服务节点103和104上部署的微服务也不相同。假设微服务节点105和微服务节点106上的微服务分别为微服务2和微服务3，二者的应用程序接口分别为API 2和API 3。

数据库节点107为微服务节点103-106提供数据支持。数据库节点107可以采用Redis数据库、MySQL数据库等。在本公开的一个实施例中，多个微服务节点共用一个数据库。在本公开的另一个实施例中，每个微服务节点具有相应的数据库，因此图1中所示的数据库节点107可以被拆分并合并到每个微服务节点中，并且每个微服务节点的数据库是彼此隔离的。微服务发现和管理节点108被配置为发现、配置和管理微服务节点103-106。微服务发现和管理节点108能够发现系统10中新增的微服务节点，记录节点上部署的微服务的ID和API标识，记录微服务节点的运行状态，管理节点上部署的微服务的上线和下线等。微服务发现和管理节点108的具体示例例如包括Nacos和Eureka等。网络防火墙109用于保护网络，使其不受到攻击。网络防火墙109的示例包括Web应用防火墙(WAF)等。此外，在微服务架构的系统10的外部(前端)，还存在客户端10。客户端10可以为计算机、移动终端等中运行的应用，包括网络平台站点、计算机上的软件、移动App等。图1中示出了三个客户端，分别具有ID1、ID2和ID3来作为标识。

在图1中所示的微服务架构的系统100工作时，API网关节点101从系统100外的客户端10接收对于一个或多个应用程序接口(API)的请求。API网关节点101根据所接收的请求中所携带的微服务ID和API标识，将该请求发送到对应的微服务节点。微服务节点的API接收到请求之后，对请求进行处理并返回数据。

从图1中可以看出，微服务架构的系统100是比较复杂的，因此需要一种简单、直观的对微服务架构的系统进行管理方法。

图2是示出了根据本公开的实施例的用于对微服务架构的系统进行管理的方法200的流程图。该方法是在具有显示器、一个或多个处理器和存储器的电子设备处实施的。电子设备是可以应用于本公开的各方面的硬件设备的示例，并且可以是被配置为执行处理和/或计算的任何机器，包括但不限于工作站、服务器、台式计算机、膝上型计算机、平板计算机、个人数据助理、智能电话、车载计算机或其任何组合。对于电子设备的一般结构，会在之后结合图18进行说明。

如图2所示，在步骤S201处，根据系统接收到的对一个或多个应用程序接口API的来自客户端的请求所经过的链路的信息，确定系统中被调用的各个节点以及与所述链路对应的、所调用的各个节点之间的连接关系。如上文所述，应用程序接口由部署在节点上的微服务提供。

之后，在步骤S202处，在显示器上显示图形用户界面，所述图形用户界面包括系统中的被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。

通过以上步骤，可以在图形用户界面中将微服务架构的系统10中被对应用程序接口的请求调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示显示出来。由此，在图形用户界面中显示的图包括节点的图形表示和节点的连接关系的图形表示，并且可以被称作为系统拓扑图。因此，可以得到微服务架构的系统的拓扑图，有助于管理员直观地管理查看被调用的节点。此外，在系统中的节点或节点上部署的微服务发生变化时，可以直接根据接收到的对API的请求所经过的链路的信息来更新微服务架构的系统的拓扑图，而不需要管理员进行任何手动操作。

图3是根据本公开的实施例的在显示器上的图形用户界面的示意图。如图3所示，图形用户界面中显示出了应用程序接口(API)网关节点101-102、微服务节点103-106、数据库节点107、微服务发现和管理节点108和网络防火墙109的图形表示。在本实施例中，系统中的节点的图形表示为与节点的类型对应的图标。每个节点的图标都是由发明人根据节点的类型来精心设计的，效果直观且美观。此外，系统中的节点的图形表示还可以包括说明文字，以说明节点的信息，例如，IP地址、节点类型等。为了图示清楚，在图中没有提供这些说明文字。图3的示例中微服务节点103-106的配置与图1中所示的配置类似。也就是说，假设微服务节点103和微服务节点104上微服务都为微服务1，并且二者的应用程序接口都为API1。另外，微服务节点105和微服务节点106上的微服务分别为微服务2和微服务3，二者的应用程序接口分别为API 2和API 3。

在图3中所示出的系统的拓扑图中，来自系统10外部(前端)的客户端(在图3中未示出)的对于API 1、API 2和API 3的请求分别进入系统10。系统10所接收的请求中携带了所请求的API的标识(即，API 1、API 2和API 3)以及对应的微服务的ID(即，微服务1、微服务2和微服务3)。在经过网络防火墙109之后，这些请求到达API网关节点101和102。在API网关节点101和102处，分析请求中携带的微服务的ID和API的标识，并将对应的请求发送到对应的微服务节点的应用程序接口。在需要时，API网关节点101和102可以与微服务发现和管理节点108通信来获得微服务架构的系统10中可用的微服务节点和地址以及对应的微服务ID和API的标识，从而能够正确地发送对API的请求。此外，在多个微服务节点部署了相同的微服务时，API网关节点101和102可以在这些微服务节点之间进行负载均衡、服务分流等控制。具体来说，对于API 1的请求被API网关节点101和102发送到具有API 1的微服务节点103和104，对于API 2的请求被API网关节点101和102发送到具有API 2的微服务节点105，而对于API 3的请求被API网关节点101和102发送到具有API 3的微服务节点106。另外，微服务节点103-106可以与数据库节点107通信来取得所需数据。此外，微服务节点103-106可以与微服务发现和管理节点108通信，使得微服务发现和管理节点108知晓微服务节点上部署的微服务的ID和API的标识以及微服务节点的当前状态等。

根据来自客户端的对于API的请求的链路，可以确定对请求的处理过程中被调用的节点以及节点之间的连接关系。由此，在图3所示的用户界面中，显示出了应用程序接口(API)网关节点101-102、微服务节点103-106、数据库节点107、微服务发现和管理节点108和网络防火墙109的图形表示，以及这些节点之间的连接关系。请注意，微服务发现和管理节点108作为系统10的重要基础设施，在请求的处理过程中可以与各个API网关节点以及各个微服务节点通信，为了不至于使得图形用户界面中的拓扑图变得过于复杂，省略了微服务发现和管理节点108与其他节点之间的连接关系。

在以上实施例中，由于所显示的节点是根据来自客户端的请求所经过的链路的信息来确定的，所以只有接收到请求的节点才会被显示在用户界面中。因此，可以动态地更新系统的拓扑图，并且隐藏未被调用的节点。由此，可以避免系统的拓扑图变得过于复杂，并且仅向管理员提供所需的信息。

在根据本公开的实施例中，图形用户界面仅包括在预定时间段内被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。也就是说，在本实施例中，与在预定时间段内未被调用的节点的图形表示以及与该节点相关联的连接关系的图形表示不会被显示。因此，在本实施例中，即使在预定时间段之前，一个节点被调用并且该节点的图形表示以及与该节点相关联的连接关系的图形表示都被显示，但是如果在预定时间段内该节点未被调用，该节点的图形表示以及与该节点相关联的连接关系的图形表示可以被从图形界面上移除。由此，可以动态地删除未被调用的节点，从而更新系统的拓扑图。

在根据本公开的实施例中，被调用的节点与多个应用程序接口相关联。换句话说，当客户端对多个应用程序接口发出的请求时，具有这些多个应用程序接口的微服务节点都会被调用。如图1所示，与API 1、API 2和API 3相关联的微服务节点被调用并被显示出来。因此，所获得的图形界面上的系统的拓扑图包括整个系统针对多个应用程序接口的处理过程的拓扑图，而不会局限于针对某一个应用程序接口的拓扑图。因此，根据本公开的实施例，能够获得系统的全局的拓扑图。由此，系统的管理员可以掌握系统的全局的拓扑，有助于他管理系统。另外，本领域技术人员可以明白，当一个微服务节点包括多个应用程序接口时，客户端可能对一个微服务节点的多个应用程序接口发出请求。在这种情况下，系统的拓扑图中可能会仅显示一个微服务节点，并且这种系统拓扑图仍然属于全局拓扑图。

另外，如图2所示，在本公开的实施例中，在步骤S202之后，还可以包括步骤S203。由于步骤S203是可选的，所以在图2中示出为虚线框。

在步骤S203中，响应于所述图形用户界面上用于选择系统中的任一节点的第一用户输入，显示所选择的节点的当前状态的表示。第一用户输入例如可以是用户点击或触摸用户界面上的任一节点的图形表示，或者用户将输入设备的指示器(例如，鼠标指针)停留在任一节点的图形表示上达预定时间段。

图4是根据本公开的实施例的用户界面的示意图。如图4所示，响应于选择微服务节点103的第一用户输入，可以在图形用户界面的右侧显示所选择的节点的当前状态的表示401。图4中以微服务节点103上部署的微服务的标识(微服务1)、节点被成功调用的次数(1000次)和节点的调用失败的次数(0次)作为节点的当前状态的示例进行了图示，这些数值可以是在预定时间段(例如，24小时)内获得的。除此之外，节点的当前状态还可以包括节点的当前负载、节点所服务的用户中的至少一个，并且本领域技术人员可以根据需要进行设置。

根据该实施例，系统的管理员可以通过简单的操作来获得各个节点的当前状态。

另外，如图2所示，在本公开的实施例中，在图2所示的方法200中，还可以包括步骤S204-S205。由于步骤S204-S205是可选的，所以在图2中示出为虚线框。

在步骤S204中，响应于所述图形用户界面上用于选择系统中的一个节点的第二用户输入显示该节点的可配置属性的表示。第二用户输入可以是例如管理员用右键点击节点的图形表示，或者点击图4中示出的节点的当前状态的表示401。节点的可配置属性例如包括该节点上部署的微服务的上线和下线，而节点的可配置属性的表示可以包括表示微服务的上线或下线的图标和/或按钮。之后，如果接收到所述图形用户界面上针对该节点的可配置属性的表示的第三用户输入，那么在步骤S205中响应于该第三用户输入改变该被节点的属性。第三用户输入例如是点击节点的当前状态的表示并点击节点的可配置属性的表示(例如，表示微服务的上线或下线的图标)，并且响应于第三输入，节点的属性被改变(例如，节点被上线或下线)。

如图5所示，示出了作为微服务的下线的图标的按钮501。在管理员希望将微服务节点103上的微服务1下线时，管理员可以点击或触摸下线按钮来完成该操作。

根据该实施例，系统的管理员可以通过简单的操作来管理各个节点的可配置的属性。

接下来参照图6，图6是对微服务架构的系统进行管理的方法200的流程图，并且是图2所示的流程图的继续。

如图6所示，在图2和图6所示的方法200中，还可以包括步骤S206-S207。由于步骤S206-S207是可选的，所以在图6中示出为虚线框。

在步骤S206中，响应于所述图形用户界面上与任一微服务对应的第四用户输入，在所述图形用户界面上显示部署该微服务的节点的列表以及对列表中的每个节点所分配的请求的权重。与任一微服务对应的第四用户输入例如可以是用户在图形用户界面的搜索栏中搜索任一微服务或在下拉菜单中选择任一微服务。每个节点所分配的请求的权重可以由权重数值或各节点的权重在环形图中所占比例来表示。之后，如果接收到所述图形用户界面上针对对任一节点所分配的请求的权重的第五用户输入，那么在步骤S207中，响应于第五用户输入改变对该节点所分配的请求的权重。第五用户输入例如可以是直接修改所显示的每个节点所分配的请求的权重的数值或者拖动表示每个节点所分配的请求的权重的滑动块。

图7是根据本公开的实施例的用户界面的示意图。如图7所示，示出了搜索栏701。当用户在搜索栏701中搜索微服务1时(第四用户输入)，在用户界面的右侧的框702中会显示部署有微服务1的微服务节点的列表(即，微服务节点103和微服务节点104)和各个节点所分配的权重。如图7所示，微服务节点103和微服务节点104都被分配了50％的权重。框702上方的环形图更加直观地展示出了微服务节点103和微服务节点104被分配的权重。之后，当管理员选择并修改每个节点所分配的请求的权重的数值时(第五用户输入)，可以改变各个节点所分配的权重。作为示例，在一个微服务部署在多个微服务的节点上时，这些微服务节点的权重之和可以为100％。此外，一个微服务节点的权重可以被设置为0％，并且在这种情况下，该微服务节点不会收到请求。通过将某一微服务节点的权重设置为0％，可以方便地对该为服务节点进行更新等。此外，通过改变各个节点的权重，可以在某一微服务节点升级之后将少量请求引导到该微服务节点上来进行升级后的测试。根据该实施例，系统的管理员可以通过简单的操作来改变部署有同一个微服务的各个节点在处理对API的请求时的权重。

如图6所示，在图2和图6所示的方法200中，还可以包括步骤S208-S209。由于步骤S208-S209是可选的，所以在图6中示出为虚线框。

在步骤S208中，响应于所述图形用户界面上与任一微服务对应的第六用户输入，在所述图形用户界面上显示部署该微服务的节点的列表以及对列表中的每个节点所分配的客户端的列表。与任一微服务对应的第六用户输入例如可以是用户在图形用户界面的搜索栏中搜索任一微服务或在下拉菜单中选择任一微服务。之后，如果接收到所述图形用户界面上针对对任一节点所分配的客户端的列表的第七用户输入，那么在步骤S209中，响应于第七用户输入改变对该节点所分配的客户端。第七用户输入例如可以是勾选或反勾选与客户端对应的复选框或者是在客户端的列表中填入或删除客户端的ID等。

图8是根据本公开的实施例的用户界面的示意图。如图8所示，与图7类似，示出了搜索栏801。当用户在搜索栏801中搜索微服务1时(第六用户输入)，在用户界面的右侧的框802中会显示部署有微服务1的微服务节点的列表(即，微服务节点103和微服务节点104)和对列表中的每个节点所分配的客户端的列表(即，客户端ID1、客户端ID2和客户端ID3)。如图8所示，客户端ID1、客户端ID2和客户端ID3都对微服务节点103和微服务节点104上部署的微服务1的API 1发出了请求。图8中作为示例示出了微服务节点103被分配了客户端ID1和客户端ID3，而微服务节点104被分配了客户端ID1和客户端ID2。之后，当管理员勾选或反勾选与客户端分别对应的复选框时(第七用户输入)，可以改变为每个微服务节点所分配的客户端。具体来说，对应的复选框被勾选的客户端表示该客户端的请求会被分配给相应的微服务节点。相反，对应的复选框没有被勾选的客户端表示该客户端的请求不会被分配给相应的微服务节点。由此，例如在微服务节点103和104彼此性能不同时，可以针对不同的用户提供不同性能的节点，改善用户的感受。此外，当一个微服务节点下的客户端都没有被勾选时，该微服务节点不会收到来自客户端的请求，并因此将某一微服务节点的权重设置为0％，从而可以方便地对该为服务节点进行更新等。此外，通过针对用户来改变各个节点的权重，可以在某一微服务节点升级之后将特定用户引流到该微服务节点上来进行升级后的测试。另外，与某一个客户端对应的复选框在所列出的微服务节点下都没有被勾选时，那么该客户端的请求不会被分配给所有的部署有微服务1的微服务节点。因此，可以实现类似于客户端权限控制的效果。

根据该实施例，系统的管理员可以通过简单的操作来针对用户来改变部署有同一个微服务的各个节点在处理对API的请求时的权重。

在本公开的一个实施例中，在步骤S206之后以及在步骤S208之后，被调用的节点的图形表示可以包括该节点所承载的请求的权重。如图7中的703和图8中的803所示，节点当前所承载的请求的权重被显示在节点的图标附近。通过查看所显示的节点所承载的请求的权重，管理员可以简单、直观地检查各个节点的权重以及权重的变化。图7中可以看出，虽然微服务节点103和104所指定的权重均为50％，但这两个微服务节点所实际承载的请求的权重可能会与指定的权重不同，并且随着系统10的工作而逐渐接近并最终等于指定权重。

如图6所示，在图2和图6所示的方法200中，还可以包括步骤S210。由于步骤S210是可选的，所以在图6中示出为虚线框。

在步骤S210中，响应于所述图形用户界面上与任一微服务对应的第八用户输入，在所述图形用户界面上突出显示与该微服务相关联的请求的链路对应的连接关系的图形表示。与任一微服务对应的第八用户输入例如可以是用户在图形用户界面的搜索栏中搜索任一微服务或在下拉菜单中选择任一微服务。

图9是根据本公开的实施例的用户界面的示意图。如图9所示，与图7类似，示出了搜索栏901。当用户在搜索栏901中搜索微服务1时(第八用户输入)，部署有微服务1的微服务节点103和104与API网关节点101和102之间的连接线被突出显示。突出显示可以是改变连接线的颜色、改变连接线的粗细、改变连接线的线条图案等。

根据该实施例，管理员可以直观地了解与微服务1有关的拓扑关系。

根据本公开的一个实施例，被突出显示的连接关系的图形表示包括连接线，并且该连接线的颜色表示链路上的下游节点对来自上游节点的请求的响应时间。例如，如图9所示，API网关节点101与微服务节点103之间的连接线的颜色表示微服务节点103对于来自API网关节点101的请求的响应时间。响应时间较短时，该连接线的颜色可以为绿色，而响应时间越长，连接线的颜色就越向红色方向改变。

根据该实施例，管理员可以直观地了解各个节点对于请求的反映时间，并且能够尽快地发现发生故障的节点。

根据本公开的一个实施例，被突出显示的连接关系的图形表示包括虚线的连接线，并且虚线的连接线上的各个虚线点沿着从虚线的上游节点一侧到下游节点一侧的方向依次突出显示。例如，如图9所示，API网关节点101与微服务节点103之间的连接线的虚线点沿着从API网关节点101一侧到微服务节点103一侧的方向依次突出显示，从而获得连接线沿着请求的链路的方向移动的动态效果。

根据该实施例，管理员可以直观地了解请求的链路在系统10的拓扑图中的发送方向，有助于更加清楚地理解并检查系统10的拓扑结构并发现拓扑结构中的故障点。

根据本公开的一个实施例，按照从链路上的上游节点到下游节点的顺序依次显示被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。突出显示节点的图形表示可以包括改变节点的图形标识的颜色、尺寸以及增加动态效果等。例如，如图9所示，按照对于微服务1的API 1的请求的链路，可以先突出显示API网关节点101，之后再突出显示API网关节点101与微服务节点103和104之间的连接线，并且最后再突出显示微服务节点103和104。由此，可以通过动态效果来直观地表示对于微服务1的API 1的请求的链路的形成过程。

根据该实施例，管理员可以直观地了解请求的链路在系统10的拓扑图中的发送方向，有助于更加清楚地理解并检查系统10的拓扑结构并发现拓扑结构中的故障点。特别地，当链路中的节点比较多时，该实施例可以清楚地表示请求在链路中的发送，这对于管理复杂的系统是非常有利的。

接下来参照图10，图10是对微服务架构的系统进行管理的方法200的流程图，并且是图2和图6所示的流程图的继续。

如图10所示，在图2、图6和图10所示的方法200中，还可以包括步骤S211。由于步骤S211是可选的，所以在图10中示出为虚线框。

在步骤S211中，响应于所述图形用户界面上与对任一应用程序接口的请求对应的第九用户输入，在所述图形用户界面上突出显示与对该应用程序接口的请求对应的被调用的节点之间的连接关系的图形表示。与任一API对应的第九用户输入例如可以是用户在图形用户界面的搜索栏中搜索任一API或在下拉菜单中选择任一API。

图11是根据本公开的实施例的用户界面的示意图。如图11所示，与示出了搜索栏1101。当用户在搜索栏1101中搜索API 1时(第九用户输入)，在图形用户界面上突出显示与对API 1的请求对应的被调用的节点之间的连接关系的图形表示。被调用的节点包括网络防火墙109、API网关节点101和102、微服务节点103和104以及数据库节点107。因此，如图11所示，这些节点之间的连接关系的图形表示(连接线1102)都被突出显示。突出显示可以是改变连接线的颜色、改变连接线的粗细、改变连接线的线条图案等。

根据该实施例，管理员可以直观地了解与API 1有关的拓扑关系。

此外，与上文类似地，根据本公开的一个实施例，被突出显示的连接关系的图形表示包括连接线，并且该连接线的颜色表示链路上的下游节点对来自上游节点的请求的响应时间。由此，管理员可以直观地了解各个节点对于请求的反映时间，并且能够尽快地发现发生故障的节点。

此外，与上文类似地，根据本公开的一个实施例，被突出显示的连接关系的图形表示包括虚线的连接线，并且虚线的连接线上的各个虚线点沿着从虚线的上游节点一侧到下游节点一侧的方向依次突出显示。由此，管理员可以直观地了解请求的链路在系统10的拓扑图中的发送方向，有助于更加清楚地理解并检查系统10的拓扑结构并发现拓扑结构中的故障点。

此外，与上文类似地，根据本公开的一个实施例，按照从链路上的上游节点到下游节点的顺序依次显示被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。突出显示节点的图形表示可以包括改变节点的图形标识的颜色、尺寸以及增加动态效果等。例如，如图11所示，按照对于微服务1的API 1的请求的链路，可以先突出显示网络防火墙109，之后突出显示网络防火墙与API网关节点101和102之间的连接线，之后突出显示API网关节点101和102，之后突出显示API网关节点101与微服务节点103之间的连接线，之后突出显示微服务节点103和104，之后突出显示微服务节点103和104与数据库节点107之间的连接线，最后再突出显示数据库节点107。由此，可以通过动态效果来直观地表示对于微服务1的API 1的请求的链路的形成过程。

由此，管理员可以直观地了解请求的链路在系统10的拓扑图中的发送方向，有助于更加清楚地理解并检查系统10的拓扑结构并发现拓扑结构中的故障点。特别地，当链路中的节点比较多时，该实施例可以清楚地表示请求在链路中的发送，这对于管理复杂的系统是非常有利的。

如图10所示，在图2、图6和图10所示的方法200中，还可以包括步骤S212。由于步骤S212是可选的，所以在图10中示出为虚线框。

在步骤S212中，响应于所述图形用户界面上与对任一应用程序接口的请求对应的第十用户输入，在所述图形用户界面上显示与对该应用程序接口的请求对应的被调用的节点的列表。与任一API对应的第十用户输入例如可以是用户在图形用户界面的搜索栏中搜索任一API或在下拉菜单中选择任一API。

图12是根据本公开的实施例的用户界面的示意图。如图12所示，与示出了搜索栏1201。当用户在搜索栏1201中搜索API 1时(第十用户输入)，在所述图形用户界面上显示与对该应用程序接口的请求对应的被调用的节点的列表。被调用的节点包括网络防火墙109、API网关节点101和102、微服务节点103和104以及数据库节点107。因此，如图12所示，在用户界面的右侧的框1202中显示这些节点的列表。

根据该实施例，管理员可以清楚地确定与任一API对应的链路上的所有节点。

另外，与图11中类似地，如图12中的连接线1202所示，被调用的节点之间的连接关系的图形表示也可以被突出显示，在此不再重复。

接下来，如图10所示，在步骤S212之后，还可以包括步骤S213。由于步骤S213是可选的，所以在图10中示出为虚线框。

在步骤S213中，响应于所述图形用户界面上用于选择列表中的任一节点的第十一用户输入，显示所选择的节点的当前状态的表示。对于任一节点的第十一用户输入可以是点击或触摸列表中的节点的表示。

图13是根据本公开的实施例的用户界面的示意图。如图13所示，API网关节点101被第十一用户输入选择，并且因此显示了该API网关节点101的状态。图13中以API网关节点101的功能的标识(API网关1)、节点被成功调用的次数(2000次)、节点的调用失败的次数(0次)以及节点响应时间作为节点的当前状态的示例进行了图示，这些数值可以是在预定时间段(例如，24小时)内获得的。除此之外，节点的当前状态还可以包括节点的当前负载、节点所服务的用户中的至少一个，并且本领域技术人员可以根据需要进行设置。此外，如图13中所示，微服务节点103也可以被第十一用户输入选择，并且因此显示了微服务节点103的状态。微服务节点103的状态与参照图4进行描述的内容类似，在此不再重复。

根据该实施例，系统的管理员可以通过简单的操作来获得期望API的链路上的各个节点的当前状态。

另外，与图11和图12中类似地，如图13中的连接线1302所示，被调用的节点之间的连接关系的图形表示也可以被突出显示，在此不再重复。

如图10所示，在图2、图6和图10所示的方法200中，还可以包括步骤S214-S215。由于步骤S214-S215是可选的，所以在图10中示出为虚线框。

在步骤S214中，响应于所述图形用户界面上的第十二用户输入，显示系统的与限流有关的参数的表示。第十二用户输入例如是点击或触摸系统设置图标的操作。系统的参数包括以下至少之一：系统中待处理的全部请求的数目的上限、系统中的每个微服务待处理的请求的数目的上限和系统中的每个应用程序接口待处理的请求的上限。显示系统的与限流有关的参数的表示包括相应的参数和该参数的设置值。之后，如果接收到所述图形用户界面上针对系统的与限流有关的参数的表示的第十三用户输入，在步骤S215中，响应于第十三用户输入改变系统的与限流有关的参数。第十三用户输入例如可以是直接修改所显示的与限流有关的参数的数值或者拖动表示与限流有关的参数的数值的滑动块。

图14是根据本公开的实施例的用户界面的示意图。如图14所示，显示器上的图形用户界面包括系统设置图标1401。在点击或触摸系统设置图标1401之后，在显示器上的图形用户界面上显示与限流有关的参数的表示。在图14中，针对系统的全部请求限制、针对每个微服务的请求限制和针对每个应用程序接口的请求限制，分别示出了系统中待处理的全部请求的数目的上限、系统中的每个微服务待处理的请求的数目的上限和系统中的每个应用程序接口待处理的请求的上限。用户可以更改所显示的设置值来对这些参数进行设置。所设置的请求的数目的上限指的是当前系统中所接收到并且还未处理完成的请求，并且因此已经成功完成的请求的数目不被包括在该限制内。

在图14为了表述的方便同时示出了针对系统的全部请求限制、针对每个微服务的请求限制和针对每个应用程序接口的请求限制，但是本领域技术人员可以明白，图形用户界面上可以仅显示其中的一个或两个。或者，图形用户界面上可以提供选项卡，以在这三种请求限制之间进行切换。

本领域技术人员可以明白，当这些参数存在冲突时，可以优先考虑系统的全部请求限制，之后再考虑每个微服务的请求限制，并且最后考虑应用程序接口的请求限制。也就是说，当系统的全部请求限制小于对某个微服务的请求限制时，以系统的全部请求限制的参数为准对系统进行限流。类似地，当对某个微服务的请求限制小于对该微服务的应用程序接口的请求限制时，以该微服务的请求限制为准对微服务进行限流。

根据本实施例，可以非常简单地针对系统的全部请求限制、针对每个微服务的请求限制和针对每个应用程序接口的请求限制进行设置，降低操作复杂度。此外，通过本公开的其他实施例的技术方案，可以简单直接地检验经过设置的请求限制是否被正确执行。因此，可以降低管理员对系统10进行管理的复杂度。

如图10所示，在图2、图6和图10所示的方法200中，还可以包括步骤S216。由于步骤S216是可选的，所以在图10中示出为虚线框。

在步骤S216中，响应于所述图形用户界面上指示进行数据统计的第十四用户输入，显示与系统相关的数据的统计结果。与系统相关的数据包括预定时间段内的以下数据中的至少一项：接收到的请求的数量、对请求的平均响应时间、处理完成的请求的数量、处理失败的请求的数量。统计结果可以为表格的形式或者柱状图、饼状图等形式。本领域技术人员可以想到其他需要统计的数据，并且这些数据的统计结果都可以在步骤S216中被显示在图形用户界面上。

图15是根据本公开的实施例的用户界面的示意图。如图15所示，显示器上的图形用户界面包括数据统计图标1501。在点击或触摸数据统计图标1501之后，在显示器上的图形用户界面上显示与系统相关的数据的统计结果。在图15中，以接收到的请求的数量、对请求的平均响应时间、处理完成的请求的数量、处理失败的请求的数量为例进行了数据统计。本领域技术人员可以根据需要来统计其他数据。

在本公开的一个实施例中，还可以根据需要设置数据统计的参数，包括统计时间段、统计的微服务ID、统计的接口标识、统计的节点等。本领域技术人员可以想到现有的各种对数据统计的参数进行设置的方式，在此不再进行详细说明。

根据该实施例，可以简单地提供系统10的工作情况的统计结果，方便管理员来监视和统计系统10的工作状态。

如图10所示，在图2、图6和图10所示的方法200中，还可以包括步骤S217。由于步骤S217是可选的，所以在图10中示出为虚线框。

在步骤S217中，响应于所述图形用户界面上的第十五用户输入，改变所述图形用户界面中的节点的图形表示。改变所述图形用户界面中的节点的图形表示包括以下至少之一：改变节点的图标、改变节点的图形表示的排列方式、改变节点的图形表示的间距。本领域技术人员可以想到其他需要设置的参数，并且在步骤S217中对这些参数进行设置。

图16是根据本公开的实施例的用户界面的示意图。如图16所示，显示器上的图形用户界面包括系统设置图标1601。在点击或触摸系统设置图标1601之后，在显示器的图形用户界面上显示节点的图形表示的设置参数的框1602。在框1602中，提供了各种参数，来设置节点的图标、节点的图形表示的排列方式、节点的图形表示的间距等。

通过该实施例，可以简单地设置系统10的拓扑图的参数，以方便管理员找到最适合的节点的图形表示。

如图10所示，在图2、图6和图10所示的方法200中，还可以包括步骤S218。由于步骤S218是可选的，所以在图10中示出为虚线框。

在步骤S218中，在图形用户界面中显示与系统延迟有关的表示，并且在系统的延迟超出阈值时发出警告。与系统延迟有关的表示可以包括图形表示、系统的延迟包括以下至少一项：系统对API的请求的整个响应时间、各个节点对API的请求的响应时间。本领域技术人员能够想到其他表示系统延迟的参数，并对其进行监视和警告。

图17是根据本公开的实施例的用户界面的示意图。如图17所示，当检测到系统的延迟超出阈值时，在显示器的图形用户界面上显示系统高延迟警报1701，并且显示与延迟有关的表示(表格1702)。在表格中，列出了发生高延迟的API标识，发生高延迟的链路以及具体响应时间。如图17所示，发生高延迟的链路可以是拓扑图中的节点之间的链路，表示某个节点对API的请求的响应时间，也可以是系统的总响应时间。

通过该实施例，在系统发生高延迟时，可以迅速准确地通知管理员出现问题的链路，帮助管理员尽快解决问题。

本领域技术人员可以明白，结合图2、图6和图10描述的步骤S203-S218可以按照需求来有选择性地执行，而不是必须全部执行。此外，虽然步骤S203-S218结合图2、图6和图10按照以上描述的顺序进行说明，但是这些步骤的执行顺序并不是固定的。具体来说，一些步骤可以在其他步骤之前执行，并且一些步骤可以和其他的步骤合并在一起同时进行。此外，本领域技术人员可以明白上述的第一到第十五用户输入也可以彼此组合。也就是说，在某一个步骤中的用户输入可以同时作为另一个步骤中的用户输入，并且因此可以同时执行两个步骤。

在根据本公开的实施例中，微服务架构的系统为采用微服务架构的中台系统，或者采用微服务架构的其他系统。根据本公开的实施例的方法可以同时应用到多个独立的微服务架构系统并对它们分别进行管理。本领域技术人员可以想到，通过接收用于切换被管理的微服务架构系统的用户输入，根据本公开的实施例的方法可以在多个独立的微服务架构系统之间切换。例如，可以在显示器的图形用户界面上提供按钮选项或下拉菜单选项来允许管理员随时切换被管理的微服务架构系统。由此，管理员可以轻松地管理多个微服务架构系统。

现在参考图18，示出了根据本公开的示例性实施例的、本公开可适用的一般硬件环境的示意图。

参考图18，现在将描述电子设备1800，该电子设备1800是可以应用于本公开的各方面的硬件设备的示例。电子设备1800可以是被配置为执行处理和/或计算的任何机器，可以是但不限于工作站、服务器、台式计算机、膝上型计算机、平板计算机、个人数据助理、智能电话、车载计算机或其任何组合。前述用于日值得归档系统的方法中的步骤可以全部或至少部分地由电子设备1800或类似设备或系统来实施。

电子设备1800可以包括可能经由一个或多个接口与总线1802连接或通信的元件。例如，电子设备1800可以包括总线1802、一个或多个处理器1804、一个或多个输入设备1806和一个或多个输出设备1808。一个或多个处理器1804可以是任何种类的处理器，并且可以包括但不限于一个或多个通用处理器和/或一个或多个专用处理器(例如特殊处理芯片)。输入设备1806可以是可以向电子设备输入信息的任何种类的设备，并且可以包括但不限于鼠标、键盘、触摸屏、麦克风和/或遥控器。输出设备1808可以是可以呈现信息的任何种类的设备，并且可以包括但不限于显示器、扬声器、视频/音频输出端子、振动器和/或打印机。电子设备1800还可以包括非暂时性存储设备1810或与非暂时性存储设备1810连接，该非暂时性存储设备1810可以是非暂时性的并且可以实施数据存储的任何存储设备，并且可以包括但不限于磁盘驱动器、光学存储设备、固态存储器、软盘、软盘、硬盘、磁带或任何其他磁性介质、光盘或任何其他光学介质、ROM(只读存储器)、RAM(随机存取存储器)、高速缓存和/或任何其他存储芯片或盒带和/或计算机可以从中读取数据、指令和/或代码的任何其他介质。非暂时性存储设备1810可以是与接口可分离的。非暂时性存储设备1810可以具有用于实施上述方法和步骤的数据/指令/代码。电子设备1800还可以包括通信设备1812。通信设备1812可以是能够与外部设备和/或与网络进行通信的任何类型的设备或系统，并且可以包括但不限于调制解调器、网络卡、红外通信设备、无线通信设备和/或芯片组(例如蓝牙设备、1302.11设备、WiFi设备、WiMax设备、蜂窝通信设施等)。

电子设备1800还可以包括工作存储器1814，该工作存储器可以是可以存储对处理器1804的工作有用的指令和/或数据的任何种类的工作存储器，并且可以包括但不限于随机存取存储器和/或只读存储设备。

软件元素可以位于工作存储器1814中，包括但不限于操作系统1816、一个或多个应用程序1818、驱动器和/或其他数据和代码。可以在一个或多个应用程序1818中包括用于执行上述方法和步骤的指令，并且可以通过处理器1804读取并执行一个或多个应用的指令来实施方法的步骤。可以将软件元素的指令的可执行代码或源代码存储在非暂时性计算机可读存储介质(例如上述存储设备1810)中，并且可以通过编译和/或安装将其读取到工作存储器1814中。也可以从远程位置下载软件元素的指令的可执行代码或源代码。

还应当理解，可以根据具体要求进行改变。例如，也可以使用定制的硬件，以及/或者特定元件可以以硬件、软件、固件、中间件、微代码、硬件描述语言或其任意组合来实施。此外，可以采用到诸如网络输入/输出设备的其他电子设备的连接。例如，所公开的方法和设备中的一些或全部可以通过使用汇编语言或硬件编程语言(诸如VERILOG、VHDL、C++)通过使用根据本公开的逻辑和算法对硬件(例如，包括现场可编程门阵列(FPGA)和/或可编程逻辑阵列(PLA)的可编程逻辑电路)编程来实现。

本领域技术人员从上面的实施例中可以清楚地知道本公开可以由软件通过必要硬件来实施，或者由硬件、固件等来实施。基于这样的理解，本公开的实施例可以部分地以软件形式体现。可以将计算机软件存储在诸如计算机的软盘、硬盘、光盘或闪存的可读存储介质中。该计算机软件包括一系列指令，以使计算机(例如，个人计算机、服务站或网络终端)执行根据本公开的各个实施例的方法或其一部分。

上面的图2、图6和图10中呈现的方法的步骤旨在进行示意性说明。在一些实施例中，可以利用未描述的一个或多个附加步骤和/或在没有所讨论的一个或多个步骤的状态下来实施该方法。另外，在图2、图6和图10中图示并在上面描述的方法步骤的顺序并非旨在进行限制。在一些实施例中，该方法可以在一个或多个处理设备(例如，数字处理器、模拟处理器、设计为处理信息的数字电路、设计为处理信息的模拟电路、状态机和/或用于电子处理信息的其他机制)中实施。一个或多个处理设备可以包括一个或多个模块，以响应于电子存储在电子存储介质上的指令来执行方法的一些或全部步骤。一个或多个处理模块可以包括通过被专门设计用于执行方法的一个或多个步骤的硬件、固件和/或软件配置的一个或多个设备。

尽管到目前为止已经参考附图描述了本公开的各方面，但是上述方法、系统和设备仅是示例性示例，并且本发明的范围不限于这些方面，而仅由以下所附权利要求及其等同物来限定。各种元件可以被省略或可以被等效元件代替。另外，可以以与本公开中描述的顺序不同的顺序执行步骤。此外，可以以各种方式组合各种元件。同样重要的是，随着技术的发展，所描述的许多元件可以由在本公开之后出现的等效元件代替。

Claims (23)

1.一种用于对微服务架构的系统进行管理的方法，包括：

在具有显示器、一个或多个处理器和存储器的电子设备处：

根据系统接收到的对一个或多个应用程序接口API的来自客户端的请求所经过的链路的信息，确定系统中被调用的各个节点以及与所述链路对应的、所调用的各个节点之间的连接关系，应用程序接口由部署在节点上的微服务提供；

在显示器上显示图形用户界面，所述图形用户界面包括系统中的被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。

2.根据权利要求1所述的方法，其中，所述图形用户界面仅包括在预定时间段内被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。

3.根据权利要求1所述的方法，其中，被调用的节点与多个应用程序接口相关联。

4.根据权利要求1-3中任一项所述的方法，还包括：

响应于所述图形用户界面上用于选择系统中的任一节点的第一用户输入，显示所选择的节点的当前状态的表示，

其中，节点的当前状态包括节点上部署的微服务、节点被成功调用的次数、节点调用失败的次数、节点的当前负载、节点所服务的用户中的至少一个。

5.根据权利要求4所述的方法，还包括：

响应于所述图形用户界面上用于选择系统中的一个节点的第二用户输入显示该节点的可配置属性的表示，以及

在接收到所述图形用户界面上针对该节点的可配置属性的表示的第三用户输入时，响应于第三用户输入改变该被节点的属性，

其中，节点的可配置属性包括节点上部署的微服务的上线或下线。

6.根据权利要求1所述的方法，还包括：

响应于所述图形用户界面上与任一微服务对应的第四用户输入，在所述图形用户界面上显示部署该微服务的节点的列表以及对列表中的每个节点所分配的请求的权重，以及

在接收到所述图形用户界面上针对对任一节点所分配的请求的权重的第五用户输入时，响应于第五用户输入改变对该节点所分配的请求的权重。

7.根据权利要求1所述的方法，还包括：

响应于所述图形用户界面上与任一微服务对应的第六用户输入，在所述图形用户界面上显示部署该微服务的节点的列表以及对列表中的每个节点所分配的客户端的列表，以及

在接收到所述图形用户界面上针对对任一节点所分配的客户端的列表的第七用户输入时，响应于第七用户输入改变对该节点所分配的客户端。

8.根据权利要求6或7所述的方法，其中，被调用的节点的图形表示包括该节点所承载的请求的权重。

9.根据权利要求1所述的方法，还包括：

响应于所述图形用户界面上与任一微服务对应的第八用户输入，在所述图形用户界面上突出显示与该微服务相关联的请求的链路对应的连接关系的图形表示。

10.根据权利要求1所述的方法，还包括：

响应于所述图形用户界面上与对任一应用程序接口的请求对应的第九用户输入，在所述图形用户界面上突出显示与对该应用程序接口的请求对应的被调用的节点之间的连接关系的图形表示。

11.根据权利要求9或10所述的方法，其中，被突出显示的连接关系的图形表示包括连接线，其中，该连接线的颜色表示链路上的下游节点对来自上游节点的请求的响应时间。

12.根据权利要求9或10所述的方法，其中，被突出显示的连接关系的图形表示包括虚线的连接线，并且，虚线的连接线上的各个虚线点沿着从虚线的上游节点一侧到下游节点一侧的方向依次突出显示。

13.根据权利要求9或10所述的方法，其中，按照从链路上的上游节点到下游节点的顺序依次显示被调用的节点的图形表示以及所调用的节点之间的连接关系的图形表示。

14.根据权利要求1-3中任一项所述的方法，还包括：

响应于所述图形用户界面上与对任一应用程序接口的请求对应的第十用户输入，在所述图形用户界面上显示与对该应用程序接口的请求对应的被调用的节点的列表。

15.根据权利要求14所述的方法，还包括：

响应于所述图形用户界面上用于选择列表中的任一节点的第十一用户输入，显示所选择的节点的当前状态的表示。

16.根据权利要求1-3中任一项所述的方法，还包括：

响应于所述图形用户界面上的第十二用户输入，显示系统的与限流有关的参数的表示，以及

在接收到所述图形用户界面上针对系统的与限流有关的参数的表示的第十三用户输入时，响应于第十三用户输入改变系统的与限流有关的参数，

其中，系统的参数包括以下至少之一：系统中待处理的全部请求的数目的上限、系统中的每个微服务待处理的请求的数目的上限和系统中的每个应用程序接口待处理的请求的上限。

17.根据权利要求1-3中任一项所述的方法，还包括：

响应于所述图形用户界面上指示进行数据统计的第十四用户输入，显示与系统相关的数据的统计结果，

其中，与系统相关的数据包括预定时间段内的以下数据中的至少一项：接收到的请求的数量、对请求的平均响应时间、处理完成的请求的数量、处理失败的请求的数量。

18.根据权利要求1-3中任一项所述的方法，还包括：

响应于所述图形用户界面上的第十五用户输入，改变所述图形用户界面中的节点的图形表示，

其中，改变所述图形用户界面中的节点的图形表示包括以下至少之一：改变节点的图标、改变节点的图形表示的排列方式、改变节点的图形表示的间距。

19.根据权利要求1-3中任一项所述的方法，还包括：

在所述图形用户界面中显示与系统延迟有关的表示，并且在系统的延迟超出阈值时发出警告，

其中，系统的延迟包括以下至少一项：系统对请求的整个响应时间、各个节点对请求的响应时间。

20.根据权利要求1-3中任一项所述的方法，其中，系统中的节点包括网络应用防火墙WAF、API网关、微服务节点、微服务管理节点以及数据库中的一个或多个。

21.根据权利要求1-3中任一项所述的方法，其中，系统为采用微服务架构的中台系统。

22.一种电子设备，包括：

显示器；

存储器，被配置为存储一系列计算机可执行指令；和

一个或多个处理器，被配置为执行存储在存储器中的计算机可执行指令，使得电子设备执行根据权利要求1-21中任意一项所述的方法的步骤。

23.一种具有存储在其上的指令的非暂时性计算机可读介质，该指令在由具有显示器的电子设备的一个或多个处理器执行时使电子设备执行根据权利要求1-21中任意一项所述的方法。

Images