CN109995713A - 一种微服务框架中的服务处理方法及相关设备 - Google Patents

一种微服务框架中的服务处理方法及相关设备 Download PDF

Info

Publication number
CN109995713A
CN109995713A CN201711485852.4A CN201711485852A CN109995713A CN 109995713 A CN109995713 A CN 109995713A CN 201711485852 A CN201711485852 A CN 201711485852A CN 109995713 A CN109995713 A CN 109995713A
Authority
CN
China
Prior art keywords
service
rule
routing
shunting
micro services
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.)
Granted
Application number
CN201711485852.4A
Other languages
English (en)
Other versions
CN109995713B (zh
Inventor
杨健
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Cloud Computing Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201711485852.4A priority Critical patent/CN109995713B/zh
Publication of CN109995713A publication Critical patent/CN109995713A/zh
Application granted granted Critical
Publication of CN109995713B publication Critical patent/CN109995713B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • 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
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
    • 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/133—Protocols for remote procedure calls [RPC]
    • 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
    • H04L67/63—Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请涉及微服务技术领域，具体涉及一种微服务框架中的服务处理方法及相关设备。该方法包括第一微服务SDK接收服务调用请求，服务调用请求中携带有第二服务的服务名称，第二服务包括至少两个服务实例节点；第一微服务SDK根据第二服务的路由分流规则和服务注册信息将服务调用请求发送至第二服务中对应的服务实例节点，路由分流规则为根据服务注册信息和分流参数设置的规则，服务注册信息包括服务实例节点的地址和第二服务的服务名称。本申请实施例通过将该分流参数应用在路由分流规则中，在发起服务调用请求后，便能够由第一微服务SDK执行该服务分流规则对服务调用请求进行分流，服务的发布方和调用方不需要任何额外开发，节省开发成本。

Description

一种微服务框架中的服务处理方法及相关设备
技术领域
本申请涉及微服务技术领域，具体涉及一种微服务框架中的服务处理方法及相关设备。
背景技术
微服务已经成为当前企业级开发当中非常流行的架构，在微服务架构下，之前的单体应用被切分成一个个独立的服务，服务之间通过微服务框架进行远程过程调用(Remote Procedure Call，RPC)通信。微服务框架是一种包含三个部分的架构，即服务发布端、服务调用端和服务注册中心。服务发布端和服务调用端上均部署有微服务软件开发工具包 (Software Development Kit，SDK)。
该框架的执行过程大致可以是服务的发布者使用服务发布端的微服务SDK开发新服务，自动将服务元数据信息发布到服务注册中心，该服务元数据信息包括服务名、网络协议(Internet Protocol，IP)和端口等；服务调用者通过服务调用端的微服务SDK向服务注册中心请求自己需要调用服务的相关信息；最后，服务调用者根据获取到的服务的元数据信息(包括服务名、参数信息、发布者IP、端口)信息向对应服务发起远程调用。可以看出，该过程中微服务框架对开发屏蔽了远程网络通信的各种细节和复杂性，开发者可以像本地调用的方式一样去实现远程方法调用。
对于服务来说，在实际运行过程中，很容易出现相同的服务同时存在多个不同的高低版本，不同版本的服务提供的服务也可以是有区别的，对于服务调用者来说，并不知晓这一情况，因此需要对通过服务调用端发布的调用请求进行合理的分流；在微服务架构中，这种同时存在多个版本的服务可以被称为灰度升级，即服务的高低两个版本之间能够平滑过渡升级的一种方式。对于接收到的针对该服务的请求，***会根据一些条件对这些请求进行分流，使得请求被转发至对应的服务版本，此过程可以被称之为分流或者灰度分流。
然而，由于微服务框架将远程调用模拟为本地调用，将分布式***中复杂的网络间通信和路由机制封装，用户可以像调用本地服务接口一样去调用一个远程服务接口；但是随着灰度升级的流行，微服务框架的这种优势却也带来问题，即用户无法灵活控制调用请求的实际路由。对于开发者来说，每个服务的灰度分流逻辑均需要单独编码处理，并且不同的服务中，灰度分流逻辑难以抽象和公用，需要重新将分流逻辑的代码复制一遍，此外，为了微服务间解耦的基本原则，服务发布端任何分流字段和分流逻辑的变更，所有调用者都必须配合改动并重新发布，而且不同的服务由于不同的应用场景，灰度分流方案之间也不具备移植性，最终导致业务实现的开发复杂度高，开发成本高。
发明内容
本申请实施例提供了一种微服务框架中的服务处理方法及相关设备来解决目前微服务框架中应用灰度升级时带来的业务实现的开发复杂度高，开发成本高的问题。
本申请实施例的第一方面提供一种微服务框架中的服务处理方法，该方法中，第一服务的第一微服务SDK接收第一服务发送的服务调用请求，该服务调用请求主要用于向第二服务发起服务调用，并且该请求中还携带有第二服务的名称，对于第二服务，至少包括两个服务实例节点；当第一微服务SDK从服务名称确定第二服务设有路由分流规则时，便会按照该路由分流规则和服务注册信息对该请求进行分流，发送至对应的服务实例节点，服务注册信息中包括服务实例节点的地址和第二服务的服务名称，该路由分流规则具体是服务注册中心根据第二微服务SDK上报的服务注册信息和分流参数设置的规则，所述服务注册信息为所述第二服务发布时在所述服务注册中心中注册的信息。
可以看出，由于通过设置分流参数，将该分流参数应用在路由分流规则中，作为服务调用端的第一服务在发起服务调用请求后，便能够由第一微服务SDK执行该服务分流规则对服务调用请求进行分流；提供的是一种简单、对业务非侵入方式支持微服务灰度分流的方式，服务的发布方和调用方不需要任何额外开发，此外，在度分流规则发生变化时，仅需要在服务注册中心进行控制，服务的发布方和调用方无需感知；后续升级的成本低。
在一些实施例中，第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。即路由分流规则能够适用到服务版本不同，并且每个服务版本对应至少一个服务实例节点的场景，从而能够对针对该第二服务的请求进行有效的导流。
在一些实施例中，路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与服务实例节点的映射关系，即一个取值可以对应到一个服务实例节点，该路由分流规则还包括启用分流的第二服务的服务名称和服务实例节点的服务版本；所述服务注册信息包括启用分流的第二服务的服务名称和服务实例节点的服务版本，作为分流维度的分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型。因此可通过该路由分流规则知晓第二服务的如何进行分流，并以此控制向第二服务中各版本的服务实例节点发送的请求。
在一些实施例中，第一微服务SDK接收服务注册中心下发的服务注册信息和路由分流规则，即，该路由分流规则是由服务注册中心下发的，而该路由分流规则是由服务注册中心根据第二微服务SDK上报的服务注册信息和分流参数生成的规则，由服务注册中心下发保证该路由分流规则的来源一致，此外，服务注册信息包括的是该路由分流规则中所示的各服务实例节点的地址等信息，使得第一服务能够直接访问到该服务实例节点。
在一些实施例中，第一微服务SDK接收服务注册中心下发的路由分流规则之前，还会执行一请求操作，即第一微服务SDK向所述服务注册中心发送第一请求，第一请求中携带有所述第二服务的服务名称，该请求能够使得服务注册中心确定所述第一请求中的服务名称对应的路由分流规则；并将所述路由分流规则发送至所述第一微服务SDK。即该方式中华，是第一微服务SDK主动向服务注册中心获取路由分流规则。
在一些实施例中，第一微服务SDK接收服务注册中心下发的第一信息，该第一信息用于将所述第二服务的分流的开启或关闭信息通知给所述第一微服务SDK，从而使得第一微服务SDK能够对当前第二服务是否开启分流进行判断，执行合理的服务调用请求的转发。
在一些实施例中，当所述第一微服务SDK根据所述第一信息判断针对第一信息确定针对所述第二服务的分流已开启时，按照所述路由分流规则转发所述服务调用请求。此设置用在第一微服务SDK上已经设有默认的转发策略时，如果第一微服务SDK能够确认第二服务的分流已开启，则按照路由分流规则进行转发，否则，按照默认转发策略转发。
在一些实施例中，第一微服务SDK接收服务中心下发的第一信息之前，第一微服务SDK 还可向所述服务注册中心发送第二请求，该第二请求用于向所述服务注册中心获取所述第二服务的分流的开启或关闭信息，所述第二请求中携带有第二服务的服务名称。即，对于第一信息，可以由第一微服务SDK通过第二请求主动向服务注册中心获取，当然，也可以由服务注册中心与第一微服务SDK建立连接后，主动发送至第一微服务SDK。
在一些实施例中，路由分流规则或所述服务注册信息中包含所述第一信息。即，在情形下，第一信息是被携带在路由分流规则中发送的，因此对于第一微服务SDK来说，在该路由分流规则更新之前，第一信息是不变，只有等到下一次更新路由分流规则时，才会将该第一信息携带在其中，从而使得第一微服务SDK能够使用更新后的第一信息判断第二服务的分流的开启状况。
在一些实施例中，路由分流规则为用户通过调用服务注册中心提供的接口配置的规则。服务注册中心对于用户提供的接口包括界面和应用程序调用接口，用户在界面上编辑的内容可通过预设的应用程序调用接口调用相应的方法。
在一些实施例中，路由分流规则的更新也是用户通过调用服务注册中心提供的接口配置进行更新的，此情形下，第一微服务SDK便会接收到更新后的路由分流规则。
在一些实施例中，第二服务的第二微服务SDK在接收所述第一微服务SDK发送的服务调用请求后，对对应版本的服务实例节点发起调用之前，还包括一个校验过程，该校验主要校验第二服务的路由分流规则，当校验通过时，才会进行发起调用的操作。
本申请实施例第二方面还提供一种微服务框架中的服务处理方法，包括：
作为服务发布方的第二服务的第二微服务SDK接收作为服务调用方的第一服务通过所述第一服务的第一微服务SDK发送的服务调用请求；其中，该所述服务调用请求为第一服务的第一微服务SDK根据路由分流规则向第二服务发起服务调用，所述第二服务包括至少两个服务实例节点，所述服务调用请求中携带有第二服务的服务名称和目标服务实例节点的地址，所述目标服务实例节点为所述第二服务的任一服务实例节点，所述路由分流规则为服务注册中心根据第二微服务SDK上报的服务注册信息和分流参数设置的规则，作为分流维度的所述分流参数为所述第二服务通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型；接着该第二微服务 SDK便会根据所述服务调用请求向路由分流规则中对应版本的服务实例节点发起调用；此情形下，所述第二微服务SDK能够获取到该路由分流规则，所述服务注册信息包括所述服务实例节点的地址和第二服务的服务名称。
可以看出，由于通过设置分流参数，将该分流参数应用在路由分流规则中，作为服务调用端的第一服务在发起服务调用请求后，便能够由第一微服务SDK执行该服务分流规则对服务调用请求进行分流即可；提供的是一种简单、对业务非侵入方式支持微服务灰度分流的方式，服务的发布方和调用方不需要任何额外开发，此外，在度分流规则发生变化时，仅需要在服务注册中心进行控制，服务的发布方和调用方无需感知；后续升级的成本低。
在一些实施例中，在服务发布阶段，第二微服务SDK会接收所述第二服务发布的服务注册信息和分流参数，；接着，第二微服务SDK将所述服务注册信息和所述分流参数发送至所述服务注册中心。
在一些实施例中，第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点，该服务注册信息包括启用分流的所述第二服务的服务名称和服务实例节点的服务版本。即路由分流规则能够适用到服务版本不同，并且每个服务版本对应至少一个服务实例节点的场景，从而能够对针对该第二服务的请求进行有效的导流。
在一些实施例中，路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与服务实例节点的映射关系，即一个取值可以对应到一个服务实例节点，该路由分流规则还包括启用分流的第二服务的服务名称；作为分流维度的分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型。因此可通过该路由分流规则知晓第二服务的如何进行分流，并以此控制向第二服务中各版本的服务实例节点发送的请求。
在一些实施例中，第二服务的第二微服务SDK接收第一服务通过所述第一服务的第一微服务SDK发送的服务调用请求后，还会执行一个校验步骤，即第二微服务SDK校验所述第二服务的路由分流规则，当校验通过时，按照所述路由分流规则对对应版本的所述服务实例节点发起调用。该设计的好处在于，如果发现接收的请求并非通过路由分流规则发送的，则可以不处理该请求，从而节省处理资源，提升处理效率。
本申请实施例第三方面还提供一种微服务框架中的服务处理方法，该方法中，首先由服务注册中心接收第二服务的第二微服务SDK发送的服务注册信息和分流参数，所述服务注册信息为所述第二服务发布时在所述服务注册中心中注册的信息，所述服务注册信息包括启用分流的所述第二服务的服务实例节点的地址和第二服务的服务名称，作为分流维度的所述分流参数为所述第二服务通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上；接着，服务注册中心会根据服务注册信息和分流参数生成路由分流规则，该路由分流规则中包含服务注册信息和分流参数的映射规律；最后，服务注册中心便可将该路由分流规则以及服务注册信息发送给第一服务的第一微服务SDK，从而使得第一微服务SDK根据所述路由分流规则将所述服务调用请求发送至对应服务版本的服务实例节点，其中，该服务注册信息为所述第二服务发布时在所述服务注册中心中注册的信息。
可以看出，由于通过设置分流参数，将该分流参数应用在路由分流规则中，作为服务调用端的第一服务在发起服务调用请求后，便能够由第一微服务SDK执行该服务分流规则对服务调用请求进行分流即可；提供的是一种简单、对业务非侵入方式支持微服务灰度分流的方式，服务的发布方和调用方不需要任何额外开发，此外，在度分流规则发生变化时，仅需要在服务注册中心进行控制，服务的发布方和调用方无需感知；后续升级的成本低。
在一些实施例中，第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。即路由分流规则能够适用到服务版本不同，并且每个服务版本对应至少一个服务实例节点的场景，从而能够对针对该第二服务的请求进行有效的导流。
在一些实施例中，在服务发布阶段，第二微服务SDK会接收所述第二服务发布的服务注册信息和分流参数，该服务注册信息包括启用分流的所述第二服务的服务名称和服务实例节点的服务版本，作为分流维度的所述分流参数为所述第二服务通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型；接着，第二微服务SDK将所述服务注册信息和所述分流参数发送至所述服务注册中心，以使得所述服务注册中心根据所述服务注册信息和所述分流参数设置路由分流规则。
在一些实施例中，服务注册中心根据所述服务注册信息和分流参数生成路由分流规则的具体可以是，通过用户调用所述服务注册中心的接口并根据所述服务注册中心接收的服务注册信息和分流参数设置所述路由分流规则。可以理解，服务注册中心提供了服务注册信息和分流参数，界面以及接口，用户根据这些资源对一个服务可以设定路由分流规则，且设置的某一服务的路由分流规则在服务注册信息和分流参数不发生改变的基础上，也是可以更改的。
在一些实施例中，用户可以调用服务注册中心的接口并根据所述服务注册中心接收的服务注册信息和分流参数更新所述路由分流规则，该更新有两种情形，一种是启用分流的第二服务的发布信息发生了改变而更新；另一种是，第二服务的发布信息未发生改变而进行的更新；对于第一种，需要给第一微服务SDK同时发送更新后的路由分流规则以及服务注册信息；而对于第二种，仅需要给第一微服务SDK发送路由分流规则即可。
在一些实施例中，服务注册中心将所述路由分流规则发送至第一服务的第一微服务 SDK之前，还可以接收服务注册中心接收所述第一微服务SDK发送的第一请求，所述第一请求中携带有所述第二服务的服务名称；该第一请求可以是第一服务初次连接到服务注册中心时发送给服务注册中心的请求，该请求中会携带第二服务的名称，服务注册中心根据所述服务名称确定对应的路由分流规则。能够提升本申请实施例的可实现性。
在一些实施例中，服务注册中心接收所述第一微服务SDK发送的第一请求之后，除了直接发送服务名称确定对应的路由分流规则之外，还可以通过第一信息告知第一微服务SDK第二服务的分流的开启或关闭信息，该信息能够指示第一微服务SDK的转发策略。对于有些场景，第一微服务SDK上本身便存储有默认的转发策略，在第一微服务SDK知晓该第一信息后，便可以按照该路由分流负责进行转发，而非默认的转发策略。
在一些实施例中，第一信息的获取方式有多种，其中一种是第一微服务SDK主动向服务注册中心获取，此情形下，服务注册中心便会接收到第一微服务SDK发送的第二请求，所述第二请求中携带有第二服务的服务名称；还第二请求用于获取第一信息，服务注册中心可根据该第二请求确定对应所述服务名称的第二服务的分流的开启或关闭信息。
在一些实施例中，还提供另外一种第一微服务SDK获取第一信息的方式，即服务注册中心将该第一信息包含在路由分流规则中，因此，会在服务注册中心每次给第一微服务SDK 下发路由分流规则时，一并告知该第二服务的分流的启用情况，从而使得第一微服务SDK 上的第二服务的分流的启用情况为最新。
本申请实施例第四方面提供一种客户端，该客户端包括所述客户端为布置在服务调用端设备上的第一客户端，所述第一服务器组件包括：
收发模块，用于接收所述服务调用端设备通过所述服务调用端设备上运行的第一服务发送服务调用请求，所述服务调用请求用于向服务发布端设备发布的第二服务发起服务调用，所述服务调用请求中携带有所述第二服务的服务名称，所述第二服务包括至少两个服务实例节点；
处理模块，用于根据所述第二服务的路由分流规则和服务注册信息，并通过所述收发模块将所述服务调用请求发送至所述服务发布端中对应的服务实例节点，所述路由分流规则为服务器根据第二客户端上报的服务注册信息和分流参数设置的规则，所述服务注册信息为所述第二服务发布时在所述服务注册中心中注册的信息，所述服务注册信息包括所述服务实例节点的地址和所述第二服务的服务名称。
在一些实施例中，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。
在一些实施例中，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和所述服务实例节点的服务版本；所述服务注册信息包括设置分流的第二服务的服务名称和所述服务实例节点的服务版本，作为分流维度的分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型。
在一些实施例中，所述收发模块还用于：
接收服务器下发的所述路由分流规则和所述服务注册信息。
在一些实施例中，所述收发模块还用于：
向所述服务注册中心发送第一请求，以使得所述服务器确定所述第一请求中的服务名称对应的路由分流规则；并将所述路由分流规则发送至所述第一客户端，所述第一请求中携带有所述第二服务的服务名称。
在一些实施例中，所述收发模块还用于：
接收服务器下发的第一信息，所述第一信息用于将所述第二服务的分流的开启或关闭信息通知给所述第一客户端。
在一些实施例中，当所述处理模块根据所述第一信息确定针对所述第二服务的分流已开启时，所述收发模块按照所述路由分流规则将所述服务调用请求转发至所述服务发布端中对应的服务实例节点。
在一些实施例中，所述收发模块接收服务器下发的第一信息之前，所述收发模块还用于：
向所述服务器发送第二请求，所述第二请求用于向所述服务器获取所述第二服务的分流的开启或关闭信息，所述第二请求中携带有第二服务的服务名称。
在一些实施例中，所述路由分流规则或所述服务注册信息中包含所述第一信息。
在一些实施例中，当用户通过调用服务注册中心提供的接口更新配置的路由分流规则时，所述收发模块还用于：
接收所述服务器更新后的路由分流规则。
本申请实施例第五方面提供一种客户端，所述客户端为布置在服务发布端设备上的第二客户端，所述第二客户端包括：
收发模块，用于接收服务调用端设备通过所述服务调用端设备的第一客户端发送的服务调用请求，所述服务调用请求为第一服务的第一微服务SDK根据路由分流规则向第二服务发起服务调用，所述第二服务包括至少两个服务实例节点，所述服务调用请求中携带有第二服务的服务名称和目标服务实例节点的地址和所述第二服务的服务名称，所述目标服务实例节点为所述第二服务的任一服务实例节点，所述路由分流规则为服务器根据第二微服务SDK上报的服务注册信息和分流参数设置的规则，所述分流参数为所述服务发布端设备通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型；
处理模块，用于根据所述目标服务实例节点的地址对对应的服务实例节点发起调用，所述第二客户端上获取有所述路由分流规则，所述路由分流规则为服务器根据所述第二客户端上报的服务注册信息和分流参数设置的规则。
在一些实施例中，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。
在一些实施例中，所述收发模块还用于：
接收所述服务发布端设备发布的服务注册信息和分流参数，所述服务注册信息包括启用分流的所述服务发布端上的第二服务的服务名称和所述服务实例节点对应的服务版本，作为分流维度的所述分流参数为所述服务发布端设备通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型；
所述收发模块将所述服务注册信息和所述分流参数发送至所述服务器，以使得所述服务器根据所述服务注册信息和所述分流参数设置路由分流规则。
在一些实施例中，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与版本服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和所述服务实例节点的服务版本。
在一些实施例中，所述处理模块还用于：
校验所述第二服务的路由分流规则，当校验通过时，按照所述路由分流规则对对应版本的所述服务实例节点发起调用。
本申请实施例第六方面提供一种服务器，该客户端包括了用于执行第三方面或第三方面的任一种实现方式中提供的微服务框架中的服务处理方法的至少一个单元。
本申请实施例第七方面还提供一种微服务框架中的服务处理***，所述***包括第五方面或第五方面任一实施例提供一种客户端以及第六方面或第六方面的任一实施例提供一种服务器。
本申请实施例第八方面还提供一种通信装置，该通信装置可以包括终端设备或者芯片等实体，所述通信装置包括：处理器、存储器；所述存储器用于存储指令；所述处理器用于执行所述存储器中的所述指令，使得所述通信装置执行如前述第一方面或第二方面或第三方面中任一项所述的方法。
本申请实施例第九方面还提供一种芯片***，该芯片***包括处理器，用于支持网络设备实现上述方面中所涉及的功能，例如，例如发送或处理上述方法中所涉及的数据和/ 或信息。在一种可能的设计中，所述芯片***还包括存储器，所述存储器，用于保存网络设备必要的程序指令和数据。该芯片***，可以由芯片构成，也可以包括芯片和其他分立器件。
本申请的又一方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。
本申请的又一方面提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。
附图说明
图1是微服务架构的结构示意图；
图2微服务框架的请求分流示意图；
图3为本申请实施例的微服务框架中的服务处理方法架构示意图；
图4为本申请实施例的微服务框架中的服务处理方法的一个实施例图；
图5是本申请实施例的微服务框架中的服务处理方法中路由分流规则的设定过程示意图；
图6是本申请实施例的微服务框架中的服务处理方法应用于IoT的结构示意图；
图7是本申请实施例的微服务框架中的服务处理方法应用于IoT场景的一个实施例图；
图8是本申请实施例的客户端的一个实施例图；
图9是本申请实施例的客户端的一个实施例图；
图10是本申请实施例的服务器的一个实施例图；
图11是本申请实施例的微服务框架中的服务处理***的一个实施例图；
图12是本申请实施例提供的一种服务器结构示意图。
具体实施方式
本申请实施例提供了一种微服务框架中的服务处理方法及相关设备，通过设置路由分流规则，使得服务调用请求能够被合理的分流至对应的服务实例节点，服务的发起方和调用方不需要任何额外开发就可实现灰度升级，降低开发复杂度，降低开发及后续服务升级的成本。
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例进行描述。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”或“具有”及其任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
微服务架构包含的服务发布端、服务调用端和服务注册中心。下面对微服务框架进行介绍，请参阅图1，图1是微服务架构的结构示意图，其中，服务调用端和服务发布端均与服务注册中心连接，服务发布端和服务调用端上均设有微服务SDK，从图示箭头方向可以看出，在注册过程中，服务发布端的微服务SDK在服务注册中心注册服务，然后服务注册中心便可将注册的服务通知给服务调用端。其中，服务发布端用作服务提供者所属的一端，对外提供一种确定格式的访问接口(主流方式为RPC和Restful API)，每个接口可提供一种的业务功能。服务调用端用作服务调用者所属的一端，通过远程网络通信的方式调用服务的发布端提供的接口，来获取数据或实现功能；服务的注册中心是微服务框架和传统的***间通信模型的典型区别之一；其作用是存储服务发布端提供的服务相关的元数据信息，并对外提供查询能力。
需要说明的是，一个可应用于生产环境的成熟微服务框架一般还会有一些服务治理和监控运维方面的组件，但并非本申请的重点。下面以一个常见论坛***为例说明微服务框架：
论坛***都会包含用户信息管理模块和登录鉴权模块；用户信息管理模块负责存储维护用户的id、密码、联系方式、用户类型等个人身份和权限信息，而登录鉴权模块则处理用户的登录请求；一般用户在登录论坛时，会首先访问登录鉴权模块，登录鉴权模块从用户请求中提取鉴权需要的相关信息，如用户id和密码，做基本的格式校验后，会调用用户信息管理模块查询该用户的账号密码是否匹配，如果匹配再查询该用户的类型(比如是普通用户，还是版主或超级管理员)，然后登录鉴权模块根据具体的用户类型来跳转到相应的用户界面。
当然，这样的论坛***做了微服务架构改造后，用户信息管理模块将会成为服务的发布端，对外提供用户信息查询和管理服务，而这个服务的相关信息(服务名、服务接口以及提供服务的节点IP、端口等，相关概念见后续详细介绍)则会由服务的发布端发布到服务的注册中心；而登录鉴权模块一般会是调用端，从服务的注册中心中获取前述服务的相关信息，其代码逻辑中将会调用该服务来读取用户数据，完成用户登录的鉴权工作。
在此情形下，微服务框架工作流程可以包括如下步骤：
1、服务的发布者使用微服务SDK开发新服务。
2、微服务SDK自动将服务元数据信息(服务名、IP、端口等)发布到服务注册中心。
3、服务调用者向服务注册中心请求自己需要调用服务的相关信息。
4、服务调用者根据获取到的服务的元数据信息(包括服务名、参数信息、发布者IP、端口)信息向对应服务发起远程调用。
可以看出，整个过程中，微服务框架对开发屏蔽了远程网络通信的各种细节和复杂性，开发者可以像LPC一样去实现远程方法调用。微服务框架主要是为了满足微服务间通信和服务治理的需求，和传统的通信方式相比，微服务框架提供了更简单的编程接口，服务的自动注册和发现，负载均衡、失败重试，以及隔离、限流、熔断等服务治理能力。
使用微服务框架后，远程服务间的通信将变的非常简单，以Java语言为例，服务的发布端代码如下：
其中，该段代码中，定义了服务名称DeviceMgmtService，以及服务接口，该服务接口中包括设备数据，以及查询设备历史数据列表的功能，该列表中，包括应用ID，首页值以及页面大小。
此时，服务调用端想要调用服务时只需要编写如下代码：
“DeviceMgmtService deviceMgmtService＝ServiceCenter。
getService(DeviceMgmtService。class)；
//调用方式和访问本地服务接口完全一样
List<DeviceData>deviceDataList＝deviceMgmtService。
queryDeviceDataList(“iot_app_1”，1，50)；”
其中，该段代码中，定义了通过服务名称DeviceMgmtService从服务中心调用该服务的方式，调用与访问本地服务接口完全一样，并且该服务接口具体的参数为应用ID为“iot_app_1”，首页值为“1”，页面大小为“50”。
可见使用了微服务框架之后，服务间远程通信所需要处理的种种复杂问题，socket通信、IO多路复用、并发、线程管理、服务参数序列化、传输、稳定性、故障检测等无需用户考虑，转而由微服务框架来处理。
下面对本申请中的灰度升级或者灰度发布进行说明，灰度发布目前并没有明确的标准和规范，不同的组织、IT从业人员在各自的环境下可能会***滑过渡升级的一种方式。
在灰度发布***中会针对每个处于灰度发布中的请求进行分流，符合某种既定规则的一类请求访问低版本服务，另一类请求访问高版本服务；当然，实际操作中也可以分为多个服务版本，同时请求也对应的分成多类。
本申请中的灰度发布中的分流过程一般称为分流或灰度分流；灰度分流的具体实施点根据不同场景和方案可能会有不同，可以在服务发布端实施，也可以在服务的调用端实施，但是不管是哪种，灰度分流中一般都会包含如下几个关键部分：
第一个是分流维度，对于任何分流来说，都必须要有一个维度，该维度主要是用来划分请求类型的维度；比如说，在一个社交应用场景中，分流的维度一般是用户ID，在电商场景中，分流的维度则可能是订单ID；而在一些匿名应用，如搜索引擎中，分流的维度则更适合使用请求源IP地址；在很多实际场景中，分流维度也可能是由多个维度组合而成。
第二个是分流规则，在分流维度确定后，进行分流时，还需要知道在该维度上具体的规则，比如说用户ID小于10000的分流到高版本服务，或者源IP段为211.13.*.*的请求分流到高版本服务；这些规则可以由用户自行设定，也可以有一些默认设定。以上只是灰度分流最基本的原理，实际在开发中，可能会有更复杂的场景；但灰度发布中分流的核心在于请求路由的控制。
可以看出，微服务框架主要是将远程调用模拟为本地调用，将分布式***中复杂的网络间通信和路由机制封装，用户可以像调用本地服务接口一样去调用一个远程服务接口，极大地简化了网络编程的难度。在微服务框架中，如果要做分流时，可以采用图2所示，图2微服务框架的请求分流示意图，可以看出，serviceA如果要请求serviceB时，若服务B有两个版本，如serviceB_v1和serviceB_v2。
举例来说，如果按照设备ID进行分流，则可以将分流的标识字段设为device id，此时需要编写如下代码：
此段代码中，如果请求中的device id是符合deviceIdSet，则分流至serviceB_v2，若不是，则会分流至serviceB_v1。
又举例来说，若按照用户ID进行分流，则可以将分流的标识字段设为user id，此时需要编写的代码如下：
此段代码中，如果请求中的user id是符合userIdSet，则分流至serviceB_v2，若不是，则会分流至serviceB_v1。
可见，采用目前的微服务框架中设置灰度分流，对于每一个服务均需要开发人员编写代码来实现，上述部分仅为方案实现的关键部分，在实际开发中，如何从服务调用请求中获取分流维度字段，如何设置、保存、分发分流规则，如何实现尽可能通用的分流逻辑等，都需要开发者自行处理，可以看出，该开发过程是一个复杂而巨大的工作过程。
从上述分析可以总结出，目前在微服务框架中实现灰度分流存在如下问题。
1、灰度分流实现对服务开发者不透明，开发者需要自己编码处理分流逻辑。
2、灰度分流逻辑难以抽象和公用，每增加一个服务的调用者，就需要将该代码复制一遍；每调用一个新服务，同样需要实现一遍该逻辑，不同服务之间很难复用。
3、服务发布端任何分流字段和分流逻辑的变更，所有调用者都必须配合改动并重新发布；为了微服务间解耦的基本原则。
4、由于应用场景的差异，不同服务在实现微服务的灰度分流时会有各种不同的实现方案，不同方案间不具备移植性。
鉴于上述问题，本申请实施例提供了一种微服务框架中的服务处理方法，该方法采样与图1所示的架构类似，并不需要额外加入组件，该方法中通过引入分流参数Greykey，该 Greykey与分流维度对应，用来标识分流过程中，用哪些维度来做分流。下面对本申请实施例的微服务框架中的服务处理方法进行说明，请参阅图3和图4，图3为本申请实施例的微服务框架中的服务处理方法架构示意图，图4为本申请实施例的微服务框架中的服务处理方法的一个实施例图，图3中，本申请实施例方法的架构中同样包括服务注册中心、作为服务发布端的ServiceB以及服务调用端的ServiceA，该ServiceB同样包含至少两个服务版本，例如图3中，包含ServiceB_V1和ServiceB_V2两个版本，ServiceB_V1对应两个服务实例节点，ServiceB_V2对应一个服务实例节点，ServiceB_V1和ServiceB_V2提供的服务接口是一样的，但是实现逻辑不通；图3中的虚线表示服务发布及注册过程，实线则表示服务的调用过程。应用该图3所示架构的本申请实施例的方法的处理过程如图4所示，该方法包括：
401、第一服务的第一微服务SDK接收所述第一服务发送的服务调用请求。其中，所述服务调用请求用于向第二服务发起服务调用，所述服务调用请求中携带有第二服务的服务名称和服务实例节点的地址，本实施例中的第二服务包含至少两个服务实例节点，路由分流规则中可以通过将第一服务的分流参数与该服务实例节点的服务名称或者地址进行映射，例如该分流参数为使用第一服务的设备的设备ID或者使用第一服务的用户的用户ID等，从而使得在路由分流时，根据该绑定关系便可将服务调用请求发送至对应的服务实例节点。其中，该服务实例节点的地址可以是网络地址，例如IP地址等
可选的，所述第二服务包括至少两个服务版本，每个服务版本对应至少一个服务实例节点。在上述路由分流规则中，还可以将服务版本与分流参数进行映射，从而根据分流参数便可确定该服务调用请求具体会发送至哪个版本的第二服务。
需要说明的是，路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与服务实例节点的映射关系，即哪一个取值对应哪一个服务版本的哪一个服务实例节点，不同的取值可以对应到不同的服务版本的不同服务实例节点，或者相同服务版本的不同服务实例节点。而所有的取值集合则能够对应到所有服务版本的服务实例节点。
此外，路由分流规则还包括启用分流的第二服务的服务名称；所述服务注册信息包括设置分流的第二服务的服务名称和服务实例节点的服务版本，作为分流维度的分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型。
需要说明的是，本实施例的场景中第一服务初次连接到服务注册中心之前，第一服务仅知晓服务注册中心上会布置第二服务，且第一服务知晓该第二服务的名称，但是不知道改第二服务是否已在服务注册中心上注册而能够被调用。因此，第一服务在初次连接到服务注册中心时，会向服务注册中心发送一个第一请求，该请求的目的地址为该服务注册中心的地址，接着，服务注册中心在接收到该服务调用请求时，会根据该服务名称去确定对应的第二服务是否已经发布，并且针对该第二服务是由具有路由分流规则，如果有，该服务注册中心便会将路由分流规则以及第二服务在服务注册中心上注册的服务注册信息一并发送给第一微服务SDK，该服务注册信息中具有第二服务的各服务实例节点的地址。上述过程完成后，便为步骤401中向第二服务发送服务调用请求，因此，第一微服务SDK在执行该路由分流规则时，能够结合各服务实例节点的地址将服务调用请求正确发送至相应的服务实例节点。
当然，该服务注册中心下发的服务注册信息和路由分流规则并不总是直接发送给第一微服务SDK，还可以设置一个中间节点，当第一微服务SDK需要获取该服务注册信息和路由分流规则时，则直接从该节点进行获取即可。
可选的，在发送第一请求后，第一微服务SDK还可接收服务注册中心下发的第一信息，第一信息用于将所述第二服务的分流的开启或关闭信息通知给所述第一微服务SDK，在具有该第一信息后，第一微服务SDK当所述第一微服务SDK根据所述第一信息判断针对第一信息确定针对所述第二服务的分流已开启时，按照所述路由分流规则转发所述服务调用请求。此设置用在第一微服务SDK上已经设有默认的转发策略时，如果第一微服务SDK能够确认第二服务的分流已开启，则按照路由分流规则进行转发，否则，按照默认转发策略转发。
需要说明的是，该第一信息可以通过三种方式被第一微服务SDK获取；第一种，可以由服务注册中心主动给第一微服务SDK发送；第二种，可以由第一微服务SDK向服务注册中心发送第二请求，通过该第二请求使得服务注册中心发送该第一信息给第一微服务SDK。当然还有一种方式，服务中心将第一信息携带在路由分流规则或者是服务注册信息中发送给第一微服务SDK。
下面对本申请实施例的方法中的路由分流规则的设定过程进行说明，请参阅图5，图 5是本申请实施例的微服务框架中的服务处理方法中路由分流规则的设定过程示意图。该过程可包括：
501、第二服务调用第二微服务SDK发布服务，并通过注解方式设置作用在第二服务的服务接口上的分流参数。
其中，第二服务调用第二微服务SDK发布服务的过程中，会将一些服务注册信息和分流参数均发送至第二微服务SDK，例如第二服务的服务名称和服务版本，该分流参数的名称和类型。需要说明的是，此处的第二服务可以仅为一个服务，也可以是能够承载多个服务的集合，本实施例中仅以该第二服务为一个服务并且该服务为需要设置分流的服务为例进行说明；若该第二服务中包含多个的服务时，则其中某一个需要设置分流的服务的路由分流规则的设定过程与本实施例类似，此处不再赘述。
举例来说，在Java环境下，分流参数Greykey在代码中以注解的方式存在，该注解可以标注在需要分流的服务调用方法的参数字段上；下面对本申请实施例的方法中注解的方式进行说明，举例来说，以前面的发布端的代码为例，加入Greykey注解方式后，代码变为如下方式：
从上述代码可以看出，对字符串类型的appId以及字符串类型的deviceId均进行了分流参数GreyKey的注解来标识分流的维度字段信息；该两处注解对应到服务接口queryDeviceDataList以及服务名称DeviceDataService。
需要说明的是，上述实例用以GreyKey进行注解，而实际上该GreyKey仅仅是一个标识，采用其他字符串进行标识也能达到同样的效果，只要是服务注册中心、服务发布端和服务调用端中均预定义该字符串为注解分流参数的字符串即可。
502、第二微服务SDK接收第二服务发布的服务注册信息和分流参数，并将该服务注册信息和分流参数发送至服务注册中心。
其中，该服务注册信息可包括启用分流服务的服务版本以及服务名称，而该分流参数则可以包括分流参数的参数名称和参数类型；第二微服务SDK在获取该服务注册信息和分流参数后，便会将其发送至服务注册中心。
503、用户调用服务注册中心的接口并通过该服务注册信息和分流参数配置路由分流规则。
其中，在服务注册中心中针对用户提供了设置分流规则的入口，包括Portal界面和 Restful API；Portal为界面，Restful API则为功能结构接口，用户可以通过Portal界面和API将分流字段的取值范围设置到服务注册中心。用户配置的路由分流规则包括启动分流的服务名称以及分流参数的取值集合中的取值与服务实例节点的映射关系。举例来说，一个路由分流规则可以是类似如下一个多远组：
{serviceName，Set<Map<key，Value>，version>}
其中，包括服务名称serviceName，分流参数的取值集合中的取值与服务实例节点的映射关系Set<Map<key，Value>，version>，其中，该key表示分流参数的名称，例如userID或者是deviceID等，该名称仅作为分流参数的标识，Value为分流参数的类型， version即为第二服务的服务版本，通过Set<Map<key，Value>，version>即可将key 和Value的取值与每个版本进行映射，从而形成路由分流规则。
504、服务注册中心将配置完成的路由分流规则和服务注册信息发送至第一微服务 SDK。
其中，完成路由分流规则的生成后，便会将该路由分流规则连同服务注册信息一起发送给第一微服务SDK，从而使得第一微服务SDK能够通过服务注册信息获取到第二服务的服务实例节点的地址，并按照路由分流规则向对应的服务实例节点发送服务调用请求。
505、第一微服务SDK存储该路由分流规则。
需要说明的是，若需要对路由分流规则进行更改时，可以再次执行类似步骤503、步骤504和步骤505的步骤506、步骤507和步骤508，通过步骤506重新对分流规则进行设置，通过步骤507将更新后的路由分流规则发送至第一微服务SDK，最后由步骤508中，第一微服务SDK也相应的将更新后的路由分流规则予以存储。
402、第一微服务SDK通过该服务调用请求中的服务名称判断该服务是否设有路由分流规则，若是，则执行步骤403，若否，则执行转发至该服务名称对应的服务。
其中，第一微服务SDK在接收到服务调用请求后，便会根据其中的服务名称对针对该服务名称的服务是否设有路由分流规则进行判断，并执行不同的分支。该路由分流规则的格式如步骤503的说明所示，第一微服务SDK仅需要通过服务名称与该路由分流规则进行比对即可确定该服务是否具有路由分流规则。
403、第一微服务SDK根据路由分流规则和服务注册信息将所述服务调用请求发送至所述第二服务中对应的服务实例节点。
其中，第一微服务SDK获取有所述路由分流规则，所述路由分流规则为所述服务注册中心根据第二微服务SDK上报的服务注册信息和分流参数设置的规则。服务注册中心中包括服务名称、服务实例节点的服务版本以及服务实例节点的地址，因此在从路由分流规则中获取到对应的服务实例节点后，便可以根据服务注册信息向该服务实例节点发送服务调用请求，该请求的目的地址即为获取的服务实例节点的地址。
404、第一微服务SDK接收所述第二服务返回的调用返回结果。
其中，所述调用返回结果为所述第二服务的第二微服务SDK在接收到所述服务调用请求后，对所述第二服务的对应版本的服务实例节点发起调用得到的返回结果，所述第二微服务SDK上存储有所述路由分流规则。
需要说明的是，第二微服务SDK在接收到该服务调用请求后，可以先对该服务调用请求所调用的服务的路由分流规则进行校验，只有校验通过的才对该路由分流规则对应的服务实例节点发起调用，第二服务在接收到调用请求后，便会对上层业务逻辑发起调用，然后将执行结果返回给第二微服务SDK，第二微服务SDK则将接收由对应的服务实例节点返回的调用结果返回给第一微服务SDK。
405、第一微服务SDK将所述调用返回结果返回至所述第一服务。
其中，第一微服务SDK在接收到服务调用请求对应的返回结果后，便会将该调用结果返回给第一服务，以完成服务调用请求的执行过程。
需要说明的是，步骤404和步骤405在本申请实施例中为可选步骤，步骤401至步骤403 完后已经能够解决不同服务实例节点或者不同版本的不同服务实例节点的分流。
可以看出，由于通过设置分流参数，将该分流参数应用在路由分流规则中，作为服务调用端的第一服务在发起服务调用请求后，便能够由第一微服务SDK执行该服务分流规则对服务调用请求进行分流即可；提供的是一种简单、对业务非侵入方式支持微服务灰度分流的方式，服务的发布方和调用方不需要任何额外开发，此外，在度分流规则发生变化时，仅需要在服务注册中心进行控制，服务的发布方和调用方无需感知；后续升级的成本低。
下面以一个IOT场景下使用本申请实施例的微服务框架对本申请实施例的微服务框架中的服务处理方法进行说明。请参阅图6和图7，图6是本申请实施例的微服务框架中的服务处理方法应用于物联网(internet of things，IoT)场景的结构示意图，图7是本申请实施例的微服务框架中的服务处理方法应用于IoT场景的一个实施例图。图6中，包括服务注册中心，与服务注册中心连接的弹性负载均衡(Elastic Load Balance，ELB)，该ELB 中，布置有服务注册中心入口、低版本服务入口和高版本服务入口，当然，如果某一服务多于两个版本，则采用类似第一、第二和第三或者是高、中和低等方式来进行表示。图6 中还包括ServiceA和的两个版本和ServiceX的两个版本，即低版本的ServiceA_v1和 ServiceX_v1，以及高版本的ServiceA_v2和ServiceX_v2。ServiceX与ServiceA进行通讯的服务，不参与到实际的灰度分流处理；此外，还包括连接至ELR的IoTAgent，该IoTAgent 作为服务调用端，即对应图4所示实施例中的第一服务，图6中还包括与服务注册中心连接的扩展规则库，用于设置一些扩展规则。
需要说明的是，相较于图4所示实施例，本实施例中的服务注册中心除了具备管理微服务注册信息的能力外，还具备管理灰度分流信息的能力。该IoTAgent模块部署在用户的设备当中，承载一定的业务逻辑；其中内嵌微服务SDK，并通过Internet向服务发布端发起调用；ServiceA作为服务发布端，即图4所示实施例中的第二服务，因为要做灰度分流，所以此处的ServiceA存在两个版本(实际中也可以是多个版本)，ServiceA_v1和 ServiceA_v2，各代表对应版本的一组服务实例。
下面对该方法执行过程进行说明：请参阅图7，该方法可包括：
701、ServiceA调用ServiceA的微服务SDK发布服务，并通过注解方式设置作用在ServiceA的服务接口上的分流参数。
其中，该ServiceA发布服务并设置分流参数与图5所示实施例中的步骤501及步骤401的说明类似，此处不再赘述。
702、ServiceA的微服务SDK接收ServiceA发布的服务注册信息和分流参数，并将该服务注册信息和分流参数发送至服务注册中心。
其中，该服务注册信息和分流参数在获取后，便会将其发送至服务注册中心。
703、服务注册中心在ELB上注册开放该服务注册的访问地址和端口信息，并将该信息上报给微服务注册中心。
其中，此过程是为了IotAgent能够通过该ELB访问服务注册中心。
704、ServiceA_V1的实例和ServiceA_V2的实例分别在ELB上注册自己的服务地址和端口。
其中，步骤703和步骤704为服务注册中心以及服务ServiceA的各版本的服务在ELB 上注册，以便于ELB进行负载均衡管理。
705、用户调用服务注册中心的接口并通过该服务注册信息和分流参数配置路由分流规则。
其中，该步骤705设置路由分流规则的过程与图5所示步骤503以及针对步骤503的说明类似，此处不再赘述。
706、IoT Agent中的微服务SDK和服务注册中心建立通信长连接，并上报自己的设备身份标识(device id)。
707、服务注册中心根据配置的分流参数(本实施例中包括device id)的取值和服务版本的服务实例节点的映射规则，向IoT Agent的微服务SDK返回对应版本服务在ELB上的访问地址和端口的消息。
其中，返回消息格式类似：{device_id，service_name，version，<ip，port>}，包括设备ID的device_id字段，服务名称的service_name字段、服务版本的version字段，以及IP地址和端口。
708、IoT Agent的微服务SDK接收该消息，便将消息中信息保存在本地。
需要说明的是，上述步骤701至步骤708过程为与图5所示实施例类似的路由分流规则的设置过程，以下步骤709至步骤713为调用过程。此外，若服务注册中心中有按照上述步骤更新的路由分流规则时，IoT Agent中的微服务SDK通过长连接来获取最新的服务版本地址和端口并更新自己本地保存的信息。
709、IoT Agent通过IoT Agent的微服务SDK接收IoT Agent发送服务调用请求。
其中，该步骤709与图4所示实施例的步骤401及针对步骤401的说明类似，此处不再赘述。
710、IoT Agent的微服务SDK通过该服务调用请求中的服务名称判断该服务是否设有路由分流规则，若是，则执行步骤711，若否，则执行转发至该服务名称对应的服务。
其中，该步骤710与图4所示实施例的步骤402及针对步骤402的说明类似，此处不再赘述。
711、IoT Agent的微服务SDK根据路由分流规则将所述服务调用请求发送至ServiceA 的微服务SDK。
其中，该步骤711与图4所示实施例的步骤403及针对步骤403的说明类似，此处不再赘述。
712、ServiceA的微服务SDK校验该服务调用请求中的服务是否具有对应的路由分流规则，若是，执行步骤713。
713、ServiceA的微服务SDK向ServiceA发起服务调用。
714、ServiceA上对应的服务版本的服务实例节点上层业务逻辑发起调用生成调用返回结果。
715、ServiceA的微服务SDK接收所述ServiceA返回的调用返回结果。
716、ServiceA的微服务SDK将调用返回结果发送至IoT Agent的微服务SDK。
其中，该步骤716与图4所示实施例的步骤404及针对步骤404的说明类似，此处不再赘述。
需要说明的是，ServiceA的微服务SDK在接收到该服务调用请求后，可以先对该服务调用请求所调用的服务的路由分流规则进行校验，只有校验通过的才对该路由分流规则对应的服务实例节点发起调用，ServiceA在接收到调用请求后，便会对上层业务逻辑发起调用，然后将执行结果返回给ServiceA的微服务SDK，ServiceA的微服务SDK则将接收由对应的服务实例节点返回的调用结果返回给IoT Agent的微服务SDK。
717、IoT Agent的微服务SDK将所述调用返回结果返回至所述IoT Agent。
其中，该步骤717与图4所示实施例的步骤405及针对步骤405的说明类似，此处不再赘述。
上面对本申请实施例的微服务框架中的服务处理方法进行了说明，下面对本申请实施例的两个客户端分别进行说明。本申请实施例的客户端是运行于第一服务或者第二服务等所在运行框架或者运行环境中的组件或者运行库。该客户端需要配合第一服务或者第二服务运行。该客户端与服务器组成微服务框架***，对第一服务和第二服务等提供微服务框架的服务。
请参阅图8，图8是本申请实施例的客户端的一个实施例图，该客户端为布置在服务调用端设备上的第一客户端，其中，该客户端8包括：
收发模块801，用于接收所述服务调用端设备通过所述服务调用端设备上运行的第一服务发送服务调用请求，所述服务调用请求用于向服务发布端设备发布的第二服务发起服务调用，所述服务调用请求中携带有所述第二服务的服务名称，所述第二服务包括至少两个服务实例节点；
处理模块802，用于根据所述第二服务的路由分流规则和服务注册信息，并通过所述收发模块将所述服务调用请求发送至所述服务发布端中对应的服务实例节点，客户端所述路由分流规则为服务器根据第二客户端上报的服务注册信息和分流参数设置的规则，所述服务注册信息为所述第二服务发布时在所述服务注册中心中注册的信息，所述服务注册信息包括所述服务实例节点的地址和所述第二服务的服务名称。
需要说明的是，该收发模块801和处理模块802的功能具体可参见图4所示实施例的各步骤以及针对各步骤的说明，此处不再赘述；其中，该收发模块801能够实现图4所示实施例中的步骤401、步骤404和步骤405的功能；该处理模块802能够实现图4所示实施例中的步骤402的功能，收发模块801和处理模块802配合能实现图4所示实施例的步骤403的功能。
可选的，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。
需要说明的是，该第二服务包括至少两个服务版本的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和所述服务实例节点的服务版本；所述服务注册信息包括设置分流的第二服务的服务名称和所述服务实例节点的服务版本，作为分流维度的分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型。
需要说明的是，该路由分流规则、映射关系、分流参数以及服务注册信息的说明可参见图4所示实施例中针对步骤401以及图5所示实施例中针对步骤503的说明，此处不再赘述。
可选的，所述收发模块801还用于：
接收服务器下发的所述路由分流规则和所述服务注册信息。
需要说明的是，接收服务器下发的所述路由分流规则和所述服务注册信息的步骤的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述收发模块801还用于：
向所述服务注册中心发送第一请求，以使得所述服务器确定所述第一请求中的服务名称对应的路由分流规则；并将所述路由分流规则发送至所述第一客户端，所述第一请求中携带有所述第二服务的服务名称。
需要说明的是，关于所述第一请求的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述收发模块801还用于：
接收服务器下发的第一信息，所述第一信息用于将所述第二服务的分流的开启或关闭信息通知给所述第一客户端。
需要说明的是，关于所述第一信息的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，当所述处理模块802根据所述第一信息确定针对所述第二服务的分流已开启时，所述收发模块801按照所述路由分流规则将所述服务调用请求转发至所述服务发布端中对应的服务实例节点。
需要说明的是，关于所述第一信息的应用方式可参见图4所示实施例中针对步骤401 的说明，此处不再赘述。
可选的，所述收发模块801接收服务器下发的第一信息之前，所述收发模块801还用于：
向所述服务器发送第二请求，所述第二请求用于向所述服务器获取所述第二服务的分流的开启或关闭信息，所述第二请求中携带有第二服务的服务名称。
需要说明的是，关于第二请求的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述路由分流规则或所述服务注册信息中包含所述第一信息。
需要说明的是，关于第一信息的携带方式的说明可参见图4所示实施例中针对步骤401 的说明，此处不再赘述。
可选的，当用户通过调用服务注册中心提供的接口更新配置的规则时，所述收发模块 801还用于：
接收所述服务器更新后的路由分流规则。
需要说明的是，该路由分流规则的更新过程可参见图5所示实施例的步骤505的相关说明，此处不再赘述。
上面对本申请实施例的作为调用方的客户端进行了介绍，下面对本申请实施例的作为服务发布方的客户端进行介绍，请参阅图9，图9是本申请实施例的客户端的一个实施例图，该客户端为布置在服务发布端设备上的第二客户端，所述第二客户端9包括：
收发模块901，用于接收服务调用端设备通过所述服务调用端设备的第一客户端发送的服务调用请求，所述服务调用请求为第一服务的第一微服务SDK根据路由分流规则向第二服务发起服务调用，所述第二服务包括至少两个服务实例节点，所述服务调用请求中携带有第二服务的服务名称和目标服务实例节点的地址和所述第二服务的服务名称，所述目标服务实例节点为所述第二服务的任一服务实例节点，所述路由分流规则为服务器根据第二微服务SDK上报的服务注册信息和分流参数设置的规则；
处理模块902，用于根据所述目标服务实例节点的地址对对应的服务实例节点发起调用，所述第二客户端获取有所述路由分流规则，所述路由分流规则为服务器根据所述第二客户端上报的服务注册信息和分流参数设置的规则。
需要说明的是，该收发模块901和处理模块902的功能具体可参见图5所示实施例的各步骤以及针对各步骤的说明，此处不再赘述；其中，该收发模块901能够实现图5所示实施例中的步骤502的功能；该处理模块902能够配合收发模块901实现图5所示实施例中的步骤501的功能。
可选的，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。
需要说明的是，该第二服务包括至少两个服务版本的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述收发模块901还用于：
接收所述服务发布端设备发布的服务注册信息和分流参数，所述服务注册信息包括启用分流的所述服务发布端上的第二服务的服务名称和所述服务实例节点对应的服务版本，作为分流维度的所述分流参数为所述服务发布端设备通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型；
所述收发模块将所述服务注册信息和所述分流参数发送至所述服务器，以使得所述服务器根据所述服务注册信息和所述分流参数设置路由分流规则。
需要说明的是，该服务注册信息和分流参数的说明可参见图5所示实施例中针对步骤 503的说明以及图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与版本服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和所述服务实例节点的服务版本。
需要说明的是，该映射关系的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述处理模块902还用于：
校验所述第二服务的路由分流规则，当校验通过时，按照所述路由分流规则对对应版本的所述服务实例节点发起调。
需要说明的是，该校验过程，可参见图4所示实施例中针对步骤404的说明，此处不再赘述。
上面对本申请实施例的客户端进行了介绍，下面对本申请实施例的服务器进行介绍，请参阅图10，图10是本申请实施例的服务器的一个实施例图，该服务器10可包括：
收发模块1001，用于接收服务发布端设备的第二客户端发送的服务注册信息和分流参数，所述服务注册信息为所述第二客户端的第二服务发布时在所述服务器中注册的信息，所述服务注册信息包括启用分流的所述第二服务的服务实例节点的地址和所述第二服务的服务名称，作为分流维度的所述分流参数为所述服务发布端设备通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上；
处理模块1002，用于根据所述服务注册信息和分流参数生成路由分流规则；
所述收发模块1001还用于将所述路由分流规则和所述服务注册信息发送至服务调用端设备的第一客户端，以使得所述第一客户端根据所述服务实例节点的地址将所述服务调用请求发送至对应的服务实例节点。
需要说明的是，该收发模块1001和处理模块1002的功能具体可参见图5中所示实施例的各步骤以及针对各步骤的说明，此处不再赘述；其中，该收发模块1001能够实现图5所示实施例中的步骤502和步骤504的功能；该处理模块1002能够实现图5所示实施例中的步骤503的功能。
可选的，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。
需要说明的是，该第二服务包括至少两个服务版本的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与版本服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和服务版本；所述服务注册信息还包括设置分流的第二服务的服务实例节点的服务版本，所述分流参数包括所述分流参数的名称和类型。
需要说明的是，该服务注册信息和分流参数的说明可参见图5所示实施例中针对步骤 503的说明以及图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述处理模块1002具体用于：
用户调用所述服务器的接口并根据所述服务器接收的服务注册信息和分流参数设置所述路由分流规则。
需要说明的是，该服务注册信息和分流参数的说明可参见图5所示实施例中针对步骤 503的说明以及图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述处理模块1002还用于：
用户调用所述服务器的接口并根据所述服务器接收的服务注册信息和分流参数更新所述路由分流规则；
所述收发模块1001还用于将更新后的路由分流规则发送至第一客户端。
需要说明的是，该路由分流规则的更新过程的说明可参见图5所示实施例中针对步骤 503的说明，此处不再赘述。
可选的，所述收发模块1001还用于：
接收所述第一微服务SDK发送的第一请求，所述第一请求中携带有所述第二服务的服务名称；
所述处理模块1002还用于根据所述服务名称确定对应的路由分流规则。
需要说明的是，该第一请求的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
可选的，所述收发模块1001还用于：
向所述第一客户端发送第一信息，所述第一信息用于将所述第二服务的分流的开启或关闭信息通知给所述第一客户端。
需要说明的是，该第一信息的应用方式的说明可参见图4所示实施例中针对步骤401 的说明，此处不再赘述。
可选的，所述收发模块1001还用于接收所述第一客户端发送的第二请求，所述第二请求中携带有所述第二服务的服务名称；
需要说明的是，该第二请求的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
所述处理模块1002根据所述第二请求确定对应所述服务名称的第二服务的分流的开启或关闭信息。
可选的，所述路由分流规则或所述服务注册信息中包含所述第一信息。
需要说明的是，该第一信息的携带方式的说明可参见图4所示实施例中针对步骤401的说明，此处不再赘述。
上面对本申请实施例的服务器进行了介绍，下面对本申请实施例的微服务框架中的服务处理***进行介绍，请参阅图11，图11是本申请实施例的微服务框架中的服务处理***的一个实施例图，所述服务处理***11包括图9所示实施例的客户端作为第二客户端1101 和图10所示实施例的服务器作为服务注册中心的服务器1102，所述处理***11作为一个整体对图8所示实施例的客户端8(作为第一客户端1103)提供服务。
下面对本申请实施例的服务器进行介绍，图12是本申请实施例提供的一种服务器结构示意图，该服务器1200可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(central processing units，CPU)1222(例如，一个或一个以上处理器)和存储器1232，一个或一个以上存储应用程序1242或数据1244的存储介质1230(例如一个或一个以上海量存储设备)。其中，存储器1232和存储介质1230可以是短暂存储或持久存储。存储在存储介质1230的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1222可以设置为与存储介质1230通信，在服务器1200上执行存储介质1230中的一系列指令操作。
服务器1200还可以包括一个或一个以上电源1226，一个或一个以上有线或无线网络接口1250，一个或一个以上输入输出接口1258，和/或，一个或一个以上操作***1241，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。
图10所示实施例中由服务器所执行的步骤可以基于该图12所示的服务器结构。在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备 (可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的和范围。

Claims (34)

1.一种微服务框架中的服务处理方法，其特征在于，包括：
第一服务的第一微服务软件开发工具包SDK接收所述第一服务发送服务调用请求，所述服务调用请求用于向第二服务发起服务调用，所述服务调用请求中携带有第二服务的服务名称，所述第二服务包括至少两个服务实例节点；
所述第一微服务SDK根据所述第二服务的路由分流规则和服务注册信息将所述服务调用请求发送至所述第二服务中对应的服务实例节点，所述路由分流规则为所述服务注册中心根据所述第二微服务SDK上报的服务注册信息和分流参数设置的规则，所述服务注册信息为所述第二服务发布时在所述服务注册中心中注册的信息，所述服务注册信息包括所述服务实例节点的地址和所述第二服务的服务名称。
2.根据权利要求1所述的方法，其特征在于，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。
3.根据权利要求2所述的方法，其特征在于，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和服务实例节点的服务版本；所述服务注册信息还包括启用分流的第二服务的所述服务实例节点的服务版本，作为分流维度的分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型。
4.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：
所述第一微服务SDK接收服务注册中心下发的服务注册信息和路由分流规则。
5.根据权利要求4所述的方法，其特征在于，所述第一微服务SDK接收服务注册中心下发的路由分流规则和服务注册信息之前，所述方法还包括：
所述第一微服务SDK向所述服务注册中心发送第一请求，以使得所述服务注册中心确定所述第一请求中的服务名称对应的路由分流规则和服务注册信息；并将所述路由分流规则和所述服务注册信息发送至所述第一微服务SDK，所述第一请求中携带有所述第二服务的服务名称。
6.根据权利要求4所述的方法，其特征在于，在所述第一微服务SDK向所述服务注册中心发送第一请求之后，所述方法还包括：
所述第一微服务SDK接收所述服务注册中心下发的第一信息，所述第一信息用于将所述第二服务的分流的开启或关闭信息通知给所述第一微服务SDK。
7.根据权利要求6所述的方法，其特征在于，所述第一微服务SDK根据所述第二服务的路由分流规则将所述服务调用请求发送至所述第二服务中对应的服务实例节点包括：
当所述第一微服务SDK根据所述第一信息判断针对所述第二服务的分流已开启时，所述第一微服务SDK根据所述第二服务的路由分流规则将所述服务调用请求发送至所述第二服务中对应的服务实例节点。
8.根据权利要求1或2所述的方法，其特征在于，所述路由分流规则为用户通过调用服务注册中心提供的接口配置的规则。
9.根据权利要求8所述的方法，其特征在于，当用户通过调用服务注册中心提供的接口更新配置的路由分流规则时，所述方法还包括：
所述第一微服务SDK接收所述服务注册中心更新后的路由分流规则。
10.根据权利要求1至9中任一项所述的方法，其特征在于，所述方法还包括：
所述第二服务的第二微服务SDK接收所述第一微服务SDK发送的服务调用请求；
所述第二微服务SDK校验所述第二服务的路由分流规则，当校验通过时，对对应版本的所述服务实例节点发起调用，所述第二微服务SDK获取有所述路由分流规则。
11.一种微服务框架中的服务处理方法，其特征在于，包括：
第二服务的第二微服务SDK接收第一服务通过所述第一服务的第一微服务SDK发送的服务调用请求，所述服务调用请求为第一服务的第一微服务SDK根据路由分流规则向第二服务发起服务调用，所述第二服务包括至少两个服务实例节点，所述服务调用请求中携带有第二服务的服务名称和目标服务实例节点的地址，所述目标服务实例节点为所述第二服务的任一服务实例节点，所述路由分流规则为服务注册中心根据所述第二微服务SDK上报的服务注册信息和分流参数设置的规则，所述服务注册信息包括所述服务实例节点的地址和所述第二服务的服务名称，作为分流维度的所述分流参数为所述第二服务通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型；
所述第二微服务SDK根据所述目标服务实例节点的地址对对应的服务实例节点发起调用。
12.根据权利要求11所述的方法，其特征在于，所述方法还包括：
所述第二微服务SDK接收所述第二服务发布的服务注册信息和分流参数；
所述第二微服务SDK将所述服务注册信息和所述分流参数发送至所述服务注册中心。
13.根据权利要求11或12所述的方法，其特征在于，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点，所述服务注册信息还包括启用分流的所述第二服务的服务实例节点的服务版本。
14.根据权利要求13所述的方法，其特征在于，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与版本服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和服务实例节点的服务版本服务注册信息。
15.根据权利要求14所述的方法，其特征在于，所述第二服务的第二微服务SDK接收第一服务通过所述第一服务的第一微服务SDK发送的服务调用请求后，所述方法还包括：
所述第二微服务SDK校验所述第二服务的路由分流规则，当校验通过时，按照所述路由分流规则对对应版本的所述服务实例节点发起调用。
16.一种微服务框架中的服务处理方法，其特征在于，包括：
服务注册中心接收第二服务的第二微服务SDK发送的服务注册信息和分流参数，所述服务注册信息为所述第二服务发布时在所述服务注册中心中注册的信息，所述服务注册信息包括启用分流的所述第二服务的服务实例节点的地址和所述服务名称，作为分流维度的所述分流参数为所述第二服务通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上；
所述服务注册中心根据所述服务注册信息和分流参数生成路由分流规则；
所述服务注册中心将所述路由分流规则和服务注册信息发送至第一服务的第一微服务SDK，以使得所述第一微服务SDK根据所述路由分流规则和所述服务注册信息将所述服务调用请求发送至对应服务版本的服务实例节点。
17.根据权利要求16所述的方法，其特征在于，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。
18.根据权利要求17所述的方法，其特征在于，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与版本服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和服务实例节点的服务版本；所述服务注册信息还包括设置分流的第二服务的所述服务实例节点的服务版本，所述分流参数包括所述分流参数的名称和类型。
19.根据权利要求16所述的方法，其特征在于，所述服务注册中心根据所述服务注册信息和分流参数生成路由分流规则包括：
用户调用所述服务注册中心的接口并根据所述服务注册中心接收的服务注册信息和分流参数设置所述路由分流规则。
20.根据权利要求19所述的方法，其特征在于，所述方法还包括：
用户调用所述服务注册中心的接口并根据所述服务注册中心接收的服务注册信息和分流参数更新所述路由分流规则；
所述服务注册中心将更新后的路由分流规则发送至第一服务的第一微服务SDK。
21.根据权利要求16所述的方法，其特征在于，所述服务注册中心将所述路由分流规则发送至第一服务的第一微服务SDK之前，所述方法还包括：
所述服务注册中心接收所述第一微服务SDK发送的第一请求，所述第一请求中携带有所述第二服务的服务名称；
所述服务注册中心根据所述服务名称确定对应的路由分流规则。
22.根据权利要求21所述的方法，其特征在于，所述服务注册中心接收所述第一微服务SDK发送的第一请求之后，所述方法还包括：
所述服务注册中心向所述第一微服务SDK发送第一信息，所述第一信息用于将所述第二服务的分流的开启或关闭信息通知给所述第一微服务SDK。
23.一种微服务框架中的客户端，其特征在于，所述客户端为布置在服务调用端设备上的第一客户端，所述第一服务器组件包括：
收发模块，用于接收所述服务调用端设备通过所述服务调用端设备上运行的第一服务发送服务调用请求，所述服务调用请求用于向服务发布端设备发布的第二服务发起服务调用，所述服务调用请求中携带有所述第二服务的服务名称，所述第二服务包括至少两个服务实例节点；
处理模块，用于根据所述第二服务的路由分流规则和服务注册信息，并通过所述收发模块将所述服务调用请求发送至所述服务发布端中对应的服务实例节点，所述路由分流规则为服务器根据第二客户端上报的服务注册信息和分流参数设置的规则，所述服务注册信息为所述第二服务发布时在所述服务注册中心中注册的信息，所述服务注册信息包括所述服务实例节点的地址和所述第二服务的服务名称。
24.一种微服务框架中的客户端，其特征在于，所述客户端为布置在服务发布端设备上的第二客户端，所述第二客户端包括：
收发模块，用于接收服务调用端设备通过所述服务调用端设备的第一客户端发送的服务调用请求，所述服务调用请求为第一服务的第一微服务SDK根据路由分流规则向第二服务发起服务调用，所述第二服务包括至少两个服务实例节点，所述服务调用请求中携带有第二服务的服务名称和目标服务实例节点的地址和所述第二服务的服务名称，所述目标服务实例节点为所述第二服务的任一服务实例节点，所述路由分流规则为服务器根据第二微服务SDK上报的服务注册信息和分流参数设置的规则，所述分流参数为所述服务发布端设备通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上，所述分流参数包括所述分流参数的名称和类型；
处理模块，用于根据所述目标服务实例节点的地址对对应的服务实例节点发起调用，所述第二客户端上获取有所述路由分流规则，所述路由分流规则为服务器根据所述第二客户端上报的服务注册信息和分流参数设置的规则。
25.一种服务器，其特征在于，包括：
收发模块，用于接收服务发布端设备的第二客户端发送的服务注册信息和分流参数，所述服务注册信息为所述第二客户端的第二服务发布时在所述服务器中注册的信息，所述服务注册信息包括启用分流的所述第二服务的服务实例节点的地址和所述第二服务的服务名称，作为分流维度的所述分流参数为所述服务发布端设备通过注解设置的参数，所述分流参数作用在第二服务的服务接口参数上；
处理模块，用于根据所述服务注册信息和分流参数生成路由分流规则；
所述收发模块，还用于将所述路由分流规则和所述服务注册信息发送至服务调用端设备的第一客户端，以使得所述第一客户端根据所述服务实例节点的地址将所述服务调用请求发送至对应的服务实例节点。
26.根据权利要求25所述的服务器，其特征在于，所述第二服务包括至少两个服务版本，每个所述服务版本对应至少一个服务实例节点。
27.根据权利要求26所述的服务器，其特征在于，所述路由分流规则包括启用分流的第二服务的分流参数的取值集合中的取值与版本服务实例节点的映射关系，所述路由分流规则还包括启用分流的第二服务的服务名称和服务版本；所述服务注册信息还包括设置分流的第二服务的服务实例节点的服务版本，所述分流参数包括所述分流参数的名称和类型。
28.根据权利要求26所述的服务器，其特征在于，所述处理模块具体用于：
用户调用所述服务器的接口并根据所述服务器接收的服务注册信息和分流参数设置所述路由分流规则。
29.根据权利要求26至28所述的服务器，其特征在于，所述处理模块还用于：
用户调用所述服务器的接口并根据所述服务器接收的服务注册信息和分流参数更新所述路由分流规则；
所述收发模块还用于将更新后的路由分流规则发送至第一客户端。
30.根据权利要求26所述的服务器，其特征在于，所述收发模块还用于：
接收所述第一微服务SDK发送的第一请求，所述第一请求中携带有所述第二服务的服务名称；
所述处理模块还用于根据所述服务名称确定对应的路由分流规则。
31.根据权利要求26所述的服务器，其特征在于，所述收发模块还用于：
向所述第一客户端发送第一信息，所述第一信息用于将所述第二服务的分流的开启或关闭信息通知给所述第一客户端。
32.一种微服务框架中的服务处理***，其特征在于，包括服务发布端设备以及如权利要求24所述的客户端，所述服务注册布置在所述服务发布端设备上，所述服务处理***还包括如权利要求25至31中任一项所述的服务器，所述服务发布端设备通过所述客户端与所述服务器通讯。
33.一种计算机可读存储介质，其特征在于，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1-22中任一项所述的微服务框架中的服务处理方法。
34.一种包含指令的计算机程序产品，其特征在于，当其在计算机上运行时，使得计算机执行如权利要求1-22中任一项所述的微服务框架中的服务处理方法。
CN201711485852.4A 2017-12-30 2017-12-30 一种微服务框架中的服务处理方法及相关设备 Active CN109995713B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711485852.4A CN109995713B (zh) 2017-12-30 2017-12-30 一种微服务框架中的服务处理方法及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711485852.4A CN109995713B (zh) 2017-12-30 2017-12-30 一种微服务框架中的服务处理方法及相关设备

Publications (2)

Publication Number Publication Date
CN109995713A true CN109995713A (zh) 2019-07-09
CN109995713B CN109995713B (zh) 2020-11-27

Family

ID=67110425

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711485852.4A Active CN109995713B (zh) 2017-12-30 2017-12-30 一种微服务框架中的服务处理方法及相关设备

Country Status (1)

Country Link
CN (1) CN109995713B (zh)

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110381058A (zh) * 2019-07-18 2019-10-25 深圳前海微众银行股份有限公司 基于全双工通信协议WebSocket的请求传输方法及装置
CN110716811A (zh) * 2019-08-14 2020-01-21 中国平安财产保险股份有限公司 数据库的调用方法、装置和计算机设备
CN110780979A (zh) * 2019-10-28 2020-02-11 北京海益同展信息科技有限公司 微服务框架下配置的控制方法及装置、介质和电子设备
CN110837424A (zh) * 2019-10-15 2020-02-25 东软集团股份有限公司 服务实例确定方法、装置、存储介质及电子设备
CN110928709A (zh) * 2019-11-21 2020-03-27 中国民航信息网络股份有限公司 一种微服务框架下的服务调用方法、装置及服务器
CN111159133A (zh) * 2019-12-16 2020-05-15 北京航天智造科技发展有限公司 一种基于微服务的分布式论坛***
CN111158654A (zh) * 2019-12-31 2020-05-15 北京每日优鲜电子商务有限公司 算法调用方法、装置、服务器及存储介质
CN111176761A (zh) * 2019-12-23 2020-05-19 中国联合网络通信集团有限公司 微服务调用方法和装置
CN111181858A (zh) * 2019-12-24 2020-05-19 浙江大华技术股份有限公司 灰度发布的方法、***、计算机设备和存储介质
CN111290867A (zh) * 2020-02-27 2020-06-16 北京三快在线科技有限公司 流量调度方法、业务服务器、存储介质及流量调度***
CN111510480A (zh) * 2020-04-08 2020-08-07 北京百度网讯科技有限公司 一种请求发送方法、装置以及第一服务器
CN111600930A (zh) * 2020-04-09 2020-08-28 网宿科技股份有限公司 微服务请求的流量管理方法、装置、服务器及存储介质
CN111711569A (zh) * 2020-06-16 2020-09-25 普元信息技术股份有限公司 企业分布式应用中实现请求动态路由的***及其方法
CN111786998A (zh) * 2020-06-30 2020-10-16 成都新潮传媒集团有限公司 基于微服务调用的权限管理方法、装置及存储介质
CN111866122A (zh) * 2020-07-18 2020-10-30 昆明理工大学 一种微服务处理方法、装置、客户终端
CN111970198A (zh) * 2020-08-13 2020-11-20 北京金山云网络技术有限公司 一种服务路由方法、装置、电子设备及介质
CN112118184A (zh) * 2020-08-06 2020-12-22 北京健康之家科技有限公司 网关自动路由方法及装置、存储介质、计算机设备
CN112181438A (zh) * 2020-09-18 2021-01-05 杭州卓健信息科技有限公司 一种2b的saas平台中的微服务独立部署***和方法
CN112202929A (zh) * 2020-12-01 2021-01-08 湖南新云网科技有限公司 一种微服务架构中的服务访问方法、装置、设备
CN112256351A (zh) * 2020-10-26 2021-01-22 卫宁健康科技集团股份有限公司 Feign组件的实现方法、微服务调用方法及装置
WO2021013023A1 (zh) * 2019-07-19 2021-01-28 深圳前海微众银行股份有限公司 一种微服务间通信方法、计算机设备及存储介质
WO2021017907A1 (zh) * 2019-07-29 2021-02-04 ***股份有限公司 一种优化的微服务间通信的方法及装置
CN112350873A (zh) * 2020-11-25 2021-02-09 中国工商银行股份有限公司 应用服务信息处理方法、应用服务调用方法、装置及***
CN112491942A (zh) * 2019-09-12 2021-03-12 曙光信息产业(北京)有限公司 集群服务访问方法、装置和计算机设备
WO2021051623A1 (zh) * 2019-09-18 2021-03-25 平安科技（深圳）有限公司 基于微服务框架的灰度发布方法、装置和计算机设备
CN113204444A (zh) * 2021-07-06 2021-08-03 北京全路通信信号研究设计院集团有限公司 一种基于全局的现车管理***及其方法
CN113495747A (zh) * 2020-04-07 2021-10-12 北京京东振世信息技术有限公司 一种灰度发布方法和装置
CN113672371A (zh) * 2021-08-24 2021-11-19 广州华多网络科技有限公司 任务引擎执行方法及其装置、设备与介质
CN113783914A (zh) * 2020-09-01 2021-12-10 北京沃东天骏信息技术有限公司 数据处理方法、装置及设备
CN113918193A (zh) * 2021-10-29 2022-01-11 平安普惠企业管理有限公司 适用于微服务的灰度调用方法、装置、设备及存储介质
CN114040024A (zh) * 2020-07-20 2022-02-11 深圳兆日科技股份有限公司 基于网关的微服务灰度发布方法、装置、设备及存储介质
CN114390109A (zh) * 2021-12-13 2022-04-22 ***股份有限公司 一种业务处理方法、微服务网关及数据中心***
CN114531366A (zh) * 2022-02-21 2022-05-24 中国工商银行股份有限公司 一种服务治理处理方法及装置
CN114827277A (zh) * 2022-05-06 2022-07-29 北京思特奇信息技术股份有限公司 基于多机房容器部署的微服务***及方法
CN114866612A (zh) * 2022-03-30 2022-08-05 中国电力科学研究院有限公司 一种电力微服务卸载方法及装置
CN116074117A (zh) * 2023-03-07 2023-05-05 徐工汉云技术股份有限公司 基于企业微服务架构的微服务访问控制方法和装置
CN118101773A (zh) * 2024-04-29 2024-05-28 华能信息技术有限公司 一种基于api网关的多服务共享方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105450757A (zh) * 2015-12-02 2016-03-30 联动优势电子商务有限公司 一种服务管理方法及***
US20160112475A1 (en) * 2014-10-21 2016-04-21 Twilio, Inc. System and method for providing a micro-services communication platform
CN106257894A (zh) * 2016-08-29 2016-12-28 北京海誉动想科技股份有限公司 基于微服务的灰度发布方法
CN106301947A (zh) * 2016-08-31 2017-01-04 广州唯品会信息科技有限公司 业务信息处理***和方法
CN106789250A (zh) * 2016-12-22 2017-05-31 焦点科技股份有限公司 一种基于容器的服务多版本共存实现方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160112475A1 (en) * 2014-10-21 2016-04-21 Twilio, Inc. System and method for providing a micro-services communication platform
CN105450757A (zh) * 2015-12-02 2016-03-30 联动优势电子商务有限公司 一种服务管理方法及***
CN106257894A (zh) * 2016-08-29 2016-12-28 北京海誉动想科技股份有限公司 基于微服务的灰度发布方法
CN106301947A (zh) * 2016-08-31 2017-01-04 广州唯品会信息科技有限公司 业务信息处理***和方法
CN106789250A (zh) * 2016-12-22 2017-05-31 焦点科技股份有限公司 一种基于容器的服务多版本共存实现方法

Cited By (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110381058A (zh) * 2019-07-18 2019-10-25 深圳前海微众银行股份有限公司 基于全双工通信协议WebSocket的请求传输方法及装置
WO2021013023A1 (zh) * 2019-07-19 2021-01-28 深圳前海微众银行股份有限公司 一种微服务间通信方法、计算机设备及存储介质
US11683316B2 (en) 2019-07-29 2023-06-20 China Unionpay Co., Ltd. Method and device for communication between microservices
WO2021017907A1 (zh) * 2019-07-29 2021-02-04 ***股份有限公司 一种优化的微服务间通信的方法及装置
CN110716811A (zh) * 2019-08-14 2020-01-21 中国平安财产保险股份有限公司 数据库的调用方法、装置和计算机设备
CN112491942B (zh) * 2019-09-12 2024-04-16 曙光信息产业(北京)有限公司 集群服务访问方法、装置和计算机设备
CN112491942A (zh) * 2019-09-12 2021-03-12 曙光信息产业(北京)有限公司 集群服务访问方法、装置和计算机设备
WO2021051623A1 (zh) * 2019-09-18 2021-03-25 平安科技（深圳）有限公司 基于微服务框架的灰度发布方法、装置和计算机设备
CN110837424A (zh) * 2019-10-15 2020-02-25 东软集团股份有限公司 服务实例确定方法、装置、存储介质及电子设备
CN110780979A (zh) * 2019-10-28 2020-02-11 北京海益同展信息科技有限公司 微服务框架下配置的控制方法及装置、介质和电子设备
CN110928709A (zh) * 2019-11-21 2020-03-27 中国民航信息网络股份有限公司 一种微服务框架下的服务调用方法、装置及服务器
CN111159133A (zh) * 2019-12-16 2020-05-15 北京航天智造科技发展有限公司 一种基于微服务的分布式论坛***
CN111159133B (zh) * 2019-12-16 2022-05-17 北京航天智造科技发展有限公司 一种基于微服务的分布式论坛***
CN111176761A (zh) * 2019-12-23 2020-05-19 中国联合网络通信集团有限公司 微服务调用方法和装置
CN111181858A (zh) * 2019-12-24 2020-05-19 浙江大华技术股份有限公司 灰度发布的方法、***、计算机设备和存储介质
CN111158654A (zh) * 2019-12-31 2020-05-15 北京每日优鲜电子商务有限公司 算法调用方法、装置、服务器及存储介质
CN111290867A (zh) * 2020-02-27 2020-06-16 北京三快在线科技有限公司 流量调度方法、业务服务器、存储介质及流量调度***
CN113495747A (zh) * 2020-04-07 2021-10-12 北京京东振世信息技术有限公司 一种灰度发布方法和装置
CN113495747B (zh) * 2020-04-07 2023-09-26 北京京东振世信息技术有限公司 一种灰度发布方法和装置
CN111510480A (zh) * 2020-04-08 2020-08-07 北京百度网讯科技有限公司 一种请求发送方法、装置以及第一服务器
CN111600930A (zh) * 2020-04-09 2020-08-28 网宿科技股份有限公司 微服务请求的流量管理方法、装置、服务器及存储介质
CN111600930B (zh) * 2020-04-09 2022-12-09 网宿科技股份有限公司 微服务请求的流量管理方法、装置、服务器及存储介质
CN111711569A (zh) * 2020-06-16 2020-09-25 普元信息技术股份有限公司 企业分布式应用中实现请求动态路由的***及其方法
CN111786998A (zh) * 2020-06-30 2020-10-16 成都新潮传媒集团有限公司 基于微服务调用的权限管理方法、装置及存储介质
CN111866122A (zh) * 2020-07-18 2020-10-30 昆明理工大学 一种微服务处理方法、装置、客户终端
CN114040024A (zh) * 2020-07-20 2022-02-11 深圳兆日科技股份有限公司 基于网关的微服务灰度发布方法、装置、设备及存储介质
CN112118184A (zh) * 2020-08-06 2020-12-22 北京健康之家科技有限公司 网关自动路由方法及装置、存储介质、计算机设备
CN112118184B (zh) * 2020-08-06 2022-06-03 北京健康之家科技有限公司 网关自动路由方法及装置、存储介质、计算机设备
CN111970198A (zh) * 2020-08-13 2020-11-20 北京金山云网络技术有限公司 一种服务路由方法、装置、电子设备及介质
CN113783914A (zh) * 2020-09-01 2021-12-10 北京沃东天骏信息技术有限公司 数据处理方法、装置及设备
CN112181438A (zh) * 2020-09-18 2021-01-05 杭州卓健信息科技有限公司 一种2b的saas平台中的微服务独立部署***和方法
CN112256351B (zh) * 2020-10-26 2023-11-17 卫宁健康科技集团股份有限公司 Feign组件的实现方法、微服务调用方法及装置
CN112256351A (zh) * 2020-10-26 2021-01-22 卫宁健康科技集团股份有限公司 Feign组件的实现方法、微服务调用方法及装置
CN112350873B (zh) * 2020-11-25 2022-10-25 中国工商银行股份有限公司 应用服务信息处理方法、应用服务调用方法、装置及***
CN112350873A (zh) * 2020-11-25 2021-02-09 中国工商银行股份有限公司 应用服务信息处理方法、应用服务调用方法、装置及***
CN112202929A (zh) * 2020-12-01 2021-01-08 湖南新云网科技有限公司 一种微服务架构中的服务访问方法、装置、设备
CN112202929B (zh) * 2020-12-01 2021-03-26 湖南新云网科技有限公司 一种微服务架构中的服务访问方法、装置、设备
CN113204444A (zh) * 2021-07-06 2021-08-03 北京全路通信信号研究设计院集团有限公司 一种基于全局的现车管理***及其方法
WO2023280140A1 (zh) * 2021-07-06 2023-01-12 北京全路通信信号研究设计院集团有限公司 一种基于全局的现车管理***及其方法
CN113672371B (zh) * 2021-08-24 2024-05-17 广州华多网络科技有限公司 任务引擎执行方法及其装置、设备与介质
CN113672371A (zh) * 2021-08-24 2021-11-19 广州华多网络科技有限公司 任务引擎执行方法及其装置、设备与介质
CN113918193A (zh) * 2021-10-29 2022-01-11 平安普惠企业管理有限公司 适用于微服务的灰度调用方法、装置、设备及存储介质
CN114390109B (zh) * 2021-12-13 2024-02-20 ***股份有限公司 一种业务处理方法、微服务网关及数据中心***
CN114390109A (zh) * 2021-12-13 2022-04-22 ***股份有限公司 一种业务处理方法、微服务网关及数据中心***
CN114531366B (zh) * 2022-02-21 2024-01-30 中国工商银行股份有限公司 一种服务治理处理方法及装置
CN114531366A (zh) * 2022-02-21 2022-05-24 中国工商银行股份有限公司 一种服务治理处理方法及装置
CN114866612A (zh) * 2022-03-30 2022-08-05 中国电力科学研究院有限公司 一种电力微服务卸载方法及装置
CN114866612B (zh) * 2022-03-30 2024-05-31 中国电力科学研究院有限公司 一种电力微服务卸载方法及装置
CN114827277B (zh) * 2022-05-06 2023-12-01 北京思特奇信息技术股份有限公司 基于多机房容器部署的微服务***及方法
CN114827277A (zh) * 2022-05-06 2022-07-29 北京思特奇信息技术股份有限公司 基于多机房容器部署的微服务***及方法
CN116074117B (zh) * 2023-03-07 2023-06-02 徐工汉云技术股份有限公司 基于企业微服务架构的微服务访问控制方法和装置
CN116074117A (zh) * 2023-03-07 2023-05-05 徐工汉云技术股份有限公司 基于企业微服务架构的微服务访问控制方法和装置
CN118101773B (zh) * 2024-04-29 2024-07-12 华能信息技术有限公司 一种基于api网关的多服务共享方法
CN118101773A (zh) * 2024-04-29 2024-05-28 华能信息技术有限公司 一种基于api网关的多服务共享方法

Also Published As

Publication number Publication date
CN109995713B (zh) 2020-11-27

Similar Documents

Publication Publication Date Title
CN109995713A (zh) 一种微服务框架中的服务处理方法及相关设备
US11044305B2 (en) Cloud federation as a service
US10361843B1 (en) Native blockchain platform for improving workload mobility in telecommunication networks
US20190238528A1 (en) Methods, Systems, Devices, and Products for Web Services
JP2022530580A (ja) エッジ・コンピューティング配備におけるマルチ・エンティティ・リソース、セキュリティ、及びサービス管理
CN109194760A (zh) 业务处理方法、网络***及服务器
CN114025021B (zh) 一种跨Kubernetes集群的通信方法、***、介质和电子设备
CN109597643A (zh) 应用灰度发布方法、装置、电子设备及存储介质
CN110458572B (zh) 用户风险的确定方法和目标风险识别模型的建立方法
US11245577B2 (en) Template-based onboarding of internet-connectible devices
WO2020134329A1 (zh) 一种网关业务实现方法、控制装置和网关
US11238448B1 (en) Efficient network service provisioning
WO2011098168A1 (en) Data management at a directory database
CN106375442A (zh) 一种跨平台管理设备信息的方法和装置
CN110121194A (zh) 信息传输方法及装置、计算机存储介质
CN109246078A (zh) 一种数据交互方法及服务器
US11689636B2 (en) Delegating network data exchange
US20220158890A1 (en) Method and system for root cause analysis across multiple network systems
US20220138220A1 (en) Dedicated replication channels for replicating records between regions
CN107018140B (zh) 一种权限控制方法和***
CN108494748B (zh) 一种通信方法、装置及存储介质
CN116566656A (zh) 资源访问方法、装置、设备及计算机存储介质
CN110391996A (zh) 一种区块链接入装置、***、方法及计算机设备
Femminella et al. An edge abstraction layer enabling federated and hierarchical orches‑tration of CCAM services in 5G and beyond net‑works
CN104144144B (zh) 一种基于roso模型的异构信息***集成方法

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
TR01 Transfer of patent right

Effective date of registration: 20220210

Address after: 550025 Huawei cloud data center, jiaoxinggong Road, Qianzhong Avenue, Gui'an New District, Guiyang City, Guizhou Province

Patentee after: Huawei Cloud Computing Technologies Co.,Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd.

TR01 Transfer of patent right