CN115567604A - 基于微服务系统的服务调用方法及服务器 - Google Patents

Abstract

本公开提供的一种基于微服务系统的服务调用方法及服务器，涉及微服务治理技术，包括：接收用户终端的接口调用请求；根据接口调用请求，并利用微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，微服务系统中包括多个第一服务；边车模式组件用于代理与边车模式组件对应的第一服务的服务治理能力；将返回值返回给用户终端。本方案，使用边车模式组件代理基于Spring Cloud架构的微服务系统中的所有服务治理能力，且内部采用Spring Cloud原生的超文本传输协议进行通信，使得业务服务与服务治理能力解耦，使服务开发人员专注于开发业务服务，进而提升了开发应用程序的效率。

Description

基于微服务系统的服务调用方法及服务器

技术领域

本公开涉及微服务治理技术，尤其涉及一种基于微服务系统的服务调用方法及服务器。

背景技术

微服务就是一个小型的应用程序，可以独立部署。在微服务架构模式下，一个完整的应用系统可以由多个微服务组成。

现有技术中，Spring Cloud是一种常用的微服务框架，提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线等组件。

但是，在使用Spring Cloud微服务生态构建应用程序时，服务开发人员往往需要在应用程序中集成Spring Cloud的服务治理能力，因此带来了侵入性与额外的复杂性，进而影响了开发应用程序的效率。

发明内容

本公开提供了一种基于微服务系统的服务调用方法及服务器，以解决现有技术中在使用Spring Cloud微服务生态构建应用程序时，服务开发人员往往需要在应用程序中集成Spring Cloud的服务治理能力，因此带来了侵入性与额外的复杂性，进而影响了开发应用程序的效率的问题。

根据本公开第一方面，提供了一种基于微服务系统的服务调用方法，内部采用超文本传输协议进行通信，包括：

接收用户终端的接口调用请求；

根据所述接口调用请求，并利用所述微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，所述微服务系统中包括多个第一服务；所述边车模式组件用于代理与所述边车模式组件对应的第一服务的服务治理能力；

将所述返回值返回给所述用户终端。

根据本公开第二方面，提供了一种基于微服务系统的服务调用装置，内部采用超文本传输协议进行通信，包括：

获取单元，用于接收用户终端的接口调用请求；

调用单元，用于根据所述接口调用请求，并利用所述微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，所述微服务系统中包括多个第一服务；所述边车模式组件用于代理与所述边车模式组件对应的第一服务的服务治理能力；

返回单元，用于将所述返回值返回给所述用户终端。

根据本公开第三方面，提供了一种服务器，包括存储器和处理器；其中，

所述存储器，用于存储计算机程序；

所述处理器，用于读取所述存储器存储的计算机程序，并根据所述存储器中的计算机程序执行如第一方面所述的基于微服务系统的服务调用方法。

根据本公开第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如第一方面所述的基于微服务系统的服务调用方法。

根据本公开第五方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时，实现如第一方面所述的基于微服务系统的服务调用方法。

本公开提供的基于微服务系统的服务调用方法及服务器，内部采用超文本传输协议进行通信，包括：接收用户终端的接口调用请求；根据接口调用请求，并利用微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，微服务系统中包括多个第一服务；边车模式组件用于代理与边车模式组件对应的第一服务的服务治理能力；将返回值返回给用户终端。本方案提供的基于微服务系统的服务调用方法及服务器中，使用边车模式组件代理基于Spring Cloud架构的微服务系统中的所有服务治理能力，且内部采用Spring Cloud原生的超文本传输协议进行通信，进而使得基于Spring Cloud架构的微服务系统的业务服务与服务治理能力解耦，进而在使用SpringCloud微服务生态构建应用程序时，服务开发人员不再需要在应用程序中集成SpringCloud的服务治理能力，没有了侵入性与额外的复杂性，使服务开发人员专注于开发业务服务，进而提升了开发应用程序的效率。

附图说明

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本公开一示例性实施例示出的基于微服务系统的服务调用方法的流程示意图；

图2为本公开另一示例性实施例示出的基于微服务系统的服务调用方法的流程示意图；

图3为本公开一示例性实施例示出的基于微服务系统的服务调用过程示意图；

