五星宏辉游戏项目小结

五星宏辉游戏项目小结

web服务端和game服务端的区别

Server的定义和分类

wiki对Server的定义：

In computing, a server is a computer program or a device that provides functionality for other programs or devices, called "clients". This architecture is called the client–server model, and a single overall computation is distributed across multiple processes or devices.

分类：Typical servers are

• Database Server
• File Server
• Mail Server
• Print Server
• Web Server
• Game Server
• Application Server

异同

Web Server，典型例子是淘宝。
特色：

• 全部流程均由客户端发起，客户端发个请求，服务端返回个响应——请求响应模式
• 根据客户端访问的服务不一样，客户端能够向不一样的具体服务端节点发起请求

Game Server，典型例子是魔兽世界。
特色：

• 有一个肉眼能感受到的链接握手的过程，创建链接后，流程有多是服务端发起（好比给你展现周边玩家），也有多是客户端发起（好比你移动了一下）——交互性
• 同时，若是你手边有抓包工具，能够看到，若是你选中了某个玩家，在该玩家的头像框消失以前，一直是同一个场景服务器在跟你通讯。——常链接

Application Server，典型例子是QQ。
特色：

• 介于Web Server和Game Server之间，看着像一个web服务器，可是又有游戏服务器的特色。

服务端在client-server模型中的扮演角色：

服务端，在物理上表现为一或多台主机，在逻辑上向客户端暴露一组host:port二元组，接受客户端链接，为每一个客户端链接维持链接会话（Session）。客户端与服务端借助链接会话传递消息，消息按必定的协议序列化与反序列化，客户端与服务端的逻辑模块由消息的内容驱动运转。
不管是Web Server，仍是Game Server，在运做流程上都大致相同。而在流程中的细节上，有共同点，也有不一样点。下面就分开说道说道。

共同点：

• 都是为客户端提供多种服务

  • 好比淘宝既提供搜索服务，又提供商品页查询服务。

    魔兽世界既提供登陆服务，又提供让你在场景里战斗、走跑跳的服务。

• 都须要链接会话概念

  • 会话是创建在链接之上的概念，其实本质上是服务端为某个特定客户端维持的数据结构与状态信息。

    Game Server自没必要说，玩家登陆以后，服务端须要有一个专门的全局服务器维护玩家状态与玩家的部分较热的存档信息，玩家进入到某个场景，场景服务器还须要专门维护一份玩家的场景相关的状态信息。

    Web Server，链接会话一样存在，最直观的理解是淘宝登陆以后服务端会为客户端保持一个会话上下文。

• 服务端的每台物理机服务多个客户端

  • 这是服务器的诞生基础，发展到如今，已经没人再讨论是异步IO仍是多路复用，如今成熟的解决方案已经不存在孰优孰劣的问题，彻底是哪一个网络库用的顺手就默认接受这个网络库底层的IO模型。

• 都具备分布式结构

  • 架构的演化老是类似的，Web服务端与游戏服务端在发展过程当中相互学习相互演进，目前造成的主流架构基本都至少应该将专门管链接的、专门管逻辑、专门管存储的作必定程度的物理隔绝。

    能够像skynet同样，利用luaState作隔绝；能够像Erlang同样，利用actor作隔绝；也能够最简单的，按进程隔绝。只要能保证其中之一挂掉不会产生连锁反应致使其余都挂掉就能够了。

• 开发语言

  • 实际上也是近几年手游开发火起来以后开发语言才趋于统一的。web开发一直是百家争鸣，而游戏开发在之前是C++一家独大。

    可是如今，客户端的逻辑层已经基本见不到C++的影子了，服务端纯用C++的也愈来愈少了。lua、python、java、C#、Erlang、js甚至ruby的工业级游戏服务端框架都有出现，web服务端和游戏服务端的开发语言已经趋同。

不一样点：

• 会话的存在形式（本质区别）

  • 这一点是web服务端与游戏服务端最本质的区别

    web服务端的客户端与客户端之间交互很是有限，所以，服务端能够将会话状态保存在外部存储服务，好比一些缓存中间件、文件系统中间件，而后等再用到的时候再拿出来就能够了。

    而游戏服务端的客户端与客户端之间交互很是频繁，好比，同场景的其余玩家会不停作不规律移动，战斗时一个技能就会对复数个玩家形成影响。

    这时若是将会话状态保存在外部，会形成频繁的状态存取，严重影响服务器吞吐量。所以对于游戏服务端来讲，会话一般保存在进程内。

• 交互频率与数据流向

  • Web Server的频率低，并且数据的流动是由客户端驱动的，流向一般是客户端请求了，服务端才返回。

    Game Server的频率高，数据的流动一部分由客户端驱动，一部分由服务端驱动。流向除了服务端对客户端请求的响应，还有服务端的主动推送。

• 通讯协议基础

  • 通讯协议基础就是客户端和服务端通讯的协议所依赖的协议基础。

    按常识理解的话，web通讯的基础在应用层是http协议。因为小说君对web开发并不太熟悉，因此不太清楚目前私有协议在web开发中的应用，可是想必即便是私有协议，也必定是套在http协议的某些字段里面的，这跟游戏的客户端服务端通讯有本质区别。

    游戏一般会实现私有的序列化协议，能够简单理解为应用层定义协议包结构平铺成字节流或者是串行序列化字节流。若是要支持必定程度的协议版本兼容，会用二进制json或者protobuf来实现协议序列化，可是通讯协议自己是没有「基础」可言的，纯私有化协议，不具普适性，也没有必要定义成一种专门的协议。

