游戏服务器开发如何组织业务逻辑的处理结构？

  所以按照以上的步骤，我们现在只关心业务逻辑的处理流程，这里设置一个前题，就是服务器的数据都是在内存中的。内存中的数据与数据库的同步由底层的其它系统处理。在内存中，我们创建并缓存一个对象Player，它包括所有模块的数据，比如背包，个人商店(Shop)，技能(Skill)，武将，副本 等等,Player只是数据类，里面不应该包括任何逻辑方法，所有的逻辑方法操作应该在Manager中处理。比如ShopManager。

  比如个人会使用netty做为网络层的通信框架，在Channel的Handler中收到客户端请求的数据，根据请求的消息号，调用处理业务的Handler。在业务的Handler中验证参数的合法性，然后再调用业务逻辑的Service层，Service层负责的业务流程的处理，比如购买商品，***步判断商品是否已卖完，第二步判断剩余数量是否足够，第三步判断是否已购买过，第四步判断钱是否足够，第五步是付钱，第六步是发送购买获得的道具。这里面应该都是方法的调用，而没有一点数据的处理，数据的处理由第三层的Manager管理。Manager对应中声明一个参数Player，在创建Manager对象时传入，不同的模块数据之间交互都由Manager处理，Manager中的方法职责单一，只负责处理一件事情。每个用户的每个模块Manager对象各一个。用户之间不共享，这样做才能够减少参数的传入。这样更便利面向对象的设计。方便对业务逻辑进行单元测试。

  每个用户的每个模块的Manager实例存储在当前用户业务逻辑处理的线程的LocalThread中的HashMap中，这样方便管理又避开使用锁了。使用一个ManagerFactory对象统一管理Manager对象的创建和获取。

  em

  游戏服务器，是一个会长时间运行程序，并且它还要服务于多个不定时，不定点的网络请求。所以这类服务的特点是要关切稳定性和性能。这类程序若需要多个协作来提高承载能力，则还要关注部署和扩容的便利性；同时，还需要仔细考虑如何实现某种程度容灾需求。由于多进程协同工作，也带来了开发的复杂度，这也是需要关注的问题。

  em

  游戏服务器，是一个会长期运行程序，并且它还要服务于多个不定时，不定点的网络请求。所以这类服务的特点是要特别关注稳定性和性能。这类程序如果需要多个协作来提高承载能力，则还要关注部署和扩容的便利性;同时，还需要考虑怎么实现某种程度容灾需求。由于多进程协同工作，也带来了开发的复杂度，这同样是需要关注的问题。

  《模拟城市》再增两台em

  为应付《模拟城市》服务器忙局面，Maxis急增两台游戏服务器：NorthAmericaWest2，以及EuropeEast2，至昨日新增服务器数目已达四台。Maxis建议玩家遇到服务器忙的提示后可自行切换所在服务器，所有服务器无论其地理位置均面向全球各地区开放。