图4为本公开一示例性实施例示出的服务注册发现过程示意图；

图5为本公开一示例性实施例示出的配置更新过程示意图；

图6为本公开一示例性实施例示出的获取服务的可观察性能力过程示意图；

图7为本公开一示例性实施例示出的基于微服务系统的服务调用装置的结构图；

图8为本公开另一示例性实施例示出的基于微服务系统的服务调用装置的结构图；

图9为本公开一示例性实施例示出的服务器的结构图。

具体实施方式

微服务就是一个小型的应用程序，可以独立部署。在微服务架构模式下，一个完整的应用系统可以由多个微服务组成。现有技术中，Spring Cloud是一种常用的微服务框架，提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线等组件。

但是，Spring Cloud是一个应用层的服务治理解决方案，对业务服务的侵入性很大。在使用Spring Cloud微服务生态构建应用程序时，服务开发人员往往需要在应用程序中集成Spring Cloud的服务治理能力，因此对业务服务带来了侵入性与额外的复杂性，进而影响了开发应用程序的效率。

Service Mesh架构模式就在这种背景下诞生了，它将服务治理能力下沉到网络层，与服务进行剥离，Service Mesh架构模式下最有名的框架要数istio，使用Envoy作为“数据面”，istio提供“控制面”，它们之间使用xDS协议进行通信，服务治理能力被单独运行并管理起来。

但是，istio这类开源框架，虽然功能丰富，但显得十分笨重，学习和使用的成本很高。Service Mesh架构模式下的istio与Linkerd都不支持Spring Cloud原生功能，而由于Spring Cloud的盛行，许多使用人并不愿意做迁移，也没有能力和资源去完成这件事。因此，istio与Linkerd的使用成本过大，迁移成本过高，如果想引入istio、Linkerd用于服务治理，那对研发以及运维的挑战是相当大的，短时间之内根本无法实现。

为了解决上述技术问题，本公开提供的方案中，使用预先设置的边车模式组件代理基于Spring Cloud架构的微服务系统中的所有服务治理能力，且内部采用Spring Cloud原生的超文本传输协议进行通信，进而使得基于Spring Cloud架构的微服务系统的业务服务与服务治理能力解耦，进而在使用Spring Cloud微服务生态构建应用程序时，服务开发人员不再需要在应用程序中集成Spring Cloud的服务治理能力，没有了侵入性与额外的复杂性，使服务开发人员专注于开发业务服务，进而提升了开发应用程序的效率；而且本方案提供的方法支持Spring Cloud原生功能，无需做迁移，且在Spring Cloud架构中配置边车模式组件，相对引入istio、Linkerd而言更容易掌握。

下面以具体地实施例对本公开的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例进行描述。

图1为本公开一示例性实施例示出的基于微服务系统的服务调用方法的流程示意图。

如图1所示，本实施例提供的基于微服务系统的服务调用方法包括：

步骤101，接收用户终端的接口调用请求。

其中，本公开提供的方法可以由具备计算能力的电子设备来执行，比如可以是计算机等设备。

该电子设备中设置有基于Spring Cloud架构的微服务系统，可以通过该微服务系统中的网关接收用户终端的接口调用请求。

具体的，用户终端可以通过向微服务系统发送接口调用请求，在微服务系统中调用需要的服务。

其中，该微服务系统为基于Spring Cloud架构的系统，微服务系统为分布式系统。

具体的，微服务系统和用户终端之间可以通过Spring Cloud原生的超文本传输协议(Hyper Text Transfer Protocol，HTTP)进行通信。

步骤102，根据接口调用请求，并利用微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，微服务系统中包括多个第一服务；边车模式组件用于代理与边车模式组件对应的第一服务的服务治理能力；其中，内部采用超文本传输协议进行通信。

其中，边车模式(Sidecar)是Service Mesh中惯用的模式。将应用程序的功能划分为单独的进程可以被视为边车模式。边车模式允许在应用程序旁边添加更多功能，而无需额外第三方组件配置或修改应用程序代码。

具体的，微服务系统中包括多个第一服务，每个第一服务都指代一个微服务。

