问微服务架构中不同服务之间是如何通信的？

微服务能解决了单体应用以及SOA带来的的问题，但是微服务使整个应用服务增多，服务间通讯更复杂，也会带来大量 的问题。比如单体如何拆分成多个微服务，团队间沟通更多，运维成本增高，分布式事务问题，依赖管理变得复杂，测试 更加困难，故障更难于定位等等。

微服务架构能够解决单体架构带来的问题。但是在微服务架构中，一个整体的程序被拆分为许多子微服务。每个微服务实现某一个单一的功能，但是这使得应用程序的应用服务变多，这就使得这些微服务程序之间的通信变得十分复杂。而在程序运行过程中存在着大量的业务逻辑，这往往需要各个微服务之间交换大量的数据。这就带来了许多微服务通信的问题。但是微服务之间是如何通信的呢？

1、客户端到服务端通信，API Gateway方法。

API Gateway是解决微服务通信的一个不错的方法。以客户端为例。一个客户端可以向多个微服务中的任意一个微服务发出请求。API Gateway负责请求转发、合成和协议转换。所有请求都要先经过API Gateway，然后再将请求转发到对应的微服务中。

2、进程通信IPC

这种通信不但可以实现一对一、一对多。还可以实现同步和异步请求。

微服务架构框架图

一般来说。传统的架构风格是将应用程序作为一个整体进行开发。这样的架构风格在开发过程非常容易而且不同模块之间通信十分方便，只需要一个简单的函数就可以实现。但是这也存在很多缺点，比如，这样的应用在开发之后很难进行维护。如果业务需求有所变化很难有所调整。

于是微服务架构开始逐渐被大多数开发者所接受。微服务架构是将一个整体的应用程序拆分为一个或者多个子微服务组成。这些子微服务可以被独立的部署，每个微服务专一地实现某一个功能。这使得应用更加便于管理。

这些微服务之间的通讯是使用异步、基于消息的通信。

不是很理解微服务架构。。。。。