最近,因为需要,编写了一个配置服务,大致罗列一下配置服务的设计逻辑。
配置服务的编写目标:
1,实现服务部署节点的信息管理,方便动态扩容,缩容; 管理功能模块的参数,比如定时器时间,日志级别等等。
2,实现部署节点的流量切换,比如一个服务的节点需要重启,可以通过配置服务,将这个节点,下线,这样后续的请求都不会发送到这个节点。重启时,也不会丢失数据。
3, 为后续的监控服务提供数据支撑。
首先,我们的配置服务需要管理两块东西,1是应用模块的全局配置参数, 2 是做注册,发现时,使用的部署节点的信息。
1是应用模块的全局配置参数。 比如应用的日志级别,可以通过修改全局配置参数,来调整这个模块的日志级别等等。
2 部署节点的管理,这个是为了类似注册发现。不使用自动处理,而是手动处理。原因是部分应用启动之后,需要预热才能对外服务。
配置服务与客户端的逻辑:
提供两个数据协议:
1, 获取并监听服务配置,服务节点协议。
客户端启动时,发送协议, 服务端返回对应的配置数据,服务节点数据等,并在服务端内部,设置一个监听,当被监听的服务配置,服务节点信息发生变化时, 通知客户端。
2,通知协议。
服务端通知客户端,服务配置,服务节点发生变化,客户端根据通知数据,变更本地的数据信息。 通知是基于协议1的监听关系。
配置服务服务端集群逻辑:
配置服务集群需要处理两种情况。
1, 配置服务数据同步问题。 比如,在a节点上更新了数据, 通知到客户端, 需要将这个数据发布到b节点上,让b节点通知监听在b节点上的客户端。这里采用了一个同步协议,同步协议发送到对应的节点上。
2, 配置服务扩容的问题。 比如,增加配置服务节点的时候,需要让客户端感知到有新的配置服务,其他的配置服务,也需要感知有新的配置服务启动,需要同步数据时,需要同步到新的配置服务里面。 这部分逻辑是配置服务自己获取并监听自己。
配置服务启动流程如下:
1, 从数据库中,获取配置服务的节点信息。
2, 如果步骤1获取失败,启动失败,如果获取成功,通过配置服务建立socket连接连接池。
3, 在socket连接池发送“获取监听配置服务协议” ,记录协议发起的socket,并根据获取的数据,更新连接池。
如果配置服务扩容,那么通过监听,其他的配置服务可以感知到数据变化。实现集群的动态扩容。
在步骤3中,记录了发起协议的socket,当出现socket断开的情况时,如果被断开的socket是发起协议的socket,需要重新发起协议。
配置服务集群同步,通知流程。
1,在配置服务里面修改数据之后,根据启动流程建立的配置服务连接池,群发同步协议消息。
2, 此时所有的配置服务都会受到同步协议消息,根据同步协议消息,查询配置服务内部的监听,将数据通知到监听的客户端上。
对于集群同步,通知可能失败的情况,配置服务客户端,采用定时拉取数据的办法来解决这个问题。
配置服务客户端启动流程。
1, 通过一个固定的域名端口,连接一个配置服务。使用域名,是为了方便切换,当配置服务ip调整时,修改hosts映射即可。
2, 通过连接获取配置服务节点信息,并根据节点信息建立连接池。
3, 关闭步骤1的连接, 通过步骤2建立的连接池,发起“获取监听协议”。记录发起的socket。如果socket出现断开的情况,需要重新发起协议。
4,根据步骤返回的数据,建立对于其他服务的连接池。
通过以上步骤,使客户端监听配置服务,以及业务需要的其他服务节点信息, 通过这种方式,实现配置服务的动态扩容。