CN102064954A

CN102064954A - 一种分布式容错系统、设备和方法

Info

Publication number: CN102064954A
Application number: CN2009102247915A
Authority: CN
Inventors: 阮曙东; 张凯; 陈生; 范世青; 陈德贤; 朱涛; 张维全
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Shenzhen Tencent Computer Systems Co Ltd
Priority date: 2009-11-17
Filing date: 2009-11-17
Publication date: 2011-05-18
Anticipated expiration: 2029-11-17
Also published as: CN102064954B

Abstract

本发明实施例公开了一种分布式容错系统、设备和方法，其中，所述系统包括：客户端和服务端；其中，所述服务端包含一个以上服务节点，每一服务节点用于发布服务，并在发布服务时携带与该服务有关的信息，所述信息包括所述服务节点的信息和所述服务节点的灰度状态；所述客户端，用于针对每一需要灰度路由的接口，将该接口运行的对应用户的用户参数值传递给自身管理的服务代理，由该服务代理根据传递的用户参数值确定用户的灰度状态；并根据服务节点发布服务时所携带的信息，将所述用户发送的消息路由到与所述用户具有相同灰度状态的服务节点上。采用本发明，能够降低网络运行风险。

Description

一种分布式容错系统、设备和方法

技术领域

本发明涉及网络管理技术，特别涉及一种分布式容错系统、设备和方法。

背景技术

目前，随着系统可靠性的发展，容错系统也随之被广泛应用。其中，容错系统是指：对系统中的关键部件进行冗余备份，并且通过一定的检测手段，能够在系统中的软件和硬件故障时，切换到冗余部件工作，以保证整个系统能够不因这些故障而导致业务处理中断；而在故障修复后，又能够恢复到冗余备份状态。使用容错系统，能够将可能的软件和硬件故障给整个系统带来的风险降至最低。

现有技术中常用的容错平台是基于中间件的容错平台，但是，这种基于中间件的容错平台在实际运营考虑较少，比如，在实际应用中，当服务端新发布一个服务时，会导致全部客户端用户都会集中访问该服务，本领域技术人员知道，新发布的服务并非是完美的，其通常会有一些bug，因此，采用现有技术的容错平台，会大大增加网络运行风险。

发明内容

本发明实施例提供了一种分布式容错系统、设备和方法，以便降低网络运行风险。

本发明实施例公开了一种分布式容错系统，所述系统包括：客户端和服务端；其中，

所述服务端包含一个以上服务节点，每一服务节点用于发布服务，并在发布服务时携带与该服务有关的信息，所述信息包括所述服务节点的信息和所述服务节点的灰度状态；

所述客户端，用于针对每一需要灰度路由的接口，将该接口运行的对应用户的用户参数值传递给自身管理的服务代理，由该服务代理根据传递的用户参数值确定用户的灰度状态；并根据服务节点发布服务时所携带的信息，将所述用户发送的消息路由到与所述用户具有相同灰度状态的服务节点上。

一种客户端，包括：通信器和服务代理处理模块；所述服务代理处理模块提供了服务代理；

所述通信器为该系统的应用层接口，对每一需要灰度路由的接口，将该接口运行的对应用户的用户参数值传递给由所述服务代理处理模块提供的服务代理；

所述服务代理处理模块提供的所述服务代理接收传递的用户参数值，根据传递的用户参数值确定用户的灰度状态；并根据服务节点发布服务时所携带的与该服务有关的信息，所述信息包括所述服务节点的信息和所述服务节点的灰度状态，将所述用户发送的消息路由到与所述用户具有相同灰度状态的服务节点上。

一种分布式容错方法，该方法包括以下步骤：

A，针对每一需要灰度路由的接口，客户端将该接口运行的对应用户的用户参数值传递给对应的服务代理；

B，所述服务代理根据传递的用户参数值确定该用户的灰度状态，并根据服务端中服务节点发布服务时所携带的与该服务有关的信息，所述信息包括所述服务节点的信息和所述服务节点的灰度状态，将所述用户发送的消息路由到与所述用户具有相同灰度状态的服务节点上。

