CN111290865A - 一种服务调用方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请涉及通信技术领域，尤其涉及一种服务调用方法、装置、电子设备和存储介质，用以提高多个微服务运行环境的服务相互调用的效率，其中，方法包括：API网关接收服务调用方发送的访问请求，并将访问请求转发给相应的服务发布方；API网关接收服务发布方返回的响应消息，并将响应消息转发给服务调用方，其中响应消息是服务发布方接收到API网关发送的访问请求后生成的。由于本申请基于API网关作为服务调用方与服务发布方之间的桥梁，由API网关实现微服务调用的统一管理与适配，因而不需要去做额外的开发去适配不同的环境，减小了***开发的复杂度，提高了服务调用的效率。

Description

一种服务调用方法、装置、电子设备和存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种服务调用方法、装置、电子设备和存储介质。

背景技术

随着微服务的盛行，越来越多机构的自研服务采用基于微服务运行的框架进行开发。但是在进入数字化转型时代的机构，不同运行环境之间的服务融合和统一治理已经成为了机构数字化转型的必经之路，而当前市场的厂商都只专注在自研微服务框架内的服务注册和调用过程，并没有考虑多个微服务运行环境的微服务相互调用和微服务与普通二进制服务之间的问题。

综上，目前对于不同微服务运行环境的服务相互调用时，需要按照对方的组件的要求来调用，带来了额外的适配开发量，实现方式复杂，效率较低。

发明内容

本申请实施例提供一种服务调用方法、装置、电子设备和存储介质，用以提高多个微服务运行环境的服务相互调用的效率。

本申请实施例提供的第一种服务调用方法，包括：

API(Application Programming Interface，应用程序编程接口)网关接收服务调用方发送的访问请求，并将所述访问请求转发给相应的服务发布方；

所述API网关接收所述服务发布方返回的响应消息，并将所述响应消息转发给所述服务调用方，其中所述响应消息是所述服务发布方接收到所述API网关发送的访问请求后生成的。

本申请实施例提供的第二种服务调用方法，包括：

服务调用方获取服务发布方的访问地址，并根据所述访问地址向API网关发送访问请求，以使所述API网关将所述访问请求转发给所述服务发布方；

所述服务调用方接收所述API网关返回的响应消息，其中所述响应消息为所述服务发布方根据所述访问请求生成的。

在一种可选的实施方式中，所述根据所述访问地址向API网关发送访问请求，包括：

所述服务调用方与所述服务发布方的微服务运行环境相同时，所述服务调用方通过所述微服务运行环境对应的鉴权方式向所述API网关发送所述访问请求；或

所述服务调用方与所述服务发布方的微服务运行环境不同时，所述服务调用方通过所述API网关对应的鉴权方式向所述API网关发送所述访问请求。

本申请实施例提供的第三种服务调用方法，包括：

服务发布方接收API网关发送的访问请求，其中所述访问请求为服务调用方发送给所述API网关的；

所述服务发布方根据所述访问请求生成响应消息，并将所述响应信息发送给所述API网关，以使所述API网关将所述响应消息转发给所述服务调用方。

可选的，所述将所述响应信息发送给所述API网关，包括：

所述服务发布方通过所在微服务运行环境对应的鉴权方式将所述响应信息发送给所述API网关。

本申请实施例提供的第一种服务调用装置，包括：

第一转发单元，用于接收服务调用方发送的访问请求，并将所述访问请求转发给相应的服务发布方；

第二转发单元，用于接收所述服务发布方返回的响应消息，并将所述响应消息转发给所述服务调用方，其中所述响应消息是所述服务发布方接收到API网关发送的访问请求后生成的。

在一种可选的实施方式中，所述第一转发单元具体用于：

通过所述服务发布方所在微服务运行环境对应的鉴权方式将所述访问请求转发给所述服务发布方。

在一种可选的实施方式中，所述第二转发单元具体用于：

确认所述服务调用方与所述服务发布方的微服务运行环境相同时，通过所述微服务运行环境对应的鉴权方式将所述响应消息转发给所述服务调用方；或

确认所述服务调用方与所述服务发布方的微服务运行环境不同时，通过所述API网关对应的鉴权方式将所述响应消息转发给所述服务调用方。

本申请实施例提供的第二种服务调用装置，包括：

访问单元，用于获取服务发布方的访问地址，并根据所述访问地址向API网关发送访问请求，以使所述API网关将所述访问请求转发给所述服务发布方；

接收单元，用于接收所述API网关返回的响应消息，其中所述响应消息为所述服务发布方根据所述访问请求生成的。

在一种可选的实施方式中，所述访问单元具体用于：

所述服务调用方与所述服务发布方的微服务运行环境相同时，通过所述微服务运行环境对应的鉴权方式向所述API网关发送所述访问请求；或

所述服务调用方与所述服务发布方的微服务运行环境不同时，通过所述API网关对应的鉴权方式向所述API网关发送所述访问请求。

本申请实施例提供的第三种服务调用装置，包括：

响应单元，用于接收API网关发送的访问请求，其中所述访问请求为服务调用方发送给所述API网关的；

发送单元，用于根据所述访问请求生成响应消息，并将所述响应信息发送给所述API网关，以使所述API网关将所述响应消息转发给所述服务调用方。

