WebGame服务端架构分析（一）

做webgame也有段时间了，最近上线的游戏还处于起步阶段，第二个月收入突破100万了，跟市面上大的webgame比起来，根本不算什么，但有收入总比没有好，呵呵，以后还需更加努力。现在总结一下自己webgame的架构设计，总结的目的一方面是为了共享给网上的朋友，也希望网友给我提出不足之处，另一方面是为了更好的降低成本，总结那些环节还能进一步节省开支。

大家一开始看的这个图是游戏服务端逻辑架构Level1，从图上大体能看出，由多个基础服务提供支持，多个游戏共享通用逻辑服务，外加各自游戏的特性逻辑服务，组成了整个服务端的逻辑架构。

基础服务有很多，有日志服务，通信和内容传递服务（类似WCF的功能），权限，事务，SSO（单点登录），异常处理和查询，路由，监控，服务的注册和分离，配置中心以及数据的提供和存储。

1.日志，用于记录游戏的点点滴滴，游戏交易，玩家数据变化以及需要记录信息的地方。

2.通信和内容传递服务，用于游戏各个逻辑服务的数据传递。

3.权限，判断玩家的操作许可以及游戏后台统计和管理站点操作人员的许可。

4.事务，玩家充值以及各种数据变化，都需要事务的保证，尤其是玩家的充值，会用到分布式事务。

5.单点登录，不管一个公司是出了多个游戏，还是一个游戏开了很多区服，单点登录，让玩家在一个地方登录，其他地方不再需要重新登录，就能玩游戏，带来更好的用户体验。

6.异常处理和查询，能保证系统的稳定性，可用性，查询能帮助更好的维护和解决问题。

7.路由，提供各服务的路由和负载均衡

8.监控，监控各服务的状态，如有异常，可以通知路由，此路服务不可用。如果整个服务器宕机，该服务器上的所有服务，路由将不再中转和调度。

9.服务的注册和分离，配置那些服务可用，那些服务处于维护阶段，那些服务已弃用。

10.数据的提供，根据不同游戏，不同服务，提供对应的数据。

11.数据存储，同上，根据不同游戏，不同服务，把数据存到正确的地方去。

12.配置中心，所有AppSetting的配置，应用配置，通信路由配置，数据存储路径配置等等，都在配置中心存储管理。这样就不用每次上线部署的时候，处理每台服务器上若干的配置

总结，这样的架构主要是为了节省成本，在节省成本的同时，保持可用性，可维护性。

第一个优点，共用。几乎每个游戏都有聊天，公会，技能，包裹物品游戏币等通用模块，把这些通用的逻辑，独立成服务，不依赖数据去驱动，就可以让多个游戏共用，提供给他数据，让他加工，然后生成处理过的数据，至于数据存储，那是数据存储服务的事，这样就不再依赖数据库去驱动了。

第二个优点，可用性，可维护性。我们都知道在架构设计过程中，不要产生单点，例如聊天服务，是否每个游戏服都要部署两套以上？有点浪费，但多个游戏服把所有的服务器资源共享，聊天服务和特定游戏服的数据库分离（聊天跟数据库有什么关系？这个天朝规定了，聊天记录要全部存储下来，随时要检查有没有不和谐的内容），就可以共用，消除单点，一个聊天服务挂了，还有几个在，所有区服的聊天功能全部正常使用，不影响玩家体验。以前我们每个区服的逻辑服务都是单独的一套，也不在乎单点，但运营出现问题后，只能忙的焦头烂额，不但被玩家骂，还要赔偿玩家损失。杯具~~~

 

快凌晨3点了，先写这么多吧，有空再补充，明天是星期天，不过我依然要加班，早点睡了，欢迎大家和我交流。

 

我的Mail：[email protected] [email protected],转载请注明出处，谢谢。