微服务架构：你能完全消除系统中服务之间的同步调用吗？

Question

在您读到微服务的任何地方，都会说微服务应该异步通信。可以理解为什么首选异步通信，因为它消除了依赖并提供了低耦合和可用性等。

假设，每次用户调用 API 时都会调用一个通用的授权服务。在这种情况下，您无法进一步使用授权服务的响应。虽然您可以使用 Async IO 异步调用授权服务，但是它仍然是请求/回复模式。

我的问题

1. 在基于微服务的系统设计中是否可以摆脱同步通信或更恰当的请求/回复模式？
2. 虽然可以通过消息传递和回调异步实现回复/响应模式，但这会增加大量开销和延迟，但是否值得将每个请求/回复都转换为异步方式？
3. 如果不能完全消除同步调用，那么微服务之间可以进行同步调用的场景有哪些？

Answer 1

我认为您的问题的简短答案是：请求-回复模式并不意味着同步。它也可以是异步的。你已经提到了。

长答案：

请求-回复只是一个原则。例如，您向朋友发送电子邮件。该消息包含与您相关的数据，您希望得到回复，但没有明确说明。您的朋友下班回来时会看到这封电子邮件，然后他可能会或可能不会回复您。只有你知道你需要他的回答。

现在在等待您的回复时有几个选项。要么阻止你的整个生活，直到你的朋友响应（这意味着同步通信）要么做其他事情直到响应到达你的收件箱（这是异步的）。

现在，重点：

是否有可能在基于微服务的系统设计中摆脱同步通信或更恰当的请求/回复模式？

是的，您已经在第二点回答了这个问题。尽管有可能，但我认为应该在需要的地方使用它。

虽然可以通过消息传递和回调异步实现回复/响应模式，但这会增加大量开销和延迟，但是否值得将每个请求/回复都转换为异步？

对于正确的场景，是的。消息传递系统具有非常好的性能，因此延迟应该不是问题。当消息传递系统中出现延迟问题时，还有其他选项可以改进它。

如果不能完全消除同步调用，那么微服务之间可以进行同步调用的场景有哪些？

是的。

还有一件事需要补充。同步并不总是意味着阻塞。在反应式世界中，如果您对另一个服务进行 HTTP 调用，调用者会发送请求，然后以非阻塞方式等待响应。当响应到达时，将通知调用者响应已到达，因此该过程继续进行。在“等待”时，CPU 可以做其他事情。