DevOps 是分工细化下的产物，用于提高开发和运维的协作效率，实现快速交付。这里主要从开发的角度谈谈游戏服务器中的DevOps，以及我们最近做的一些尝试。
我们现在是不同的项目使用不同的语言和框架，上线前，运维了解熟悉各个项目组的配置方案，部署流程，数据管理等，同时开发也需要熟悉运维的检测工具，接入监控报警机制。这通常需要一周甚至更多的时间，并且线上部署和本地部署可能是两套完全不同的流程，由于项目组相关性太强，运维通常也是专职维护指定项目，效率很低。上线后，如果出了BUG 需要紧急修复，通常是开发人员直接ssh到正式环境的主机上，进行日志查看，状态调试，甚至代码修改，对操作人员的要求比较高并且风险大，没有充分发挥运维的作用。
异步思维是后端架构设计的必备思维，尽管同步代码简单直观且易于维护，但为了构建健壮，可靠的后端系统，对于同步的选择是应该慎之又慎的。为了方便讨论同步可能带来的问题，我将同步请求大概分为三类:
第一类同步请求的问题很明显，就是请求方无法对对端的响应有一个最坏预期，即有可能对端挂掉了，永远也不响应，那么请求方就永远被阻塞了。很多时候我们在实现同步语义的时候会忽略超时处理，或者说对对端的可用性作出过高的假设。而我们要在语言机制上实现同步语义是很简单的，比如Go的res := <-chanRet，Erlang的receive Answer -> ok，而对于同步调用失败或无响应的情况却没有过多考虑。好在Go的很多网络库都通过context来规范化了超时处理。
现在我们加上超时，来看看带超时的非关键同步请求，非关键请求是指请求方不必等该请求完成之后，再处理接下来的任务。即如果这个请求是异步的，那么其实请求方也可以先处理接下来的消息。比如地图线程在发起一个DB请求加载某个玩家数据时，这个过程中地图线程其实可以先处理来自其它玩家的请求。在这种情况下，很明显的，同步请求相比异步，降低了地图线程的吞吐量。前段时间公司一个项目出现CPU Load上不去，而Erlang消息队列有堆积的情况，排查了很久，发现是日志库log4erl里面有同步调用，导致写日志的API其实是有阻塞的，然后基本所有的逻辑线程都会写大量日志，导致CPU不能跑满。
最后来看看带超时且关键的同步请求，举个例子，玩家登录的时候，玩家的agent线程会向平台去认证鉴权，即使这个鉴权过程是异步的，agent线程也不能处理接下来的任务，因为玩家还没有鉴权成功，它发来的后续消息是没有意义的，agent要么将接下来收到的消息丢掉，要么将其缓存下来，等鉴权完成再处理。在这种情况下，你可能会觉得用同步总不会有什么问题了吧，既不会降低吞吐量，也不会有永久阻塞的问题，然而我们有项目也遇到过这种情况，玩家多点登录时，新的agent会同步等老的agent走完下线流程之后，再处理后续登录逻辑(这个地方的同步调用没有设置超时)，然而如果老的agent在阻塞处理某些请求(这个请求的超时可能比较长)，并无法即时响应登出请求，那么新的agent也会阻塞，然后玩家觉得几秒钟没登录上，可能又会再次重启游戏重新登录，这个时候新建的agent仍然会继续阻塞，然后agent数量就会暴增，内存增长等不稳定性。当然，这个事故的部分原因是没有正确设置超时，但也从另一方面揭露了关键同步请求相比异步的缺陷: 虽然异步请求过程中，agent也不能处理后续逻辑消息，但起码agent是可响应的，可响应意味着可以处理一些如终止消息，系统消息等高优先级的任务。前面定义的所谓关键二字，其实是对同等优先级的任务而言的，而往往在实践中，总有意外或者更重要的事情发生。
另外，关于同步请求的一个周知问题就是环形依赖，即A同步请求B，B又直接或间接同步请求A，同步意味着强依赖，随着逻辑复杂度的提升，理想的单向依赖会很难保证和检查，一旦出现环形依赖，轻则请求失败，伴随系统吞吐量降低(有超时的情况)，重则环中的线程全部无响应(没做超时的情况)。因此对于以上的三类同步请求，环形依赖都不会带来好结果。
讲了这么多同步的缺点，不是说完全不用同步，而是说慎用同步，要理解同步可能带来的边界问题是什么，比如服务器启停服流程，各种数据模块的加载/保存可能会有顺序依赖，如果做成异步，可能需要维护非常复杂的状态机，并且代码维护成本也比较高，而同步则可以获得清晰的执行流程和错误处理。
相比同步而言，异步看起来更安全，但是相对复杂，比如可能会用到状态机，需要考虑异步请求的上下文等。另外，用异步不意味着上面讲的同步的问题就可以忽略，比如如果没有做超时，对同步而言的代价是可能永久阻塞，而对异步的代价则是”请求沉没”，即请求方在发出异步请求之后，如果对端没有响应，那么这个请求就没有后续处理了，如果日志记录得不好的话，可能都很难追溯到这个请求，因此对于异步请求而言，日志记录，超时机制都是要去考虑的事情。另外，由于异步本身的特性，消息时序性问题也要考虑，比如前面讲的agent在异步执行鉴权操作，如果没有做状态机保护，直接处理后续请求的话，那么在逻辑上来说都是错误的。有时候时序性的问题比这个更复杂，比如A请求的异步请求还没有响应，后续处理的B请求跟A请求有数据相关性，就可能导致数据不一致。一致性的问题我在这里有讨论。
总之，异步很多时候是让服务器不出现大问题(无响应/雪崩/系统吞吐量变低等)，但同时也带来了开发复杂度，以及一些”小问题”(请求沉没/数据不一致/逻辑错误等)。
下面来简单谈谈后端几种常见的异步交互机制，及其优缺点。
Go的package和goroutine，前者组织Go程序的静态结构，后者形成Go程序的动态结构，这里谈谈对这两者的一些理解和实践。
分包的目的是划分系统，将系统划分为一个个更小的模块，更易于理解，测试和维护。如何组织Go项目的包结构，是大多数Go程序员都遇到过的问题，各个开源项目的实践可能也并不相同。以下是几种常见分包方案。
适用于小型应用程序，无需考虑循环依赖等问题。但在Go中，同一个Package下的类和变量是没有隐私可言的，C++/Java可以在同一个文件中通过Class实现访问控制，但是Go不可以。因此随着项目代码规模增长(超过10K SLOC，代码维护和隔离将变得非常困难。
如果给你一个服务器框架，你如何评估这个框架？不同的人可能有不同的维度和优先级，比如性能，可维护性，可扩展性，可用性，可靠性等等等等，目前已经有相对成熟的几种软件质量评估方案。其中McCall软件评估模型(1977)比较有意思:
产品修正: 开发视角，反映系统应对变更的能力
产品运行: 用户视角，产品稳定性，效率，易用性等
产品转移: 运维视角，可移植性，组件复用性等
现在的游戏服务器通常使用NoSQL作为DB以满足Model设计上的灵活性，特别是即将到来的MongoDB 4.0将提供多文档事务支持，这意味着，SQL转向NoSQL的最后障碍已经被消除。
理想的MongoDB使用场景是将单个对象映射为单个文档，比如玩家数据，公会数据等，但一方面MongoDB对单文档大小硬限制为16M，另一方面，我们需要根据对象更新频度，固有特性等进一步优化，提高DB性能。这里简单谈谈那些GS对象落地的方方面面。
React实际上只是View层的一套解决方案，它将View层组件化，并约定组件如何交互，数据如何在组件内流通等，但实际的Web App除了View层外，还包括Model层，界面响应，服务器请求等，Flux则是Facebook为此给出一套非常简洁的方案，用于管理Web应用程序数据流。与其说Flux是一套框架，不如说其是一套设计模式，因为其核心代码只有几百行，它主要表述的是一种Web应用设计理念和模式。