具体的，可以为微服务系统中的每个第一服务预先配置对应的边车模式组件，并令边车模式组件代理与该边车模式组件对应的第一服务的服务治理能力。这样就使得微服务系统的所有服务治理能力都集中在边车模式组件中。进而使得业务逻辑与服务治理能力解耦了。

具体的，可以根据接口调用请求，并利用与第一服务对应的边车模式组件，确定并调用目标服务，进而得到返回值。

具体的，微服务系统中各边车模式组件之间可以通过Spring Cloud原生的超文本传输协议进行通信。

步骤103，将返回值返回给用户终端。

具体的，微服务系统可以通过网关将得到的返回值发送给用户终端。

本公开提供的基于微服务系统的服务调用方法，内部采用超文本传输协议进行通信，包括：接收用户终端的接口调用请求；根据接口调用请求，并利用微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，微服务系统中包括多个第一服务；边车模式组件用于代理与边车模式组件对应的第一服务的服务治理能力；将返回值返回给用户终端。本公开采用的方法中，使用边车模式组件代理基于Spring Cloud架构的微服务系统中的所有服务治理能力，且内部采用超文本传输协议进行通信，进而使得基于Spring Cloud架构的微服务系统的业务服务与服务治理能力解耦，进而在使用Spring Cloud微服务生态构建应用程序时，服务开发人员不再需要在应用程序中集成Spring Cloud的服务治理能力，没有了侵入性与额外的复杂性，使服务开发人员专注于开发业务服务，进而提升了开发应用程序的效率。而且本公开采用的方法支持SpringCloud原生功能，无需做迁移，且在Spring Cloud架构中配置边车模式组件，相对引入istio、Linkerd而言更较容易掌握，因此本公开采用的方法更易使用。

图2为本公开另一示例性实施例示出的基于微服务系统的服务调用方法的流程示意图。

如图2所示，本实施例提供的基于微服务系统的服务调用方法包括：

步骤201，接收用户终端的接口调用请求。

具体的，步骤201与步骤101的原理、实现方式类似，不再赘述。

步骤202，根据接口调用请求，并利用微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，微服务系统中包括多个第一服务；边车模式组件用于代理与边车模式组件对应的第一服务的服务治理能力；其中，内部采用超文本传输协议进行通信；边车模式组件包括如下一种或者几种的组合：服务注册发现模块、配置更新模块、监控模块、流量代理模块、流量治理模块；其中，服务注册发现模块用于与预设的服务注册中心组件进行交互、以及与边车模式组件代理的第一服务进行交互；配置更新模块用于与预设的配置中心组件进行交互、并管理第一服务的配置；监控模块用于采集第一服务的日志和预设指标，以及实现链路追踪并获取链路信息；流量代理模块用于通过超文本传输协议实现目标服务与用户终端之间的南北流量、通过超文本传输协议实现第一服务与其他第一服务之间的东西流量、进行负载均衡操作、以及进行报文转换操作；流量治理模块用于管理第一服务的流量。

具体的，边车模式组件用于代理与该边车模式组件对应的第一服务的服务治理能力。边车模式组件可以包括如下一种或者几种的组合：服务注册发现模块、配置更新模块、监控模块、流量代理模块、流量治理模块。

其中，服务注册中心组件可以为Spring Cloud中的服务发现框架，可以根据需要预先设置服务注册中心组件，比如可以预先设置Spring Cloud中的Eureka为服务注册中心组件，或者Spring Cloud中的Nacos为服务注册中心组件。

具体的，服务注册发现模块可以用于与预设的服务注册中心组件进行交互，也可以与边车模式组件代理的第一服务进行交互。

其中，配置中心组件可以用于管理微服务系统的配置。可以根据需要预先设置配置中心组件。其中，配置中心组件比如可以使用阿波罗(Apollo)，Apollo是一种分布式配置中心。

具体的，配置更新模块可以用于与预设的配置中心组件进行交互、并可以用于管理第一服务的配置。

其中，预设指标为根据实际需要预先设置的指标，比如可以包括第一服务的每秒查询率(Query Per Second，QPS)、总调用次数、平均响应时间、最大响应时间、最小响应时间、业务指标出现的次数、以及业务的波动等。