由以上技术方案可以看出，本发明实施例中，能够实现将用户路由到与该用户具有相同灰度状态的服务节点上，这相比于现有技术，能够大大减少访问发布新服务的服务节点的用户个数，避免现有技术中由于将所有用户路由到发布新服务的服务节点所带来的网络运行风险。

附图说明

图1为本发明实施例提供的系统结构图；

图2为本发明实施例提供的系统详细结构图；

图3为本发明实施例提供的客户端结构图；

图4为本发明实施例提供的流程图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

本发明实施例基于对自动生成协议(jce：Java Cryptography Extension)的分析，提出了分布式容错系统。其中，本发明实施例提供的分布式容错系统，能够对服务的灰度发布提供框架层面的支持，具体可参见图1。

参见图1，图1为本发明实施例提供的统一容错系统结构图，如图1所示，该容错系统可包括：客户端11和服务端22。

其中，服务端22，用于发布服务，并在发布服务时携带与该服务有关的信息，所述信息包括所述服务端包含的1个以上部署了所述服务的服务节点的信息和所述服务节点的灰度状态，具体地，本实施例中，服务节点的信息可为该服务节点的IP地址和端口。

需要说明的是，服务节点的灰度状态与该服务节点提供的服务有关，当该服务节点提供的服务不变，则该服务节点的灰度状态也一般不会发生改变。

客户端11用于针对每一需要灰度路由的接口，将该接口运行的对应用户的用户参数值传递给自身管理的服务代理，这里，用户参数值与客户端用户对应，具体实现时可为QQ号码，或者用户的电话号码等，本发明实施例并不具体限定；由该服务代理根据传递的用户参数值确定用户的灰度状态；并根据服务端22发布服务时所携带的信息，将来自所述用户的消息路由到与所述用户具有相同灰度状态的服务节点上。

至此，通过本发明实施例提供的系统，能够实现将用户路由到与该用户具有相同灰度状态的服务节点上，这相比于现有技术，能够大大减少访问发布新服务的服务节点的用户个数，避免现有技术中由于将所有用户路由到发布新服务的服务节点所带来的网络运行风险。

本实施例在具体实现时，可通过直接指定与客户端11相连的服务节点，具体是通过直接指定IP地址和端口指定与客户端相连的服务节点，其中，在指定服务节点时，可以指定多个服务节点，用于容错；如此，客户端11即可获取与自身相连的服务节点发布服务时携带的与该服务有关的信息；这里，直接指定服务节点的示例如下：

其中，Test为服务所在的应用名称，HelloServer为服务名称，HelloObj为对象名称ObjectName，@为直接指定的标识，-h 127.0.0.1为服务节点的IP地址；-p 45458、-p 45459和-p 45460为服务节点的监听端口，可以看出，一个服务节点可以支持多个监听端口，这里，该监听端口可支持TCP/UDP。

可以看出，通过直接指定服务节点的形式，能够使客户端比较简单地获取与自身相连的服务节点发布服务时所携带的与该服务相关的信息。但是，采用上述通过直接指定与客户端11相连的服务端的服务节点的方式，需要在程序代码中写死，大大减少本发明实施的灵活性，因此，本实施例还提供了另一种方式：即利用Registry来获取与自身相连的服务节点。这里，Registry的服务地址可通过配置中的locator参数指定，例如：

locator＝taf.tafregistry.QueryObj@tcp-h 127.0.0.1-p 17890；

如此，本实施例中，通过Registry间接指定服务节点可如下式：

HelloPrx pPrx＝_comm-＞stringToProxy<HelloPrx>

(″Test.HelloServer.HelloObj”)；

为了便于客户端11获取与自身相连的服务节点发布服务时所携带的信息，本实施例中，客户端11需要按照预设的刷新规则从Registry上刷新最新的服务列表，这里，服务列表中包含了服务节点的灰度状态、服务节点提供的服务信息和服务节点的信息(比如IP地址和端口)；刷新原则为：如果本地服务列表为空且距离上次更新时间大于预设时间(比如2秒)，则同步刷新服务列表；如果距离上次刷新时间大于配置的刷新时间(比如1分钟)，则异步刷新服务列表。如此，客户端11即可获取与自身相连的比较新的服务列表。

