服务发现

在游戏服务器中,通常有一些功能本身非常内聚,甚至是无状态的,在这种时候,我们应该将其单独地做成一个服务,而不是嵌入到GameServer中,这种思想就是所谓的服务(microservice)思想。

服务发现本身可以看做是一个业务独立的”特殊服务”,它用于逻辑服务的注册/查找/配置信息共享。通常由如下三部分组成:

  • 一个强一致,高可用的服务存储
  • 提供服务注册和服务健康状态监控的能力
  • 提供查找服务,连接服务的能力

在分布式领域中,服务发现是一个非常实用和通用的组件,并且已经有一些比较成熟的组件,如zookeeperetcd等。服务发现组件的好处有很多:微服理念,为负载均衡,灾难恢复提供基础。更多应用场景,可参见etcd的这篇文章

阅读全文 »

一. network部分

EndPoint:

抽象一个Socket及其相关操作,隔离平台相关性。

TcpPacket:

代表一个TCP包,这个包只是recv收到的字节流,并不是上层协议中的消息(Message)。

MsgHandlers:

每个MessageHandler类对应一个消息的处理。MsgHanders维护MsgId -> MsgHandler的映射。

阅读全文 »

链接器的工作主要分为两个阶段:符号解析和重定位。本文简单介绍符号解析过程。

符号解析的功能是将每个模块符号引用绑定到一个确切的符号定义。

1. 符号分类

  • 全局符号:非静态全局变量,非静态函数
  • 外部符号:定义于其它模块,而被本模块引用的全局变量和函数
  • 本地符号:静态变量(包括全局和局部),静态函数
阅读全文 »

由于项目开发中早早地用到了rebar,虽然rebar在很多方面都比自己构建原生OTP应用更方便,但是每一次修改,都需要重新编译,发布,启动,非常耗费时间,而rebar本身的upgrade又比较麻烦,是针对于版本发布的,不适合开发测试使用。

因此找到了一种基于.beam文件更新加载的方法,借鉴自mochiweb reloader

mochiweb reloader每隔一秒检查一次已加载的所有模块(code:all_loaded()),遍历模块列表,检查其所在路径的变更状况,若模块在一秒内有变动,则通过code:load_file(Module)加载模块到运行时系统,执行热更。整个过程需要我们做的就是,将编译好的beam文件放到rebar rel对应的发布版本目录下,可通过code:all_loaded()查看各lib或app所在的发布路径,该发布路径是具有版本号的,但是由于我们在开发测试中暂时无需版本号控制,因此直接通过makefile将编译好的beam文件放到发布路径即可。

阅读全文 »

一. 简介

Supervisor(监督者)用于监督一个或多个Erlang OTP子进程,Supervisor本身是个behaviour,仅有一个Callback: init/1,该函数返回{ok, {ChildSpecList, RestartStrategy}}。ChildSpecs是ChildSpec列表,

ChildSpec(子进程规范)

指定要监控的子进程的所在模块,启动函数,启动参数,进程类型等等。格式为:

阅读全文 »

一. GlobalObject

每个节点(即一个FFServer)对应一个GlobalObject,存放该节点的节点信息和分布式信息。GlobalObject中包含多种组件,FFServer根据节点配置信息决定为节点创建哪些组件。这样分布式配置更为灵活,一个节点可以单一职责,也可以多种职责。GlobalObject包含的组件主要有:

  • netfactory: 前端节点,对应netport字段,监听和管理客户端连接。
  • root: 分布式根节点,对应字段rootport
  • remote: 分布式子节点,对应字段remoteport
  • db: 数据库节点

简单介绍一下netfactory, root, remote 这三个组件,已经远程调用的实现机制。

阅读全文 »

前几天学习firefly游戏服务器框架,其底层用twisted实现,twisted是一个比较出名的python异步回调框架,将reactor回调模式运用到极致,并且也对传统回调所面临的一些问题提出了很好的解决方案。

我的twisted学习主要是基于Dave的系列博客的,英文原版在这里,看了前面比较基础的几章,根据这些文章做个阶段性总结。顺便附上官方文档

一. reactor

twisted的核心是reactor,而提到reactor不可避免的是同步/异步,阻塞/非阻塞,在Dave的第一章概念性介绍中,对同步/异步的界限有点模糊,关于同步/异步,阻塞/非阻塞可参见知乎讨论。而关于proactor(主动器)和reactor(反应堆),这里有一篇推荐博客有比较详细的介绍。

就reactor模式的网络IO而言,应该是同步IO而不是异步IO。而Dave第一章中提到的异步,核心在于:显式地放弃对任务的控制权而不是被操作系统随机地停止,程序员必须将任务组织成序列来交替的小步完成。因此,若其中一个任务用到另外一个任务的输出,则依赖的任务(即接收输出的任务)需要被设计成为要接收系列比特或分片而不是一下全部接收。

显式主动地放弃任务的控制权有点类似协程的思考方式,reactor可看作协程的调度器。reactor是一个事件循环,我们可以向reactor注册自己感兴趣的事件(如套接字可读/可写)和处理器(如执行读写操作),reactor会在事件发生时回调我们的处理器,处理器执行完成之后,相当于协程挂起(yield),回到reactor的事件循环中,等待下一个事件来临并回调。reactor本身有一个同步事件多路分解器(Synchronous Event Demultiplexer),可用select/epoll等机制实现,当然twisted reactor的事件触发不一定是基于IO,也可以由定时器等其它机制触发。

reactor的回调机制如下:

阅读全文 »

一. 简介

firefly是一款python开发的开源游戏服务器框架,基于分布式,底层使用twisted。

firefly采用多进程方案,节点之间通过网络通信(当然你也可以创建单节点,独立完成大部分功能),具有很好的可扩展性。

二. 使用

作为一个Python初学者,下面只谈一些自己对firefly的一些肤浅认识。上面的途径可以获取到更完整和深入的资料。

下面的Demo的源代码可在我的Github上下载。

1. 流程

总体上看,如果你要使用firefly,所需要做的事就是:

  • 通过配置文件定义所有节点,节点配置,节点实现文件,以及节点和节点之间的联系(通过网络端口)
  • 定义节点实现文件
  • 启动主节点

firefly通过配置文件来设定你的分布式服务器,然后你只需创建和启动master节点,master服务器会启动配置文件中的各个子节点:

阅读全文 »

记录一下搭建wordpress博客的过程,做备忘之用,仅供参考。

一. 前期准备

一台云服务器和一个域名(可选)。国内的服务器搭建网站需要备案,国外的话推荐linode,目前linode tokyo服务器应该是国内访问最快的,但是已经缺货了,而新开的singapore服务器线路优化又不是很好(ping 300+),后来又换成了fremont,速度总算稳定了一些,ping值 210 左右。

阅读全文 »