游戏服务器架构系列前面分享的文章有:
当架构中有了网关之后,客户端就可以连接上来了。接下来客户端就需要请求游戏业务了,网关负责转发;
那么问题来了,网关怎么知道转发到哪里?
一、解决网关转发到“业务服务器”
面对游戏需求,我们的结构如下:
【客户端 * 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)
客户端请求服务注册表,获取一个服务列表;
客户端使用一个负载均衡算法,选择一个服务;
客户端直接请求这个服务。
优点:简单直接;客户端实现负载均衡。
缺点:每一种客户端都要实现一套服务发现逻辑;无法根据服务器使用情况进行负载均衡;
服务器端服务发现(server-side discovery)
客户端请求服务端的负载均衡器(如网关);
负载均衡器去请求服务注册表,利用负载算法选择一个服务;
获取具体服务后,可直接转发,也可发给客户端进行调用。
优点:客户端不需要知道具体的负载算法,不需要实现服务发现逻辑;
缺点:对于负载均衡器的稳定性要求比较高(如果是网关,就要开多台),也增加了整体系统的维护性。
五、工具理论 - 服务注册表(Service Registry)
服务注册表是服务发现的关键部分,是一个包含了服务实例的网络地址的数据库,必须是高可用和最新的。客户端可以缓存从服务注册表处获得的网络地址。但是,这些信息最终会失效,客户端会找不到服务实例。所以,服务注册表由一个服务器集群组成,通过应用协议来保持一致性。
六、工具理论 - 服务注册(Service Registration)
服务注册模式分:服务实例自己注册(self-registration模式)和其它的系统组件管理服务实例的注册(third-party registration模式
自注册模式(The Self-Registration Pattern)
服务实例启动后,自己注册到服务注册表
服务实例停止后,自动从服务注册表注销
当服务实例异常挂掉时,服务注册表通过“过期时间”或“心跳检测”来判断失效
优点:简单,不需要其他组件
缺点:每一种服务实例需要实现注册和注销的代码
第三方注册模式(The Third-Party Registration Pattern)
服务实例启动后,由另一个系统组件service registrar负责检测和注册
服务实例停止(或异常挂掉)后,也同上
优点:解耦了服务实例和服务注册表,不需要实现服务注册代码;
缺点:对系统组件service registrar的稳定性要求很高,也增加了整个系统的维护性。