业务信息处理系统的制作方法

文档序号:11085138阅读:1066来源:国知局
业务信息处理系统的制造方法与工艺

本实用新型涉及通信技术领域,尤其涉及一种业务信息处理系统。



背景技术:

传统C/S架构的RPC(Remote Procedure Call Protocol,远程过程调用协议)框架,客户端非常臃肿,它需要处理协议的序列化和反序列化,需要处理路由算法、隔离、熔断等服务治理的功能,但服务治理功能会不断的更新,使得客户端的版本也需要不断升级。

由于客户端部署非常庞大,每次客户端升级都会需要业务重新编译打包,然后升级非常多台机器,即使业务代码没有改变,这也需要对升级客户端版本进行升级,导致工作量和风险非常大。



技术实现要素:

本实用新型的主要目的在于提出一种业务信息处理系统,旨在解决客户端版本升级时,工作量和风险非常大的技术问题。

为实现上述目的,本实用新型提供的一种业务信息处理系统,所述业务信息处理系统包括:代理服务器和客户端,

所述代理服务器包括连接模块和服务治理模块,所述客户端与所述连接模块连接,所述连接模块还分别与注册中心和目的服务器连接;

所述客户端将用户触发的业务请求发送至所述连接模块;

所述连接模块与所述处理芯片连接,所述连接模块将所述业务请求发送至所述处理芯片;

所述处理芯片根据所述业务请求从所述注册中心获取目的服务器的实例;

所述处理芯片根据所述代理服务器中预设服务治理策略和所述实例通过所述连接模块将所述业务请求发送至所述目的服务器。

可选地,所述系统还包括:与所述注册中心连接的所述目的服务器,所述目的服务器还与配置中心连接;

所述目的服务器从所述配置中心获取配置信息,并从所述安全中心获取安全策略;

所述目的服务器根据所述配置信息和安全策略将自身的地址和端口注册至所述注册中心,并向所述注册中心发送服务器的实例。

可选地,所述代理服务器包括本地代理服务器和备份代理服务器,所述本地代理服务器包括第一连接模块和第一处理芯片,所述备份代理服务器包括第二连接模块和第二处理芯片,

所述客户端分别与所述第一连接模块和所述第二连接模块连接,所述第一连接模块和第二连接模块还分别与所述目的服务器连接;

在本地代理服务器正常运行时,所述客户端发送将用户触发的业务请求发送至所述第一连接模块,所述第一连接模块与所述第一处理芯片连接,所述第一连接模块将所述业务请求发送至所述第一处理芯片,所述第一处理芯片根据所述业务请求从所述注册中心获取目的服务器的实例;

在本地代理服务器发生故障时,所述客户端发送将用户触发的业务请求发送至所述第二连接模块,所述第二连接模块与所述第二处理芯片连接,所述第二连接模块将所述业务请求发送至所述第二处理芯片,所述第二处理芯片根据所述业务请求从所述注册中心获取目的服务器的实例。

可选地,在本地代理服务器正常运行时,所述第一处理芯片根据所述预设服务治理策略和所述实例通过所述第一连接模块将所述业务请求发送至所述目的服务器;

在本地代理服务器发生故障时,所述第二处理芯片根据所述预设服务治理策略和所述实例通过所述第二连接模块将所述业务请求发送至所述目的服务器。

可选地,所述代理服务器根据所述业务请求中目的服务器的标识从所述注册中心获取目的服务器的实例。

可选地,所述业务信息处理系统还包括:监控报警服务器,所述监控报警服务器分别与所述客户端、代理服务器和目的服务器连接,所述客户端、代理服务器和目的服务器将各自的监控日志发送至所述监控报警服务器。

可选地,所述注册中心为基于分布式应用程序协调服务的注册中心。

本实用新型业务信息处理系统包括:代理服务器和客户端,所述代理服务器包括连接模块和处理芯片,所述客户端与所述连接模块连接,所述连接模块还分别与注册中心和目的服务器连接;所述客户端将用户触发的业务请求发送至所述连接模块;所述连接模块与所述处理芯片连接,所述连接模块将所述业务请求发送至所述处理芯片;所述处理芯片根据所述业务请求从所述注册中心获取目的服务器的实例;所述处理芯片根据所述代理服务器中预设服务治理策略和所述实例通过所述连接模块将所述业务请求发送至所述目的服务器。通过上述方式,本实用新型中在业务信息处理系统中添加代理服务器,将传统客户端中服务治理策略抽离,设置在代理服务器中,客户端只产生对应的业务请求,并发送至代理服务器,代理服务器根据业务请求获取目的服务器的实例,并根据预设的服务治理策略对业务请求进行对应的处理,采用本实用新型代理服务器能够在软件版本升级时,可以只需要对代理服务器进行升级,因此能够减少升级过程中的工作量和风险。

