CN102739799A - 一种分布式应用中的分布式通讯方法 - Google Patents

Abstract

一种分布式应用中的分布式通讯方法，包括如下步骤：S1，由代理服务器将用户请求分发到内部的多个子系统；S2，串行同步调用所述多个子系统；S3,每个子系统设置多台服务器，采用并行异步调用的方式调用子系统内部的所述多台服务器；S4，当子系统的某个节点服务器宕机或压力过大时，代理服务器将用户请求动态分配到其它节点服务器；S5，子系统经过各自独立的运算后将运算结果返回给代理服务器，代理服务器再进行汇总处理并返回给外部调用方。

Description

一种分布式应用中的分布式通讯方法

技术领域

本发明属于分布式应用技术领域，尤其涉及一种分布式应用中的分布式通讯方法。

背景技术

在分布式应用中，经常会有多个子系统之间调用的需求，比如在承载大并发量的系统实现中，一般用户请求会调用到负载均衡设备，负载均衡设备再将请求分发到web服务器集群，web服务器集群再将请求分发到缓存服务器集群，如果缓存服务器集群能够命中缓存则返回结果给web服务器，否则web服务器继续将请求分发给后端的应用服务器集群。在这一系列的调用过程中，每个环节都需要进行网络通讯，并且对于通讯过程的性能、稳定性、容灾性等都有较高的要求。而现有的通讯框架往往更加关注于点对点的通讯性能，而缺少在集群应用时需要考虑的集群整体可用性。从而导致在大规模分布式系统在使用此类通讯框架时，稳定性不够高。比如容灾的策略、被调方的自动监控、恢复策略、报警策略等不够完善。(比如Mina、Netty等都缺少对集群系统高可用性的功能)。此外，现有通讯框架为了提供更高的可定制性，以适应在不同应用场景下的需求，必须通过对调用方暴露大量API，由此，导致封装性不够好，使用者往往需要关心通讯协议、连接池、线程池等通讯细节，所以配置复杂，学习成本较高（比如开源通讯框架JGroup）。

发明内容

鉴于现有技术的缺陷，本发明提供一种分布式应用中的分布式通讯方法，其特征在于包括如下步骤：

S1，由代理服务器将用户请求分发到内部的多个子系统；

S2，串行同步调用所述多个子系统；

S3,每个子系统设置多台服务器，采用并行异步调用的方式调用每个子系统内部的所述多台服务器；

S4，当子系统的某个节点服务器宕机或压力过大时，代理服务器将用户请求动态分配到其它节点服务器。

S5，子系统经过各自独立的运算后将运算结果返回给代理服务器，代理服务器再进行汇总处理并返回给外部调用方。

进一步，本发明所述的分布式应用中分布式通讯方法，其特征在于步骤S2中所述串行同步调用所述多个子系统的过程具体为：只有调用一个子系统完成或超时后，才能调用另一子系统，依次类推。

进一步，本发明所述的分布式应用中分布式通讯方法，其特征在于步骤S3中采用并行异步调用的方式调用每个子系统内部的多台服务器过程具体为：将用户请求复制多份相同请求同时向子系统集群内的多台服务器发起，并且不会阻塞等待某一台服务器返回结果，而是通过事件机制，当调用方收到被调方返回结果的事件时触发回调，当回调次数等于服务器个数或超时后，子系统集群调用结束。

进一步，本发明所述的分布式应用中分布式通讯方法，其特征在于在所述子系统内设置多组服务器，每组服务器的数量相同，并且一组服务器构成一个完整数据集，多组服务器构成多个完整数据集的冗余集合以分流并发请求。

进一步，本发明所述的分布式应用中分布式通讯方法，其特征在于步骤S5中所述当子系统的某个节点服务器宕机或压力过大时，代理服务器将用户请求动态分配到其它节点服务器具体为：代理服务器通过与子系统内的每台服务器保持通讯稳定性的校验来确定服务器的负载情况，当某台子系统服务器负载过高时,代理服务器将子系统服务器暂时从系统内摘除，并且将用户请求切换到冗余集合内的服务器；当此服务器恢复正常负载后代理服务器再将其加载回系统，以达到整体服务的容灾目的。

