CN114363350B - 一种服务治理***及方法 - Google Patents

Abstract

本发明公开了一种服务治理***和服务治理方法，所述***包括服务端模块、客户端模块和监控告警模块，服务端模块包括多个由一个主节点和其管理的多个从节点组成的机器组，在主节点中通过选举模块确定一个控制节点，控制节点优先接收客户端的服务请求；选举模块中主节点在未收到来自其他主节点的投票结果前，将票投给自己，否则按照已收到的投票结果投出相同的票；数据注册表通过数据分片存储在不同的主节点上，主节点将数据分片信息通过同步模块发送至从节点，当超过半数的从节点接收到数据分片信息并返回确认字符即可将数据信息保存至本地；本发明克服了单节点存放数据表过于庞大的问题，读写性能强，提升***的稳定性，保证***高可用。

Description

一种服务治理***及方法

技术领域

本发明涉及一种服务治理***及方法。

背景技术

在互联网的时代中，随着业务***越来越复杂，单体***会越来臃肿，相关的代码会不停的堆砌在单体架构上面，这时就需要将单体服务进行拆分，拆分后又造成新的问题，如何能够将这些服务进行集中式的管理，对这些服务之间如何能感知到其他服务的存在，因此需要一个服务治理***综合来对这些服务进行集中式的管理。

目前服务治理***主要对服务发现的时效性较差，一般在几秒钟或几分钟之内才能发现一个服务，或者感知到一个服务的下线；如果通过配置将服务发现的时间缩短，这时就会造成很大的网络瓶颈的开销，由于目前的服务治理***采用的对等的架构，每台服务器需要承载大量的请求；同时节点之间需要将注册表进行复制，数据的一致性较差，只能达到最终一致性，一般需要几十秒甚至一分钟才能完成数据同步。

另外，目前也有服务治理***采用反向推送的方式来进行具体的实现，每个服务实例都监听特定服务目录，一旦有服务上线或者下线就会将服务注册表变动反向推送给几百个或者上千个服务实例，若机器频繁上下线，服务治理***将信息进行广播时，会对网卡造成较高负载，使***稳定性变差。

发明内容

发明目的：本发明的目的是提供一种高时效、高可用的服务治理***及方法，能针对服务进行集中式的发现与管理，降低资源消耗，提升***健壮性，消除单点故障。

技术方案：本发明所述的一种服务治理***包括：

服务端模块，包括多个由一个主节点和其管理的多个从节点组成的机器组，在主节点中通过选举模块确定一个控制节点，控制节点优先接收客户端的服务请求；所述选举模块中每个主节点在未收到来自其他主节点的投票结果前，将票投给自己，否则将按照已收到的投票结果投出相同的票；得票数超过主节点总数一半的主节点为控制节点；

客户端模块，用于向服务端模块进行服务注册和服务发现；

监控模块，用于监控机器的心跳请求和运行状态，当状态值超过阈值范围时发出告警通知。

所述选举模块中，第一轮投票时每个主节点将票投给自己，然后每个主节点会随机休眠一段时间，优先苏醒的主节点将票投给自己，并将投票结果通知其他主节点，其他主节点苏醒后按照已收到的投票结果投出相同的票。

进一步地，数据注册表通过数据分片存储在不同的主节点上，主节点将数据分片信息通过同步模块发送至从节点中进行数据存放；所述同步模块中，主节点向从节点发送数据分片信息和提交请求，主节点在一定时间内，只要接收到超过半数的从节点返回的确认字符，就将请求标记为已提交并发送给从节点，从节点将数据分片信息保存至本地；否则主节点重新发送数据分片信息和提交请求。

进一步地，***启动时，通过命令行参数或配置文件确定节点为主节点或从节点；***运行时，主节点每秒向从节点发送心跳请求，若从节点一定时间内未接收到心跳请求，则从节点充当主节点；若只有1个从节点，则该从节点充当主节点；若有多个从节点，则选择已同步的数据分片信息时间戳最新的从节点充当主节点，若时间戳一致，则选择编号最大的从节点充当主节点。

所述客户端模块向服务端模块进行服务注册时，先随机连接一个主节点询问控制节点的访问地址，然后连接控制节点，控制节点根据服务名称进行哈希计算，将该服务分片到指定的机器组中。

所述服务分片到指定机器组中的主节点，主节点先将服务操作进行预写日志，一定时间后将主节点中的内存数据写为数据快照存入磁盘；重启恢复时，使用数据快照和预写日志恢复注册表信息。