附图说明

图1为本实用新型业务信息处理系统第一实施例的系统架构示意图;

图2为本实用新型实施例中业务信息处理方法的系统处理流程时序示意图;

图3为本实用新型业务信息处理系统第二实施例的系统架构示意图;

图4为本实用新型实施例中业务信息处理系统的逻辑架构示意图;

图5为本实用新型实施例中业务信息处理系统的物理部署示意图;

图6为本实用新型业务信息处理的流程示意图。

本实用新型目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。

具体实施方式

应当理解,此处所描述的具体实施例仅仅用以解释本实用新型,并不用于限定本实用新型。

本实用新型提供一种业务信息处理系统。

参照图1,图1为本实用新型业务信息处理系统第一实施例的系统架构示意图。

在本实施例中,该业务信息处理系统包括:代理服务器200和客户端100,所述代理服务器200包括连接模块201和处理芯片202,所述连接模块201分别与所述客户端100注册中心、目的服务器连接;

所述客户端100将用户触发的业务请求发送至所述连接模块201;

所述连接模块201与所述处理芯片202连接,所述连接模块201将所述业务请求发送至所述处理芯片202;

所述处理芯片202根据所述业务请求从所述注册中心获取目的服务器的实例;

所述处理芯片202根据所述代理服务器200中预设服务治理策略和所述实例通过所述连接模块201将所述业务请求发送至所述目的服务器。

传统C/S结构中,即客户端和目的服务器结构中,客户端非常臃肿,客户端需要处理协议的序列化和反序列化,需要处理路由算法、隔离、熔断等服务治理功能,即服务治理策略,本实用新型中将传统客户端中的服务治理策略抽离出来,设置至代理服务器中,客户端则变成瘦客户端。

本实施例中代理服务器200,即Proxy,完全跟业务代码无关,是单独的Java进程,单独升级,升级时无需客户端100进行任何处理。

在用户需要进行业务处理时,通过客户端100触发对应的功能,客户端100根据用户操作产生对应的业务请求,并将用户触发的业务请求发送至代理服务器200中连接模块201,连接模块201与所述处理芯片202连接,所述连接模块201将所述业务请求发送至所述处理芯片202。处理芯片202接收到业务请求,则根据业务请求从注册中心获取目的服务器的实例,目的服务器即对应的服务提供方,然后处理芯片202根据代理服务器200中预设服务治理策略和所述实例对所述业务请求通过连接模块201将业务请求发送至目的服务器,即处理芯片202根据代理服务器200中预设服务治理策略和所述实例对所述业务请求进行对应的处理,本实施例中获取目的服务器的所有实例,以保证业务的进行。其中对所述业务请求进行对应的处理包括对所述业务请求进行转发、降级或拒绝。如将业务请求发送至目的服务器,则目的服务器根据接收到的业务请求反馈对应的内容至是代理服务器,由代理服务器发送至客户端。

处理流程时序图可以如图2所示:

客户端OSP Client进行序列化、监控埋点、安全签名、代理选择和异步发送。其中序列化就是一种用来处理对象流的机制,所谓对象流也就是将对象的内容进行流化。可以对流化后的对象进行读写操作,也可将流化后的对象传输于网络之间。序列化是为了解决在对对象流进行读写操作时所引发的问题。监控埋点就是监控用户操作的每一步。安全签名是对发送的信息进行加密。代理选择是选择代理服务器。异步发送是一种通讯方式,异步双方不需要共同的时钟,也就是接收方不知道发送方什么时候发送,所以在发送的信息中就要有提示接收方开始接收的信息,如开始位,同时在结束时有停止位。