本发明利用其调用机制及容灾策略可以最大程度的规避在分布式系统中，高访问量导致服务不稳定的风险。可以配置多组服务以达到访问量分流的目的。对于一组服务，可以分为多个节点以达到数据分片的目的，同时起到灾备和数据冗余备份的功能。

附图说明

图1是实施本发明所述分布式应用中分布式通讯方法的系统架构图；

图2是实施本发明所述分布式应用中分布式通讯方法的子系统的架构图。

具体实施方式

为使本发明的上述目的、特征和优点更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明所述分布式应用中分布式通讯方法正是基于图1和图2所示系统架构实现了系统间一对一、一对多调用的分布式通讯。

图1是实施本发明所述分布式应用中分布式通讯方法的系统架构图；如图1所示，由多台代理服务器负责将用户请求分发到内部的各个子系统，子系统经过各自独立的运算后将运算结果返回给代理服务器，代理服务器再进行一些汇总和后期处理，将最终结果返回给外部调用方。本发明解决了代理服务器向内部子系统分发时的具体通讯细节和容错处理。调用机制为：代理服务器可以向多个子系统分发请求，每个子系统可以有多台服务器。分发请求的通讯细节将被封装在本系统中。封装的过程包含了通讯层封装、连接池封装、容灾策略封装、动态切换服务封装，以及服务配置的封装，其中重点为通讯层封装，通讯层封装基于Javanio（具体内容请参见：http://docs.oracle.com/javase/6/docs/api/java/nio/package-summary .html）实现，封装了基于事件驱动的异步Socket网络通讯，并且基于集群多播的特点（分布式系统调用时，往往需要向集群服务同时发起多份请求，等待集群服务并行处理并依次返回结果后，调用方即完成了一次调用。这种调用过程我们称之为集群多播），提供了异步多播通讯的功能。所谓异步多播，指的是java nio通讯在网络传输过程中，调用方不需要阻塞等待，所以可以利用此特性将一个集群调用的多份请求异步发送，以达到集群接收方可以几乎同时接收到调用请求，马上开始并行处理，大大提高了分布式系统的性能。在一次用户请求到代理服务器后（单个请求），代理服务器可以通过本系统，根据不同的业务调用不同的子系统集群。由于不同的子系统之间可能存在依赖关系，所以这里提供的是串行同步调用方式。也就是只有调用子系统A完成或超时后，才能调用子系统B；当调用子系统B完成或超时后，才能调用子系统C。但在调用一个子系统集群时，考虑到不同机器之间可能不存在依赖关系，所以提供并行异步调用的方式。也就是当调用子系统A集群时，将用户请求复制多份相同请求同时向子系统集群内的多台服务器发起，并且不会阻塞等待某一台服务器返回结果，而是通过事件机制，当调用方收到被调方返回结果的事件时触发回调。当回调次数等于服务器个数（或超时）后，子系统集群调用结束。这种串行、并行混合的方式为调用者提供了多种选择，可以按照不同需求选择不同的调用方式。当选择并行异步调用方式时，可以大大增强系统的性能，减少调用开销。例如，在某分布式搜索的前端web服务接收到一个用户请求后，它将先调用缓存集群（子系统A），如果缓存集群处理完毕并且没有命中缓存的情况下，才会继续调用索引集群（子系统B），而索引集群由于采用了分片索引（将索引数据分为多个节点分别存储以提高系统的总存储量），需要将多个相同请求同时发起给索引集群的所有节点以进行并行计算，当计算完毕后，调用方将集群计算结果汇总合并后，最终返回给用户。整体上来看，分布式系统在外部调用方来看是不关心内部具体的分发、容错机制的。