在一种可选的实施方式中，所述发送单元具体用于：

通过所述服务调用方所在微服务运行环境对应的鉴权方式将所述响应信息发送给所述API网关。

本申请实施例提供的一种电子设备，包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行上述任意一种服务调用方法的步骤。

本申请实施例提供一种计算机可读存储介质，其包括程序代码，当所述程序产品在电子设备上运行时，所述程序代码用于使所述电子设备执行上述任意一种服务调用方法的步骤。

本申请有益效果如下：

本申请实施例提供了一种服务调用方法、装置、电子设备和存储介质，由于本申请实施例中所有的服务调用过程都经过了API网关，基于API网关作为服务调用方与服务发布方之间的桥梁实现服务之间的融合。由API网关实现微服务调用的统一管理与适配，因而不需要去做额外的开发去适配不同的环境，减小了***开发的复杂度，提高了服务调用的效率。此外达到了屏蔽研发技术差异，实现机构应用的统一管理的目的，加快机构的数字化转型过程。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1A为本申请实施例中的一种微服务框架的示意图；

图1B为本申请实施例中的另一种微服务框架的示意图；

图2为本申请实施例中的一种应用场景的示意图；

图3为本申请实施例中的第一种用户界面的示意图；

图4为本申请实施例中的第二种用户界面的示意图；

图5为本申请实施例中的第一种服务调用方法的示意图；

图6为本申请实施例中的一个可选的交互实现时序流程示意图；

图7为本申请实施例中的另一个可选的交互实现时序流程示意图；

图8A为本申请实施例中的一种微服务运行环境内部调用的示意图；

图8B为本申请实施例中的一种不同微服务运行环境调用的示意图；

图9为本申请实施例中的第二种服务调用方法的示意图；

图10为本申请实施例中的第三种服务调用方法的示意图；

图11为本申请实施例中的一种集中控制平台注册中心注册和调用逻辑时序图；

图12为本申请实施例中的第一种服务调用装置的示意图；

图13为本申请实施例中的第二种服务调用装置的示意图；

图14为本申请实施例中的第三种服务调用装置的示意图；

图15为本申请实施例中的一种电子设备的组成结构示意图；

图16为应用本申请实施例的一种计算装置的一个硬件组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请技术方案保护的范围。

下面对本申请实施例中涉及的部分概念进行介绍。

1、微服务，是指开发多个独立小型、但有完整业务功能的服务，例如***拆分成的很多小应用。其中每个服务都有自己的处理和通讯机制，可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。微服务需要运行在微服务框架下，如spring cloud(春云，是一系列框架的有序集合)、K8S+Istio(Kubernetes+Istio，开源微服务框架)等，因而spring cloud、K8S+Istio等都属于本申请实施例中的微服务运行环境。

2、普通二进制服务，强调的是整个***或者应用。普通的二进制服务可以部署在任意环境，不需要依赖微服务框架。在本申请实施例中，普通二进制服务与微服务之间相互调用时，也属于不同微服务运行环境下服务调用的情况。

3、集中控制平台：是一个聚焦于用户身份、应用和服务、网络访问控制的融合统一，助力政府和大型企业推进数字化转型的平台。在本申请实施例中，包含了若干个***，主要包括门户管理***、注册中心以及相关的API网关等。其中，门户管理***用于机构管理员对服务进行管理，通过门户管理***可以将服务写入注册中心；注册中心用于完成服务统一注册和更新；相关的API网关用于完成多个运行环境微服务相互调用。

4、API网关，是一个服务器，是***的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了***内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。

在本申请实施例中的API网关分为集中控制平台相关的API网关以及微服务API网关。其中集中控制平台相关的API网关即本申请权利要求中的API网关，主要用于完成多个微服务运行环境微服务的相互调用，在微服务之间起到一个桥梁的作用，多个微服务之间的调用都会经过集中控制平台相关的API网关进行统一管理。微服务API网关是针对微服务运行环境而言，微服务运行环境可以分为有微服务API网关和无微服务API网关两种方式，有微服务API网关时，该网关主要用于将客户端或消费端通过统一入口接入微服务。

5、服务调用，指某个微服务需要访问其他微服务。具体可分为两种方式：1)同一微服务运行环境内部服务相互调用；2)某一微服务运行环境内部的服务需要访问其他的运行环境的服务。例如，同一个机构的不同部门分别采购了不同的微服务框架服务，但是部门之间又有需要互相调用；或者，不同部门的IT(Internet Technology，互联网技术)技术人员的技术能力不一致，采用的服务开发框架不一样；或者，同一个部门需要搭建不同的微服务运行环境来区分正式环境、研发环境、敏感环境等环境。上述这些情况下都需要进行不同微服务运行环境的服务调用。

6、服务调用方，指服务调用过程中需要访问其他服务的一方，也可以称作服务消费方。例如APP1需要访问APP2时，APP1即服务调用方。

7、服务发布方，指服务调用过程中需要被其他服务访问的一方，也可以称作服务提供方。例如APP1需要访问APP2时，APP2即服务发布方。

8、云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络***的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台***进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的***后盾支撑，只能通过云计算来实现。

