有状态 无状态 stateful stateless monolithic architecture microservice architecture 单体架构

为什么游戏公司的server不愿意微服务化？ - 知乎 https://www.zhihu.com/question/359630395

我大概说了，方便测试，方便维护，方便升级，服务之间松耦合，可多语言开发，自动扩容…之类的点

然后他说游戏server不太需要微服务，因为要求real time，做微服务会影响效能，分模组来开发就好

作者：陈宏基
链接：https://www.zhihu.com/question/359630395/answer/954452799
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

比如moba类游戏，就看LOL的客户端吧，想象一下。

• 账号系统，符文系统，英雄系统，皮肤系统，好友系统，好友之间messaging，这些都是常规操作，如果流量足够大，当然可以用微服务的架构去做。

不过这不是这个游戏的核心，核心是MOBA：Multiplayer online battle arena。特性是什么？

• 10个人之间各种游戏事件的高速多向通讯 streaming/broadcast/multicast/pubsub各种通讯模式

所以游戏的核心在于小规模群体之间的高速网络通信。就是对方说的realtime。多了一个10ms的延迟玩家就要骂娘了。

• 微服务为了把业务完美拆解，把原来的同一个进程里的模块拆分成不同的服务，显著增加额外的网络开销。更别说什么service mesh，各种gateway，proxy，sidecar，简直就是担心延迟太低。
• 微服务基本只有request/response的模式。做不了streaming？微服务通常要求应用是无状态的才能做到水平扩展。streaming本身就是加入了状态
• 我可以想像，为了提高通讯的性能，一场英雄联盟游戏很可能会使用同一个服务器负责这10个玩家之间的通讯，这样就使得数据可以在本地交换，性能最大化。这对客户端或者说服务端统一网关的要求是必须支持sticky routing。假设客户端连接断了，接下来的必须重连之前的同一个服务器。微服务的stateless，水瓶扩展要求本身就是反sticky routing的，因为sticky routing本身就是状态。
• 对服务端集群来说，同时有无数个LOL比赛在进行，每个都可以看成一个沙盒，每个沙盒都处于一个不同的状态：塔被推了几个了，你被杀了几次了，对面几个超神了，20分钟到了没。 这些都是长时间存在的状态，直到游戏结束，服务端才可以清理一场游戏的状态。所以虽然不用把这些状态写进持久性存储，但是必然会在内存中存在很长时间。都是状态，反正有状态，就别想用微服务。除非你说把这些状态都移到redis里去，那么在服务器在信息流传输到一半还要做一个remote request，一来一回，延迟就上升了。总之怎样都不好。（比如想象对方在A你的水晶，每一次A的操作都是一个event，被streaming到服务端的沙盒中，沙盒中有一个流处理器，每次接收到一个你水晶被A的event都会计算一下你水晶爆了没。这个计算需要极快，你是不可能把你水晶生命值的数据存在远端的）

像这类游戏，都是对网络，内存，CPU的优化需求很高，整个游戏进行过程中，几乎不存在什么RPC call，真的需要remote data，也应该是prefetch，就是在游戏刚开始的时候加载好

微服务不是什么银弹，也就是方便拆解一下原来的CRUD应用罢了而已，一没触及高级的交互方式，二没触及分布式系统真正的难点：状态，其实没有大家想的那么有用。之所以感觉上好像微服务改变了互联网，只不过90%的互联网应用都只是简单小规模的CRUD而已。

对方没有听说过微服务完全没有问题，因为这本身就不是什么高深的概念，反而对方听你一说一下就知道微服务不适合游戏，说明对方理解能力很强，对游戏系统设计也了解足够深。

作者：放浪者
链接：https://www.zhihu.com/question/359630395/answer/982001747
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

有些国民级moba游戏的微服务化过程，可能有保密问题，我就不谈了。

拿中年人喜闻乐见的WOW来说，你们不知道有专门的排队服务器、场景服务器、副本服务器么这些么？你以为每次切换场景时的loading界面在做啥？就是完成service的切换啊。

你非要用web那一套来套在游戏上面，那当然不行，那说明你对microservice的理解太狭隘了。microservice重点是业务逻辑的拆分和独立，难道你以为这么多mmorpg，是一个巨大无比的monolithic的应用在跑？怎么可能。