需要说明的是，本实施例中，客户端管理的服务代理可通过以下两种方式确定(当然，客户端提供并管理的的代理，比如对象代理(Object Proxy)等也可采用以下两种方式确定)：

第一种方式：直接代理，具体是通过指定服务端IP地址和端口获取代理，比如：

stringToProxy(″Test.TestServer.TestBaseObj@tcp-h 127.0.0.1-p 22322”)；

其中，Test：服务所在的应用名称；TestServer：服务名称；TestBaseObj：ObjectName；@：直接代理标识；tcp：传输协议，支持tcp和udp；-h 127.0.0.1：服务端IP地址为127.0.0.1；-p 22322：服务端监听端口为22322。

第二种方式：间接代理，这种方式是通过指定ObjectName，由taf-registry根据ObjectName获取对应的IP和Port，其中，taf-registry的地址需要在通信器的配置文件中配置。可以看出，因此ObjectName必须在Registry上全局唯一。比如：

stringToProxy(″Test.TestServer.TestBaseObj”)。

至此，通过以上方式，客户端即可获取对应的服务代理。

为了使本发明实施例提供的系统更加清楚，下面对本发明实施例提供的系统进行详细描述。

参见图2，图2为本发明实施例提供的系统结构图。如图2所示，可包括：客户端和服务端。其中，客户端和服务端的具体功能可与图1所述。

优选地，本实施例中，如图2所示，客户端11包括：通信器101和服务代理处理模块102；这里，服务代理处理模块102提供了服务代理(Servant Proxy)；

其中，通信器101为该系统的应用层接口，针对每一需要灰度路由的接口，将该接口运行的对应用户的用户参数值通过调用预先设置的Invoke接口传递给与所述预先设置的Invoke接口具有映射关系的服务代理；

服务代理处理模块102提供的服务代理还提供了用于注册路由的路由接口，其中，所述路由接口接收传递的用户参数值，并判断所述用户参数值是否满足预设的灰度状态条件，如果满足，则确定所述用户的灰度状态为灰度，如果不满足，则确定所述用户的灰度状态为普通；之后，将确定的灰度状态返回。这里，灰度状态具体为灰度(标记为“1”)和普通(标记为“0”)。

如图2所示，客户端11还可包括：客户端业务线程处理模块103；

其中，客户端业务线程处理模块103连接在通信器101和服务代理处理模块102之间，提供了业务线程，在接收到用户发送的消息时，由自身提供的业务线程将所述消息提供给服务代理处理模块；

如此，服务代理处理模块102根据确定的该用户的灰度状态和获取的服务端发布服务时所携带的信息通过自身提供的所述服务代理调用与所述用户具有相同灰度状态的服务节点的接口，以使该接口处理该用户发送的消息。

具体地，这里，服务代理处理模块102提供的服务代理调用服务节点的接口具体实现时主要有同步调用、异步调用和单向调用。

其中，同步调用是服务代理同步调用服务节点(具体是调用服务节点的某个接口)，调用后该业务线程阻塞，直到调用被服务端返回或者调用超时，即同步调用时，客户端业务线程timewait在当前请求上，直到调用被服务端返回或者直到调用超时；其中，同步超时时间可以由应用层设定，可以精确到毫秒级，具体可在配置中指定，缺省为3秒。可以看出，一个业务线程每次只能处理一个消息，因此同一ObjectName队列中的消息数小于等于应用层业务线程个数。为便于了解同步调用，下面描述同步调用的示例：

需要说明的是，上述DemoPrx在生成的代码.h.cpp中定义；并且，如果调用时存在网络、协议上的错误，则可采用异常抛出的方式。

至此，同步调用即可实现。

异步调用为服务代理调用服务端的某个异步接口(async_)，在执行异步调用时，需要在客户端先实现对应的回调接口(必选)和异常处理接口(可选)，每次异步调用时需要生成一个新的回调对象，作为异步接口调用的第一个参数，具体如下：