具体的，预设的监控模块可以用于采集第一服务的日志以及预设的指标；还可以用于实现链路追踪，并根据链路追踪获取链路信息。

具体的，监控模块可以通过集成一种可观测性协议OpenTelemetry(OTEL)软件开发工具包(Software Development Kit，SDK)来实现链路追踪。OTEL SDK支持Jaeger、Zipkin等链路追踪中间件。

其中，南北流量(NORTH SOURTH TRAFFIC)指用户终端通过微服务系统中的网关，与目标服务之间通信的流量。

其中，东西流量(EAST WEST TRAFFIC)指微服务系统中各第一服务之间通信的流量。

具体的，微服务系统中的各第一服务可以为消费方服务或者提供方服务。在根据接口调用请求进行服务调用时，可以先利用消费方服务来调用提供方的服务。其中，消费方服务可以利用负载均衡操作，选择要调用的提供方服务，即目标服务。

具体的，报文转换指将返回值的格式转换为预设格式。

具体的，流量代理模块可以用于通过Spring Cloud原生的超文本传输协议实现目标服务与用户终端之间的南北流量、通过Spring Cloud原生的超文本传输协议实现该边车模式组件代理的第一服务与其他第一服务之间的东西流量、进行负载均衡操作、以及进行报文转换操作。

具体的，流量治理模块可以用于管理第一服务的流量，以实现更好的数据传输效果。

在一种可实现方式中，服务注册发现模块具体用于：与预设的服务注册中心组件进行心跳连接，以实现与服务注册中心组件的数据交互以及健康检查，并完成自身的服务注册与发现；与第一服务进行心跳连接，以实现与第一服务的状态同步以及健康检查；从预设的服务注册中心组件中获取并保存服务注册表；对第一服务进行优雅上线或者优雅下线。

具体的，服务注册发现模块可以用于与预设的服务注册中心组件进行心跳连接，通过心跳连接来实现与服务注册中心组件的数据交互，并可以通过心跳连接来实现服务注册中心组件对边车模式组件的健康检查，也可以通过心跳连接，完成该边车模式组件自身的服务注册与发现。

具体的，服务注册发现模块还可以与该边车模式组件代理的第一服务进行心跳连接，通过心跳连接来实现该边车模式组件与代理的第一服务的状态同步，并可以通过心跳连接实现边车模式组件对其代理的第一服务的健康检查。其中，这里的状态可以为表征第一服务的可用状态，不可用状态等。

其中，服务注册表中包括微服务系统中各第一服务的信息。

具体的，服务注册发现模块可以从预设的服务注册中心组件中获取服务注册表并保存该服务注册表。可以根据服务注册表来调用目标服务。

具体的，若第一服务为提供方服务，且确定该第一服务出现问题，则服务注册发现模块可以对已经上线的第一服务进行优雅下线；若确定该第一服务准备好，则服务注册发现模块可以再次对该第一服务进行优雅上线。

在一种可实现方式中，配置更新模块具体用于：通过与预设的配置中心组件的交互，获取初始配置；并根据初始配置更新第一服务的本地配置。

具体的，可以利用预设的配置中心组件预先设置微服务系统中各第一服务的配置属性与区分标识。配置更新模块可以通过与预设的配置中心组件的交互，订阅该边车模式组件代理的第一服务的配置属性，进而得到该第一服务的初始配置。进而可以根据该初始配置更新该第一服务的本地配置。

通过与预设的配置中心组件的交互，进行远程配置监听，得到监听结果；若监听结果显示第一服务对应的配置发生变化，则进行远程配置更新；远程配置更新用于通过远程配置解析，再次更新第一服务的本地配置。

具体的，配置更新模块可以通过与预设的配置中心组件的交互，进行对代理的第一服务的远程配置监听，进而得到监听结果。若该监听结果显示该第一服务对应的配置发送变化，则可以对该第一服务进行远程配置更新。该远程配置更新可以为通过远程配置解析，从预设的配置中心组件中获取该第一服务更新后的配置，并用更新后的配置再次更新该第一服务的本地配置。

在一种可实现方式中，监控模块还用于：将得到的日志、预设指标、链路信息，发送至消息队列；用以实现根据日志、预设指标、链路信息分析第一服务的运行情况。