下面对本申请实施例的设计思想进行简要介绍：

目前，互联网公司的***通常由大量提供不同功能的子***采用微服务的架构组成，下面介绍相关技术中常见的两种微服务框架中的微服务API网关：

一、Zuul(祖鲁)是一个API网关组件，提供了认证、鉴权、限流、动态路由，监控，弹性，安全、负载均衡、协助单点压测、静态响应等边缘服务的框架。Zuul对的大部分功能都是通过过滤器来实现的，其核心是一系列的filters(过滤器)，Zuul把请求路由到用户处理逻辑的过程中，这些filter参与一些过滤处理，最后把请求转发到微服务中。

如图1A所示，是本申请实施例提供的一种Zuul请求的生命周期示意图，该图详细描述了各种类型的过滤器的执行顺序，根据过滤器类型的不同，执行的顺序不同且可完成不同的功能。具体的，pre在请求被路由之前调用，可实现日志监控、身份认证、黑名单等功能；routing在路由请求时候被调用，用于构建发送给微服务的请求，并请求微服务；post在routing和error过滤器之后被调用，可实现审计、统计等功能；error在处理请求时发生错误时被调用、可实现统一异常处理等功能。此外，Zuul还包括custom fifters，即自定义过滤器。

二、Kong(空)是另一种API网关组件，其原理和Zuul类似，如图1B所示可用于身份验证、缓存、监测、调用速率限制、登陆、安全、访问控制列表等。其提供了大量的插件来扩展应用，通过设置不同的插件可以为服务提供各种增强的功能。

虽然，Zuul或Kong都能提供对对应微服务运行环境内的权限控制、安全、负载均衡、请求分发、监控等能力。但是，无论是Zuul、kong还是其他的微服务框架网关，这些组件都会有以下问题：

1、组件基本只关心遵循API网关组件流入的流量，来保护自身服务，如果某个微服务运行环境内部的服务需要访问其他的微服务运行环境的服务，则该服务需要按照对方的组件的要求来调用，包括接入方式和调用鉴权方式等，带来了额外的适配开发量。

2、如果一个机构有多个微服务运行环境的时候，当前组件无法提供一个统一的管理平台进行管理，无法达到机构统一管理的目的。如同时有正式环境、测试环境，则需要维护两套***部署。或者同时存在不同的微服务运行环境，还需要在不同的平台进行维护应用或服务。

有鉴于此，本申请实施例提供了一种服务调用方法、装置、电子设备和存储介质。通过集中控制平台提供与当前主流微服务运行环境提供的注册方式一致的注册中心和服务同步，首先通过集中控制平台的注册中心实现完成服务的统一注册或更新，再通过API网关实现不同运行环境微服务的相互调用。在本申请实施例中，API网关在服务调用过程中起到一个桥梁的作用，多个微服务之间的调用都会经过API网关进行统一管理。对于服务调用方只需要确认需要调用的服务是在某一环境下的，不需要为了不同环境的服务去做额外的开发去适配不同的微服务运行环境；对于服务发布方，只需要确认发布的服务的鉴权方式和调用格式，其他环境的鉴权则由API网关统一转换和适配，因而可以融合多个微服务运行环境和普通二进制服务，达到屏蔽研发技术差异，实现机构应用的统一管理的目的，加快机构的数字化转型过程。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

参阅图2所示，其为本申请实施例提供的一种应用场景示意图。图2所示的应用场景包括集中控制平台、内部***。此外，机构内可以根据合作伙伴的诉求，部署多个运行环境，如普通服务器、spring cloud运行环境和K8S+Istio运行环境等，而这些环境又可以分为正式环境、测试环境、敏感环境等。如图2所示的应用场景就包括spring cloud运行环境和K8S+Istio运行环境等。

在本申请实施例中，通过集中控制平台可以使得基于spring cloud或者K8S进行开发的服务，保持注册方式不变，当服务在具体的微服务运行环境启动之后，集中控制平台的注册中心会自动将服务同步到集中控制平台中，后端服务会自动接入API网关，API网关支持跨网络服务的相互调用，为API提供数据格式转化、加解密、过载保护、二次验证等能力，因而基于集中控制平台可以实现不同微服务运行环境的融合，以使不同运行环境的微服务可以通过保持原服务注册方式来注册和调用。

需要说明的是，API网关是服务器。在本申请实施例中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

可选的，机构管理员可以使用的集中控制平台的门户管理***进行所有服务的统一维护，例如机构管理员可以登录门户管理***，通过相应的***找到直接注册在上的所有服务；也可以通过对应的微服务运行环境查看某个微服务的注册情况。

如图3所示，为本申请实施例提供的一种UI(User Interface，用户界面)示意图，通过该界面可以查看所有服务列表。例如，机构管理员可以通过点击图中所示的创建服务按钮来注册新的服务，通过我的服务部分来查看已注册的服务，其中具体包括服务名称、服务标识、可见性、服务部署区域、状态、授权应用、操作等信息。

以图3所示的一个服务为例，该服务名称为：spring cloud服务示例，服务标识为：spring cloud demo；其中，服务的可见性是服务注册在集中控制平台的一个参数，只有设置为公开的服务才能被其他应用调用公开服务，因而该服务可见性为公开服务即表示该服务可以被其他应用调用；服务部署区域为spring cloud环境下，状态：已审批，是服务注册在集中控制平台的一种状态，服务注册之后需要管理员审批之后才能正式启用。

