PROSAGA码农传奇-SOA/RPC-微服务之间的通信

0# 部落用户 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    就个人而言，我不喜欢使用RPC的消息代理。它增加了不必要的复杂性和开销
  
  
    如何在用户Web服务中托管长期存在的RabbitMQ使用者？如果你使它成为一些静态单例，在你的web服务中你如何处理扩展和并发？或者你是否将它作为一个独立的守护进程？现在您有两个User应用程序而不是一个。如果您的用户消费者放慢速度，在消费请求消息时Orders服务上下文可能已超时并发送另一条消息或放弃，会发生什么情况。
  
  
    对于RPC，我建议使用简单的HTTP。
  
  
    存在涉及消息代理的模式，其可以避免对同步网络调用的需要。该模式用于服务以消耗来自其他服务的事件，并将该数据本地存储在它们自己的数据库中。然后，当Orders服务需要用户记录的时候，它可以从自己的数据库访问它。
  
  
    在您的情况下，您的用户应用程序不需要了解有关订单的任何信息，但您的订单应用程序需要了解有关您的用户的一些详细信息。因此，每次添加，修改，删除用户等时，用户服务都会发出一个事件（UserCreated，UserModified，UserRemoved）。 Orders服务可以订阅这些事件并仅存储它所需的数据，例如用户地址。
  
  
    好处是，在请求时，您的Orders服务对另一个服务的同步依赖性较小。由于您具有较少的请求时间依赖性，因此测试服务更容易。然而，还有一些缺点，例如Orders应用程序发生的用户记录更改和接收之间存在一些延迟。需要考虑的事情。
  
  
    UPDATE
如果您使用RabbitMQ for RPC，请记住使用消息TTL功能。如果客户端将超时，则将消息过期设置为该时间段。这将有助于避免消费者的浪费工作，并避免在负载下备份队列。 RPC通过消息代理的一个问题是，一旦队列填满，它就会增加需要一段时间才能恢复的长延迟。将邮件过期设置为客户端超时有助于避免这种情况。
  
  
    关于RabbitMQ for RPC。通常我们使用消息代理进行解耦和持久性。看到RPC是同步通信，也就是说，我们正在等待响应，然后耐用性不是考虑因素。这让我们脱钩了。问题是，通过网关或Docker服务名称，您可以通过解耦来解决问题吗？
  
</DIV>

1# 妖邪 | 2019-08-31 10-32

2# v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    的
      这完全取决于您的服务的通信行为，以便在REST API和基于事件的设计或两者之间进行选择
    </强>
    。
  
  
    你做的是根据你的要求你可以选择
    的
      REST API
    </强>
     在哪里看到
    的
      同步行为
    </强>
     服务之间
和...一起去
    的
      基于事件的设计
    </强>
     在哪里找到服务需求
    的
      异步行为
    </强>
    ，两者结合也没有害处。
  
  
    理想情况下，对于进程间通信协议，最好使用消息传递，并且最适合客户端服务REST API。
检查通讯样式
    <a href="http://microservices.io/" rel="nofollow noreferrer">
      microservices.io
    </A>
  
  
    的
      基于REST的架构
    </强>
  
  <UL>
    <LI>
      
        优点
      
      <OL>
        <LI>
          
            当您需要同步环境时，请求/响应非常简单且最适合。
          
        </LI>
        <LI>
          
            更简单的系统，因为没有中间代理
          
        </LI>
        <LI>
          
            促进编排，即服务可以根据其他服务的响应采取行动。
          
        </LI>
      </醇>
    </LI>
    <LI>
      
        退税
      
      <OL>
        <LI>
          
            服务需要发现服务实例的位置。
          
        </LI>
        <LI>
          
            服务之间的一对一映射。
          
        </LI>
        <LI>
          
            Rest使用的HTTP是在TCP / IP之上构建的通用协议，在使用它传递消息时会增加大量的开销。
          
        </LI>
      </醇>
    </LI>
  </UL>
  
    的
      事件驱动架构
    </强>
  
  <UL>
    <LI>
      
        优点
      
      <OL>
        <LI>
          
            事件驱动的体系结构对API开发人员很有吸引力，因为它们在异步环境中运行良好。
          
        </LI>
        <LI>
          
            松散耦合，因为它将服务解耦为一次服务事件，多个服务可以根据应用程序要求采取行动。很容易将任何新的消费者插入生产者。
          
        </LI>
        <LI>
          
            消息代理缓冲消息直到消费者能够处理消息，从而提高了可用性。
          
        </LI>
      </醇>
    </LI>
    <LI>
      
        退税
      
      <OL>
        <LI>
          消息代理的额外复杂性，必须具有高可用性
        </LI>
        <LI>
          调试事件请求并不容易。
        </LI>
      </醇>
    </LI>
  </UL>
</DIV>

微服务之间的通信 - 请求数据