所述监控模块监控所述***的心跳请求，若服务端模块一定时间内没有接收到客户端模块所在服务发送的心跳请求，则服务端模块将该服务从注册表中摘除；若主节点管理的从节点中，一定数量的从节点均无法接收到心跳请求，则监控模块对心跳频率进行计算判断是否为主节点故障，若主节点故障则重新选举主节点；若主节点和控制节点之间心跳丢失，则触发选举模块重新确定控制节点。

所述主节点先与比自己编号小的主节点建立连接，然后连接与自己相关联的从节点。当所有的主从节点启动并建立完成之后，从主节点中选举出来控制节点。

本发明所述的一种服务治理方法，包括如下步骤：

(1)客户端连接服务端的控制节点，根据服务名称进行哈希计算并分配到指定主节点，客户端与该主节点连接并向其发送服务信息；所述控制节点通过在主节点中选举得到，一个主节点或控制节点连接多个从节点构成机器组，所述服务端包括多个机器组；

(2)主节点将服务信息写日志文件，构建内存注册表，令本地读写缓存失效；

(3)从节点定期向主节点拉取注册信息表；当超过一半的从节点接收到注册表信息并向主节点返回确认字符，主节点向从节点发送确认提交请求；

(4)后台线程定期检测读写缓存是否失效，若失效则从内存拉取注册表存入读写缓存和读缓存；

(5)客户端服务从主节点拉取所依赖服务地址进行本地访问。

有益效果：本发明与现有技术相比的优点在于：(1)节点负载小，通过将注册信息表进行数据分片，存放在不同的主节点，只需向从节点同步少量的数据分片，克服了单节点存放数据表过于庞大的问题；(2)读写性能强，采用了两阶段提交和过半数确认的方式进行数据同步，既保证了数据的一致性，也保证了写入性能，极大了提高的写的效率；(3)网络负载低，在注册表中设置并发安全的哈希表、只读哈希Map和读写哈希Map的多级缓存机制，客户端只订阅自己所关心的服务，在服务注册和上下线时，只需推送少量的配置信息，无需拉取全量注册表信息，时效性高，极大的降低了网络负载；(4)***稳定性强，通过投票选举的方式确定控制节点，保证了选举的随机性，每一个主节点都有可能充当控制节点，整体提升的***的稳定性；(5)***高可用，通过心跳机制，保证节点出现宕机时，由其他节点快速接替当前节点充当该宕机节点的角色，整体保证整个服务治理***的稳定性；在进行服务注册和服务发现时，将每个节点的上下线、心跳的信息形成预写日志，并通过冗余校验和的方式防止文件被篡改，定时将注册表导出成镜像文件进行保存，极大的提高了内存注册表的恢复效率；

附图说明

图1为本发明的服务治理***架构图；

图2为本发明的服务端建立和启动流程图；

图3为本发明的客户端上线流程图；

图4为本发明的主节点宕机处理流程图

图5为本发明的控制节点宕机处理流程图。

具体实施方式

下面结合附图对本发明的技术方案作进一步说明。

如图1所示，本发明所述的服务治理***包括服务端模块、客户端模块和监控模块；服务端模块，开放接口让需要管理的服务进行注册，针对服务的上线和下线进行集中式的管理，并让其他服务也能感知到其他服务的上线与下线行为；客户端模块，让需要进行管理的服务进行集成，方便向服务端进行注册，也可以感知到相应其他服务的变动，如上线或者下线；监控模块，会定时采集服务治理***机器本身的cpu，磁盘，内存等信息。当服务治理***本身所在机器出现比较大的负载的时候，或者异常宕机的时候，会针对性的提出告警。

(一)服务端模块服务设计：

由于整个服务治理***是分布式架构的，所以由多个机器节点共同构成了这个分布式治理***。

(a)角色及组划分

本发明所述***的服务端模块包括主节点、从节点和控制节点三类角色。

主节点主要负责处理客户端服务的读写请求，而从节点主要是主节点的冗余备份，当主节点出现宕机的时候，从节点可以快速的充当主节点。控制节点是从多个主节点中选举出来的，在多个主节点中，通过分布式一致性协议选举出来控制节点，该节点接收其他主节点的服务注册请求，当客户端需要进行服务注册和服务发现的时候，优先访问控制节点。控制节点会告知客户端服务它所需要的服务的数据分片的位置，在哪个特定的节点中；控制节点会优先初始化10240个数据分片，然后根据节点中的主节点的数量，进行平均分配。类似于节点1负责1-2048号分片，节点2负责2049-4096号分片，节点3负责4097-6144号分片，节点4负责6145-8192号分片，节点5负责8193-10240号分片。

