Overview#

Project Background#

在生产环境中一个 “魔兽世界服务器” 通常有多个 “大区”, 亚洲, 北美, 美国西部, 美国东部等. 每个 “大区” 下有多组服务器, 一个服务器也就是我们在选择服务器见面看到的 Realm, 比如国服著名的 “山丘之王”, “洛萨” 等. 每个服务器都有自己的配置, 例如数据库账号密码等. 那么如何对这么多服务器的配置进行管理呢? 本项目就是为了解决这个问题而生的.

下面, 我们来详细分析一下为了维护许多 “魔兽世界服务器” 集群的配置数据, 我们需要解决的问题.

Manage Shared and Unique Configuration Data#

挑战

一个集群是由多个游戏服务器组成. 而每条配置数据本质上就是一个 Key Value. 这些配置数据有些是共享的 (比如游戏服务器的默认语言全部都是英语), 有些是特定于某个服务器的 (比如每个服务器的数据库密码可能不同).

解决方案

在维护配置数据的时候, 我们需要维护一个 Hierarchy 的层级结构, 类似于面向对象编程中的继承概念. 例如可以把一个 Key 的 Value 设为顶层, 所有服务器自动继承这个 Value, 同时也可以 Override 这个 Value.

Decoupling Servers and Configuration Data for Flexible Updates#

挑战

从开发者的角度看, 我们需要对服务器集群配置进行批量管理和部署. 同时, 我们希望将服务器本身和配置数据分离, 以便在不重新部署服务器的情况下更新配置. 举例来说, 游戏的 ``worldserver.conf ``文件保存在游戏服务器上. 每次修改这个文件, 都需要通过 SSH 登录到服务器上进行更改, 这不仅麻烦, 而且频繁访问服务器也存在安全隐患, 很难追踪是谁在什么时间做了何种修改.

解决方案

我们将服务器本身不保存任何配置数据, 而是将配置数据单独保存在专门的存储中 (例如 AWS S3). 服务器启动时会从该存储读取配置数据并将其应用. 服务器对 S3 的 读权限 被精确配置, 不会有安全风险. 开发者对配置数据的 写权限 也同样经过严格配置, 并且可以通过业务流程来确保对配置的修改是经过审批的. 同时, 任何对配置的修改都会留下历史记录, 方便追踪是谁在什么时间做了何种更改.

Configuration Access Control#

从服务器的角度来看, 出于安全考虑, 每个服务器只需要知道自己的配置, 不需要了解其他服务器的配置. 因此, 我们需要一个脚本来实现 “自省” 功能 - 让服务器能自行判断自身身份, 并从专门的存储中读取属于自己的配置数据. 这个脚本只需要能在服务器上运行即可.

同样出于安全考虑, 具有配置数据写权限的管理员也应该采取分层管理. 例如, 管理员团队的领导可以有所有服务器配置的写权限, 而单个服务器的管理员只能有当前服务器配置数据的写权限. 这样可以确保对配置数据的访问和修改都经过适当的权限控制和审批。

Decoupling Configuration Data Management and Application Logic#

好的,明白了。以下是使用中文写作,同时使用英文标点符号并在符号和后面的字之间添加空格的版本:

在服务器读到配置数据之后, 还需要将这些配置应用到对应的地方。例如: 游戏服务器相关的配置会被写入到 worldserver.conf 文件中, 而一些脚本的配置数据则应该被写入到特定位置的 JSON 文件中。从软件架构的角度考虑, 配置数据的读写应该和配置数据的应用逻辑分离。配置管理就是管理, 配置数据的应用则应该由业务逻辑来负责。所以我们这个 acore_server_config 库只负责对配置数据的定义和读写, 而不管如何将这些配置应用到游戏服务器上。

What’s Next#

下面我们来介绍 acore_server_config 是如何解决上述问题的.