一种服务管理方法和系统与流程

本发明涉及互联网领域，尤其涉及一种服务管理方法和系统。

背景技术：

目前，常用的分布式架构下的服务管理方案主要包括如下两种：

1、如图1所示，前端直接与后台系统的多个服务提供方交互，例如，前端要展示产品详情信息页，产品详情信息包括产品基本信息和产品历史订单信息等，而产品基本信息来自产品管理系统，产品历史订单信息来自场外柜台交易系统，因此前端客户端需要同时与多个业务系统后台进行交互。

2、如图2所示，明确区分服务提供方和服务消费方两个角色，在这种架构中后台系统按照业务横向切分，每个服务提供方节点只负责特定业务场景的功能；服务提供方对外发布所提供的服务，并由服务消费方订阅及消费；每个服务消费方节点消费其中的部分服务来完成业务处理，所有服务消费方节点上不会存在有全量的服务引用。

但是，这两种服务管理方案都存在一定的缺陷：

第一种方案的结构相对简单，但由于服务提供方提供的服务都是细粒度的服务，例如查询一个产品详情信息需要发起2次或者更多的请求来完成，交互次数多，网络开销大，同时导致客户端代码非常复杂；如果服务提供方的协议不统一时，前端需要对每一种服务提供方的协议进行支持，这对前端来说是一种灾难；同时，这种方案也给后期的业务重构带来困难，当需要把两个服务合并或者一个服务拆分时，前端的重构很难实施。

第二种方案虽然提供了服务发布/订阅的服务治理措施，但其对服务的引用仍然是分散在不同的服务消费方节点上，当需要统计服务的调用信息或者请求数据时，无法获取到全局的数据；同时，这种方案在服务消费方调用服务时需要显式地引用某个服务，缺乏服务调用的灵活性。

技术实现要素：

本发明的目的在于提供一种服务管理方法和系统，旨在解决现有技术中分布式架构下的服务没有实现集中化管理，灵活性不高的问题。

本发明的第一方面，提供了一种服务管理系统，包括：

接入层，用于提供统一接入总线，将客户端的服务请求发送到服务中心；

所述服务中心，用于提供服务集中化处理和监控，对接收到的所述服务请求进行集中化处理后，向后台节点发送服务调用请求，并对接收到的所述后台节点发送的服务应答进行封装后返回给所述客户端；

所述后台节点，用于对接收到的所述服务调用请求进行处理和应答。

本发明的第二方面，提供了一种服务管理方法，包括：

通过统一接入总线接收客户端发送的服务请求；

对接收到的所述服务请求进行统一的服务治理过程，并根据所述服务治理的结果向所述后台节点发送服务调用请求，所述服务治理过程包括对所述服务请求进行服务检索、集群选择、负载均衡和协议调用的过程；

接收所述后台节点发送的服务应答，并对所述服务应答进行封装后返回给所述客户端。

本发明与现有技术相比存在的有益效果是：通过服务中心实现服务集中化处理和监控，对外提供统一的接口，使所有的服务请求统一通过服务中心的集中化处理后，与后台节点的服务提供方进行交互，方便了业务的复用和整合，提升了分布式架构的灵活性。

附图说明

图1是现有技术中前端直接与后台系统的多个服务提供方进行服务交互处理的结构示意图；

图2是现有技术中采用服务提供方和服务消费方进行服务交互处理的结构示意图；

图3是本发明实施例一提供的一种服务管理系统的结构示意图；

图4是本发明实施例二提供的一种服务管理系统的结构示意图；

图5是本发明实施例三提供的一种服务管理方法的流程图；

图6是本发明实施例四提供的一种服务管理方法的流程图；

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

以下结合具体附图对本发明的实现进行详细的描述。

实施例一：

图3是本发明实施例一提供的一种服务管理系统的结构示意图，为了便于说明，仅示出了与本发明实施例相关的部分。图3示例的服务管理系统包括接入层11、服务中心12和后台节点13，详细功能说明如下：

1)接入层11，用于提供统一接入总线，将客户端的服务请求发送到服务中心12。

具体地，客户端的服务请求统一经过接入层11被发送到服务中心12。接入层11提供统一的接入总线，通过硬件负载均衡(F5)将客户端的服务请求发送到服务中心12。