TestPrxCallback cb＝new TestPrxCallback()；

TestProxy proxy＝comm-＞stringToProxy(″Test.TestServer.TestObj”)；

proxy-＞async_doTest(cb，“123”)；

本实施例中，服务端对异步调用处理和同步调用类似，不同的是，异步处理完成后返回结果，客户端会在异步回调线程中选择一个空闲线程，执行参数中的传入的回调对象的callback接口，相比于同步调用，可以提高业务线程的效率。异步调用示例如下：

至此，异步调用即可实现。需要说明的是，异步调用时，可通过一个单独的定时器线程来触发队列中的超时，超时后调用回调方法对应的异常接口比如上述的callback_接口，异步超时时间控制只能精确到秒级，具体数值在配置中指定：缺省为5秒。

单向调用为服务代理单向调用服务节点(即服务节点的某个接口)，调用后该业务线程即返回。当服务节点接收到服务代理发送的消息后，确定该消息的类型为单向调用时，在对该消息执行逻辑处理完后不做返回，即，单向调用不保证一定成功，失败后也不回调异常处理接口。单向调用与异步调用类似，不同的是，由于单向调用不回调异常处理接口，因此，只需将上述异步调用示例中回调接口的callback对象传入NULL即可，即pPtr-＞async_set(NULL，v)；其他都类似。

通过上述三种调用方式，能够实现客户端通过服务代理发送消息给服务端的操作。

本实施例中的服务端22可采用多线程模型，并且可支持多个监听TCP/UDP端口，这里，每个端口对应一个Adapter。

需要说明的是，本实施例中，服务端只有一个网络发送队列，但每一个端口对应的一个Adapter有独立的消息接收队列。其中，每个Adapter具有一组独立的可进行逻辑处理的业务线程。

如图2所示，服务端22中每一服务节点可包括：网络线程处理模块201。

其中，网络线程处理模块201由EPoll时间驱动，执行的所有操作为非阻塞，用于负责建立和管理与服务端22的所有连接，以及所述服务端接收和发送的所有消息，当通过所述服务端支持的端口接收到消息时，判断所述端口对应的Adapter对象的当前访问量是否已到达预设的阈值，比如，判断所述端口对应的Adapter对象的连接数量当前是否超过了预设的阈值；或者判断接收的消息所携带的客户端IP地址是否不在所述端口对应的Adapter对象的访问权限内等，如果是，丢弃所述消息；否则，将所述消息放入Adapter对象对应的消息接收队列中。

优选地，如图2所示，服务端22中每一服务节点还可包括：服务端业务线程处理模块202，

其中，服务端业务线程处理模块202提供了业务线程，从其提供的业务线程所属的Adapter对应的消息接收队列中读取消息，对所述消息执行逻辑处理，并在完成处理后，返回相应的消息，将该返回消息放入网络发送队列中；这里，服务端业务线程处理模块202从其执行的业务线程所属的Adapter可以注册一个Handle的处理类，这样，可利用注册的Handle处理类对所述消息执行逻辑处理。

需要说明的是，客户端发送的消息携带了该消息的超时时间，网络线程处理模块201将该消息放入消息接收对列时会记录该消息的入队时间，之后，服务端业务线程处理模块202读取该消息时，会计算该消息在队列中的时间，如果计算的时间超过预设的超时时间，则丢弃该消息，不对该消息执行逻辑处理；否则，对所述消息执行逻辑处理。

由于网络线程处理模块201负责管理服务端接收和发送的消息，因此，执行到这里，网络线程处理模块201从网络发送队列中取出并发送该返回消息。

需要说明的是，本实施例中，每个Adapter对象包含的每一业务线程都有一个Handle的对象实例，以避免线程安全问题，其中，Handle对象主要有Initialize()，handle()，handle timeout()接口；为便于提高系统可靠性，可为每一Adapter设置其在服务端的消息接收队列的最大长度，当网络线程处理模块201将接收的消息放入Adapter的消息接收队列中时，如果判断出该消息接收队列的长度已达到最大长度，则调用属于该Adapter的业务线程的handleoverload接口，返回客户端过载异常的响应消息。