代理服务器OSP Proxy进行反序列头信息、降级熔断、降级处理、服务路由、监控埋点和异步发送。其中反序列头信息就是将客户端发送的信息中的序列头进行解析。降级熔断是由于某些原因使得服务出现了过载现象,为防止造成整个系统故障,从而采用的一种保护措施,所以熔断亦称为过载保护。降级处理整体资源快不够了,先将某些服务先关掉,待整体资源足够时,再开启回来关掉的服务。服务路由就是可以自定义路由,通过定义路由将业务信息发送至指定的目的服务器。代理服务器向获取服务实例列表及服务配置,然后根据接收到的业务信息、服务实例和服务配置进行对应的处理。

目的服务器OSP应用则先进行反序列头信息、限流隔离、监控埋点、安全校验对接收到的业务信息进行验证,然后调用服务对通过验证的业务信息进行处理,然后进行返回数据、序列化返回数据和监控埋点。

其中,所述注册中心为基于分布式应用程序协调服务的注册中心。

基于Zookeeper的服务注册中心,可以实现服务的地址感知,错误感知,平滑升级,高可伸缩性,多版本支持。

进一步地,代理服务器200根据所述业务请求中目的服务器的标识从注册中心获取目的服务器的实例。

具体地,代理服务器200在接收到业务请求时,对接收到的业务请求进行解析,获得客户端100所要访问的目的服务器的标识,目的服务器的标识至少包括目的服务器的地址或者名称。然后代理服务器200根据目的服务器的标识从注册中心获取目的服务器的实例,进一步地,保持实时更新目的服务器的实例。

需要特别说明的是,对比于传统的负载平衡器LoadBalancer提供基本的负载均衡与HA(High Available,高可用性集群)能力,本实用新型Proxy提供了丰富的服务治理功能包括:

丰富的路由自定义功能:支持条件化的路由定义,负载均衡,权重调整,支持灰度发布,AB测试,黑白名单,跨机房路由等;

高可用与自我保护的机制:超时控制、重试、限流、熔断、降级、隔离;

服务监控,性能监控,故障快速定位支持;

服务配置:支持服务配置集中管理,动态下发;

服务安全:支持服务认证、授权、签名、加密传输的需求。

本实用新型业务信息处理系统包括:代理服务器和客户端,所述代理服务器包括连接模块和处理芯片,所述客户端与所述连接模块连接,所述连接模块还分别与注册中心和目的服务器连接;所述客户端将用户触发的业务请求发送至所述连接模块;所述连接模块与所述处理芯片连接,所述连接模块将所述业务请求发送至所述处理芯片;所述处理芯片根据所述业务请求从所述注册中心获取目的服务器的实例;所述处理芯片根据所述代理服务器中预设服务治理策略和所述实例通过所述连接模块将所述业务请求发送至所述目的服务器。通过上述方式,本实用新型中在业务信息处理系统中添加代理服务器,将传统客户端中服务治理策略抽离,设置在代理服务器中,客户端只产生对应的业务请求,并发送至代理服务器,代理服务器根据业务请求获取目的服务器的实例,并根据预设的服务治理策略对业务请求进行对应的处理,采用本实用新型代理服务器能够在软件版本升级时,可以只需要对代理服务器进行升级,因此能够减少升级过程中的工作量和风险。

进一步地,参照图3,图3为本实用新型业务信息处理系统第二实施例的系统架构示意图。

基于本实用新型业务信息处理系统第一实施例,该系统还包括:与所述注册中心连接的目的服务器300,目的服务器300还与配置中心连接;

所述目的服务器300用于从配置中心获取配置信息,并从所述安全中心获取安全策略;

所述目的服务器300还用于根据所述配置信息和安全策略将自身的地址和端口注册至所述注册中心,并向所述注册中心发送目的服务器的实例。

为使得业务信息处理系统能够执行,在系统运行时,目的服务器300需要从配置中心获取配置信息,并从所述安全中心获取安全策略,然后根据获取到的配置信息和安全策略将自己的地址和端口注册至所述注册中心,然后将目的服务器自身的实例发送至注册中心。其中,配置中心也可以设置在代理服务器中,当然也可以设置在其他终端/网络中。

具体地,该业务信息处理系统的逻辑架构可以如图4所示。

OSP服务端,即目的服务器,服务端包含服务容器和服务本身。服务容器提供服务本身基本以业务逻辑为主,由业务团队实现。

在服务启动时,每个服务首先从配置中心获取配置,从安全中心获取安全策略,然后将自己的地址和端口注册到服务注册中心。