具体的，监控模块可以将得到的该边车模式组件代理的第一服务的日志，预设指标，以及链路信息，发送至消息队列。Spring Cloud中的Logstash或者ElasticSearch组件可以从消息队列中获取该日志信息，并对日志信息进行分析处理，并根据分析结果推断该第一服务的内部运行情况。Spring Cloud中的Prometheus组件可以从消息队列中获取该预设指标，并对预设指标进行分析处理，并根据分析结果推断该第一服务的内部运行情况。Spring Cloud中的Jaeger、Zipkin及SkyWalking组件可以从消息队列中获取该链路信息，并对链路信息进行分析处理，并根据分析结果推断该第一服务的内部运行情况。

可以通过剖析该第一服务的运行情况，进而得到该第一服务的可观测性能力。其中，可观测性(Observability)指，通过检查系统输出指标来衡量系统内部状态的能力，如果仅使用来自输出的数据信息就可以推断系统当前的运行状态，则该系统被认为是具备可观测性的。

在一种可实现方式中，流量代理模块具体用于：根据预设的负载均衡算法，为各第一服务之间的请求选择服务实例。

其中，预设的负载均衡算法可以为如下算法中的一种：轮询算法、随机算法、权重算法、最小响应时间算法。

具体的，可以根据需要预先设置负载均衡算法，并根据预设的负载均衡算法，为微服务系统中的消费方服务选择需要调用的提供方服务。

将发送至边车模式组件的流量，发送到与其他第一服务对应的边车模式组件。

具体的，流量代理模块可以将发送至第一服务对应的边车模式组件的流量，发送到其他第一服务对应的边车模式组件中，进而实现微服务系统中各内部服务(即各第一服务)之间的交互。

将返回值的格式转换为预设格式。

其中，预设格式为根据需要预先设置的格式。比如，预设格式可以为json格式。

具体的，流量代理模块还可以将返回值的格式转换为预设格式。

在一种可实现方式中，流量治理模块具体用于对第一服务的流量执行如下操作的一种或几种组合：熔断、限流、灰度发布、流量整形、流量染色。

其中，灰度发布，指可以根据需要只对部分用户公开该第一服务，进而可以通过分析该第一服务的使用情况对该第一服务做改进，然后再将改进后的第一服务对全部用户公开。

其中，流量染色，指可以对接口调用请求中预先设置的特殊标记，进行相应的预先设置的特殊处理。

具体的，流量治理模块可以根据需要对第一服务的流量进行如下操作的一种或者几种的组合：熔断、限流、灰度发布、流量整形、流量染色。

图3为本公开一示例性实施例示出的基于微服务系统的服务调用过程示意图。

如图3所示，用户终端可以将接口调用请求发送给微服务系统，微服务系统可以通过网关接收该接口调用请求，并可以根据该接口调用请求，获取微服务系统中的消费方服务，并利用与消费方服务对应的预先设置的边车模式组件，与通过预设的负载均衡算法得到的目标服务对应的预先设置的边车模式组件进行交互，调用该目标服务，得到返回值。并可以通过网关将返回值返回给用户终端。其中，用户终端和网关之间可以通过SpringCloud原生的超文本传输协议(Hyper Text Transfer Protocol，HTTP)进行通信。微服务系统中各服务对应的边车模式组件之间也可以通过Spring Cloud原生的超文本传输协议(Hyper Text Transfer Protocol，HTTP)进行通信。

具体的，与各服务对应的边车模式组件可以包括服务注册发现模块、配置更新模块、监控模块、流量代理模块、以及流量治理模块。

具体的，服务注册发现模块可以用于与Eureka或者Nacos等服务注册中心组件进行交互，以及健康检查，并可以通过交互，获取服务注册表；可以用于与代理的第一服务进行交互，并进行健康检查；可以用于对代理的第一服务进行优雅上线或者优雅下线。

如图4所示，当发生服务间的请求调用时(东西流量)，原先是由左边的业务服务直接调用右边的业务服务，有了Sidecar之后，就可以由Sidecar来完成服务注册与发现了。整个流程是：服务A发起对服务B的请求，首先流量经过与服务A对应的Sidecar A，Sidecar A根据服务B的服务名称去服务注册中心组件Eureka、或者Nacos中获取服务注册表，拿到服务注册表后再发起对服务B对应的Sidecar B的请求，Sidecar B再将请求转到服务B。

