比HTTP上的REST更高效，从最低效率到最高效率：

• 基于HTTP/2的REST
• WebSocket
• TCP套接字
• UDP数据包

但是，如果您的miscroservices实际上正在做任何有用的事情，并且不花费大部分时间处理HTTP头，那么这种差异可能完全无关紧要。
例如，当你花半秒钟等待数据库，然后返回一兆字节的JSON，然后添加几行额外的HTTP头甚至是不可测量的。
在进行过早优化之前，你需要分析你的代码并对其进行测试，并记住，其中一些在发送更少字节方面更有效地通信的方法，在开发时间方面效率可能要低得多，维护和调试。请记住，没有什么比基于文本的协议更容易检查和调试的了，比如很好的旧HTTP/1.1，你可以使用netcat或任何其他处理纯文本的东西进行对话。

有几种选择：

• 如果你没有太多的微服务，它们是强大的，在服务间通信中有很多ACL/作用域逻辑，没有什么比通过HTTP/1.1的好的旧REST更好了。它是Web的默认最基本的语言，任何语言都有很多好的REST连接器，这使得通信的开发变得轻松。
• 如果有很多服务，需要消息持久化，并且任何类型的分布式事务都是不可避免的，那么选择是强大的u-boat消息总线，如RabbitMQ（AMQP）。可以使用任何其他消息传递协议/队列（ZeroMQ/通过Redis）-选择取决于您的系统ISC必须具有哪些特性。
• IPC（通过TCP或UDP），如上所述-此选项的首选项取决于您编写服务的语言，因为在某些语言中执行此操作比在其他语言中更容易，并且这需要编写大部分代码（如果您的系统中有几种语言-这将需要在每种语言中编写）
• 插座，如上所述。

我个人最喜欢的是前两个-一个提供简单和熟悉，其他速度和鲁棒性和控制。

上面的两个答案都很好。我想知道你是否期待使用Docker来有效地支持你的微服务，并拥有更多的可见性和安全性。到目前为止，它被用作最流行的微服务架构组件。
这是一个很好的阅读：https://medium.com/aws-activate-startup-blog/using-containers-to-build-a-microservices-architecture-6e1b8bacb7d1#.qztlom227