为便于本发明实施例的实现，本发明实施例还提供了客户端的具体结构图，其中，该客户端的结构具体如图3所示，主要包括：通信器301和服务代理处理模块302，其中，通信器301和服务代理处理模块302的具体功能与上述图2中通信器101和服务代理处理模块102的功能类似，这里不再详述。

优选地，客户端还可包括：客户端业务线程处理模块303；该客户端业务线程处理模块303也与图2所示的客户端业务线程处理模块103类似，这里不再详述。

以上对本发明实施例提供的系统和设备进行了描述，下面结合具体实施例对本发明提供的方法进行描述。

本发明实施例提供的方法应用于包含上述客户端和服务端的系统中，如图4所示，该方法包括以下步骤：

步骤401，针对每一需要灰度路由的接口，客户端将该接口运行的对应用户的用户参数值传递给对应的服务代理。

这里，本步骤401中客户端将该接口运行的对应用户的用户参数值传递给对应的服务代理具体实现时可通过调用预先设置的Invoke接口传递给与所述预先设置的Invoke接口具有映射关系的服务代理。

步骤402，由该服务代理根据传递的用户参数值确定该用户的灰度状态。

通常，服务代理提供了用于注册路由的路由接口，该路由接口接收传递的用户参数值，并判断所述用户参数值是否满足预设的灰度状态条件，如果满足，则确定所述用户的灰度状态为灰度(记为1)，如果不满足，则确定所述用户的灰度状态为普通(记为0)。

至此，通过上述步骤401至步骤402实现了确定用户的灰度状态的操作。

步骤403，根据获取的服务节点发布服务时所携带的与该服务有关的信息，将用户发送的消息路由给与所述用户具有的灰度状态相同的服务节点。

这里，服务节点在发布服务时，其通常会发布与该服务有关的信息，其中，该信息包括服务节点的信息(比如服务节点的IP地址和端口)、服务节点的灰度状态。因此，本步骤403可根据确定的用户的灰度状态和服务端发布的信息将该用户发送的消息路由给与所述用户具有的灰度状态相同的1个或者多个服务节点上。

之后，服务端将该用户的灰度状态和用户参数值保存到线程私有数据中，如果后续调用仍然在当前线程(比如同步调用)，且用户参数值等于线程私有数据保存的用户参数值，则灰度状态继续有效，即被有效透传。

需要说明的是，通常，服务节点发布与服务有关的信息与客户端获取该信息并不同步，比如，当前需要将灰度状态为0的用户发送的消息进行路由，而当前已获取的信息为服务节点1的灰度状态为0，因此，当前需要将用户消息路由到服务节点1上，而事实上，服务节点1的灰度状态当前已被更新为1，只不过客户端还未获取，如此，就会导致灰度状态为0的消息送到灰度状态为1的服务节点(记为情况1)，或者，服务代理当前需要将灰度状态为1的用户发送的消息进行路由，而自身获取的信息为服务节点1的灰度状态为1，因此，当前需要将用户消息路由到服务节点1上，而事实上，服务节点1的灰度状态已更新为0，只不过客户端还未获取；如此，就会导致灰度状态为1的消息送到灰度状态为0的服务节点(记为情况2)。

针对这两种情况，本发明实施例提出了不同的措施，其中，针对情况1，服务节点会产生reset响应，如此，服务代理根据产生的reset响应重新更新本地服务列表中该服务节点的灰度状态。针对情况2，服务节点正常处理该消息。

至此，通过上述步骤，实现了本发明实施例提供的流程。