图2是实施本发明所述分布式应用中分布式通讯方法的子系统的架构图；图2所示子系统为子系统A的内部架构图，为了能够支持灾备切换和分流并发量，在子系统内部一般可以提供多组服务器，每组服务器的数量相同，并且一组服务器构成一个完整数据集。多组服务器构成多个完整数据集的冗余集合以分流并发请求。可以为每台服务器编号，多组同号服务器称之为一个“集群分支”，每个“集群分支”内部的每台服务器互为灾备，调用机制为：针对子系统A的一次集群调用将同时发送三次相同的调用请求到子系统A内部的三个集群分支，具体发送规则由负载均衡规则决定，其实现方式为：在每一次集群调用前取得当前集群内的所有集群分支信息，遍历每个集群分支，每次从一个集群分支中随机取得一台服务器，如果这台服务器的状态可用，则此服务器作为本次集群调用针对此集群分支的目标服务器；否则将顺序查找集群分支中的下一台服务器的状态是否可用，依此类推（如果当前集群分支中的所有服务器状态都不可用，则本次集群调用针对此集群分支将不发起请求）。当子系统A内部的三个集群分支的结果都返回或超时后，针对子系统A的一次集群调用结束。

具体到集群调用的实现，采用并行异步调用的方式调用每个子系统内部的多台服务器，其并行异步调用的通讯具体实现方式为：对于每个子系统内部的多台服务器的并行异步调用，系统采用线程池来处理请求调用，这样针对子系统A内部的多台服务器的调用将并行运行在多个线程内。具体实现采用了javaExecutor线程池模型，并且使用固定最大线程数的池以避免线程过多，同时当线程数达到最大线程数后，将线程任务放入缓冲队列暂时缓冲，当缓冲队列满后，开始泄洪策略（从队列头取出任务并抛弃），以保证系统的稳定性。对于通讯传输过程，封装了java nio的底层通讯过程，用户可以直接将通讯内容以java对象的形式传递给本系统，本系统内部进行对象的序列化编码，然后再将序列化后的byte数组转化为java nio的ByteBuffer，通过SocketChannel发送异步Socket通讯数据给集群中的某个节点服务器，随后，当java nio的Selector线程发现某节点服务器有返回数据后，通过SocketChannel可以读出ByteBuffer，再将其中的byte数组通过对象反序列化解码为java对象。当一次调用的集群中所有节点服务器都成功返回java对象后，将唤醒调用方线程继续后续工作（或者当调用方线程超过业务最大等待时间后自动唤醒，并做相应容错处理）。为了保证在通讯过程中的高性能，代理服务器与子系统的每台服务器建立一定数量的Socket长连接，并且使用连接池技术管理这些链接。对于连接池的实现，采取了活跃连接池、闲置连接池和管理线程三部分组成，当系统需要Socket连接时会去闲置连接池中检查是否有存留的闲置连接，如果有则直接取出以实现连接复用，否则创建一个新连接并放入活跃连接池然后返回此连接。当系统对某个连接使用完毕后将此连接放入闲置连接池。当闲置连接过多时，管理线程会将其回收并关闭此连接，来保证系统不会因为闲置连接过多而消耗过多系统资源。

