我在读 Sam Newman 的书《Creating Microservices》，有这样一句话：
通过同步阻塞调用，微服务将某种类型的调用发送到下游进程（可能是另一个微服务）并阻塞，直到调用完成，并且可能直到收到响应。
俄语翻译：
在同步阻塞调用中，微服务调用下游进程（可能是另一个微服务）并阻塞，直到调用完成并且可能收到响应。
我想澄清一下 - 整个微服务（毫秒）是否被阻止，或者只是进行调用的线程？
我想象这样的工作：假设我们有 2 毫秒，A 和 B，在 Spring Web 或任何其他 Web 框架上完成。每个女士一份。
- 用户单击某些内容。
- 请求发送至 A。
- 在 A 中创建一个新线程（或从池中取出 - 这并不重要）来服务传入的请求。
- A 给 B 打电话并等待他的回复。
- 在这种情况下，并不是整个 A 被阻塞，而是只有服务请求的线程被阻塞。
因此，如果另一个用户也点击了某些内容，那么他的请求也将由单独的线程提供服务，因此 MS A 本身不会被阻塞并继续正常工作。那么为什么书上会说微服务被屏蔽呢？
如果您进一步阅读文本，它会解释其含义。如果我理解正确的话，那么我们不是在谈论操作系统或程序线程，而是在谈论控制流。
下面以“Async/Await 和 When Asynchronous Is Still Blocking”为例进行说明，即软件异步可能不会阻塞 OS /程序线程，但确实会阻塞控制流。因此，非阻塞调用意味着将一些数据传输到另一个模块/服务并且不期望（同步或异步）任何响应的调用。响应将不再到达此控制流，而是到达此微服务的其他处理程序，该处理程序将以某种方式处理此响应并对其做出反应。
也就是说，流量控制工作的两种范式是对比的：
例如，可以使用消息代理（
RabbitMQ等Kafka）来组织第二个选项一般来说，在这种情况下，您需要注意的不是调用是同步的，而是阻塞的。如果您使此调用异步或并发（在单独的线程中运行），从微服务架构的角度来看，这仍然不会使此调用成为非阻塞 ，这就是重点。