(b)选举模块

节点之间的角色可以转化，控制节点通过选举模块来确定。主节点优先由配置文件指定，当主节点启动的时候，首先会多个主节点中选出一个控制节点，在选举的过程中会发起投票，首先第一轮将选票优先投给自己，表明自己希望成为控制节点，然后再将选票投递给其他节点，假设有三台机器A，B，C，那么第一轮投票结束之后，每个节点收到的选票分别为A(1张)，B(1张)，C(1张)。由于大家得到的票数是一样多的，这时就需要发起第二轮的投票，在进行第二轮投票之前，每个节点会随机休眠一段时间，优先苏醒的节点还是会将选票投递给自己，假设这时是机器B优先苏醒过来，这时将投票信息投递给B之后，还会将投票信息投递给机器A和机器C，之后，当机器A苏醒过来之后，发现已经收到机器B的投给自己的票了，那么就不会把票投递给自己了，而是直接将选票投给B，并将该选票也投给其他节点，同理当机器C苏醒之后，也发现有节点将选票投给B了，那么这时C就不会将选票投给自己了，而是直接将选票投递给了B。第二轮投递完成之后，大家会进行各自统计算票，A节点接收到了B节点和C节点的2票都是投给B，而B节点接收到了A节点和C节点的2票投给B，C节点接收到了A节点和B节点的2票投票投给B。这时大多数节点(大多数节点的定义是，如果是3个节点，大多数就是2个节点，如果是5个节点，大多数节点就是3个节点)都是将选票投给B，这时B节点就会充当控制节点。

主节点和从节点之间身份的确定通过以下方式来完成。首先，主节点和从节点启动的时候，优先是通过命令行参数或者配置文件来指定当前节点的角色。在运行的过程中，主节点会定时每秒钟的向从节点发送心跳，如果从节点超过5秒中都没有收到主节点的心跳请求，这时从节点会认为主节点可能已经宕机了。这时就需要从节点来接管主节点，成为新的主节点，如果只有1个从节点的话，那么就不需要进行重新选举了，直接从节点就可以充当主节点。如果有多个从节点，判断当前从节点已经同步的注册表的数据的时间戳是否是最新的，如果是最新的，那么当前的从节点就可以充当主节点。如果所有的从节点从主节点接收到的数据时间戳一致，那么就会选择编号最大的那个节点作为主节点。一旦选举出来新的主节点之后，也会向之前已经选举好的控制节点进行注册。控制节点在运行过程中，由于内存溢出，或者机器的原因，导致该节点宕机了，这时也会触发再次选举。由于控制节点本身也是主节点。主节点之间每秒钟发送心跳请求，当超过5秒钟之后，控制节点和其他的主节点之间无法监听到心跳请求之后，就会触发控制节点进行重新选举。选举的整个过程是基于剩下的主节点完成。在控制节点没有选举出来之前，客户端也无法感知到其他服务所在的位置信息，所以重新选举的过程中，整个服务治理***会有一个短暂的无法提供服务。整个选举过程和之前启动的时候类似，通过投票和归票的方式进行式选举。一旦控制节点选举出来之后，其他的主节点就会向该控制节点进行注册，之后恢复的主节点也会向这个新的控制节点进行注册。

(c)数据分片及机器组

一台主节点和多台从节点，共同构成一个机器组。对外提供服务的时候，可以从中随机挑选出来一台提供服务，主节点提供读写服务，而从节点只提供读服务。如果有相应的写请求到发送从节点，这个时候，从节点会将该请求转发给主节点进行处理。为了让注册表相关的服务信息全部分散在不同的机器上面，采用数据分片的设计，一般注册中心横向扩展一般不会超过100台，设计10240个分片进行存放，本实施例中服务治理***有15台机器，每三台机器构成一主两从，一共是5个机器组，那么每个机器组会负责大概200个分片左右，整体数据分片的数据量是不可变的，一旦设定就不可变更。每台进行服务注册的机器按照服务名称(ServiceB)，进行哈希计算，路由到特定的数据分片上面，该特定的数据分片绑定了一台特定的服务治理***所在的机器，而服务实例的注册信息全部都注册到那个特定数据分片上去。数据分片首先存放在主节点上，由主节点将数据分片信息同步给从节点中进行数据存放。如果存放某台服务ServiceC部署了多台，而又有很多客户端服务依赖ServiceC，可能会导致大量的连接请求连向服务治理中的特定机器组，这时容易发生热点key等问题。这时，可以通过增加从节点，分散连接请求，从而解决热点key以及数据倾斜等相关问题。