当子系统的某个节点服务器宕机或压力过大时，代理服务器将用户请求动态分配到其它节点服务器，其具体实现方式为：代理服务器使用健康检查的方式保持与节点服务器之间通讯稳定性的校验，健康检查策略分为定时健康检查策略和基于统计的实时健康检查策略，两种策略在系统内同时运行，以确保能够自动发现被调方宕机、服务不稳定等问题。一旦发现宕机或服务不稳定，马上采取热备切换或功能降级将这些不稳定的服务器从系统中暂时摘除，并且将用户请求切换到冗余集合内的服务器。当被摘除的服务器恢复服务后，本系统可以马上发现并将此服务器重新加载回系统中。定时健康检查策略根据一定时间间隔（用户可以设置此时间间隔，不设置则使用默认值10秒）进行轮询检查，轮询到每台服务器后发送健康检查请求，根据服务器的返回来确定服务器状态是否健康。当发现某台服务器的连通失败率高于一定阀值（用户可以设置此阀值，不设置则默认向每台服务器访问10次，最高失败率为60%）时，马上将这台服务器标记为暂停服务状态，当调用方发现目标调用服务器为暂停服务状态时，将绕开此服务器，调用集群分支中的其它服务器。直到某次轮询检查发现曾经被标记为暂停状态的服务器能够成功连通后，再重新将此服务器标记为正常服务状态。之后调用方会自动恢复对此服务器的调用。基于统计的实时健康检查策略首先记录下近期（默认为最近5秒内）每台被调用服务器的调用成功、失败次数，当调用失败次数超过“失败次数阀值”（默认为100次），或调用失败率超过“失败率阀值”（默认为50%）后，都会将此台服务器标记为暂停服务状态，直到定时健康检查策略再次发现此服务器能够成功连通后，再重新将此服务器标记为正常服务状态。这里之所以需要失败次数阀值和失败比率阀值两个值来定义服务器失败，是因为在系统并发访问量较低时，失败比率容易超过“失败率阀值”，而在系统并发访问量较高时，失败次数容易超过“失败次数阀值”。这样无论在任何情况下，只要服务的稳定性较低，都能够触发健康检查机制，并马上采取自动容灾策略。当某个集群分支内的所有服务器都被标记为暂停服务状态时，默认将启用功能降级策略（可以配置为不启用）。此时所在的子系统在短暂时间内将不再请求这个集群分支内的任何服务器。这样保证了在任何情况下（超高负载、内部多台服务器异常、内网通讯异常）整体系统的可用性，避免了由于多台服务器异常导致的整体服务崩溃的状况。

进一步的，以基于统计的健康检查为例，其内部具体实现方式为：建立一个ConcurrentHashMap<Long,AtomicInteger>对象用来记录调用方近期每一秒的总调用次数，其中key为某一秒的时间戳，value为调用次数。建立一个ConcurrentHashMap<Long,FallAddressMap>对象用来记录调用方近期每一秒的失败调用信息，其中key代表某一秒的时间戳，value代表调用失败信息。调用失败信息对象内部存储了一个ConcurrentHashMap<InetSocketAddress,AtomicInteger>对象，它的key代表某个Socket地址信息，value代表某个Socket在某一秒内的失败次数。这样就可以记录下每一秒内针对所有Socket的失败次数。启动一个线程，定时清理总调用次数map中20秒前的Entry，同时清理失败调用信息map中20秒前的Entry，以避免历史记录信息过多而导致内存溢出。启动一个线程，定时取得最近5秒的总调用次数，同时取得最近5秒的调用失败信息对象。依次遍历这些调用失败信息对象中的Socket对象，如果某个Socket对象计算出来的失败次数或失败比率符合设置的阀值，则设置此服务器为暂停服务状态。并且将此失败服务器信息追加到预备报警List中去。最后遍历报警List，取出所有失败服务器信息并且发送报警事件给所有报警监听者（本系统不限制具体的报警方式，仅提供报警监听接口，调用方可以实现监听接口并注册监听。当有服务器异常事件发生时，本系统自动调用注册的所有监听者，通知相应的报警事件发生。这样监听者可以根据事件的回调信息自主选择不同的报警方式如短信报警或邮件报警等）。

这里使用两种健康检查策略的好处是，定时健康检查策略由于在每次健康检查时都需要向目标服务器发起健康检查请求，所以往往无法平衡健康检查的时效性和健康检查对系统性能造成影响这两方面的矛盾，如果定时健康检查的间隔时间较长，则健康检查时效性会较低，如果间隔较短，则健康检查对目标服务器又会造成较大负载压力。而基于统计的实时健康检查在每次请求调用开始和结束时仅仅做计数动作（记录每个Socket连接每一秒的总调用次数、失败调用次数），所以统计定时器可以以非常短的间隔（间隔在毫秒级别）不断统计内存中每个Socket的调用失败次数和调用失败率，当此比率超过设定值后马上做容灾处理。这样，以基于统计的健康检查为判断目标服务器是否需要摘除的主要手段，以定时健康检查为恢复以前已经摘除的服务器的主要手段，即保证了健康检查的时效性，又保证了健康检查对系统性能不会造成影响。

