- README.md -- 当前文档
- ROADMAP.md -- 开发计划
- TOOLCHAIN.md -- 工具链
- INSTALL.md -- 安装
关键词: 分布式，手游服务器，基于GO语言
业务分离是游戏服务器架构的基本思路，通过职能划分，能够合理调配服务器资源。 资源的大分类包括，IO,CPU,MEM, 例如常见的服务：
IO: 如: 数据库，文件服务
CPU: 如: 游戏逻辑
MEM: 如: 分词，排名，pubsub
玩家对每种服务的请求量有巨大的不同，比如逻辑请求100次，分词请求1次，所以，没有必要1:1配置资源。 当服务容量增长，如果在monolithic的架构上做(全部服务揉在一起成一个大进程），会严重浪费资源(大量资源闲置，性价比极低), 所以gonet2架构也是基于microservice的一次尝试。
为了把所有的服务串起来，必须满足的条件有：
- 支持一元RPC调用 (一般的请求/应答模式，类似于函数调用)
- 支持服务器推送（例如pubsub服务）
- 支持双向流传递 (网关透传stream到后端)
我们暂不想自己设计RPC，一是目前RPC繁多，没必要重新发明一个轮子，二是作为开源项目，应充分融入社区，利用现有资源。我们发现目前http2(rfc7540)支持所有以上的要求，google推出的gRPC就是基于http2的RPC实现，当前架构中，所有的服务(microservice)全部通过gRPC连接在一起。 http2支持stream multiplex，即可以在单一tcp连接上，传输多个流，非常适合表达透传数据。
附: HTTP/2 帧封装
+-----------------------------------------------+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
Figure 1: Frame Layout
进入每个服务阅读对应文档
- agent: 网关
- game: 游戏逻辑
- snowflake: UUID发生器
- chat: 聊天服务
- auth: 鉴权，登陆环节
- libs: 公共组件包
- rank: 排名服务
- geoip: IP归属查询
- arch: 归档服务
- bgsave: 与redis结合的存档服务
- wordfilter: 脏词过滤服务
基础设施是用于支撑整个架构的基石，选择nsq, etcd的理由是:
- 全部采用go实现，技术栈统一
- nsq在bitly商用效果很好，能支持大规模的，高可用(特别是发生网络分区)的分布式应用
- etcd是coreos出品的coordinator, 已经得到大面积的使用，有成功案例，配套完善。
+
|
+--------------> auth
|
+----> game1
|
agent1+------>
|
+----> game2
| +
agent2+------> +-----> snowflake
| |
+----> game3+---->
| |
| +-----> chat
++ |
+-----> rank
+
具体的服务描述以及使用案例，请进入各个目录中阅读
所有服务都依赖的一个基础服务是nsqd，用来搜集日志，所有的服务会把日志发送到本地的nsqd收集，通过nsqlookupd管理nsqd拓扑，通过tailn工具或nsq_tail，可以集中收集格式化的日志(json)，消息主题为 : LOG。
游戏中的归档日志(REDOLOG)，也会通过nsqd发布，并通过arch服务自动归档，消息主题为REDOLOG。
nsqd部署的方式为： 每个服务器实例部署一个
QQ: 459420581
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent