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

游戏服务器架构系列前面分享的文章有:

  1. 分布式架构 – https://www.jianshu.com/p/84ab097df650
  2. 网关服务 – https://www.jianshu.com/p/fcf60d64c6c9
  3. 网关限流 – https://www.jianshu.com/p/0bd8587084ef
  4. 网关协议加密 – https://www.jianshu.com/p/26b6f417413a

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

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

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

面对游戏需求,我们的结构如下:

【客户端 * 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
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