在使用者具体使用本系统时，为了解决业务系统和通讯框架之间调用的复杂性，将业务层和通讯层完全解耦，本系统设计为使用配置文件进行服务配置，运维工程师在配置文件中指定业务代号和集群服务器的调用策略之间的关系。这样业务调用方调用本通讯框架时只需要关心分配给本业务的业务代号，将业务代号和业务请求内容发送给通讯框架即可。其配置方式遵循“约定优于配置”的原则，使用者可以只提供极少的配置就可以马上使用此系统。在系统加载配置文件过程中，如果发现使用者没有提供可选配置（比如Socket连接池的池大小、定时健康检查的时间间隔、线程池的最大线程个数等），则会使用该配置的默认值作为系统参数加载（此默认值是通过大量压力测试和线上运营后找到的大并发情况下的较优值。当然，使用者也可以根据自己的业务特点、服务器状况等因素对这些参数进行调优，并定义在自己的配置文件中）。

本发明价值在于利用其调用机制及容灾策略可以最大程度的规避在分布式系统中，高访问量导致服务不稳定的风险。例如，对于某一个业务代号，可以配置多组服务以达到访问量分流的目的。对于一组服务，又可以分为多个节点以达到数据分片的目的。这样当流量增加，系统可以水平伸缩（增加多组服务器），当某组服务的某台分片服务器宕机，通过健康检查机制，其它组同分支下的分片服务器马上起到灾备和数据冗余备份的功能。

最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制；尽管参照较佳实施例对本发明进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本发明的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本发明技术方案的精神，其均应涵盖在本发明请求保护的技术方案范围当中。

Claims (5)

1.一种分布式应用中分布式通讯方法，其特征在于包括如下步骤：

S1，由代理服务器将用户请求分发到内部的多个子系统；

S2，串行同步调用所述多个子系统；

S3,每个子系统设置多台服务器，采用并行异步调用的方式调用每个子系统内部的所述多台服务器；

S4，当子系统的某个节点服务器宕机或压力过大时，代理服务器将用户请求动态分配到其它节点服务器；

S5，子系统经过各自独立的运算后将运算结果返回给代理服务器，代理服务器再进行汇总处理并返回给外部调用方。

2.根据权利要求1所述的分布式应用中分布式通讯方法，其特征在于步骤S2中所述串行同步调用所述多个子系统的过程具体为：只有调用一个子系统完成或超时后，才能调用另一子系统，依次类推。

3.根据权利要求1所述的分布式应用中分布式通讯方法，其特征在于步骤S3中采用并行异步调用的方式调用每个子系统内部的多台服务器过程具体为：将用户请求复制多份相同请求同时向子系统集群内的多台服务器发起，并且不会阻塞等待某一台服务器返回结果，而是通过事件机制，当调用方收到被调方返回结果的事件时触发回调，当回调次数等于服务器个数或超时后，子系统集群调用结束。

4.根据权利要求1或3所述的分布式应用中分布式通讯方法，其特征在于在所述子系统内设置多组服务器，每组服务器的数量相同，并且一组服务器构成一个完整数据集，多组服务器构成多个完整数据集的冗余集合以分流并发请求。

5.根据权利要求1所述的分布式应用中分布式通讯方法，其特征在于步骤S4中所述当子系统的某个节点服务器宕机或压力过大时，代理服务器将用户请求动态分配到其它节点服务器的过程具体为：代理服务器通过与子系统内的每台服务器保持通讯稳定性的校验来确定服务器的负载情况，当某台子系统服务器负载过高时，代理服务器将子系统服务器暂时从系统内摘除，并且将用户请求切换到冗余集合内的服务器；当此服务器恢复正常负载后代理服务器再将其加载回系统，以达到整体服务的容灾目的。

Images