当主节点存放服务注册表的数据分片之后，主节点需要将数据分片中的数据同步给从节点。整个同步的过程底层采用的是两阶段提交加过半数确认的方式。首先，主节点接收到客户端服务发送的服务注册请求，将服务信息保存到本地，然后主节点将这个待提交的请求发送给各个从节点，作为第一个阶段；各个从节点接收到待提交的请求之后，会返回ack(Acknowledge character，确认字符)给主节点，如果主节点收到超过半数的从节点的ack之后，就会进入到下一个阶段中，此时主节点会将该请求标记为已提交，并将已提交的请求发送给各个的从节点，让它们也对消息进行提交，这个过程中只要主节点一旦提交了消息，那么客户端服务就能感知到特定服务上线的消息了。待从节点也进行消息提交之后，从节点上也可以获取到最新的注册表数据分片信息了。

(d)重平衡设计

重平衡主要体现在两个方面，第一个方面主要是在服务治理***需要进行增容或者缩容的时候，原先的服务治理中心无法承载海量服务的注册与发现的时候，这时就需要增容，对应的就是扩建机器，将新的机器加到整个服务治理中心集群中，如果整体的机器资源出现了富余，这时就需要进行缩减，下线指定的机器。一旦上线或者线下特定的机器，这时，数据分片就需要进行迁移。内部会对服务名称进行重新的哈希计算，将需要迁移的数据分片迁移到指定的机器上面去。待重平衡完成之后，会对整体的存储进行重新的负载均衡。完成数据重平衡之后，还有一部分需要进行重平衡的是请求的重平衡以及长连接的重平衡。每当有新的服务开始注册的时候，会找到指定的主节点建立长连接，当有新的节点加入了，这时由于数据分片可能就不会存放在这个节点了，长连接也需要重新进行切换，其中从节点承担了服务发现的一部分职责，但数据分片发生迁移之后，相应的长连接也需要断开，和新的机器组中的机器建立连接。数据分片迁移完成之后，会反向推送给与该服务治理的机器，让其主动断开连接，去连接指定的新机器。

(e)注册表设计

首先注册表中利用数据分片将注册表信息平均分散在数据分片中存储，每个机器组中的主节点和从节点都会负责一部分数据分片，每个机器中的注册表采用的并发安全的哈希Map来实现。并且其中主要采用了多级缓存来进行处理，其中主要分为最原始的并发安全的哈希表(内存注册信息表)，只提供读缓存的哈希Map和读写缓存的哈希Map。整个处理流程是，首先从只读缓存Map中读取数据，如果没有读取到数据，就从读写Map中读取数据，如果都没有读取到数据，就从核心的哈希表中读取数据(内存注册信息表)。如果新的服务注册上来了，让核心的哈希Map(内存注册信息表)出现了变更，这时，需要进行的操作就是将读写缓存Map进行过期并清空，后台会有一个线程定时去比对只读缓存和读写缓存中的信息表中的信息是否一致，如果不一致的话，那么只读缓存就会被清空，那么下一次就要从核心注册表中进行重新加载了。通过这种方式的设计，大大的减少了锁竞争，提升了并发访问的能力，大幅提高的访问效率。

整个注册表是需要提供给客户端服务进行使用，客户端需要通过注册表知道他所依赖的服务有哪几台，这些服务中具体的ip地址和端口是什么，这样在客户端服务才能对这些服务所在的机器发起请求，请求相关服务。传统获取注册表的方式是采用的是拉的方式，就是每隔一段时间一般是30秒或者一分钟，去服务治理***中拉取注册表。一般拉取的策略是，第一次是全量拉取，而后面采用的是增量拉取。但是这个会有一个问题，就是服务C只关心服务A，但是它要将所有其它服务的变动都要拉取下来(服务E，服务F发生了上下线)，这个无形会增大很多网络负载。目前，采用的方式是利用客户端服务只订阅自己所关心的服务，在集成客户端的服务进行启动的时候，首先需要告知当前服务所依赖的服务有哪些，针对他们需要的调用的服务，直接发送订阅请求。比如服务C需要知道服务A的相关机器及地址信息，那么服务C启动之后，先会随机找到一台机器，向其询问控制节点是哪个，然后请求控制节点，通过控制节点获取服务A的数据分片是在哪台机器上面的，这时相当于服务C直接订阅特定的服务A，服务C可以和服务治理***的中某个机器组中的一台机器(包含服务A数据分片的节点)建立一个长连接即可，这时如果出现服务的上线和下线，只需要推送少量的配置信息即可，而不需要拉取全量注册表信息，时效性会非常的高。极大的降低了网络负载。

