游戏服务器架构系列 - 服务注册与发现

当架构中有了网关之后，客户端就可以连接上来了。接下来客户端就需要请求游戏业务了，网关负责转发；

那么问题来了，网关怎么知道转发到哪里？

一、解决网关转发到“业务服务器”

面对游戏需求，我们的结构如下：

【客户端 * N】 -----请求----> 【网关服务器 * N】 -----请求----> 【业务服务器 * 1】

从上图，我们可以看到有N台客户端请求N台网关服务器，然后转发到1台业务服务器；

按照这种结构，先用最快速的方法，把功能实现了：

把业务服务器的“IP”和“端口”写死在网关服务器代码里。

过了两天...

策划说：我们现在需要增加一台战斗服务器，没有战斗的游戏怎么玩？

二、解决网关转发到<多台>业务服务器

当网关服务器后面有多台业务服务器时，我们发现写死在代码里，总不是那么好，修改特别不方便。

为了避免后续又增加很多业务服务器，我们决定：

用JSON或XML结构把每一台业务服务器的“IP”和“端口”写死在配置（文件或数据库）中。

当增加、修改、删除业务服务器时，直接修改配置文件就搞定了，比写死在代码里好多了。

终于上线了...

运营说：今天怎么线上突然报了很多“战斗请求失败”的问题啊？

先让我追查一番...

终于发现，原来是有1个战斗服务器因为“内存满了”挂掉了，当网关在按照配置文件请求时，每次请求到这个战斗服务器就出现“战斗请求失败”了。

这下该怎么办呢？

话不多说，先修复掉...

过了几天，运营又打电话来，说又挂了...，表示很无奈！！！

三、解决业务服务器突然挂掉的问题？

业务服务器挂掉是经常发生的事情，有时候“内存满了”，“磁盘满了”，还有的时候就是代码BUG了。

那么，业务服务器挂了怎么办？我觉得网关应该直接转到其他业务服务器，而不能转到这个挂掉的业务服务器。

如果当前业务服务器不够了，我能动态添加业务服务器去做支援。所以，我们就需要做到：

服务注册：当业务服务器启动后，自动注册到配置中心；用于增加服务后，能够立即被调用；

服务发现：客户端可以从配置中心获取到所有的业务服务器信息；

健康检查：当业务服务器挂掉或无法处理请求时，需要被及时发现，然后从配置中心移除；

负载均衡：当某个业务的服务有多个时，可提供负载均衡算法进行选择；

看到上面这几个需求，你是不是怕了，有没有种感觉“项目又要延期了”？

不要怕，我给你推荐几个工具！

• Etcd：一个高可用，分布式，一致的key-value存储，用来共享配置和服务发现。Kubernetes和Cloudfoundry都使用了etcd；

• Consul：一个发现和配置服务的工具。客户端可以利用它提供的API，注册和发现服务。Consul可以执行监控检测来实现服务的高可用；

• Apache Zookeeper：一个常用的，为分布式应用设计的高可用协调服务，最开始Zookeeper是Hadoop的子项目，现在已经顶级项目了。

• Eureka：Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。 Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。

这些工具都可以解决服务注册与发现，流程如下：

1. ��注����.png

这几个工具的对比如下：

image

四、工具理论 - 服务发现模式（Service Discovery）

服务发现模式分：客户端服务发现（client-side discovery）和服务器端服务发现（server-side discovery）

客户端服务发现（client-side discovery）

1. 客户端请求服务注册表，获取一个服务列表；

2. 客户端使用一个负载均衡算法，选择一个服务；

3. 客户端直接请求这个服务。

优点：简单直接；客户端实现负载均衡。

缺点：每一种客户端都要实现一套服务发现逻辑；无法根据服务器使用情况进行负载均衡；

服务器端服务发现（server-side discovery）

1. 客户端请求服务端的负载均衡器（如网关）；

2. 负载均衡器去请求服务注册表，利用负载算法选择一个服务；

3. 获取具体服务后，可直接转发，也可发给客户端进行调用。

优点：客户端不需要知道具体的负载算法，不需要实现服务发现逻辑；

缺点：对于负载均衡器的稳定性要求比较高（如果是网关，就要开多台），也增加了整体系统的维护性。

五、工具理论 - 服务注册表（Service Registry）

服务注册表是服务发现的关键部分，是一个包含了服务实例的网络地址的数据库，必须是高可用和最新的。客户端可以缓存从服务注册表处获得的网络地址。但是，这些信息最终会失效，客户端会找不到服务实例。所以，服务注册表由一个服务器集群组成，通过应用协议来保持一致性。

六、工具理论 - 服务注册（Service Registration）

服务注册模式分：服务实例自己注册（self-registration模式）和其它的系统组件管理服务实例的注册（third-party registration模式

自注册模式（The Self-Registration Pattern）

1. 服务实例启动后，自己注册到服务注册表

2. 服务实例停止后，自动从服务注册表注销

3. 当服务实例异常挂掉时，服务注册表通过“过期时间”或“心跳检测”来判断失效

优点：简单，不需要其他组件

缺点：每一种服务实例需要实现注册和注销的代码

第三方注册模式（The Third-Party Registration Pattern）

1. 服务实例启动后，由另一个系统组件service registrar负责检测和注册

2. 服务实例停止（或异常挂掉）后，也同上

优点：解耦了服务实例和服务注册表，不需要实现服务注册代码；

缺点：对系统组件service registrar的稳定性要求很高，也增加了整个系统的维护性。

作者：MaxwellGames
链接：https://www.jianshu.com/p/6854b62387c2