https://mp.weixin.qq.com/s/x7YF-V_siX2ZiYroB8xPRw
游戏server不太需要微服务，因为要求real time，做微服务会影响效能
10个人之间各种游戏事件的高速多向通讯streaming/broadcast/multicast/pubsub各种通讯模式。
微服务为了把业务完美拆解，把原来的同一个进程里的模块拆分成不同的服务，显著增加额外的网络开销，增加延迟
微服务基本只有request/response的模式。做不了streaming？微服务通常要求应用是无状态的才能做到水平扩展。streaming本身就是加入了状态。
尽量使用本地内存，除非你说把这些状态都移到redis里去，那么在服务器在信息流传输到一半还要做一个remote request，一来一回，延迟就上升了。
对网络，内存，CPU的优化需求很高，整个游戏进行过程中，几乎不存在什么RPC call，真的需要remote data，也应该是prefetch，就是在游戏刚开始的时候加载好。
状态就存在内存，偶尔会接受Redis，MySQL等是绝对不可以的接受的
游戏服务器一般纯需要主动推送，所以第一代微服务网关就没办法满足需求， TCP的没有网关用，Spring Cloud Gateway的Web socket也许可以用（但是从防攻击角度讲端游用TCP绝对比Web socket合理）。全双工
全双工决定了不能使用http，必须使用tcp
低延迟、低风险决定了尽量少的使用外部中间件，以本地内存为主
再来看交易网关为什么使用redis做持久
低延迟决定了撮合不能使用mysql，最好使用本地内存
分布式决定了撮合不能使用本地内存，redis这个remote rpc避无可避
事务决定了撮合必须与基本信息使用同种持久化，否则会是一个分布式事务问题