游戏服务器设计，单服结构能行吗？

         根据个人的工作经历，就先拿游戏服务器说吧。游戏服务器开发，这是最意难平的。

           游戏梦，很多人都有，开发一款游戏，是爱玩游戏的人，都想做的事情。即使，上班只是参与其中一小块，那也能挺满足。

        但是，实际呢：加不完的班，干不完的体力活，复制黏贴，增删改查。 

        不过吧，谁不都是这样过来的呢。

        游戏为什么都是分区服的，不分区服，难吗？

        应该是不划算，不分区服，难维护，开发成本还高，关键后续其实还是有办法容下大用户量的。

---

一. 单个服务，能服务的用户并不多

        大概2010年的样子，还没拿到毕业证，进了一家很小的网页游戏开发公司，做C++游戏开发。那个年代，网页游戏很火，为什么火呢，有一定的历史背景。

        具体的历史背景、技术背景，就不去过多的去说了。感兴趣的话，可以自己去了解，总的脉络，主要还是和“技术与网络红利”有关。

        游戏公司，基本就是赶大流，能赚钱就往哪扎堆，大致便是：PC端游->2D网游/3D网游->页游->手游。

        那时候，游戏公司都在开发网页游戏，Actionscript是关键，不仅能开发出很不错的游戏界面，还能进行Socket通信，那时候H5和websocket都还不成熟。

1.  游戏服务器，单进程多线程就行了？

        一开始，很不理解一个RPG页游的服务器，居然只是采用单进程多线程的设计。不过，仔细想想，大部分的创业公司，都得快，更何况是盯着快钱的网络游戏。虽然，单进程多线程是图快，但多少也有点误解了。

        后来了解到，即便是此前的端游，很多游戏服务器，也都是以分服务器/分区的方式存在。玩家，都得选服务器/分区进入游戏，数据和信息是完全独立的。

        至于，有没必要支持同服很多人呢？显然，很多游戏，其实压根没必要，且就算这么做了，也不划算，服务器、带宽、维护等，其成本都很大。

2.  单服务结构，能支持多少人？

        只有少数游戏，才真正支持同服很多人，主要也都是以多进程，多服务架构实现。单服务结构，后期其实也能扩展，且难度不会太大。

        至于单服务结构，能支持多少人呢？

        几千、上万人同时在线，游戏不怎么耗性能，纯硬件支持也是可以的。当年，有询问过业内的前辈，一般单服务结构，实际能抗住过多少用户。

        得到的数据，还是挺意外，最高的用户峰值是一万多。不过，其在通信上做了压缩优化，耗性能的对方也做了多次优化，才能达到这个数值。说是不敢再往上怼用户了，怕游戏业务服务出问题。

        当然，不做极致的优化，一般一千多人同时在线，在那个年代，还是很容易实现的，有这个数量级的服务器，一般够用了。这还是在较为普通的服务器上，如果，硬件再提一提，还能再多点。

---

二. 单服务结构，其实也有优化

        单服务结构，并不是毫无优化，便能支持较多用户。毕竟，所谓的“大用户，高并发”，虽然，有点虚，但是，也还是要点手段。

        先不说别的，当年，主流的游戏服务器开发便是C++，用JAVA都怕性能差点。虽然，有的会采用lua去写业务，但核心都是用C++去实现。

1. 数据放内存

        性能开销，数据访问是大头，较好的方法便是放内存。一般，数据库还是会用的，也有不用数据库的（数据丢失风险大，需要自己开发持久化方案）。

        某种意义来说，这和内存数据库很像，但是，还是有区别的，有的是在同一个进程里，有的也跨进程。根据业务情况，有的游戏是用户上线加载到内存，有的甚至是，启动服务便同步所有数据到内存。

2. 网关代理，多线路

        除了数据访问外，网络是另外一个瓶颈，单个服务即使有再好的吞吐能力，也还是需要做一些网络上的优化。机房和网卡，这是运维部署上的方案，有的也会使用或自研一些软件上的代理。

---

三. 单服结构扩展，需注意：网络，进程，数据

        单服结构，如果不能扩展，那就挺软肋。实际，扩展起来也不会太麻烦，不过，要是最初的代码设计，没有考虑到这方面，就会很恶心。

1. 网络代理（网关代理）

        先得解决的是网络问题，对外访问，那是最大的瓶颈。很显然，这不一定是最难的，代理/网关模式，一定程度就能解决这问题。

        如果，只是单纯的外网和内网的一对一转换，依然无法根本解决内网负载问题。客户端分别连接不同的服务，通常被称为网关代理，对外通信都通过对应的服务便可。

2. 多服务并存（多进程）

        解决掉对外网络的问题，内部的负载，也依然是个大问题。抛开复杂的业务逻辑，内网通信达到一定的压力，也都会成问题。

        很显然，分流是个很好的办法，利用多个服务去解决负载问题。不过，如果是单点派发的话，在压力达到一起程度，也会成为瓶颈。

        比较好的办法，便是多个网关，或者直接去掉网关（网关代理，本身便等同于网关）。

3. 数据和逻辑分离

        如果，数据和逻辑没有很好的分离，只能在不同功能上做多进程设计，并不好做过多的进程优化。数据和逻辑分离，进程设计便能很灵活。

        数据和逻辑的分离，其方法很多，数据库本身就是一种很常见的方法。不过，单纯的数据库，并不能很好的满足需求，有的应用会做数据处理服务。

        要求不高，数据库和内存数据库，便能满足需求，但也容易出现瓶颈。数据库和内存数据库，主备、分表分库，能满足大部分的需求场景。

        还不行的话，就上分布式数据库，上数据处理中心等，这些的高大上的设计，那肯定能满足需求，就是太麻烦。