题记：
服务器学习也有一段时间了，没有人指点进度还是挺慢的。因为参考的是个成熟的框架，所以学的过程中被一些环环相扣的东西搞得身心俱疲，比如你你在收发数据的时候要使用对应的协议，于是中途去补了Protobuf的使用，然后在链接时需要发存取数据，于是又中途补了数据库mongodb的使用，然后就是相关的有多少，就得中途插入对应东西的学习。所以学了快一个月了，算是略微理解了一些，以下总结一下最近的学习进度。
关于进度
所以就从头学起，就搭配了客户端从登陆开始。然后从数据库取服务器的地址返回给客户端做展示，嗯，就到这里了而已。
关于服务器
作用就是和客户端进行数据交互，其实我一开始只是想搞个简单的Scoket测试的，后来发现如果根据交互的程度不同，服务器所扮演的角色也有所不同，现在接触的一种是服务器就作为数据存储的角色，只记录重要的信息用以记录玩家信息及游戏进度。另外一种是服务器参与所有计算和游戏逻辑，客户端仅作为展示页面。这样的话，客户端还真就是拼图仔了。
其中比较麻烦的是理解服务器框架的设计，就和客户端一样，入门的时候只考虑写出功能就完了，后来开始考虑扩展复用，系统化组件。所以对于成熟的框架，还要去理解为什么要那么设计。
具体可以参考一些讲服务器架构的文档，我接触的比较单一。
比较困扰的是为什么服务器还要区分什么登陆服，什么游戏服，什么db服，GM服，等乱七八糟的，这让我单线学习的过程中雪上加霜，因为我测试发给登陆服信息的时候，登录服又发信息给游戏服或者其他位置，让我不得不在不同的模块之间跳来跳去。
直到现在概念还是有点比较模糊的。
答案参考
然后查到了一段我觉得比较符合我揣测的解释，以下仅做参考：
因为现在手游几乎全部是运营商(渠道)和开发商（CP）分开的模式了。
在渠道的概念下，再来理解为何要把登陆和游戏服务器分开就很容易了。因为在手游时代，是个网游都是要接入渠道登陆功能的，因此在开发游戏的初期就应该把接入渠道的工作纳入开发计划之中。
一般运营的游戏实际负责保存游戏数据和执行服务端逻辑的服务器由开发商进行部署和维护，而负责登陆的服务器则由渠道负责部署和维护。由于渠道往往拥有很多现成的用户，以及各种方便快捷的登陆方式（例如微信的自动登录），而这些登陆方式不同平台往往差别很大，而渠道间的竞争也很激烈，因此大多数渠道都会通过给出现成的登陆模块（SDK）和统一接口的方式供开发商进行接入。
不过要指出的是，这里的“登陆”应该是只单纯的用户名密码、游客账号等等单纯的“验证身份”的模块。事实上，开发商在自己的游戏服务器中也会有单独的登陆功能模块。
把游戏登陆逻辑单独成一个服务的优点有如下几点：
1:登陆入口唯一.：游戏如果不是自己运营，则需要上其他平台。每个平台只能有一个登陆服务器，但是游戏逻辑服务器要跟着玩家数量的增加而增加。
2:方便扩展：游戏可能会在多个平台一起运营，不同的平台对登陆的处理方式可能不一样。单独把登陆部分分开的话，只要修改登陆服务的代码，然后发布就可以了，其他部分的服务器不需要做任何修改。
3:部署灵活：游戏中玩家数量较少的时候，可以将登陆服和逻辑符部署到一台物理服务器上。当玩家增多，服务器压力增大时，可以将登陆服单独部署到性能更强大的物理服务器上。
4:减少耦合：登陆服和逻辑服独立后，登陆服挂了不会影响正在游戏中的玩家。某一个逻辑服挂了也不会影响到登陆。
后续进度
到这里算是简单的对服务器结构有了概念。后续会尝试使用一个简单的构架来测试搭建一个功能完整的服务器。
跑通的话会补上概念的架构图。
以上。