此外，机构管理员还可以进行统一的增删查改等动作，大大降低了管理员的维护成本。

参阅图4所示，为本申请实施例提供的另一种UI示意图，图中主要显示的是服务的基本信息和服务信息。其中基本信息具体包括：服务名称、服务标识、服务描述、服务标签、公开路径、可见性、负载方式等信息，此外，还包括全局配置。服务信息具体包括服务部署区域等。

其中，服务描述指服务发布的时候的描述信息，可以由发布者填写，用来说明该服务的作用。例如图4中所示的服务名称为spring cloud服务示例的服务，其服务描述为：验证服务融合过程，则表明该服务是为了验证服务融合过程而创建的一个示例。

此外需要说明的是，本申请实施例中服务的公开路径是实际公开给其他应用查看的路径，有些***负责人不希望服务实际路径给其他应用看到时，就可以使用公开路径来隐藏。而全局配置中的原始路径则是原始服务部署的实际路径，是API网关转发请求的实际寻找地址。

参阅图5所示，为本申请实施例提供的第一种服务调用方法的实施流程图，应用于API网关，该方法的具体实施流程如下：

S51：API网关接收服务调用方发送的访问请求，并将访问请求转发给相应的服务发布方；其中，该API网关指集中控制平台相关的API网关。

可选的，API网关将访问请求转发给相应的服务发布方时，具体过程为：

无论服务调用方与服务发布方的微服务运行环境是否相同，通过服务发布方所在微服务运行环境对应的鉴权方式将访问请求转发给服务发布方。

也就是说，实现了不同的微服务运行环境进行融合，不同环境的服务可以通过保持原服务注册方式来注册和调用。经过集中控制平台相关的API网关调用注册在springcloud或者K8S的服务，按照集中控制平台的鉴权方式使用；在spring cloud或者K8S发起调用服务时，可以按照原有环境的调用方式进行访问。下面以图6和图7所示为例进行举例说明：

在本申请实施例中，微服务运行环境可分为有微服务API网关和无微服务API网关两种形式，这两种情况下，微服务运行环境对应的鉴权方式不同。

具体的，针对无微服务API网关的微服务运行环境，对应的鉴权方式为微服务运行环境原本的鉴权方式，以微服务运行环境为spring cloud为例，则微服务运行环境对应的鉴权方式即spring cloud鉴权方式，具体参阅图6所示，spring cloud微服务运行环境无微服务API网关。

以服务调用方与服务发布方的微服务运行环境相同为例，例如图6所示，位于spring cloud微服务运行环境的APP2访问APP3时，服务调用方A为APP2，服务发布方B为APP3，APP2与APP3都位于spring cloud微服务运行环境，其中，集中控制平台相关的API网关使用spring cloud鉴权方式将访问请求发送给APP3。

以服务调用方与服务发布方的微服务运行环境不同为例，例如图6所示位于普通二进制服务环境下的APP1访问位于spring cloud微服务运行环境的APP2时，服务调用方为APP1，服务发布方为APP2，APP1与APP2位于不同的微服务运行环境，则集中控制平台相关的API网关使用spring cloud鉴权方式将访问请求发送给APP2。

针对有微服务API网关的微服务运行环境，对应的鉴权方式为微服务API网关鉴权方式，具体参阅图7所示，spring cloud微服务运行环境有微服务API网关。

以服务调用方与服务发布方的微服务运行环境相同为例，例如图7所示，在APP2访问APP3时，集中控制平台相关的API网关使用微服务API网关鉴权方式将访问请求发送给APP3。具体的，由集中控制平台相关的API网关转发出的访问请求，首先会先经过springcloud中的微服务API网关，之后再到APP3。

例如图7所示，在APP1访问APP2时，则集中控制平台相关的API网关使用微服务API鉴权方式将访问请求发送给APP2。

S52：API网关接收服务发布方返回的响应消息，并将响应消息转发给服务调用方，其中响应消息是服务发布方接收到API网关发送的访问请求后生成的。

可选的，集中控制平台相关的API网关将响应消息转发给服务调用方，具体可分为如下两种方式：

方式一、API网关确认服务调用方与服务发布方的微服务运行环境相同时，通过微服务运行环境对应的鉴权方式将响应消息转发给服务调用方。

针对无微服务API网关的微服务运行环境，仍以图6所示为例，在APP2访问APP3时，集中控制平台相关的API网关通过spring cloud鉴权方式将响应消息转发给APP2。

针对有微服务API网关的微服务运行环境，仍以图7所示为例，则API网关通过微服务API鉴权方式将访问请求转发给APP3。具体的，集中控制平台相关的API网关转发给APP2的响应消息不是直接到达APP2，而是先经过spring cloud中的微服务API网关，再由微服务API网关转发给APP2。

方式二、API网关确认服务调用方与服务发布方的微服务运行环境不同时，通过API网关对应的鉴权方式将响应消息转发给服务调用方。

仍以图6所示为例，APP1访问APP2时，API网关使用集中控制平台相关的API网关鉴权方式将响应消息转发给APP1。