2)服务中心12，用于提供服务集中化处理和监控，对接收到的服务请求进行集中化处理后，向后台节点13发送服务调用请求，并对接收到的后台节点13发送的服务应答进行封装后返回给客户端。

具体地，服务中心12连接接入层11和后台节点13，使所有需要进入中台系统或者后台系统的服务请求全部通过服务中心进行集中化处理，对接收到的服务请求进行集中化处理后，向提供服务应答的后台节点13发送服务调用请求，并将并接收到的后台节点13返回的服务应答进行封装后发送给客户端。

服务中心12基于访问压力实时管理集群容量，提高集群利用率，保证服务的高并发需求，并采用多节点部署保证服务高可用性。服务中心12在进行服务集中化处理的同时，对所有服务调用请求和服务应答进行统一监控，管理整个集群的服务接口，统计服务调用请求，记录并统计服务调用量、响应时间、请求链路和业务日志等，作为容量规划的参考指标。

服务中心12通过传输控制协议(Transmission Control Protocol，TCP)与后台节点13的服务提供方进行交互，优选地，TCP协议采用Netty开源框架实现，Netty是由JBOSS提供的一个java开源框架，Netty提供异步的和事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。

3)后台节点13，用于对接收到的服务调用请求进行处理和应答。

服务中心12向提供服务应答的后台节点13发送服务调用请求，后台节点13对接收到的服务调用请求进行处理，并向服务中心12返回服务应答。

具体地，后台节点13可以是一个也可以是多个，每个后台节点13可以提供多个服务提供方的服务接口，服务中心12在对接收到的服务请求进行集中化处理后，对处理后得到的需要调用的服务，向这些需要调用的服务的服务提供方所在的后台节点13发送服务调用请求，后台节点13将接收到的服务调用请求发送到具体的服务提供方进行处理，并将处理后的服务应答返回给服务中心12。

本实施例中，通过服务中心实现服务集中化处理和监控，对外提供统一的接口，使所有的服务请求统一通过服务中心的集中化处理后，与后台节点的服务提供方进行交互，方便了业务的复用和整合，提升了分布式架构的灵活性。

实施例二：

图4是本发明实施例二提供的一种服务管理系统的结构示意图，为了便于说明，仅示出了与本发明实施例相关的部分。图4示例的服务管理系统包括接入层21、服务中心22和后台节点23，详细功能说明如下：

接入层21，用于提供统一接入总线，将客户端的服务请求发送到服务中心12；

服务中心22，用于提供服务集中化处理和监控，对接收到的服务请求进行集中化处理后，向后台节点23发送服务调用请求，并对接收到的后台节点23发送的服务应答进行封装后返回给客户端；

后台节点23，用于对接收到的服务调用请求进行处理和应答。

进一步地，服务中心22包括协调模块221、服务治理模块222和服务监控模块223。各功能模块详细说明如下：

1)协调模块221，用于提供服务发布订阅机制。

具体地，发布订阅(Pub/Sub)是一种消息通信模式，其主要目的是解耦消息发布者和消息订阅者之间的耦合。协调模块221负责提供针对服务的发布订阅机制，优选地，协调模块221通过分布式应用程序协调服务ZooKeeper负责服务的注册和发布，提供服务动态注册和自动发现功能。

ZooKeeper是一个分布式的开放源码的分布式应用程序协调服务，为分布式应用提供一致性服务。在服务中心22和后台节点23中分别设置Zookeeper客户端，其中，服务中心22中的Zookeeper客户端用于服务发现，后台节点23中的Zookeeper客户端用于服务注册。

2)服务治理模块222，用于对接收到的服务请求进行统一的服务治理过程，根据服务治理的结果向后台节点23发送服务调用请求，并对接收到的后台节点23发送的服务应答进行封装后返回给客户端，其中，服务治理过程包括对服务请求进行服务检索、集群选择、负载均衡和协议调用的过程。

进一步地，服务治理模块222包括脚本过滤子模块2221、集群路由子模块2222、负载均衡子模块2223和协议通讯子模块2224。各功能模块详细说明如下：

