SNS游戏服务器架构随笔

在最近设计的SNS游戏服务器架构中有一些感悟:

第一, 首先对业务领域进行建模; 产生一些核心的, 不变的概念: 在设计中, 我抽象了几个概念,

1) 绝对ID: 在系统中需要唯一标识的实体或类型;

2) 类型: 实体的类型

3) 数据源: 实体的数据来源和持久化, 在其中实现数据源与程序数据的相互转化

4) 战斗元素: 可以被装备, 可以被在战斗中使用, 为战斗者提供战斗加成 如装备, 技能, 经验药水等(只负责与数据源进行交互, 计算属性与数值)

5) 战斗者: 可以装备战斗元素, 使用战斗元素的加成(只负责与数据源进行交互, 计算属性与数值)

6) 战斗控制者: 控制战斗者进行战斗, 产生战斗逻辑

7) 路由器或叫分派器: 为各种需要路由或分派的对象提供接口与基本逻辑(在当前设计中, 我实现了一个数据库分表与分库的一个分派器, 便于以后的横向扩展)

第二, 为架构进行目标定位: 性能, 扩展性, 可读性, 如何部署, 开发效率

第三, 进行技术选型: 根据定位, 选定一种或几种技术来架构系统, 为了解决问题, 通常会引入一些第三方库或技术, 或许没用过, 或许不熟悉, 我采用的技术选型原则是: 为了解决问题必然会引入新的问题, 这个时候我们要就要根据第二点的指标进行权衡, 找出最合适当前场景的技术(我选择的是Niginx + MySQL + memcache(可替换) + gearman)

第四, 保持简单, 只有需要的时候才进行设计, 不进行过于复杂的自动化架构设计;

第五, 服务保持单一, 逻辑仅进行逻辑计算, 不负责进行存取, 存取的只负责存取, 相互之间没有耦合, 为以后进行服务分离提供设计基础

第六, 设计灵活, 弹性的插件体系: 在不修改原有程序的基础上, 提供活动, 任务或其他业务扩展

刚拜读了"分布式系统的工程化开发方法", 很是受到了一些启发, 考虑在架构中实现REST风格的监控机制