配置服务设计

 最近，因为需要，编写了一个配置服务，大致罗列一下配置服务的设计逻辑。

 

配置服务的编写目标：

  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,根据步骤返回的数据，建立对于其他服务的连接池。

通过以上步骤，使客户端监听配置服务，以及业务需要的其他服务节点信息， 通过这种方式，实现配置服务的动态扩容。