微服务你得知道这些！从核心组件到远程调用方式以及HTTP通信方法

微服务的核心组件

微服务的架构设计之前总结过，微服务的思想是分离，微服务模式下将应用程序拆分为不同的微小服务，通过使用或者组合不同的服务来完成不同的业务功能。那么一旦分离后再组合，就意味着服务之间一定会存在相互调用的过程，在前面微服务的定义中提到过，微服务之间都使用粗糙的通信机制，它一定是轻量级的，而且是可以支持跨语言调用的，包括微服务本身对客户端提供服务也是采用这种机制的。因此，设计并实现适合的通信组件来提供远程调用的能力是微服务架构的核心。下面来了解微服务的远程调用方式。

微服务的远程调用方式

微服务架构中常用的调用方式有两种：一种是通过异步的消息交换来通信，这里服务调用双方一般使用一些中间件，如RabbitMQ、Kafka等；另一种是通过HTTP的资源接口，通过JSON作为信息载体的格式，即REST API的方式进行远程通信。

1. 异步消息通信

先来看一下异步消息是如何通信的，这里以RabbitMQ的工作原理为例，如图2.6所示。

首先消息由生产者发送到一个统一的交换中心（又称交易所），交换中心根据一定的转发规则（如直接、主题匹配、扇出等方式），将消息转发到对应的队列中，然后通过消息队列最终将消息传递给消费者。消费者可以选择只订阅自己关心的消息。

可以利用消息机制来做很多事情，如可以做一个简单的任务队列，也可以去订阅和发布消息。当然，订阅和发布的方式有很多，最常见的就是图2.7RabbitMQ远程调用工作原理中描述的定向转发和Topic机制，这里对消息机制的原理不做阐述，利用这种发布和订阅的工作方式，我们可以通过消息做到服务的远程调用。

但是，在微服务中这并不是常见的用法，因为本身消息机制的实现会依赖相关的中间件或框架，服务调用双方都需要集成相同的消息服务或技术框架，这本身就会加重微服务架构的通信方式，而且过度松散异步的操作也为代码带来了一定的复杂度。所以，在微服务中最常见的通信还是基于HTTP的REST API。

2. REST API

REST（Representational State Transfer，表述性状态转移）用来描述创建HTTP API的标准方法，REST API的核心概念是资源，对于资源有4种常见的行为：查看、创建、编辑和删除，都可以直接映射到HTTP中已实现的GET、POST、PUT和DELETE方法。REST本身并没有创造新的技术、组件或服务，只是正确地使用Web的现有特征和能力，更好地使用现有Web标准中的一些准则和约束。

如果一个架构符合REST的约束条件和原则，就称它为RESTful架构，当然理论上REST架构风格并不是绑定在HTTP上的，只不过目前HTTP是唯一与REST相关的实现，所以一般情况下REST API都是表示基于HT