(f)高可用设计

整个服务治理***采用的是分布式架构，其本身有多个机器组，每个机器组中存储了部分数据分片，而每个机器组中又通过一主多从的方式组织在一起的。每个机器组的内部本身保证了高可用。其内部可以通过从节点的冗余实现相应的冗余备份。当主节点宕机的时候，在从节点中选择接受数据最新的节点作为主节点，如果接收的数据分片相同，数据分片之间不存在差异，那么就需要选择编号最大的那个机器作为主节点。主节点和从节点的中注册表的分片信息并不是只存放在内存中的，如果只存放在内存中，如果机器出现了主节点或者从节点出现了宕机，那么就有可能造成数据的丢失。所以，当有新的机器发起注册的时候，优先是先进行预写日志，在文件中记录了每个服务的注册，心跳，下线等操作。一段时间之后，会将主节点中的内存数据写一个数据快照，将其全部写到磁盘文件中去。后期重启恢复的时候，优先使用数据快照进行恢复，然后在根据时间戳记，结合预写日志并采用前滚的策略，恢复得到最新的注册表信息，任何一个写入磁盘的快照文件或者预先日志文件都会通过crc32生成校验和，防止数据文件被强行篡改。

当整个服务治理***中的控制节点出现宕机时，通过从剩下的主节点中，通过分布式一致性协议选举出来一个新的节点充当控制节点。管理整个集群中的所有数据分片的分步。客户端通过控制节点知道所属的分片在哪个节点，这样可以通过请求的路由将消息转发到指定的节点中去。

(二)客户端服务设计：

任何一个服务需要对外提供服务的时候，都是需要集成服务治理客户端，利用客户端可以实现服务注册及服务发现等功能。客户端所在服务启动的时候，会利用客户端向服务治理***进行注册。客户端会从集群中随机找一台主机器进行询问，查看当前节点是不是控制节点，由于主节点内部是知道当前控制节点的地址，当前节点会告知客户端，控制节点的访问地址，客户端会向控制节点发送连接请求，当客户端连接上控制节点之后，控制节点会根据服务名称进行哈希计算，将该服务的相关信息，分片到指定的机器组中。由指定的机器组来负责该数据分片的。完成服务注册之后，相当于在整个服务治理***上面进行了登记。那么其他的服务如果需要对其进行远程调用，就可以通过服务治理***的控制节点，从具体的数据分片中，获取到其调用路径。当前客户端启动的时候，其本身也会依赖一些其他服务，这时，客户端所在服务启动成功之后，就会进行相应的服务发现操作。通过控制节点，找到该服务所依赖的那些服务所在的数据分片在哪些机器组中，这时，当前服务会利用客户端向这些分片所在的机器组中发起长连接，获取依赖服务的具体地址。当业务执行流程在执行的过程中，需要这些服务时，就可以采用特定的访问策略向指定的服务发起请求。其访问的方式可以采用轮询访问的方式，或者随机访问的方式，哈希访问的方式进行访问。极大程度将请求平均分配到各个服务节点。

(三)监控模块设计：

整个监控模块会监控整个服务治理***集群的运行状况，对于心跳的监控包括三个方面：

第一方面，客户端所在服务通过客户端，会定时向服务端发送心跳请求，服务端也会根据心跳知道当前服务是否存活，如果某台服务的客户端超过了5秒仍然没有给服务端发送心跳，当前服务有可能宕机了。这时，服务端就会将其从注册表中进行摘除。但是如果在某个时间，主节点发现他所管理的机器百分之90的机器都无法接收到心跳了，很有可能是自己本身机器出现了问题。监控模块会对心跳的频率数进行智能的计算，并根据计算结果进行综合的反馈，如果出现上述问题，可能是主节点本身出现了问题，这时立即触发主节点的重新选举，并使当前的主节点暂停对外提供服务。等待选举出来新的节点之后，再对外提供服务。

第二方面，主节点和从节点之间也会通过心跳保持连接，如果主节点在5秒中内收不到从节点的心跳，这时就会将从节点进行摘除，如果从节点收不到主节点的心跳，这时就会触发，主节点的重新选举。

第三方面，如果主节点和控制节点之间的心跳出现了丢失，下面监控模块就会触发控制节点的重新选举。

