序
- 今天看到一个文章谈论了一些游戏server为什么不愿意使用微服务的原因。觉得说的挺好，从侧面能反映出来微服务的好处和弊端。
首先说下微服务架构
就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
- 微服务有什么好处？
方便测试，方便维护，方便升级，服务之间松耦合，可多语言开发，自动扩容 等等
- 微服务有什么弊端？
分布式事务，运维的成本增加，模块与模块之间的调试相对复杂。
- PS 如果你之前接触过模块化构建的工程，那么微服务化和模块化思想上还是有点类似的，只不过微服务更复杂了。我个人理解一个Springboot的模块化工程也是需要考虑，模块的拆解，哪些是公共依赖模块，哪些是自己独立的模块不需要被人依赖，怎么设计模块之间的依赖关系，会不会开发途中发现循环依赖了。诸如此类的东西都需要慢慢经历了解。举个例子，工程里面可能会集成操作Mysql的模块，也会有操作MongoDB的模块。这两个模块就可以都构建成独立的模块。其他的模块需要对Mysql操作就依赖Mysql模块。
以Moba类型游戏为例，最重要的关键是 real time
- 微服务为了把业务完美拆解，把原来的同一个进程里的模块拆分成不同的服务，显著增加额外的网络开销。更别说什么service mesh，各种gateway，proxy，sidecar，简直就是担心延迟太低。
- 微服务基本只有request/response的模式。做不了streaming？微服务通常要求应用是无状态的才能做到水平扩展。streaming本身就是加入了状态
- 我可以想像，为了提高通讯的性能，一场英雄联盟游戏很可能会使用同一个服务器负责这10个玩家之间的通讯，这样就使得数据可以在本地交换，性能最大化。这对客户端或者说服务端统一网关的要求是必须支持sticky routing。假设客户端连接断了，接下来的必须重连之前的同一个服务器。微服务的stateless，水瓶扩展要求本身就是反sticky routing的，因为sticky routing本身就是状态。
- 对服务端集群来说，同时有无数个王者荣耀的比赛在进行，每个都可以看成一个沙盒，每个沙盒都处于一个不同的状态：塔被推了几个了，你被杀了几次了，对面几个超神了，20分钟到了没。这些都是长时间存在的状态，直到游戏结束，服务端才可以清理一场游戏的状态。所以虽然不用把这些状态写进持久性存储，但是必然会在内存中存在很长时间。都是状态，反正有状态，就别想用微服务。除非你说把这些状态都移到redis里去，那么在服务器在信息流传输到一半还要做一个remote request，一来一回，延迟就上升了。总之怎样都不好。（比如想象对方在A你的水晶，每一次A的操作都是一个event，被streaming到服务端的沙盒中，沙盒中有一个流处理器，每次接收到一个你水晶被A的event都会计算一下你水晶爆了没。这个计算需要极快，你是不可能把你水晶生命值的数据存在远端的）。
- PS : Spring的出发点是为J2EE 而生，是替代EJB的产物。本就不是为设计开发游戏而生。