21)脚本过滤子模块2221，用于根据预设的服务编排条件，对接收到的服务请求进行服务编排条件的匹配，并根据匹配的结果获取需要执行的服务。

具体地，脚本过滤子模块2221完成对服务请求的服务检索，脚本过滤子模块2221可以采用脚本过滤器进行服务编排条件的匹配，脚本过滤器以脚本语言编写，根据脚本语言的动态性可以在运行时定义各种规则，默认规则可以是根据请求串检索到需要执行的服务，还可以动态编排规则进行对应的逻辑处理。

22)集群路由子模块2222，用于查找需要执行的服务对应的服务注册信息，根据服务注册信息对需要执行的服务进行集群路由选择，其中，服务注册信息通过协调模块221获取。

具体地，集群路由子模块2222完成对服务请求的集群选择，集群路由子模块2222根据服务注册信息完成对集群路由的选择，服务注册信息为预先通过协调模块221进行服务注册的相关内容。

23)负载均衡子模块2223，用于对需要执行的服务进行负载均衡处理。

具体地，负载均衡子模块2223完成对服务请求的负载均衡，负载均衡子模块2223提供随机调用、轮询调用、最小活跃数调用以及一致性哈希(Hash)调用等多种负载均衡算法，完成对服务的负载均衡处理。

24)协议通讯子模块2224，用于查找需要执行的服务对应的服务注册信息，根据服务注册信息对需要执行的服务进行通讯协议的调用，向后台节点23发送服务调用请求。

具体地，协议通讯子模块2224完成对服务请求的协议调用，协议通讯子模块2224根据服务注册信息选择通讯协议并完成通讯协议的调用，向需要执行的服务对应的服务提供方所在的后台节点23发送服务调用请求。

3)服务监控模块223，用于对服务调用请求和服务应答进行集中监控和管理。

具体地，服务监控模块223管理整个集群的服务接口，统计服务调用请求，记录并统计服务调用量、响应时间、请求链路和业务日志等，作为容量规划的参考指标。

进一步地，服务监控模块223包括：

运维子模块2231，用于提供统一的服务运维监控功能；

统计分析子模块2232，用于提供统一的业务数据的统计和分析功能。

服务监控模块223通过运维子模块2231实现了方便统一的服务运维监控，通过统计分析子模块2232实现了包括用户行为分析和差异化服务等有效的业务数据统计和分析。

本实施例中，服务中心通过协调模块提供服务发布订阅机制，通过服务治理模块实对服务请求包括服务检索、集群选择、负载均衡和协议调用的统一服务治理过程，并向服务请求对应的服务提供方所在的后台节点发送服务调用请求，同时接收该后台节点返回的服务应答，并对服务应答进行封装后发送给客户端，从而实现了服务集中化管理，封装应用内部结构，对外提供统一的接口，所有的服务请求统一通过服务中心进行集中化处理，根据服务编排规则调用各个业务系统的服务接口，与后台节点的服务提供方进行交互，使得客户端只需一次请求便可以完成所有分布式业务操作，方便了业务的复用和整合，提升了分布式架构的灵活性。同时，通过服务中心对全部服务调用请求和服务应答进行集中监控和管理，提供了统一的服务运维监控，以及业务数据的统计和分析功能。

实施例三：

图5是本发明实施例三提供的一种服务管理方法的流程图，图5示例的服务管理方法的执行主体是服务中心。具体包括步骤S301至S303，详述如下：

S301、通过统一接入总线接收客户端发送的服务请求。

具体地，客户端的服务请求全部统一经过接入总线被发送到服务中心。

S302、对接收到的服务请求进行统一的服务治理过程，并根据服务治理的结果向后台节点发送服务调用请求，其中，服务治理过程包括对服务请求进行服务检索、集群选择、负载均衡和协议调用的过程。

具体地，服务中心对接收到的服务请求进行集中化处理，该集中化处理包括服务检索、集群选择、负载均衡和协议调用在内的统一服务治理过程，并根据服务治理的结果向应答该服务请求的服务提供方所在的后台节点发送服务调用请求。

S303、接收后台节点发送的服务应答，并对服务应答进行封装后返回给客户端。