OSP Proxy,即代理服务器,服务客户端将请求发送至代理服务器中OSP代理进程,服务代理层从注册中心获取当前服务提供方的实例(并保持实时更新),根据服务治理逻辑对请求进行处理(转发、降级或拒绝),服务治理的实现保持对客户端和服务端完全透明。

OSP Client,即客户端,由于客户端是业务应用的一部分,为避免框架代码改动对业务方的影响,服务客户端遵循的首要设计原则是单纯简单。除了必须的功能如通信协议、序列化、代理层容错以及监控埋点外,其他高级功能全部在代理层实现。从服务开发者的角度,客户端SDK由osp-idlc自动生成,无额外工作;从服务使用者的角度,只需将服务客户端SDK作为依赖引入,即可对服务进行调用,极少额外的工作。

进一步地,代理服务器200包括本地代理服务器210和备份代理服务器220,所述本地代理服务器210包括第一连接模块和第一处理芯片,所述备份代理服务器220包括第二连接模块和第二处理芯片,

所述客户端100分别与所述第一连接模块和所述第二连接模块连接,所述第一连接模块和第二连接模块还分别与所述目的服务器300连接;

在本地代理服务器210正常运行时,所述客户端100发送将用户触发的业务请求发送至所述第一连接模块,所述第一连接模块与所述第一处理芯片连接,所述第一连接模块将所述业务请求发送至所述第一处理芯片,所述第一处理芯片根据所述业务请求从所述注册中心获取目的服务器的实例;

在本地代理服务器210发生故障时,所述客户端100发送将用户触发的业务请求发送至所述第二连接模块,所述第二连接模块与所述第二处理芯片连接,所述第二连接模块将所述业务请求发送至所述第二处理芯片,所述第二处理芯片根据所述业务请求从所述注册中心获取目的服务器300的实例。本实施例中,代理服务器200包括两种类型的代理服务器:本地代理服务器210和备份代理服务器220,服务器300从配置中心获取配置信息,并本地代理服务器210和备份代理服务器220从安全中心获取安全策略,在本地代理服务器210正常运行时,所述本地代理服务器210根据所述业务请求和获得的所述实例进行对应的处理;在本地代理服务器210发生故障时,所述备份代理服务器220根据所述业务请求和获得的所述实例进行对应的处理。

具体地,该系统物理部署图可以如图5所示。

OSP服务端,即目的服务器,基于无状态服务的理念,可以无限扩展,也可以通过代理层的错误感知和负载均衡等功能自动摘出有问题的目的服务器;开发团队无需做特殊处理,也不必部署负载均衡器。

OSP Proxy,即代理服务器,代理层由本地Local Proxy和集中式备份集群Remote Proxy组成,本地代理以独立进程方式部署在每一台调用者服务器上,只为本机调用者服务;集中式备份集群每个机房部署一个,由集群技术LVS提供负载均衡,为本地代理提供容错能力。在本地代理发生故障时,调用方切换到使用集中式备份集群完成服务调用。代理层从注册中心获取各机房的服务实例信息,并优先选择使用本机房服务实例,在本机房无可用实例时选择使用其他机房实例。

OSP Client,即客户端,客户端内嵌在业务应用里,通过SDK向使用者提供调用接口和对象模型;从使用者的角度,只需进行调用。客户端不与配置中心产生联系,但会与Salus连接,并将监控信息上报到监控报警系统Mercury。配置中心集中部署在一个机房内,在远程机房可用选择部署ZK观察集群,以提高性能和降低网络影响。Mercury集中部署在一个机房内。

参照图6,图6为本实用新型业务信息处理的流程示意图。

在本实施例中,该业务信息处理方法包括:

步骤S10,客户端发送用户触发的业务请求至代理服务器;

步骤S20,所述代理服务器根据所述业务请求从注册中心获取目的服务器的实例;

步骤S30,所述代理服务器根据所述代理服务器中预设服务治理策略和所述实例对所述业务请求进行对应的处理。

传统C/S结构中,即客户端和目的服务器结构中,客户端非常臃肿,客户端需要处理协议的序列化和反序列化,需要处理路由算法、隔离、熔断等服务治理功能,即服务治理策略,本实用新型中将传统客户端中的服务治理策略抽离出来,设置至代理服务器中,客户端则变成瘦客户端。

本实施例中代理服务器,即Proxy,完全跟业务代码无关,是单独的Java进程,单独升级,升级时无需客户端进行任何处理。