在上述实施方式中，经过API网关调用注册在spring cloud或者K8S等微服务运行环境的服务时，按照集中控制平台的鉴权方式使用；在spring cloud或者K8S等微服务运行环境的服务发起调用服务时，可以按照原有环境的调用方式进行访问，所有调用过程都经过了集中控制平台相关的API网关，机构可以对机构内所有的服务进行统一的管理、审批等，也可以用统一的方式或者外接查看运营监控日志。

在本申请实施例中，针对微服务运行环境而言，有微服务API网关和无微服务API网关这两种方式的服务调用实现过程类似，唯一的区别在于服务在实际发起调用的时候，集中控制平台适配的是微服务API网关的鉴权方式，还是微服务本来的鉴权方式。下面以无微服务API网关为例，参照图6对本申请实施例中的服务调用的操作过程进行详细介绍：

图6为本申请实施例提供的一种服务调用示意图。图中所示包括：无微服务API网关的Sping Cloud框架、3个APP(Application，应用程序)，分别为APP1、APP2、APP3，以及集中控制平台。

需要说明的是图6介绍的是通过集中控制平台实现spring cloud应用微服务调用的过程，需要说明的是，该方法同样适用于K8S。主要可分为部署过程、注册服务过程以及服务调用过程三部分，下面对这三部分过程进行详细介绍。

一、部署过程：

首先在机构部署集中控制平台、注册中心，并以spring cloud作为微服务运行环境。之后在机构部署spring cloud，并将spring cloud的注册中心配置为集中控制平台提供的注册中心，以便于服务统一注册。

具体的，可通过修改spring cloud应用的consul(领事，提供服务发现的工具)地址为集中控制平台域名的方式将spring cloud的注册中心配置为集中控制平台提供的注册中心，例如修改Spring Cloud的配置文件application.yml或bootstrap.yml实现注册中心的配置。其中，consul是spring cloud的一个服务注册组件，用来管理在spring cloud里启用的服务。

二、注册服务：

以APP1、APP2、APP3为例，假设将APP1部署在普通服务器上，将APP2、APP3部署在Spring Cloud微服务运行环境。由于普通服务器可以部署在任意环境，因而在部署APP1时，则可通过门户管理***直接注册服务，具体过程为：在API网关生成APP1的服务地址，并将该服务写入注册中心。

针对APP2、APP3，使用Spring Cloud的方式启动服务，并将自身服务注册到SpringCloud中，由于Spring Cloud的注册中心已经预先配置为集中控制平台提供的注册中心，因而此时就已经将服务注册到集中控制平台注册中心。

在上述实施方式中，可实现不同微服务运行环境下服务的统一注册与管理，使得普通二进制服务与微服务实现服务融合，以便在spring cloud或者K8S发起调用服务时，可以按照原有环境的调用方式进行访问。

需要说明的是，图中灰色部分为相关技术中spring cloud内部微服务调用支持的默认调用方式，在本申请实施例中通过注册服务过程将调用方式由集中控制平台托管之后，则不再使用该方式，而是采用第三部分虚线框中的服务调用方式，下面将进行详细介绍。

三、服务调用过程：

在本申请实施例中，根据上述微服务运行环境的部署，具体可分为同一微服务运行环境的服务调用以及不同微服务运行环境的服务调用，下面分别举例说明。

1、同一微服务运行环境的服务调用。

例如Spring Cloud内部APP2与APP3之间的调用，假设服务调用方A为APP2，服务发布方B为APP3。当服务调用方A(即APP2)发起请求时，请求会通过API网关转发到服务发布方B(即APP3)，此时API网关会自动适配服务发布方和服务调用方原来的调用方式，如果原来无校验过程，则透明转发并提供负载均衡、流量控制等保护机制，如图8A所示。

其中，图8A所示的consul是spring cloud的一个服务注册组件，用来管理在spring cloud里启用的服务，也就是本申请实施例中的APP2、APP3。其中虚线部分为普通Spring cloud环境调用过程，也就是相关技术中同一微服务运行环境下服务调用的方式。具体的服务调用过程为：服务调用方A从Consul获取服务发布方的ip(Internet Protocol，互联网协议)，根据Consul返回的ip列表，服务调用方A根据ip直接访问服务发布方B。

实线部分为本申请实施例提供的集中控制平台注册中心调用过程。具体的服务调用过程为：服务调用方A首先通过服务融合获取方式，从注册中心获取注册时分配的域名，之后通过服务融合访问方式通过API网关访问服务发布方B。

需要说明的是，实际上，虚线部分和实线部分的使用方式完全一致，针对服务调用方A，其并不知道集中控制平台的存在，因而服务调用方A对微服务内的所有应用的调用都是基于原有的使用方式，包括输入和返回参数都是一致的，这样才能保证原来的服务不会受到影响。

2、不同微服务运行环境的服务调用，例如其他环境(普通二进制服务环境)与Spring Cloud服务相互调用。

