像这类游戏，都是对网络，内存，ＣＰＵ的优化需求很高，整个游戏进行过程中，几乎不存在什么ＲＰＣ ｃａｌｌ，真的需要ｒｅｍｏｔｅ ｄａｔａ，也应该是ｐｒｅｆｅｔｃｈ，就是在游戏刚开始的时候加载好
微服务不是什么银弹，也就是方便拆解一下原来的ＣＲＵＤ应用罢了而已，一没触及高级的交互方式，二没触及分布式系统真正的难点：状态，其实没有大家想的那么有用。之所以感觉上好像微服务改变了互联网，只不过９０％的互联网应用都只是简单小规模的ＣＲＵＤ而已。
对方没有听说过微服务完全没有问题，因为这本身就不是什么高深的概念，反而对方听你一说一下就知道微服务不适合游戏，说明对方理解能力很强，对游戏系统设计也了解足够深。
１．微服务本身是为了应对业务逻辑的复杂，需要要的新的组织接口的方式。游戏本身逻辑其实没有这么复杂，比如大厅就是一些基本功能，修改帐号，登录等。游戏本身就是游戏本身的逻辑。
２．游戏逻辑服务器本身（比如斗地主等棋牌）因为网络响应性能要求问题（玩家对每个操作的反馈时长敏感度远高于业务系统），所以游戏服务器都是有状态的，状态就存在内存，偶尔会接受ｒｅｄｉｓ，ｍｙｓｑｌ等是绝对不可以的接受的，关系行数据库仅用来定时异步持久化数据，仅游戏服务器而言持久化在ｒｅｄｉｓ即可。
３．游戏服务器一般纯需要主动推送，所以第一代微服务网关就没办法满足需求， ｔｃｐ的没有网关用，ｓｐｒｉｎｇ ｃｌｏｕｄ ｇａｔｅｗａｙ的ｗｅｂ ｓｏｃｋｅｔ也许可以用（但是从防攻击角度讲端游用ＴＣＰ绝对比ｗｅｂ ｓｏｃｋｅｔ合理）。
４．服务间通信ｒｐｃ首先ｒｉｂｂｏｎ，ｆｅｉｇｎ等并不是合适，因为都是基于ｈｔｔｐ的，用Ｈｔｔｐ存在一个消息乱序问题，比如玩家出牌两次，在ｈｔｔｐ就可能出现次序不一致。游戏服务器集群一般使用长连接互联。可能需要用ｄｕｂｂｏ？（听说是长连接）
５．游戏逻辑服务器（比如斗地主服务器），一般是不能用ｓｐｒｉｎｇ ｍｖｃ做的，因为线程模型完全不同。多线程模型处理游戏性能差还非常复杂，一般都是使用单进程／线程 驱动固定数量房间的方式（这也是为何服务器一定有状态，一定不能直接读写ｍｙｓｑｌ）。一般就直接ｎｅｔｔｙ了
６．自动扩容在游戏这边叫做开服，早就有固定流程和工具和限流方式了
７．游戏很多操作不存在服务降级熔断，不行就要直接报错给用户。
８．大厅服务器登录注册等的确可以做微服务，但是其实也不是做微服务，就是几个接口有自动水平扩容的方案即可。服务注册发现用处不大，开服都是确定的事情，还有一系列运营手段配合，关服也是绝对不能随便关的。
９．游戏处理的流量真的不算多，你在线１万的棋牌游戏已经很赚钱了，１０Ｗ就是个特别厉害的产品了。
１０．一些独立的服务器比如充值之类的需要微服务化么？只能说这种服务器都需要微服务处理了，项目组做梦都能笑醒。
虽然上面说了很多点，但是其实也是可以考虑用ｓｐｒｉｎｇ ｃｌｏｕｄ改造的，因为游戏集群一样有注册中心，需要服务发现，需要编排启动顺序，只是ｓｐｒｉｎｇ ｃｌｏｕｄ没有为了游戏设计而已，比如至少要完全支持 ｗｅｂｆｌｕｘ吧（没有仔细研究），需要一个单线程的长连接最好支持ｐｒｏｔｏｂｕｆ ｒｐｃ框架吧（集成服务发现相关功能与接口），网关支持ｔｃｐ或者至少封装或者暴露一些ｎｅｔｔｙ的ｄｅｃｏｄｅｒ ｅｎｃｏｄｅｒ（或者允许注入）等等。
网友评论
最新评论