监控模块会实时的采集整个服务治理***集群的整体状态，根据其中的机器负载状态，当前的cpu的使用率，磁盘读写速度，网络流量速度，整个服务治理***中gc的频率，每次full gc所花费的时间。当其中某台机器超过之前设定的告警阈值时，就会发出告警通知，相关运维人员可以根据告警内容进行***参数的优化或者硬件本身问题的排查。

本发明所述的服务治理方法包括如下内容：

根据现场的环境，按照要求对服务端的文件进行配置操作。配置完成之后，启动服务端，整个服务治理***是由多台机器组成，他们内部有多个机器组构成。依次启动各个机器组，启动完成之后。首先主节点会主动去连接比自己编号小的机器，将所有的主节点的机器都连接完成之后，主节点之间会发起一轮投票选举，第一轮默认都是投给自己的，每一轮结束之后，会进行计算自己所拿到的投票。如果，机器中的大多数节点都是投递给某个节点的话，那么他就是控制节点，如果当前这一轮，主节点中间并没有节点获取到大多数节点的投票，这个时候节点会随机休眠一段时间，然后立即进行下一轮的投票。经过多轮投票之后，会有一个节点得到大多数节点的投票，该节点当选为控制节点。控制节点选举出来之后，所有的主节点都会向控制节点进行注册，控制节点会根据当前节点的数量，将10240个数据分片进行切分，平均分配到这些主节点当中，让这些主节点负责10240个数据分片中的一部分分片。主节点和控制节点一直都有心跳，维护两者之间的连接。在选举控制节点期间，从节点会默认向配置的主节点发起连接。从节点定时和主节点同步数据分片及心跳的信息。

某个应用服务集成了客户端之后，当应用服务启动的时候，客户端服务就会向服务治理服务端发起服务注册请求。客户端会随机挑选一台服务器，询问其控制节点，主节点会将客户端服务的请求转发给控制节点。控制节点接收到请求之后，根据客户端所在的服务名称进行哈希计算，找到指定负责存储的数据分片的主节点，并将该主节点的地址告诉客户端，客户端知道该主节点的地址之后，会再次向主节点所在的机器组发起连接，该机器组中的主节点会将该客户端服务相关基本信息写入到自己负责管理的数据分片中。在写入数据分片时，优先先写预写日志，之后再将预写日志写到磁盘上去。5秒钟后，机器组中的从节点会拉取预写日志等信息，对数据分片信息进行同步。

当客户端服务完成服务注册之后，客户端服务在访问控制节点的时候，同时会从控制节点中获取相应的它所依赖的服务的主节点信息。客户端会向所依赖的服务的机器组中发起请求，机器组中会随机分配一台机器处理请求，可能是主节点，也可能是从节点。客户端服务与该服务建立长连接。客户端服务相当于只是订阅了他需要进行调用的服务，当这个服务上线，下线的时候，依赖服务中的节点会及时通知到客户端服务。其内部延迟很低，时效性很高。客户端服务定时同步其依赖服务的注册表信息。当需要进行访问时，可以根据不同的访问策略进行访问。

具体地服务端建立和启动流程、客户端上线流程和异常处理服务流程如下。

(1)如图2所示为服务端建立和启动流程，包括如下步骤

(1.1)加载配置文件，解析配置文件中的各个参数。

(1.2)启动监听线程，监听编号比自己大的主节点来与自己建立连接，主节点会主动连接比自己编号小的主节点。等待所有的主节点都建立好连接。

(1.3)所有的主节点完成连接建立之后，会启动监听线程等待与自己相关联的从节点，从节点的数量可能是一个，也可能是多个。等待从节点和主节点完成连接的建立。

(1.4)当所有的主从节点启动并建立完成之后，从主节点中选举出来控制节点。

(1.5)控制节点通过投票的方式进行选举，中间可能需要多轮投票。每次如果没有接收到其他节点的投票的话，优先投递给自己，如果接收到其他节点的投票，默认下一轮投票直接投给在休息时接收到第一张选票的机器。一轮投票结束之后，每个节点会查看自己收到的投票，并进行投票分类合计，如果某台机器被大多数节点都选中了，那么他就是控制节点，如果一轮没有被选中，经过几轮投票之后，就可以从主节点中选举出控制节点。

(1.6)控制节点一旦选举出来，所有主节点需要主动和控制节点建立连接。