例如图8B所示，假设服务调用方C为APP1，服务发布方D为APP2。首先服务调用方C(即APP1)从门户管理***查看服务发布方D(即APP2)的访问地址，并通过集中控制平台相关的API网关的签名访问；API网关接受到服务调用方A发送的访问请求后，根据访问地址为服务ID(Identity，标识)而并非服务域名则可确认实际访问请求为微服务运行环境，因而API网关在注册中心查找服务ID对应在注册中心的地址；进一步API网关根据查找到的服务ID对应在注册中心的地址，将访问请求转发到微服务运行环境内的服务发布方D。

其中，服务ID是指发布在微服务运行环境内的服务ID，所有微服务运行环境内的应用在启动的时候都会先注册一个服务ID。

在上述实施方式中,API网关的签名访问即API网关对应的鉴权方式，API网关鉴权是针对普通二进制服务环境需要发起对微服务运行环境内的服务调用才需要完成的，用以保护被调用方，确定本次发起的请求是真实有效的。

需要说明的是，图7即微服务运行环境有微服务API网关时服务调用的操作过程，与图6的唯一区别在于，不再使用spring cloud鉴权方式，而是使用微服务API网关鉴权方式。

在一种可选的实施方式中，API网关可通过下列方式判断服务调用方与服务发布方的微服务运行环境是否相同。

具体的，API网关根据服务调用方获取的服务发布方的地址信息来判断，当服务发布方的地址为API网关域名时，则确认服务调用方与服务发布方的微服务运行环境相同；当服务发布方的地址为服务ID，而非API网关域名时，则确认服务调用方与服务发布方的微服务运行环境不同，服务发布方位于微服务运行环境，而服务发布方位于普通二进制服务环境。该方式下，服务调用方只需要从门户管理***或注册中心获取服务发布方的地址信息即可，而不再需要为了不同环境的服务去做额外的开发去适配不同的微服务运行环境。

需要说明的是，上述实施方式仅是本申请实施例中所列举的一种微服务运行环境判断方式，其它判断方式同样适用于本申请实施例，在此不做具体限定。

参阅图9所示，为本申请实施例提供的第二种服务调用方法的实施流程图，应用于服务调用方，该方法的具体实施流程如下：

S91：服务调用方获取服务发布方的访问地址，并根据访问地址向API网关发送访问请求，以使API网关将访问请求转发给服务发布方；

可选的，服务调用方获取服务发布方的访问地址时，可通过注册中心或门户管理***获取，如图8A或图8B所示，其中普通二进制服务环境下的服务调用方C可以直接从门户管理***找到服务发布方D的公开路径然后调用，不需要经过注册中心。

在一种可选的实施方式中，服务调用方根据访问地址向API网关发送访问请求，具体可分为以下两种方式：

方式一、服务调用方与服务发布方的微服务运行环境相同时，服务调用方通过微服务运行环境对应的鉴权方式向API网关发送访问请求。

针对无微服务API网关的微服务运行环境，仍以图6所示为例，APP2访问APP3时，APP2使用spring cloud鉴权方式将访问请求发送给集中控制平台相关的API网关。

针对有微服务API网关的微服务运行环境，仍以图7所示为例，APP2访问APP3时，APP2使用微服务API网关鉴权方式将访问请求发送给API网关。具体的，APP2发送的访问请求需要经过spring cloud中的微服务API网关发送给集中控制平台相关的API网关。

方式二、服务调用方与服务发布方的微服务运行环境不同时，服务调用方通过API网关对应的鉴权方式向API网关发送访问请求。

仍以图6所示为例，位于普通二进制服务环境下的APP1访问位于spring cloud微服务运行环境的APP2时，则APP1使用集中控制平台相关的API网关鉴权方式将访问请求发送给API网关。

需要说明的是，微服务API网关的鉴权是集中控制平台相关的API网关和微服务运行环境内的应用发生的，与普通二进制服务环境的应用无关。

S92：服务调用方接收API网关返回的响应消息，其中响应消息为服务发布方根据访问请求生成的。

上述实施方式中，对于服务调用方，只需要关心需要调用的服务是在某一环境下的，不需要为了不同环境的服务去做额外的开发去适配不同的环境。降低机构的维护成本的同时为机构的合作伙伴/开发人员屏蔽技术差异，节省开发时间和采购适配成本。

参阅图10所示，为本申请实施例提供的第三种服务调用方法的实施流程图，应用于服务发布方，该方法的具体实施流程如下：

S101：服务发布方接收API网关发送的访问请求，其中访问请求为服务调用方发送给API网关的；

S102：服务发布方根据访问请求生成响应消息，并将响应信息发送给API网关，以使API网关将响应消息转发给服务调用方。

在一种可选的实施方式中，服务发布方将响应信息发送给API网关时，无论服务调用方与服务发布方的微服务运行环境相同还是不同，服务发布方通过其所在微服务运行环境对应的鉴权方式将响应信息发送给API网关。

针对无微服务API网关的微服务运行环境，例如图6所示位于spring cloud微服务运行环境的APP2访问APP3时，APP3使用spring cloud鉴权方式将响应消息发送给集中控制平台相关的API网关。

针对有微服务API网关的微服务运行环境，例如图7所示位于spring cloud微服务运行环境的APP2访问APP3时，APP3使用微服务API鉴权方式将响应消息经过微服务API网关发送给集中控制平台相关的API网关。