在用户需要进行业务处理时,通过客户端触发对应的功能,客户端根据用户操作产生对应的业务请求,并将用户触发的业务请求发送至代理服务器。代理服务器接收到业务请求,则根据业务请求从注册中心获取目的服务器的实例,目的服务器即对应的服务提供方,然后代理服务器根据代理服务器中预设服务治理策略和所述实例对所述业务请求进行对应的处理,本实施例中获取目的服务器的所有实例,以保证业务的进行。其中对所述业务请求进行对应的处理包括对所述业务请求进行转发、降级或拒绝。如将业务请求发送至目的服务器,则目的服务器根据接收到的业务请求反馈对应的内容至是代理服务器,由代理服务器发送至客户端。

处理流程时序图可以如图2所示:

客户端OSP Client进行序列化、监控埋点、安全签名、代理选择和异步发送。其中序列化就是一种用来处理对象流的机制,所谓对象流也就是将对象的内容进行流化。可以对流化后的对象进行读写操作,也可将流化后的对象传输于网络之间。序列化是为了解决在对对象流进行读写操作时所引发的问题。监控埋点就是监控用户操作的每一步。安全签名是对发送的信息进行加密。代理选择是选择代理服务器。异步发送是一种通讯方式,异步双方不需要共同的时钟,也就是接收方不知道发送方什么时候发送,所以在发送的信息中就要有提示接收方开始接收的信息,如开始位,同时在结束时有停止位。

代理服务器OSP Proxy进行反序列头信息、降级熔断、降级处理、服务路由、监控埋点和异步发送。其中反序列头信息就是将客户端发送的信息中的序列头进行解析。降级熔断是由于某些原因使得服务出现了过载现象,为防止造成整个系统故障,从而采用的一种保护措施,所以熔断亦称为过载保护。降级处理整体资源快不够了,先将某些服务先关掉,待整体资源足够时,再开启回来关掉的服务。服务路由就是可以自定义路由,通过定义路由将业务信息发送至指定的目的服务器。代理服务器向获取服务实例列表及服务配置,然后根据接收到的业务信息、服务实例和服务配置进行对应的处理。

目的服务器OSP应用则先进行反序列头信息、限流隔离、监控埋点、安全校验对接收到的业务信息进行验证,然后调用服务对通过验证的业务信息进行处理,然后进行返回数据、序列化返回数据和监控埋点。

其中,所述注册中心为基于分布式应用程序协调服务的注册中心。

基于Zookeeper的服务注册中心,可以实现服务的地址感知,错误感知,平滑升级,高可伸缩性,多版本支持。

进一步地,代理服务器根据所述业务请求从注册中心获取目的服务器的实例的步骤包括:

代理服务器对所述业务请求进行解析,获得目的服务器的标识;

代理服务器根据目的服务器的标识从注册中心获取目的服务器的实例。

具体地,代理服务器在接收到业务请求时,对接收到的业务请求进行解析,获得客户端所要访问的目的服务器的标识,目的服务器的标识至少包括目的服务器的地址或者名称。然后代理服务器根据目的服务器的标识从注册中心获取目的服务器的实例,进一步地,保持实时更新目的服务器的实例。

需要特别说明的是,对比于传统的负载平衡器LoadBalancer提供基本的负载均衡与HA(High Available,高可用性集群)能力,本实用新型Proxy提供了丰富的服务治理功能包括:

丰富的路由自定义功能:支持条件化的路由定义,负载均衡,权重调整,支持灰度发布,AB测试,黑白名单,跨机房路由等;

高可用与自我保护的机制:超时控制、重试、限流、熔断、降级、隔离;

服务监控,性能监控,故障快速定位支持;

服务配置:支持服务配置集中管理,动态下发;

服务安全:支持服务认证、授权、签名、加密传输的需求。

本实用新型业务信息处理系统包括:代理服务器,以及与所述代理服务器连接的客户端,所述客户端用于发送的业务请求至代理服务器;所述代理服务器用于根据所述业务请求从注册中心获取目的服务器的实例;所述代理服务器还用于根据所述代理服务器中预设服务治理策略和所述实例对所述业务请求进行对应的处理。通过上述方式,本实用新型中在业务信息处理系统中添加代理服务器,将传统客户端中服务治理策略抽离,设置在代理服务器中,客户端只产生对应的业务请求,并发送至代理服务器,代理服务器根据业务请求获取目的服务器的实例,并根据预设的服务治理策略对业务请求进行对应的处理,采用本实用新型代理服务器能够在软件版本升级时,可以只需要对代理服务器进行升级,因此能够减少升级过程中的工作量和风险。