多人游戏和互联网app相比，最大的差别不是microservice还是monolithic，也不是啥实时还是非实时，而是stateful和stateless的差别。互联网app大量的工作是在数据读写上，为了能疯狂scale，service本身一般是stateless的，最简单的一个例子就是web server的session概念（现在比较过时了，但是是个很好的例子），既可以本地，也可以存入redis或者db。游戏的server其实也是保存这样一个当前场景涵盖所有人的巨大session（比如副本，比如moba中的游戏全局状态）。由于游戏过程本身并没有什么保存价值，所以对这些实时进行的游戏状态进行持久化没啥意义，因此才有专门的对战服务器等等。

其实你把什么对战服务器、排队服务器、匹配服务器等等都叫做xx service，就会发现其实就是微服务概念。

补充一点个人不保证正确的私货：其实整个游戏开发行业和互联网行业的技术思维差异就在于stateful vs stateless，做习惯了游戏开发的人（无论客户端还是backend），习惯了直接在内存读写数据，不习惯从远程读写（无论是redis还是db或者nosql或者啥），换句话说他们不太习惯原始数据不在本地机器上，而恰恰业务逻辑和数据分离是互联网架构的重要指导思想。这使得游戏开发程序员的技术思维很有些不一样，我不能说不好，但是确实有点技能点的配置不同的感觉，这当实现非游戏项目的时候是有障碍的。

*********************************************

评论中的朋友是一个较为典型的例子，始终固守在传统（国内）对游戏单体开发的思路上，你当然可以这么做，但是不意味着就必须这么做，更不意味着这么做就是好的。

一开始我说的国民级游戏之一就是LOL，搜了一下公开资料，，发现他们也略微谈过一点他们后台微服务化的事情 ，有兴趣的可以看看。

 

《英雄联盟》在线服务运维之道 - InfoQ https://www.infoq.cn/article/running-online-services-riot/

美国拳头公司（Riot Games）成立于 2006 年，2009 年发行《英雄联盟》游戏，2015 年被腾讯全资收购，成为腾讯旗下的子公司。

几年来，《英雄联盟》获奖无数，来自世界各地的玩家促成了数千万人同时在线游戏的盛况。拳头公司把玩家的游戏体验放在第一位，他们的开发团队和基础设施团队为此做出了不可磨灭的贡献。来自拳头公司基础设施团队的工程师们分享了他们运维在线服务的发展历程，介绍了他们从手动部署到自动运维的演变过程。

拳头公司的在线服务运行环境十分复杂，他们使用了共有云和本地数据中心，这些数据中心遍布世界各地，如何快速做出服务变更，并及时将它们推送给玩家，同时又能保证不对玩家造成不好的影响，这是基础设施团队需要解决的重大难题。

任何一家公司都是从小做起的，刚开始的时候规模小，服务器也少，很多事情可以通过手动进行。但随着规模的增长，服务器越来越多，系统越来越复杂，人工干预容易出错，也跟不上变更的节奏，所以必然会走向自动化。系统也从单体变成了微服务，数据中心从一个变成多个，除了本地数据中心之外，还加入了公有云。开发、部署、测试、监控，这些环节一个都不能少。网络的部署和管理、应用程序的部署和管理、如何进行快速而安全的变更、如何保证数据的安全、如何进行失效备援以便提高可用性，如何为玩家带来最佳的体验，有太多的问题需要解决。而拳头公司的基础设施团队又是怎么做到这些的呢？

第一章介绍了拳头公司的在线服务发展概况，简述了他们的调度系统、容器化进程、持续集成、网络管理、应用程序动态化。第二章深入介绍了他们的调度系统 Admiral。第三章详细介绍了叠加网络、OpenContrail 以及与 Docker 的集成。第四章介绍了他们是如何实现基础设施即代码的，还介绍了他们的负载均衡和失效备援策略。第五章介绍了他们的微服务生态系统，包括高度可移植性、动态配置、服务发现、全局搜索和秘钥获取等方面的内容。第六章介绍了他们的开发者生态系统，包括他们的开发者工具箱，如监控可视化工具、网络管理工具、服务搜索工具、构建跟踪工具等。

正如这些工程师所说的，拳头公司灵活而敏捷的氛围让他们可以为开发团队开发出真正有价值的工具，让他们能够专注在产品的开发上，从而把最好的游戏功能带给玩家。

目录

第一章 简介

第二章 调度

第三章 网络（一）

第四章 网络（二）

第五章 微服务生态系统

第六章 开发者生态系统

阅读数：4705发布于：2018 年 1 月 29 日 20:09