或者，例如图6所示位于普通二进制服务环境下的APP1访问位于spring cloud微服务运行环境的APP2时，APP2使用spring cloud鉴权方式将响应消息发送给集中控制平台相关的API网关，等。

在上述实施方式中，对于服务发布方，只需要关心发布的服务的鉴权方式和调用格式，其他环境的鉴权则由API网关统一转换和适配，降低机构的维护成本的同时为机构的合作伙伴或开发人员屏蔽技术差异，节省开发时间和采购适配成本。

可选的，本申请实施例中集中控制平台的注册中心还可以支持异步同步的方式来更新服务。

例如，微服务运行环境不采用配置注册中心修改为注册中心，而是直接使用consul时，集中控制平台可以支持将consul中的服务同步到注册中心，包括全量同步、指定服务同步等。

其中，全量同步是指将所有服务同步到集中控制平台注册中心，指定服务同步是指将特定服务同步到集中控制平台注册中心。

上述实施方式中，通过微服务注册中心的修改或是服务同步使得集中控制平台注册中心能够统一管理所有服务，实现普通二进制服务环境和微服务运行环境的相互融合。微服务运行环境可以按照原有的运行方式不变。因而在降低机构的维护成本的同时为机构的合作伙伴或开发人员屏蔽技术差异，节省开发时间和采购适配成本。

参阅图11所示，为本申请实施例提供的一种微服务运行环境内部服务调用交互时序图。该方法的具体实施流程如下：

步骤1101：服务A调用接口/agent/service/register在集中控制平台注册服务A；

步骤1102：集中控制平台向服务A返回服务A注册成功的消息；

步骤1103：服务B调用接口/agent/service/register从集中控制平台获取服务A地址；

步骤1104：集中控制平台向服务B返回服务A的地址A.service..com；

步骤1105：服务B发送访问请求GET http://A.service.rio.com/user/list；

步骤1106：集中控制平台根据地址A.service.rio.com将请求转发到服务A；

步骤1107：服务A向返回users(用户)列表；

步骤1108：集中控制平台将users列表转发给服务B。

其中，步骤1101中服务的注册方式可具体参见上述实施例中所列举的注册服务部分，重复之处不再赘述。在步骤1105中，GET用于信息获取，其中基于*.service.rio.com会将请求解析到集中控制平台相关的API网关，而/user/list表示用于获取服务A的用户列表。

需要说明的是，在本申请实施例中，服务注册和服务发现的逻辑与spring cloudconsul过程(即图8A所示虚线部分)完全一致，唯一不同的地方是服务调用方根据服务名获取到的address(地址)将不再是服务发布方(目标服务)的原始IP，而是域名形式，如serviceid.service.rio.com，而该域名会解析到集中控制平台相关的API网关，API网关再将请求转发到服务发布方地址。

例如，图11中服务B使用域名A.service.rio.com访问服务A，其中\*.service.rio.com域名全部解析到API网关，API网关再将请求转发到服务A。

参阅图12所示，为本申请实施例提供的第一服务调用装置的结构示意图。如图12所示，服务调用装置1200可以包括：

第一转发单元1201，用于接收服务调用方发送的访问请求，并将访问请求转发给相应的服务发布方；

第二转发单元1202，用于接收服务发布方返回的响应消息，并将响应消息转发给服务调用方，其中响应消息是服务发布方接收到API网关发送的访问请求后生成的。

在一种可选的实施方式中，第一转发单元1201具体用于：

通过服务发布方所在微服务运行环境对应的鉴权方式将访问请求转发给服务发布方。

在一种可选的实施方式中，第二转发单元1202具体用于：

确认服务调用方与服务发布方的微服务运行环境相同时，通过微服务运行环境对应的鉴权方式将响应消息转发给服务调用方；或

确认服务调用方与服务发布方的微服务运行环境不同时，通过API网关对应的鉴权方式将响应消息转发给服务调用方。

参阅图13所示，为本申请实施例提供的第二种服务调用装置的结构示意图。如图13所示，服务调用装置1300可以包括：

访问单元1301，用于获取服务发布方的访问地址，并根据访问地址向API网关发送访问请求，以使API网关将访问请求转发给服务发布方；

接收单元1302，用于接收API网关返回的响应消息，其中响应消息为服务发布方根据访问请求生成的。

在一种可选的实施方式中，访问单元1301具体用于：

服务调用方与服务发布方的微服务运行环境相同时，通过微服务运行环境对应的鉴权方式向API网关发送访问请求；或

服务调用方与服务发布方的微服务运行环境不同时，通过API网关对应的鉴权方式向API网关发送访问请求。

参阅图14所示，为本申请实施例提供的第三种服务调用装置的结构示意图。如图14所示，服务调用装置1400可以包括：

响应单元1401，用于接收API网关发送的访问请求，其中访问请求为服务调用方发送给API网关的；

发送单元1402，用于根据访问请求生成响应消息，并将响应信息发送给API网关，以使API网关将响应消息转发给服务调用方。

在一种可选的实施方式中，发送单元1402具体用于：

通过服务发布方所在微服务运行环境对应的鉴权方式将响应信息发送给API网关。

为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本申请时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。