通常，客户端到每个服务节点都建立一个或多个连接(缺省为1个)，如果某个连接断掉，则客户端每隔预设时间比如10秒会尝试重连(时间判断由消息触发)；当某个服务节点上的连接全部不可用(消息触发检测，且检测过程中同样会判断每隔预设时间比如10秒重连)，则从该服务节点所在组中选择该服务节点的下一个有效节点；这里，根据上面的描述可以得到，客户端能够获取服务端中服务节点发布服务时携带的信息，为便于管理该信息，可以按照同一灰度状态处于同一组的原则对各个服务节点发布的信息进行分组，因此，这里的服务节点所在组为与该服务节点处于同一灰度状态的组；当然，如果轮询选择不到有效节点，则会随机选择一个节点进行实时重连。

还需要说明的是，本实施例中，为便于针对某一用户参数值进行跟踪，本实施例中，服务端接收到消息后，判断该消息携带的标识信息是否和预设的需要染色的标识信息匹配，这里，标识信息可为用户号码、远程对象和接口中的至少一个；如果是，则对该消息进行处理，并打印对应的染色日志；如果在处理过程中，还需调用其他服务，则通过状态字传递染色信息，被调服务进行相应的处理，并打印对应的染色日志。

还需要说明的是，本实施例中，为解决本申请的技术问题，上述步骤401至步骤403也可替换为：在需要发送用户的消息时，如果当前有多个服务节点可以处理该消息，则客户端缺省使用随机策略选择，具体为按照相同用户参数值(比如按用户号码)的消息都发送给相同服务节点的原则对该消息进行路由，如此，提高hash接口来控制相同用户参数值的消息(比如按用户号码)在一定时间内都发送到同一台服务节点。但是，hash方式并不保证同一用户参数值的消息始终发送到某个服务端(比如在该服务端出现异常时)，因此，优选推荐本实施例提供的图4所示的流程。

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

Claims

1.一种分布式容错系统，其特征在于，所述系统包括：客户端和服务端；其中，

2.根据权利要求1所述的系统，其特征在于，所述客户端通过直接指定IP地址和端口的形式指定与自身相连的服务节点，并获取该服务节点发布服务时所携带的信息；或者，

所述客户端通过由注册器Registry间接获取与自身相连的服务节点；并按照预设的刷新原则从所述注册器上刷新服务列表，所述服务列表中包含了服务节点发布服务时所携带的信息；所述刷新原则为：如果客户端本地服务列表为空且距离上次更新时间大于预设时间，则同步刷新服务列表；如果距离上次刷新时间大于配置的刷新时间，则异步刷新服务列表。

3.根据权利要求1或2所述的系统，其特征在于，所述客户端包括：通信器和服务代理处理模块；所述服务代理处理模块提供了服务代理；

所述通信器为该系统的应用层接口，对每一需要灰度路由的接口，将该接口运行的对应一用户的用户参数值通过调用预先设置的Invoke接口传递给与所述预先设置的Invoke接口具有映射关系的服务代理；

所述服务代理处理模块提供的服务代理还提供了用于注册路由的路由接口，所述路由接口接收传递的用户参数值，并判断所述用户参数值是否满足预设的灰度状态条件，如果满足，则确定所述用户的灰度状态为灰度，如果不满足，则确定所述用户的灰度状态为普通。

4.根据权利要求3所述的系统，其特征在于，所述客户端还包括：客户端业务线程处理模块；

所述客户端业务线程处理模块连接在通信器和服务代理处理模块之间，提供了业务线程，在接收到用户发送的消息时，由自身提供的业务线程将所述消息提供给所述服务代理处理模块；

所述服务代理处理模块根据确定的用户的灰度状态和服务节点发布服务时所携带的信息，并通过自身提供的所述服务代理调用与所述用户具有相同灰度状态的服务节点的接口处理该用户发送的消息。

5.根据权利要求2所述的系统，其特征在于，所述服务节点包括：网络线程处理模块和服务端业务线程处理模块；

所述网络线程处理模块在通过所述服务端支持的端口接收到消息时，判断所述端口对应的Adapter的当前访问量是否已到达预设的阈值，如果是，丢弃所述消息；否则，将所述消息放入Adapter对象对应的消息接收队列中；

所述服务端业务线程处理模块提供业务线程，从其提供的业务线程所属的Adapter对应的消息接收队列中读取消息，对所述消息执行逻辑处理，并在完成处理后，返回相应的消息，将该返回消息放入网络发送队列中；

