在微服务中，我应该使用pub / sub而不是RPC来获得更松散的耦合体系结构吗？

作者: 日耀九洲
发布时间: 2024-01-24 05:48:06 (2月前)
转自：

3 条回复

0#
回复此人
独奏♪ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 取决于你的用例，实际上与“解耦”无关。如果来自生产服务的调用必须等待来自使用服务的响应，则应使用同步消息传递（RPC）。当生产服务发送旨在由另一个服务消费的消息并且在不等待甚至需要响应的情况下继续其结婚方式时，使用诸如pub / sub的异步通信形式。 </p> <P> 在微服务世界中，异步形式的通信是可取的，因为阻塞线程和等待响应的代价很高。良好的体系结构将有助于解耦服务之间的运行时依赖性，以便每个服务器尽可能独立地运行，而无需直接依赖其他服务来完成它所分配的工作。 </p> </DIV>

编辑
1#
回复此人
star | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 实际上没有人回答这个问题。这取决于：-） </p> <P> 使用RPC从一方面您就可以在服务之间建立更紧密的关系，但从另一方面，您可以获得更简单的请求/响应通信模型。因此，一个服务发送请求期望来自另一个服务的某种响应或者如果它不可访问则超时。 RPC with TCP还具有会话和双向通信方式。 </p> <P> 使用发布/订阅模型，一个服务发送一些关于某个发生事件的消息，而不关心该消息将如何由另一个服务处理。或者服务将消息发送到一个特定服务，并且不期望它的响应 - （单向请求）。当然，第二服务可以向第一服务发送消息，也传递一些工作结果。 </p> <P> 松散耦合本身并不是一个目标 - 它是一种如何使系统更可靠，稳定，可扩展的方式，但它带来了一些价格，工作开销，在某些情况下它是不可能的或根本不必要的。 </p> <P> 因此，根据您的需要，您可以选择第一种或第二种方法。如果您不能简单地发送请求并忘记它或者没有意义，则使用RPC，无论如何您都需要响应。 RPC更容易实现。发布/订阅适用于某种“繁重”的后台作业，如图像，视频，文件处理，发送电子邮件等，您发送请求的地方，它将在队列中处理。使用pub / sub，您可以更有效地利用资源。 </p> </DIV>

编辑

登录后才能参与评论