具体的，配置更新模块可以与Apollo等配置中心组件进行交互，进而进行远程配置监听，得到监听结果；若监听结果显示第一服务对应的配置发生变化，则进行远程配置更新；远程配置更新用于通过远程配置解析，热更新第一服务的本地配置。

如图5所示，Sidecar A和Sidecar B集成了Apollo配置中心的SDK，在Apollo配置中心的管理页面上可以随时更新配置信息。

具体的，监控模块可以采集第一服务的日志、预设指标，并进行链路追踪得到链路信息，并可以将日志、预设指标，以及链路信息发送至消息队列。

如图6所示，Sidecar可以采集其代理的服务的日志、指标、链路信息。并可以将日志、指标、链路信息，发送到消息队列，供后续处理分析处理，并得到服务的可观察性能力。

具体的，流量代理模块可以用于通过超文本传输协议实现目标服务与用户终端之间的南北流量、通过超文本传输协议实现各第一服务之间的东西流量、进行负载均衡操作、以及进行报文转换操作。

具体的，流量治理模块可以对代理的第一服务的流量执行如下操作的一种或几种组合：熔断、限流、灰度发布、流量整形、流量染色。

图7为本公开一示例性实施例示出的基于Spring Cloud架构的微服务系统的服务调用装置的结构图。

如图7所示，本公开提供的基于微服务系统的服务调用装置700，包括：

获取单元710，用于接收用户终端的接口调用请求；

调用单元720，用于根据接口调用请求，并利用微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，微服务系统中包括多个第一服务；边车模式组件用于代理与边车模式组件对应的第一服务的服务治理能力；

返回单元730，用于将返回值返回给用户终端。

图8为本公开另一示例性实施例示出的基于微服务系统的服务调用装置的结构图。

如图8所示，在上述实施例的基础上，本公开提供的基于微服务系统的服务调用装置800中，调用单元720中边车模式组件包括如下一种或者几种的组合：

服务注册发现模块721、配置更新模块722、监控模块723、流量代理模块724、流量治理模块725；

其中，服务注册发现模块721用于与预设的服务注册中心组件进行交互、以及与边车模式组件代理的第一服务进行交互；配置更新模块722用于与预设的配置中心组件进行交互、并管理第一服务的配置；监控模块723用于采集第一服务的日志和预设指标，以及实现链路追踪并获取链路信息；流量代理模块424用于通过超文本传输协议实现目标服务与用户终端之间的南北流量、通过超文本传输协议实现第一服务与其他第一服务之间的东西流量、进行负载均衡操作、以及进行报文转换操作；流量治理模块725用于管理第一服务的流量。

服务注册发现模块721具体用于：与预设的服务注册中心组件进行心跳连接，以实现与服务注册中心组件的数据交互以及健康检查，并完成自身的服务注册与发现；与第一服务进行心跳连接，以实现与第一服务的状态同步以及健康检查；从预设的服务注册中心组件中获取并保存服务注册表；对第一服务进行优雅上线或者优雅下线。

配置更新模块722具体用于：通过与预设的配置中心组件的交互，获取初始配置；并根据初始配置更新第一服务的本地配置；

通过与预设的配置中心组件的交互，进行远程配置监听，得到监听结果；若监听结果显示第一服务对应的配置发生变化，则进行远程配置更新；远程配置更新用于通过远程配置解析，再次更新第一服务的本地配置。

监控模块723还用于：将得到的日志、预设指标、链路信息，发送至消息队列；用以实现根据日志、预设指标、链路信息分析第一服务的运行情况。

流量代理模块724具体用于：根据预设的负载均衡算法，为各第一服务之间的请求选择服务实例；

将发送至边车模式组件的流量，发送到与其他第一服务对应的边车模式组件；

将返回值的格式转换为预设格式。

流量治理模块725具体用于对第一服务的流量执行如下操作的一种或几种组合：熔断、限流、灰度发布、流量整形、流量染色。

图9为本公开一示例性实施例示出的服务器的结构图。

