我是微软服务的新手，我试图把我的项目变成一个基于微服务的项目。我的问题是弄清楚每种服务是如何相互通信的。微服务通信
首先，我探索了REST风格的服务，但是如果每个服务都基于HTTP REST，他们究竟怎么相互“交谈”？
然后我试着学习Spring集成，但后来变得更清楚，他们应该如何沟通，因为现在我想到，也许我需要使用RabbitMQ作为前端和微服务后端之间的中间件。
我也遇到了云和Docker技术，所以我猜每个服务都应该在云上，但是它并没有说明服务如何通信。
我正在使用Java，Spring技术。
我会很高兴，如果有人会给我一个更好的图片应该怎么样。
你走向正确的道路。使用REST体系结构公开服务功能强大且简单。每个微服务都暴露出一些可以被其他微服务调用的功能。你可以用SpingMVC和注解@RestController来做到这一点。要调用REST API，您可以使用Spring类RestTemplate。
您可能还需要一个网关，将请求重定向到正确的服务。我建议你试试Netflix Cloud Stack：
如果您使用的是Spring Boot，您可以使用一些注释快速设置此体系结构。
你可以在这里找到一个简单的例子：https://cloud.spring.io/spring-cloud-netflix/
微服务的通信或传输机制没有标准。通常，微服务使用广泛采用的轻量级协议（例如HTTP和REST）或消息传递协议（如JMS或AMQP）相互通信。在特定情况下，可以选择更优化的通信协议，例如Thrift，ZeroMQ，Protocol Buffers或Avro。
微服务之间的通信可以设计为同步（请求响应）或异步（消除和遗忘）样式。两种方法都有其优点和限制。仅用一种方法开发系统是不可能的。基于用例需要两种方法的组合。
根据您的使用情况和要求，您应该选择最适合您的项目的项目。
我曾亲自使用的尤里卡发现服务。如果您愿意，这基本上就是微服务的“木偶大师”。每个微服务在启动时将自己注册到单独的微服务（发现服务）。发现服务因此知道每个微服务的地址和端口，并且每个微服务可以询问发现服务哪些（其他）微服务被注册。另外，每个微服务可以简单地向发现服务询问关于另一微服务的信息。所有的沟通（在我的情况下）都是使用REST完成的，但这是一个选择，因为具有Eureka发现服务依赖项的Spring Boot会促进它。
非常少的配置，你可以得到这个整个框架的功能。
这是基于Netflix使用的框架。我相信尤里卡甚至是这方面的netflix库。
我不太喜欢从服务A到服务B的直接API调用，反之亦然，原因有两个。首先，它创建服务A和B之间的依赖关系。其次，随着服务数量的增长，它可以轻松地创建一个意大利面的混乱关系。我想看到的是一个酒吧/子模式，例如服务A向传输层发布消息（RabbitMQ不是一个不错的选择），然后继续。解析消息的订阅和业务逻辑很好地封装在服务B中。通过这样做，服务B根本不需要知道关于服务A的任何信息，但它们可以很好地相互交流。
有微服务做同步相互沟通是一个风险，大问题是耦合，它意味着服务现在耦合到对方，如果其中一个失败它的依赖项将完全或部分禁用/崩溃，更好的解决方案是使用异步通信进行状态更改操作。
您想清楚区分状态更改操作和读取操作（CQS命令查询分隔）。对于状态更改操作，您可以使用某种消息传递基础结构并着火并忘记通信。对于查询，您可以使用同步请求响应通信，并可以使用http API或直接转到数据存储。
如果您使用消息传递，那么您还可以查看发布订阅以提高服务之间的事件。
如果您暴露了内部状态，读者可能会得到错误的数据状态或错误的版本，并且可能会锁定您的数据（另请参见“数据共享”数据？
最后但并非最不重要的一点，尽量做到让服务保持自治（至少在逻辑层面上）。
希望这是有道理的。