工作总结(2022)–服务器列表更新

后端领域会遇到需要动态的注册新服务器、替换旧的服务器、删除新服务器,这种情况下都需要更新服务器的列表。就拿我之前所在的游戏行业来说，项目刚上线测试可能并不会一次性去开很多的服务器。因为游戏不真的测过，我们并不会知道游戏的火爆程度。如果开的太多，成本上是一种浪费。所以会有先开个几台，看看情况，情况好的话就再另外加服务器。

但是服务器与服务器之间有时候并不是完全的架构/业务层面上的隔离。架构层面指无法从架构上无成本的将一个服务器割裂出去，比如服务器群中会有一个leader领导其余的服务器，业务层面指服务器的业务可能会涉及跨服务器这种情况比如游戏中的跨服玩法/活动。所以根据我的经验服务器列表更新需要从这两个层面去考虑。并不能片面的从业务/架构单方面去考虑这个问题。

服务器列表更新策略

首先，我们需要知道动态的注册/替换/删除可一采取那些策略

leader控制

一般服务器架构中会有一台服务器承担着管理其余服务器的职能，这一台服务器就叫做leader。也可以理解为，其余服务器会与某台服务器建立链接形成一种星型拓扑结构, 中间的服务器就是leader。

这种架构下，一般是由leader去检测服务器列表更新，然后将新的服务器列表广播出去。比如有新服务器注册的时候，新服启动自动向leader上报，leader更新服务器列表然后广播。

控制台控制

有些后端程序会预留一个控制台端口，这样方便发送一些指令给后端程序（比如skynet）。这种情况其实我们可以先将新的服务器列表描述文件发送到各个服务器，然后通过指令让他们加载新的列表。

实现注意点

服务器列表刷新，是会牵扯到服务链接的中间件（mysql，redis这些），这个在架构设计上需要注意。这种分布式服务器架构设计时，应该要明确服务器职能,还得注意服务的资源的隔离性，因为如果混乱的话，会滋生一些灰色地带。举个例子，我上家公司的项目，所有服务器都公用同一个数据库配置。就是说，A服务器的mysql数据库可以被B服务器访问到。这种情况就是一种灰色地带，因为A的数据库应该由A自己操作，而不是B也能操作。因为如果没有特殊手段保护(比如分布式锁)，B可以在A不知情的情况下操作他的数据库。当然作为有经验的程序应该知道不要这样去操作，但是人的素质不同，你不能保证每个人第一次遇到这种情况的时候都是这种想法。

前面说了，架构层面和业务层面都需要具体的考虑，而且项目情况不一样的话也会有区别。另外要注意在更新服务器列表的时候，该锁的东西要锁上，该释放的资源要释放。

在刷新之前应该注意先检查新的列表的有效性。如果是错误的列表，程序应该有检测这种错误的能力。因为这种操作会比较敏感和危险，可能一不小心某些服务就不可访问了。

最后就是服务器列表在更新的时候，会存在有的服务内部的列表先刷新了，有的服务内部的列表后刷新。即集群在刷新服务器列表的时候，会遇到极短的时间内列表不一致的情况。这种情况下，要评估会不会造成问题。如果会，要考虑在更新列表的时候，锁住集群的状态。等更新完以后，再让状态继续。我知道这里是个坑，也有些想法，但是没具体实践过，可能不成熟，我就不在这里说了。