具体地，后台节点对接收到的服务调用请求进行处理后，向服务中心发送服务应答，服务中心对服务应答进行封装后返回给客户端。

本实施例中，服务中心对接收到的服务请求进行包括服务检索、集群选择、负载均衡和协议调用的统一服务治理过程，根据服务治理的结果向后台节点发送服务调用请求，并对接收到的服务应答进行封装后返回给客户端，从而实现了服务集中化管理，封装应用内部结构，对外提供统一的接口，所有的服务请求统一通过服务中心进行集中化处理，根据服务编排规则调用各个业务系统的服务接口，与后台节点的服务提供方进行交互，使得客户端只需一次请求便可以完成所有分布式业务操作，方便了业务的复用和整合，提升了分布式架构的灵活性。

实施例四：

图6是本发明实施例四提供的一种服务管理方法的流程图，图6示例的服务管理方法的执行主体是服务中心。具体包括步骤S401至S407，详述如下：

S401、通过统一接入总线接收客户端发送的服务请求。

具体地，客户端的服务请求全部统一经过接入总线被发送到服务中心。

S402、根据预设的服务编排条件，对接收到的服务请求进行服务编排条件的匹配，并根据匹配的结果获取需要执行的服务。

具体地，通过脚本过滤器完成对服务请求的服务检索，采用脚本过滤器对接收到的服务请求进行服务编排条件的匹配，脚本过滤器以脚本语言编写，根据脚本语言的动态性可以在运行时定义各种规则，默认规则可以是根据请求串检索到需要执行的服务，还可以动态编排规则进行对应的逻辑处理。

S403、查找需要执行的服务对应的预设的服务注册信息，根据服务注册信息对需要执行的服务进行集群路由选择。

具体地，根据服务注册信息选择集群路由，完成对服务请求的集群选择。服务注册信息通过服务发布订阅机制注册和发布。

S404、对需要执行的服务进行负载均衡处理。

具体地，通过随机调用、轮询调用、最小活跃数调用以及一致性哈希(Hash)调用等多种负载均衡算法，完成对服务请求的负载均衡。

S405、查找需要执行的服务对应的服务注册信息，根据服务注册信息对需要执行的服务进行通讯协议的调用，向后台节点发送服务调用请求。

具体地，根据服务注册信息选择通讯协议，完成对服务请求的协议调用，向需要执行的服务对应的服务提供方所在的后台节点发送服务调用请求。

S406、接收后台节点发送的服务应答，并对服务应答进行封装后返回给客户端。

具体地，后台节点对接收到的服务调用请求进行处理后，向服务中心发送服务应答，服务中心对服务应答进行封装后返回给客户端

S407、对服务调用请求和服务应答进行集中监控和管理。

具体地，集中监控和管理包括统一的服务运维监控和对业务数据进行统计和分析，实现对整个集群的服务接口的管理，统计服务调用请求，记录并统计服务调用量、响应时间、请求链路和业务日志等，这些统计数据可以作为容量规划的参考指标，同时可以对包括用户行为分析和差异化服务等在内的业务数据进行统计和分析。

本实施例中，服务中心对接收到的服务请求进行服务编排条件的匹配，根据匹配的结果获取需要执行的服务，并根据服务注册的相关信息完成对服务请求的集群选择和协议调用，并采用多种负载均衡算法对需要执行的服务进行负载均衡处理，向后台节点发送服务调用请求，并对接收到的服务应答进行封装后返回给客户端，从而实现了服务集中化管理，封装应用内部结构，对外提供统一的接口，所有的服务请求统一通过服务中心进行集中化处理，根据服务编排规则调用各个业务系统的服务接口，与后台节点的服务提供方进行交互，使得客户端只需一次请求便可以完成所有分布式业务操作，方便了业务的复用和整合，提升了分布式架构的灵活性。同时，通过服务中心对全部服务调用请求和服务应答进行集中监控和管理，提供了统一的服务运维监控，以及业务数据的统计和分析功能。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每一个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同或者相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

值得注意的是，上述装置实施例中，所包括的各个模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能模块的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

本领域普通技术人员可以理解，实现上述各实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，相应的程序可以存储于一计算机可读取存储介质中，所述的存储介质，如ROM/RAM、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。