前提

目前跟过的几个游戏项目，都使用了微服务架构，都用到了etcd。所以有必要学习和记一下etcd在游戏服务器中的作用。

微服务

将一个应用程序拆分为一组小的、独立部署的服务，每个服务运行在自己的进程中，并通过轻量级通信机制（通常是 HTTP 或消息队列）进行交互。每个微服务通常围绕某个特定业务能力构建。

每个服务部署独立、单一职责、不同微服务内部有通信、可以用不同的编程语言、好维护。

有了k8s的部署加持，微服务部署起来很快。

在实际的使用中，游戏服务器一般的划分为：

• 网关服

• 登录鉴权服

• 主游戏逻辑服

• 社交好友服

• 内部路由服

• 邮件服（游戏一般有全服邮件、指定uid的用户群体邮件等等，因此邮件服也比较重要）

• 数据同步落地服

• 战斗服

• gm服 （用于处理运营的一些操作）

• 一些重要的业务；

• 等等…

这么多服，每个服都有自己的配置，部署的规模（pod数量）也都不一样。

etcd也就这样被引入了，解决的问题包括：

• 统一配置管理；

• 服务发现；

• 分布式锁；

一些实践

配置管理

• 通过git来管理配置信息；

• 运维提供一键更新的流程；

• 通过etcd keeper来查看配置信息；

• 基于raft算法保证每个微服务都使用同一套配置；

🔥服务发现

• 因为用了k8s部署，一般就不用etcd的服务发现功能了；负载均衡也依赖kube-proxy

• 当然如果有些微服务没有在k8s中部署，那么还是要用etcd的

分布式锁

• 有些微服务需要有一个master，etcd就可以利用分布式锁协助选主；

• 不过有些服务器自己用了redis中的分布式锁来实现；