> 我认为依赖例如 Servlet 容器无法处理请求的做法似乎很糟糕。这是一种非常粗糙的错误处理方式。这是那种情况之一，即最简单的「单线程非事件驱动服务器偶然得到的」解决方案，和最华丽而复杂的解决方案，从客户端角度来看看起来却很相似。你真正想要的是每个后端都能监控自身的资源使用情况，并在其就绪检查端点中当它接近其已知的每个后端的最大资源容量（例如线程、内存使用、数据库连接池中已检出的连接等）时，标记自身为不健康状态。…
源讨论为什么消息传递比 REST 更适合微服务之间的通信原帖 156 条评论 · 导入时统计在我看来，依赖例如Servlet容器无法处理请求似乎很糟糕。这是一种非常粗糙的错误处理方式。 我们在这个问题上的结论似乎正好相反。你的解释完全符合我的想法，但我发现这种“混乱”的错误处理正是我想避免的。 有一个具体点我们可能意见不一致：我最初设计Mats主要是为了处理同步情况，即有用户在等待的情况。这是“额外”的部分，你可以使用MatsFuturizer或MatsSocket来实现这一点。 我最初设计它主要是为了内部的、类似批量处理的流程，比如“我们收到了这个基金的新价格（NAV），现在需要结算这5000个等待中的订单”。在这种情况下，工作是有限的，如果线程不足导致错误情况会非常混乱。队列可以100%解决这个问题。 我写了一些关于…
完整原文把你的经验，加入这段讨论。
至于你后面的部分：这正是重点：使用消息和队列可以让流程花费所需的时间。所提到的订单的处理并不需要时间紧迫——至少不像用户坐在手机前登录查看他的资产那样紧迫。因此，如果需要1秒或1小时，差别不大。 关键是所有的流程都不会失败。它们会尽可能快地通过， literally，并且永远不会因为随机资源耗尽而出现任何失败模式。你不需要为此做任何预防措施——背压、失败处理、重试——因为这是基于消息的系统工作方式的固有特性。 此外，如果用户登录系统，而其中一个登录流程需要与结算流程相同的服务，那么该流程将“插队”，因为它们被标记为“交互式”…
完整原文除非你非常小心，否则当服务在过载时被移出服务，通常会导致级联故障，因为每个服务器依次崩溃，因为越来越多的流量被导向健康的服务器。 你需要非常小心，确保服务永远不会允许超过其处理能力的并发量，并且在过载时快速失败请求。否则，TCP队列会堆积，服务器最终只处理过时的请求，这些请求已经没有用了。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。