进一步地,基于本实用新型上述实施例,业务信息处理流程还包括:

所述目的服务器从配置中心获取配置信息,并从所述安全中心获取安全策略;

所述目的服务器根据所述配置信息和安全策略将自己的地址和端口注册至所述注册中心,并向所述注册中心发送目的服务器的实例。

为使得业务信息处理系统能够执行,在系统运行时,目的服务器需要从配置中心获取配置信息,并从所述安全中心获取安全策略,然后根据获取到的配置信息和安全策略将自己的地址和端口注册至所述注册中心,然后将目的服务器自身的实例发送至注册中心。其中,配置中心也可以设置在代理服务器中,当然也可以设置在其他终端/网络中。

具体地,该业务信息处理系统的逻辑架构可以如图4所示。

OSP服务端,即目的服务器,服务端包含服务容器和服务本身。服务容器提供服务本身基本以业务逻辑为主,由业务团队实现。

在服务启动时,每个服务首先从配置中心获取配置,从安全中心获取安全策略,然后将自己的地址和端口注册到服务注册中心。

OSP Proxy,即代理服务器,服务客户端将请求发送至代理服务器中OSP代理进程,服务代理层从注册中心获取当前服务提供方的实例(并保持实时更新),根据服务治理逻辑对请求进行处理(转发、降级或拒绝),服务治理的实现保持对客户端和服务端完全透明。

OSP Client,即客户端,由于客户端是业务应用的一部分,为避免框架代码改动对业务方的影响,服务客户端遵循的首要设计原则是单纯简单。除了必须的功能如通信协议、序列化、代理层容错以及监控埋点外,其他高级功能全部在代理层实现。从服务开发者的角度,客户端SDK由osp-idlc自动生成,无额外工作;从服务使用者的角度,只需将服务客户端SDK作为依赖引入,即可对服务进行调用,极少额外的工作。

进一步地,代理服务器包括本地代理服务器和备份代理服务器,所述客户端分别与所述本地代理服务器和备份代理服务器连接,所述本地代理服务器和备份代理服务器分别与所述目的服务器连接;在本地代理服务器正常运行时,所述本地代理服务器根据所述业务请求和获得的所述实例进行对应的处理;在本地代理服务器发生故障时,所述备份代理服务器根据所述业务请求和获得的所述实例进行对应的处理。

本实施例中,代理服务器包括两种类型的代理服务器:本地代理服务器和备份代理服务器,目的服务器从配置中心获取配置信息,并本地代理服务器和备份代理服务器从安全中心获取安全策略,在本地代理服务器正常运行时,所述本地代理服务器根据所述业务请求和获得的所述实例进行对应的处理;在本地代理服务器发生故障时,所述备份代理服务器根据所述业务请求和获得的所述实例进行对应的处理。

具体地,该系统物理部署图可以如图5所示。

OSP服务端,即目的服务器,基于无状态服务的理念,可以无限扩展,也可以通过代理层的错误感知和负载均衡等功能自动摘出有问题的目的服务器;开发团队无需做特殊处理,也不必部署负载均衡器。

OSP Proxy,即代理服务器,代理层由本地Local Proxy和集中式备份集群Remote Proxy组成,本地代理以独立进程方式部署在每一台调用者服务器上,只为本机调用者服务;集中式备份集群每个机房部署一个,由集群技术LVS提供负载均衡,为本地代理提供容错能力。在本地代理发生故障时,调用方切换到使用集中式备份集群完成服务调用。代理层从注册中心获取各机房的服务实例信息,并优先选择使用本机房服务实例,在本机房无可用实例时选择使用其他机房实例。

OSP Client,即客户端,客户端内嵌在业务应用里,通过SDK向使用者提供调用接口和对象模型;从使用者的角度,只需进行调用。客户端不与配置中心产生联系,但会与Salus连接,并将监控信息上报到监控报警系统Mercury。配置中心集中部署在一个机房内,在远程机房可用选择部署ZK观察集群,以提高性能和降低网络影响。Mercury集中部署在一个机房内。

以上仅为本实用新型的优选实施例,并非因此限制本实用新型的专利范围,凡是利用本实用新型说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本实用新型的专利保护范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1