wudaijun's blog

服务发现

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

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

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

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

一. 登录流程

注册

Unity3d:CreateAccount
Loginapp:reqCreateAccount 
-> dbmgr:reqCreateAccount 
-> Loginapp:onReqCreateAccountResult 
-> Client:onReqCreateAccountResult

一. 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 左右。