(1.7)如果是首次启动，控制节点会进行数据分片策略的制定，假设有5台主节点，那么将10240个分片分配到这5台机器上。每台机器负责2048个分片。如果不是首次启动，主节点在启动的时候，会优先加载本地磁盘的数据分片的快照文件以及根据预先日志中的内容，在内存表中恢复出一份完整的数据分片的数据。由于主节点已经知道了控制节点所在的位置，这时需要发送数据请求给控制节点，将分片数据的分布发送给控制节点。控制节点接收到请求之后，在自己的内存中重新构建数据分片与主节点之间的分步及映射关系。

(1.8)完成上述流程之后，主节点和控制节点之间，每隔1秒会发送心跳请求。同一个机器组内主节点和从节点，也会每隔一秒发送心跳请求。

(2)如图3所示为客户端上线流程，包括如下步骤

整体的客户端服务上线主要分为两个部分，一是服务注册，二是服务发现。

(2.1)需要向服务治理***注册的服务，先集成引入客户端。服务治理客户端会随着服务一起启动。

(2.2)客户端在启动的过程中会从配置文件中读取到所有主节点的地址，然后从主节点中随机选择一个节点进行连接。

(2.3)连接成功之后，查看该节点是否是控制节点，如果不是控制节点，可以从该主节点获取到控制节点的相关信息。然后向控制节点发起连接。

(2.4)客户端和控制节点建立连接之后，客户端会尝试从控制节点中获取到数据分片的相关数据信息。控制节点会根据当前需要注册的服务名称进行哈希运算。分配指定的主节点进行处理。

(2.5)客户端服务得到控制节点的相关信息反馈之后，就会向该主节点发起连接请求。当和该主节点连接建立完成之后，客户端会将自己相关的服务信息发送给特定的主节点。

(2.6)主节点接收到相关的信息之后，将服务信息优先写入到预写日志的文件中去，构建新的内存注册表，并让本地的读写缓存失效，保证数据的一致性。

(2.7)从节点会每隔5秒中，会从主节点中拉取最新的注册表信息，并进行预写日志的同步，通过预写日志，让从节点的注册表信息和主节点保持一致。

(2.8)每隔30秒，后台线程会检查读写缓存是否失效了，如果失效了，会直接从内存中加载一份最新的注册表信息进入读写缓存，并利用读写缓存中的数据覆盖原来读缓存中的数据。

(2.9)完成服务注册之后，客户端服务可以从控制节点中获取到它所需要调用的服务所在的数据分片的主节点地址。客户端会向该服务节点发起连接，并建立长连接操作，其建立连接的方式是可以同主节点建立连接，也可以和从节点建立连接。

(2.10)连接一旦建立，客户端服务就可以从该节点上拉取到所依赖服务地址，结合本地访问的策略，进行轮询或者哈希的方式进行访问，如果所依赖的服务，进行了上线或者下线，它所连接的主节点或者从节点，可以直接反向推送通知他。只推送特定服务，整个集群的负载会很低。

(3)主节点异常和控制节点异常的处理服务流程包括如下步骤

(3.1)如图4所示，主节点(非控制节点)宕机的异常处理服务流程如下

(3.1.1)机器组中的从节点和主节点之间，每隔一秒会有心跳交互。如果双方超过5秒，没有接收到双方的心跳。这时主节点会主动下线。并由剩下的从节点中选举出来一个作为主节点。

(3.1.2)比较从节点中所拉取的注册表中最新的时间戳记，如果当前节点的时间戳记是所有的从节点中最新的，那么当前从节点就会当选为主节点，如果某些从节点中的时间戳记是一样的。那么选择编号最大的那个从节点为主节点。

(3.1.3)还有一种情况，也会触发主从节点的切换，从节点能够接收到主节点的心跳，但是主节点并不能接收到从节点的心跳信息。可能是，当单方向的网络故障。之后主节点会主动拒绝服务，并尝试让从节点发起主从切换行为。

(3.1.4)切换完成之后，原来的主节点会以从节点的身份加入到机器组中去。

(3.2)如图5所示，主节点(控制节点)宕机的异常处理服务流程如下

(3.2.1)控制节点和其他相关的主节点会定时的进行心跳通信，如果5秒中内，主节点感知不到控制节点的心跳，可能控制节点出现了宕机。

(3.2.2)这时主节点会联合其他的主节点一起发起选取新控制节点的操作。再次进行多轮投票，归票阶段，得票最多的那个节点，当选为控制节点。

(3.2.3)控制节点选举出来之后，其他所有的主节点会向控制节点进行注册。

Claims (6)

1.一种服务治理***，其特征在于，包括：

