点击上方"数据与人", 右上角选择“设为星标”
分享干货，共同成长！
背景介绍
回答
陈宏基：
微服务为了把业务完美拆解，把原来的同一个进程里的模块拆分成不同的服务，显著增加额外的网络开销 。更别说什么 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 都会计算一下你水晶爆了没。这个计算需要极快，你是不可能把你水晶生命值的数据存在远端的）
像这类游戏，都是对网络，内存，CPU 的优化需求很高，整个游戏进行过程中，几乎不存在什么 RPC call，真的需要 remote data，也应该是 prefetch，就是在游戏刚开始的时候加载好。
匿名用户：
liulilte：
更多精彩内容，关注我们▼▼