如图9所示，本实施例提供的电子设备包括：

存储器901；

处理器902；以及

计算机程序；

其中，计算机程序存储在存储器901中，并配置为由处理器902执行以实现如上的任一种基于微服务系统的服务调用方法。

本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行以实现如上的任一种基于微服务系统的服务调用方法。

本实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时，实现上述任一种基于微服务系统的服务调用方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (11)

1.一种基于微服务系统的服务调用方法，其特征在于，内部采用超文本传输协议进行通信，包括：

接收用户终端的接口调用请求；

根据所述接口调用请求，并利用所述微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，所述微服务系统中包括多个第一服务；所述边车模式组件用于代理与所述边车模式组件对应的第一服务的服务治理能力；

将所述返回值返回给所述用户终端。

2.根据权利要求1所述的方法，其特征在于，所述边车模式组件包括如下一种或者几种的组合：

服务注册发现模块、配置更新模块、监控模块、流量代理模块、流量治理模块；

其中，所述服务注册发现模块用于与预设的服务注册中心组件进行交互、以及与所述边车模式组件代理的第一服务进行交互；所述配置更新模块用于与预设的配置中心组件进行交互、并管理所述第一服务的配置；所述监控模块用于采集所述第一服务的日志和预设指标，以及实现链路追踪并获取链路信息；所述流量代理模块用于通过超文本传输协议实现所述目标服务与所述用户终端之间的南北流量、通过超文本传输协议实现所述第一服务与其他第一服务之间的东西流量、进行负载均衡操作、以及进行报文转换操作；所述流量治理模块用于管理所述第一服务的流量。

3.根据权利要求2所述的方法，其特征在于，所述服务注册发现模块具体用于：

与预设的服务注册中心组件进行心跳连接，以实现与所述服务注册中心组件的数据交互以及健康检查，并完成自身的服务注册与发现；与所述第一服务进行心跳连接，以实现与所述第一服务的状态同步以及健康检查；从所述预设的服务注册中心组件中获取并保存服务注册表；对所述第一服务进行优雅上线或者优雅下线。

4.根据权利要求2所述的方法，其特征在于，所述配置更新模块具体用于：

通过与所述预设的配置中心组件的交互，获取初始配置；并根据所述初始配置更新所述第一服务的本地配置；

通过与所述预设的配置中心组件的交互，进行远程配置监听，得到监听结果；若所述监听结果显示所述第一服务对应的配置发生变化，则进行远程配置更新；所述远程配置更新用于通过远程配置解析，再次更新所述第一服务的本地配置。

5.根据权利要求2所述的方法，其特征在于，所述监控模块还用于：

将得到的所述日志、所述预设指标、所述链路信息，发送至消息队列；用以实现根据所述日志、所述预设指标、所述链路信息分析所述第一服务的运行情况。

6.根据权利要求2所述的方法，其特征在于，所述流量代理模块具体用于：

根据预设的负载均衡算法，为各所述第一服务之间的请求选择服务实例；

将发送至所述边车模式组件的流量，发送到与其他第一服务对应的边车模式组件；

将所述返回值的格式转换为预设格式。

7.根据权利要求2所述的方法，其特征在于，所述流量治理模块具体用于对所述第一服务的流量执行如下操作的一种或几种组合：

熔断、限流、灰度发布、流量整形、流量染色。

8.一种基于微服务系统的服务调用装置，其特征在于，内部采用超文本传输协议进行通信，包括：

获取单元，用于接收用户终端的接口调用请求；

调用单元，用于根据所述接口调用请求，并利用所述微服务系统中预先配置的与第一服务对应的边车模式组件，确定并调用目标服务，并得到返回值；其中，所述微服务系统中包括多个第一服务；所述边车模式组件用于代理与所述边车模式组件对应的第一服务的服务治理能力；

返回单元，用于将所述返回值返回给所述用户终端。

9.一种服务器，其特征在于，包括存储器和处理器；其中，

所述存储器，用于存储计算机程序；

所述处理器，用于读取所述存储器存储的计算机程序，并根据所述存储器中的计算机程序执行上述权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现上述权利要求1-7任一项所述的方法。

11.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时，实现上述权利要求1-7任一项所述的方法。

Images