服务端模块，包括多个由一个主节点和其管理的多个从节点组成的机器组，在主节点中通过选举模块确定一个控制节点，控制节点优先接收客户端的服务请求；所述选举模块中每个主节点在未收到来自其他主节点的投票结果前，将票投给自己，否则将按照已收到的投票结果投出相同的票；得票数超过主节点总数一半的主节点为控制节点；

客户端模块，用于向服务端模块进行服务注册和服务发现；

监控模块，用于监控机器的心跳请求和运行状态，当状态值超过阈值范围时发出告警通知；

数据注册表通过数据分片存储在不同的主节点上，主节点将数据分片信息通过同步模块发送至从节点中进行数据存放；所述同步模块中，主节点向从节点发送数据分片信息和提交请求，主节点在一定时间内，只要接收到超过半数的从节点返回的确认字符，就将请求标记为已提交并发送给从节点，从节点将数据分片信息保存至本地；否则主节点重新发送数据分片信息和提交请求；

***启动时，通过命令行参数或配置文件确定节点为主节点或从节点；***运行时，主节点每秒向从节点发送心跳请求，若从节点一定时间内未接收到心跳请求，则从节点充当主节点；若只有1个从节点，则该从节点充当主节点；若有多个从节点，则选择已同步的数据分片信息时间戳最新的从节点充当主节点，若时间戳一致，则选择编号最大的从节点充当主节点；

所述客户端模块向服务端模块进行服务注册时，先随机连接一个主节点询问控制节点的访问地址，然后连接控制节点，控制节点根据服务名称进行哈希计算，将该服务分片到指定的机器组中。

2.根据权利要求1所述的服务治理***，其特征在于，所述选举模块中，第一轮投票时每个主节点将票投给自己，然后每个主节点会随机休眠一段时间，优先苏醒的主节点将票投给自己，并将投票结果通知其他主节点，其他主节点苏醒后按照已收到的投票结果投出相同的票。

3.根据权利要求1所述的服务治理***，其特征在于，所述服务分片到指定机器组中的主节点，主节点先将服务操作进行预写日志，一定时间后将主节点中的内存数据写为数据快照存入磁盘；重启恢复时，使用数据快照和预写日志恢复注册表信息。

4.根据权利要求1所述的服务治理***，其特征在于，所述监控模块监控所述***的心跳请求，若服务端模块一定时间内没有接收到客户端模块所在服务发送的心跳请求，则服务端模块将该服务从注册表中摘除；若主节点管理的从节点中，一定数量的从节点均无法接收到心跳请求，则监控模块对心跳频率进行计算判断是否为主节点故障，若主节点故障则重新选举主节点；若主节点和控制节点之间心跳丢失，则触发选举模块重新确定控制节点。

5.根据权利要求1所述的服务治理***，其特征在于，所述主节点先与比自己编号小的主节点建立连接，然后连接与自己相关联的从节点。

6.一种服务治理方法，其特征在于，包括如下步骤：

(1)客户端先随机连接一个服务端的主节点询问控制节点的访问地址，然后连接服务端的控制节点，控制节点根据服务名称进行哈希计算并分配到指定主节点，客户端与该主节点连接并向其发送服务信息；所述控制节点通过在主节点中选举得到，一个主节点或控制节点连接多个从节点构成机器组，所述服务端包括多个机器组；

通过命令行参数或配置文件确定节点为主节点或从节点；主节点每秒向从节点发送心跳请求，若从节点一定时间内未接收到心跳请求，则从节点充当主节点；若只有1个从节点，则该从节点充当主节点；若有多个从节点，则选择已同步的数据分片信息时间戳最新的从节点充当主节点，若时间戳一致，则选择编号最大的从节点充当主节点；

(2)主节点将服务信息写日志文件，构建内存注册表，令本地读写缓存失效；

(3)从节点定期向主节点拉取注册信息表；当超过一半的从节点接收到注册表信息并向主节点返回确认字符，主节点向从节点发送确认提交请求；

注册表通过数据分片存储在不同的主节点上，主节点将数据分片信息发送至从节点中进行数据存放，主节点向从节点发送数据分片信息和提交请求，主节点在一定时间内，只要接收到超过半数的从节点返回的确认字符，就将请求标记为已提交并发送给从节点，从节点将数据分片信息保存至本地；否则主节点重新发送数据分片信息和提交请求；

(4)后台线程定期检测读写缓存是否失效，若失效则从内存拉取注册表存入读写缓存和读缓存；

(5)客户端服务从主节点拉取所依赖服务地址进行本地访问。