在介绍了本申请示例性实施方式的服务调用方法和装置之后，接下来，介绍根据本申请的一示例性实施方式的电子设备。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为***、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“***”。

参阅图15所示，为本申请实施例提供的一种电子设备的结构示意图。根据本申请的电子设备1500可以至少包括处理器1501和存储器1502，如图15所示。其中，所述存储器1502存储有程序代码，当所述程序代码被所述处理器1501执行时，使得所述处理器1501执行本说明书中描述的根据本申请各种示例性实施方式的服务调用方法中的步骤。例如，所述处理器1501可以执行如图5中所示的步骤。

在一些可能的实施方式中，根据本申请的计算装置可以至少包括至少一个处理单元、以及至少一个存储单元。其中，存储单元存储有程序代码，当程序代码被处理单元执行时，使得处理单元执行本说明书上述描述的根据本申请各种示例性实施方式的服务调用方法中的步骤。例如，处理单元可以执行如图5中所示的步骤。

下面参照图16来描述根据本申请的这种实施方式的计算装置160。图16的计算装置160仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图16，计算装置160以通用计算装置的形式表现。计算装置160的组件可以包括但不限于：上述至少一个处理单元161、上述至少一个存储单元162、连接不同***组件(包括存储单元162和处理单元161)的总线163。

总线163表示几类总线结构中的一种或多种，包括存储单元总线或者存储器控制器、***总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储单元162可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1621和/或高速缓存存储单元1622，还可以进一步包括只读存储器(ROM)1623。

存储单元162还可以包括具有一组(至少一个)程序模块1624的程序/实用工具1625，这样的程序模块1624包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算装置160也可以与一个或多个外部设备164(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与计算装置160交互的设备通信，和/或与使得该计算装置160能与一个或多个其它计算装置进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口165进行。并且，计算装置160还可以通过网络适配器166与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器166通过总线163与用于计算装置160的其它模块通信。应当理解，尽管图中未示出，可以结合计算装置160使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

在一些可能的实施方式中，本申请提供的服务调用方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在计算机设备上运行时，程序代码用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的服务调用方法中的步骤，例如，计算机设备可以执行如图5中所示的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种服务调用方法，其特征在于，该方法包括：

应用程序编程接口API网关接收服务调用方发送的访问请求，并将所述访问请求转发给相应的服务发布方；

所述API网关接收所述服务发布方返回的响应消息，并将所述响应消息转发给所述服务调用方，其中所述响应消息是所述服务发布方接收到所述API网关发送的访问请求后生成的。

2.如权利要求1所述的方法，其特征在于，所述将所述访问请求转发给相应的服务发布方，包括：

通过所述服务发布方所在微服务运行环境对应的鉴权方式将所述访问请求转发给所述服务发布方。

3.如权利要求1所述的方法，其特征在于，所述将所述响应消息转发给所述服务调用方，包括：

所述API网关确认所述服务调用方与所述服务发布方的微服务运行环境相同时，通过所述微服务运行环境对应的鉴权方式将所述响应消息转发给所述服务调用方；或

所述API网关确认所述服务调用方与所述服务发布方的微服务运行环境不同时，通过所述API网关对应的鉴权方式将所述响应消息转发给所述服务调用方。

4.一种服务调用方法，其特征在于，该方法包括：

服务调用方获取服务发布方的访问地址，并根据所述访问地址向API网关发送访问请求，以使所述API网关将所述访问请求转发给所述服务发布方；

所述服务调用方接收所述API网关返回的响应消息，其中所述响应消息为所述服务发布方根据所述访问请求生成的。

5.一种服务调用方法，其特征在于，该方法包括：

服务发布方接收API网关发送的访问请求，其中所述访问请求为服务调用方发送给所述API网关的；

所述服务发布方根据所述访问请求生成响应消息，并将所述响应信息发送给所述API网关，以使所述API网关将所述响应消息转发给所述服务调用方。

6.一种服务调用装置，其特征在于，包括：

第一转发单元，用于接收服务调用方发送的访问请求，并将所述访问请求转发给相应的服务发布方；

第二转发单元，用于接收所述服务发布方返回的响应消息，并将所述响应消息转发给所述服务调用方，其中所述响应消息是所述服务发布方接收到API网关发送的访问请求后生成的。

7.一种服务调用装置，其特征在于，包括：

访问单元，用于获取服务发布方的访问地址，并根据所述访问地址向API网关发送访问请求，以使所述API网关将所述访问请求转发给所述服务发布方；

接收单元，用于接收所述API网关返回的响应消息，其中所述响应消息为所述服务发布方根据所述访问请求生成的。

8.一种服务调用装置，其特征在于，包括：

响应单元，用于接收API网关发送的访问请求，其中所述访问请求为服务调用方发送给所述API网关的；

发送单元，用于根据所述访问请求生成响应消息，并将所述响应信息发送给所述API网关，以使所述API网关将所述响应消息转发给所述服务调用方。

9.一种电子设备，其特征在于，其包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行权利要求1～5中任一所述方法的步骤。

10.一种计算机可读存储介质，其特征在于，其包括程序代码，当所述程序产品在电子设备上运行时，所述程序代码用于使所述电子设备执行权利要求1～5中任一所述方法的步骤。

Images