一、前言
没有最好的架构，只有最适合自身业务的架构。
首先我们应该确定的是大的架构方向：分布式 / 单应用+负载均衡，这两种架构设计直接影响后续的网络层、缓存层、数据层、业务层的设计。笔者这两种架构的应用都接触过，两种架构各有优劣：
- 分布式架构在业务层设计上更轻巧，更容易迭代，并且将各个业务模块独立开来可以大量减少锁竞争、线程阻塞的情况，可以做到无状态数据通信，天然支持跨服业务，且耦合性低内聚性高……缺点是分布式架构会有进程间调用上的性能损失(但是在现在硬件条件下损失微乎其微)，且相对于单应用架构技术性更为复杂，缓存、锁、数据同步机制设计上也更为复杂，对开发人员、运维等要求更高。
- 再说单应用的架构，目前业界内采用这种设计的可能更为常见一些，优点是内存共享性能好，且开发、运维更容易上手，如果想要达到能承载较大负载的场景下在负载均衡的设计上需要下一些功夫，缺点是更新迭代相对麻烦，模块间耦合性难以拆分，锁竞争激烈环境下性能影响较大。
一个大型的网落游戏服务器应该包含几个模块：网络通讯，业务逻辑，数据存储，守护监控（不是必须），其中业务逻辑可能根据具体需要，又划分为好几个子模块。
这里说的模块可以指一个进程，或者一个线程方式存在，本质上就是一些类的封装。
二、进程与线程的服务器设计模式
对于服务器的并发性，要么采用单进程多线程，要么采用多进程单线程的方式，说说两种方式的优缺点：