所述网络线程处理模块在预设时间到达时，从所述网络发送队列中取出并发送该返回消息。

6.根据权利要求5所述的系统，其特征在于，所述消息中携带了该消息的超时时间；

所述网络线程处理模块将所述消息放入Adapter对象对应的消息接收队列中时，记录该消息的入队时间；

所述服务端业务线程处理模块读取消息时，计算该消息在队列中的时间，如果计算的时间超过该消息携带的超时时间，则不对该消息执行逻辑处理；否则，对所述消息执行逻辑处理。

7.一种客户端，其特征在于，所述客户端包括：通信器和服务代理处理模块；所述服务代理处理模块提供了服务代理；

8.根据权利要求7所述的客户端，其特征在于，所述服务代理处理模块提供的服务代理中存在与预先设置的Invoke接口具有映射关系的服务代理；

所述通信器通过调用预先设置的Invoke接口将所述用户参数值传递给与所述预先设置的Invoke接口具有映射关系的服务代理；

所述服务代理处理模块提供的与所述Invoke接口具有映射关系的服务代理提供了用于注册路由的路由接口，所述路由接口接收传递的用户参数值，并判断所述用户参数值是否满足预设的灰度状态条件，如果满足，则返回所述用户的灰度状态为灰度，如果不满足，则返回所述用户的灰度状态为普通。

9.根据权利要求7或8所述的客户端，其特征在于，所述客户端还包括：客户端业务线程处理模块；

10.一种分布式容错方法，其特征在于，该方法包括以下步骤：

11.根据权利要求10所述的方法，其特征在于，所述步骤A中，所述客户端将用户参数值通过预先设置的Invoke接口传递给预先配置的与该Invoke接口对应的服务代理；

所述步骤B中，所述服务代理提供了用于注册路由的路由接口；所述服务代理根据传递的用户参数值确定该用户的灰度状态包括：

所述服务代理通过所述路由接口接收传递的用户参数值，并判断所述用户参数值是否满足预设的灰度状态条件，如果满足，则确定所述用户的灰度状态为灰度，如果不满足，则确定所述用户的灰度状态为普通。

12.根据权利要求11所述的方法，其特征在于，所述步骤B中，所述根据服务节点发布服务时所携带的信息，将用户发送的消息路由到与所述用户具有相同灰度状态的服务节点上包括：

B1，如果通过由注册器Registry间接获取与自身相连的服务节点，则按照预设的刷新原则从所述注册器上刷新服务列表，所述服务列表中包含了服务节点的灰度状态、服务节点的提供的服务信息和服务节点的信息；所述刷新原则为：如果本地服务列表为空且距离上次更新时间大于预设时间，则同步刷新服务列表；如果距离上次刷新时间大于配置的刷新时间，则异步刷新服务列表；

B2，根据刷新的服务列表，获取与所述用户具有相同灰度状态的服务节点，将用户发送的消息路由给所述确定的1个或者多个服务节点。

13.根据权利要求11所述的方法，其特征在于，如果所述服务列表的刷新时间与服务节点灰度状态变化的时间不同步，

则所述步骤B中，当将灰度状态为普通的用户发送的消息路由到灰度状态当前更换为灰度的服务节点时，则所述服务节点产生reset响应，根据产生的reset响应重新更新本地服务列表中该服务节点的灰度状态为灰度；

当将灰度状态为灰度的用户发送的消息路由到灰度状态当前更换为普通的服务节点时，则所述服务节点正常处理所述消息。

14.根据权利要求10所述的方法，其特征在于，该方法进一步包括：服务端接收到消息后，判断该消息携带的标识信息是否和预设的需要染色的标识信息匹配，这里，标识信息可为用户号码、远程对象和接口中的至少一个；如果是，则对该消息进行处理，并打印对应的染色日志；如果在对消息的处理过程中，还需调用其他服务，则通过状态字传递染色信息，被调服务进行相应的处理，并打印对应的染色日志。