• 对第三方组件的依赖程度

  • web服务端发展速度快，从业者多，同技术栈的从业者交流更深刻更频繁。所以，web服务端出现、而且还会出现愈来愈多的第三方独立组件。web服务端的从业者甚至只须要在本身的技术栈不一样层次上选择不一样的第三方组件，黏合起来，就能造成一整套的解决方案，很是方便。

    游戏服务端正相反，比较封闭，基本上每一个项目组要么是从头至尾重写，要么是从其余项目组拿来整套技术栈直接改改。基本不存在第三方独立组件的状况，在技术开放氛围好些的公司还好，毕竟你们能够复用同一套框架，不然的话，公司内的框架多种多样，各类造轮子出来的，各类空降团队从原来公司带过来的，技术没法复用，团队成员流动更是一大难题。

Firefly框架

在游戏服务器端，每每须要处理大量的各类各样的任务，每一项任务所需的系统资源也可能不一样。而这些复杂的任务只用一个单独的服务器进程是很难支撑和管理起来的。因此，游戏服务器端的开发者每每须要花费大量的时间精力在诸如服务器类型的划分，进程数量的分配，以及这些进程的维护，进程间的通信，请求的路由等等这些底层的问题上。而Firefly彻底能够完成这些重复而繁琐的工做，从而将上层的游戏开发者解放出来，把精力更多的放在游戏逻辑的实现上面。

Firefly是免费、开源、稳定、快速扩展、能“热更新”的分布式游戏服务器端框架，采用Python编写，基于Twisted框架开发。

Firefly特性

1. 采用单线程多进程架构，支持自定义的分布式架构
2. 方便的服务器扩展机制，可快速扩展服务器类型和数量
3. 与客户端采用TCP长链接，无需考虑粘包等问题

Firefly思路

一个最基本的服务器就是一个在不停运行着的应用程序。

在分布式游戏服务器中，咱们须要的服务器具备的功能有：

• 监听客户端的链接
• 监听其它服务进程的消息
• 链接其它服务进程
• 数据库链接和缓存服务

Net connect 作客户端链接

Root监听其余服务进程消息

Node链接其余服务进程，db数据库，cache缓存

是否须要监听客户端链接，是否监听其余服务进程消息等这是都是能够在config.json中进行配置。包括各个服务器的名称以及各个服务器之间的链接关系。这样就能够自定义出本身的分布式架构。

Firefly结构

从功能职责上来看，Firefly框架结构以下图所示：

1. management：Firefly 是个多进程、分布式的游戏服务器。所以各游戏server(进程)的管理和扩展是firefly很重要的部分，框架经过抽象使服务器的扩展很是容易。
2. Network：客户端链接通讯、server进程间的通讯等构成了整个游戏框架的脉络，全部游戏流程都构建在这个脉络上。与客户端的通讯采用的是请求/响应式的，全部收到的客户端的请求，服务端都会给出相应的回应，服务端也能主动的推送，广播给客户端消息。这些请求是基于指令号的请求（例如定义101为登录指令）。server进程之间的通讯时采用的异步回调的方式，这样就减小了的进程间经过网络通讯中的时间消耗。
3. Data: 数据处理是网游的重要部分。在网游有大量的数据须要存储，须要更新，这使得数据库的读写效率成为服务器的最大的性能瓶颈。Firefly的db处理可以将数据库表中的数据缓存到memcache中并能以对象的形式进行调用相应的对象方法对数据进行操做。能够在不一样的进程中经过实例化相同的名称的缓存实例，获得同步的数据。并能将缓存对象中的数据写回数据库中。

Firefly流程

1. 从config.json中读取配置数据
2. 根据配置中定义的服务端的架构，启动相应的服务进程。并创建节点之间的链接。有配置数据库的，实例化数据库链接池。有配置memcached的，创建memcached的链接。
3. 根据配置相应的的进程启动的入口模块。

Python游戏后端架构

设计方案

• 性能卓越和高可用性
  1. 分布式架构（客户端到服务端全部环节避免单点问题、有效负载均衡）
  2. 支持高并发写（db缓存，部分模块改成批量操做，减缓DB压力）
  3. 游戏推送机制可靠快速，无延迟
  4. 分布式代理，故障发生时自动切换
  5. 游戏服务热更新
  6. DDos防御
• 监控运维
  1. 用户行为模拟（开发实现模拟大量真实用户行为机器人程序）
  2. 通知模块（独立语音、短信、邮件通知服务模块）
  3. 游戏异常监控系统（异常出现时实时通知相关人员）
  4. Linux上线操做脚本自动化，远程部署
  5. ELK体系（引入kafka、elasticsearch、kibana，记录分析游戏日志信息）

整体架构

Web服务代码架构

预警系统体系

Client端（各待预警的子项目）数据上报（只需1步）：

1. 在用户操做的先后调用已经封装好的日志agent上报原始操做的信息（信息格式参考后续的接口文档）；

Server端（分析预警系统）：

1. 收到client发送过来的请求后，首先进行鉴权验证；
2. 验证经过后，根据类型（异常错误类和信息记录类）分类存储到不一样的消息队列；

​ 异常错误类：上报过来的信息通常为须要进行预警通知，错误的验证逻辑由上报者本身内部判断；

​ 信息记录类：上报者只是上报原始记录信息，具体是否触发预警的逻辑验证由预警后台程序验证；

1. 不一样类型的worker持续从对应的消息队列中获取最新消息，产生分析结果；
2. 根据分析结果决定是否调用Notice服务通知产品开发、运营人员；

周期性任务：

该部分主要指预警后台周期性（天/小时/分钟）执行各类统计分析任务，对可能出现异常的分析结果进行预警；某种程度上能够很好的起到数据埋点实时预警的第二道保障做用；

预警系统主体表结构设计：

项目代码