笔者最近去采访了一家游戏公司。
最近面试了一家游戏公司（有上市的大公司）
他很惊讶，说，我从来没有听说过微服务。 你能解释一下吗？
我大致说的是方便测试、方便维护、方便升级、服务之间松耦合、多语言开发、自动扩展……等等。
然后他说游戏服务器不需要微服务，因为它需要实时性。 做微服务会影响性能。 它可以以模块的形式进行开发。
我也不确定，但是微服务不是一种趋势吗？ 尤其是对于大公司来说，游戏服务器服务应该很容易拆分吧？
回答
我整理了一些好的答案并想与大家分享。 只能说学会了，手法一定要用在对的场景！
陈宏基的回答
比如moba游戏/王者荣耀/LOL，只要看王者荣耀的客户端就可以想象了。
账号系统、符文系统、英雄系统、皮肤系统、好友系统、好友之间的消息传递都是常规操作。 如果流量足够大，当然可以使用微服务架构来完成。
但这不是这个游戏的核心。 核心是MOBA：多人在线竞技场。 有什么特点？
顺便说一句，如果你近期准备面试跳槽，建议到ddkk.com在线答题，涵盖10000+Java面试题，涵盖几乎所有主流技术面试题，最全面的500道面试题市场上有成套技术栈，都是优质产品。 一系列教程，免费提供。
10人之间各种游戏赛事高速多方位通讯流/广播/组播/pubsub多种通讯方式
所以游戏的核心是小群体之间的高速网络通信。 就是对方所说的实时。 如果多出10ms的延迟，玩家就会骂人。
1、微服务为了完美拆解业务，将同一进程中的原有模块拆分为不同的服务，这显着增加了额外的网络开销，更不用说servicemesh、各种网关、代理、sidecar了。 这简直令人担忧。 延迟太低；
2. 微服务基本上只有请求/响应模型，不能做流式传输？ 微服务通常要求应用程序是无状态的，以实现水平扩展。 流本身会添加状态；
3.我可以想象，一款英雄联盟游戏为了提高通信性能，很可能会使用同一个服务器来负责这10个玩家之间的通信，这样就可以在本地交换数据，并提高这对客户端的性能可以最大化。 也就是说，服务器端统一网关的要求是必须支持粘性路由。 如果客户端连接断开，则必须重新连接同一服务器的无状态微服务。 水瓶扩展需求本身就是反粘性路由，因为粘性路由本身就是状态；
4、对于服务器集群来说，有无数王者荣耀游戏同时进行。 每一个都可以看作是一个沙箱。 每个沙箱都处于不同的状态：有多少塔被推了？ 我已经被杀过好几次了，而且有些对手超级强大。 20分钟后，这些都是长期状态。 直到游戏结束，服务器才能清除游戏状态；
所以虽然这些状态不需要写入持久化存储，但它们肯定会长期存在于内存中。 这都是状态。 如果无论如何你都有状态，就不要考虑使用微服务。 除非你想将所有这些状态移至redis，否则服务器将不得不在信息流传输的过程中发出远程请求。 每次回来，延迟都会增加。 无论如何，都不好。 （举个例子，假设对方是A你的水晶，A的每一次操作都是一个事件，流式传输到服务器上的沙箱，沙箱里有一个流处理器，每次接收到你的水晶的事件是A，它会计算你的水晶是否爆炸。这个计算需要非常快，你不可能远程存储你的水晶的生命值数据。）
。 插播一下，如果你近期准备面试跳槽，建议在ddkk.com在线答题，涵盖10000+条Java面试题，涵盖几乎所有主流技术面试题，500套最市场上完整的技术堆栈。 优秀的系列教程，免费提供。
这类游戏对网络、内存、CPU的优化要求很高。 整个游戏过程中，几乎没有RPC调用。 确实需要远程数据，应该预取，也就是游戏刚开始的时候。 已加载
微服务不是灵丹妙药。 它们只是为了拆解原有的CRUD应用提供方便。 它们没有触及高级的交互方法和分布式系统的真正难点：状态。 事实上，它们并不像大家想象的那么有用。 之所以感觉微服务改变了互联网，是因为90%的互联网应用都只是简单的、小规模的CRUD。
如果对方没有听说过微服务也没有问题，因为这本身并不是一个高深的概念。 相反，对方听了你的解释就会知道微服务不适合做游戏。 这说明对方对游戏系统设计有很强的理解力和足够的认识。 深的。
匿名用户的回答
看来我最近被微服务洗脑了。 我个人感觉，对于正常的微服务来说，一个服务必须由3个以上的工程师单独维护，才能真正把微服务组织起来。
而且，现在大多数微服务都运行在HTTP协议上，这对性能的占用很大。 即使使用TCP HTTP2，性能也远远不如单个实体。 尤其是业务fork调用时如何划分微服务，以及数据事件的一致性是非常头疼的。 一件事。
微服务在WEB领域应用广泛，工程师也很多。 业务越来越大，几乎发挥了自己的作用。 这个场景很适合。实时性不需要那么高
我知道很多人妖魔化了微服务。 别人要求100级的技能，你只学了1级，然后他就提出来，告诉别人，这太棒了。
我读了那么多博客和技术文章，但微软官方关于微服务技术的文章是最好的。 它清楚地告诉你这个架构适合什么样的场景和团队，什么样的场景不应该使用。 而不是有些文章都是废话
脱离业务的技术架构是为了框架而构建架构，这只是搬起石头砸自己的脚。
对于开发者来说，强烈建议自己研究新技术。 但如果不考虑实际情况，那就是疯了。
顺便说一句，如果你近期准备面试跳槽，建议到ddkk.com在线答题，涵盖10000+Java面试题，涵盖几乎所有主流技术面试题，最全面的500道面试题市场上有成套技术栈，都是优质产品。 一系列教程，免费提供。
为什么我有这样的感觉？ 因为我是受害者。 因此，我建议您无论您的团队项目的基本业务是什么，都选择最适合您的结构。 不要盲目跟风，更不要盲目与大公司比较。 您的企业和团队仅仅只是其他企业和团队的一小部分是不够的。 别人的HR团队可能比你的技术团队人数还多。
架构越统一，维护它的人就越多。 不然你就会发现为什么这个架构我用起来这么麻烦。不是别人的架构不够好，而是你的团队还不需要。
莉莉尔特的回答
...游戏服务器几乎总是有很多状态。 让我问你一个致命的问题。 游戏原本是在同一个进程中，可以直接访问内存。 如果您使用微服务，该服务可能不在本地设备上。 ，那么就需要通过网络进行传输。 你考虑过延迟问题吗？ 您是否考虑过如果连接中断会发生什么？
每个微服务都是跨本地计算机的 RPC 调用。 这东西不靠谱。 如果您希望它可靠，您是否会同意超时并重新传输接口调用的毫秒数？ 200/500？ （有两种情况：对方已处理和对方未处理，但实际上是同一个呼叫请求）
如果玩家只是放一个技能，需要投射状态，那么由于断线重传需要数百毫秒才能响应，玩家体验如何。
当然我们可以使用协程，也可以使用C++，但是你考虑过编码的复杂度吗？ 而且大量的异步编程在游戏服务器上是非常困难的，这意味着需要更多的游戏服务器开发人员，并且开发人员的整体素质不能太差。
评论列表