dubbo
springcloud
REST
json
RabbitMq
ActiveMq
Kafka
同步通信：dubbo通过 RPC 远程过程调用、springcloud通过 REST接口json调用等。异步：消息队列，如：RabbitMq、ActiveMq、Kafka 等。
微服务能解决了单体应用以及SOA带来的的问题，但是微服务使整个应用服务增多，服务间通讯更复杂，也会带来大量 的问题。比如单体如何拆分成多个微服务，团队间沟通更多，运维成本增高，分布式事务问题，依赖管理变得复杂，测试 更加困难，故障更难于定位等等。
API Gateway是解决微服务通信的一个不错的方法。以客户端为例。一个客户端可以向多个微服务中的任意一个微服务发出请求。API Gateway负责请求转发、合成和协议转换。所有请求都要先经过API Gateway，然后再将请求转发到对应的微服务中。
这种通信不但可以实现一对一、一对多。还可以实现同步和异步请求。
其中代理访问我们使用的是netflix-zuul，只要是对外暴露请求的所有网关，主要用在oauth项目；服务之间的相互请求多使用feign request使用的是openfeign，主要用在需要立即响应，聚合功能和数据的请求；消息队列我们使用的是腾讯的CMQ，一般用在不需要立即返回，同时需要业务解耦，肖峰填谷的业务请求上。
API是服务端和客户端之间的契约。不管选择了什么样的IPC机制，重要的是使用某种交互式定义语言（IDL）来精确定义一个服务的API。甚至有一些关于使用API first的方法（API-first approach）来定义服务的很好的理由。在开发之前，你需要先定义服务的接口，并与客户端开发者详细讨论确认。这样的讨论和设计会大幅度提到API的可用度以及满意度。
选择服务如何相互通信时，最直接的方式往往是 HTTP。事实上，我们可以提出一个案例，即所有通信渠道都来自这个渠道。但是除此之外，服务之间的 HTTP 调用是服务到服务通信的可行选择。
与HTTP通信不同，所涉及的服务不直接相互通信。相反，服务将消息推送到其他服务订阅的消息代理。这消除了许多与 HTTP 通信相关的复杂性。它不需要服务知道该如何相互交流，它消除了直接相互调用的服务需求。相反，所有服务都知道消息代理，并且它们将消息推送到该代理。其他服务可以订阅代理中自己关心的消息。如果我们的应用在 Amazon Web Services 中，可以用简单通知服务(SNS)作为消息代理。现在 ServiceA 可以将消息推送到 ServiceB 监听的 SNS 主题。
单体架构所有功能耦合在一起，开发效率低
SOA架构的总线模式与某种技术耦合过高
轻量级运行时技术的出现(node.js, WAS Liberty等)
新的轻量级协议(RESTful API接口, 轻量级消息机制)
新的可替代数据持久化模型：如NoSQL, MapReduce, BASE, CQRS等