微服务：服务间如何通信？-微服务之间如何通信

在微服务架构中，会将一个完整的应用程序拆分成一组服务。这些服务之间需要经过协作，通过接口调用，才能组成一个完整的应用。

不同的服务部署在不同的机器上，或者同一个机器的多个容器中，进程间进行通信就不可避免了，也变得非常重要。

按种类来分，进程间的通信方式有很多种，比如远程过程调用的 RESTful API 和 gRPC 、基于消息机制的异步方式等。

RESTful API ：现在前后端分离比较流行，RESTful API 大家应该都比较熟悉。REST 是一种使用 HTTP 协议的进程间通信机制，一般使用 Json 来传递数据;
gRPC ：是一个高性能、开源和通用的 RPC 框架，基于 ProtoBuf ( Protocol Buffers ) 序列化协议开发，支持众多开发语言。面向服务端和移动端，基于 HTTP/2 设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特性;
异步消息：使用消息中间件来实现，比如 RabbitMQ、Kafka 等。

按照交互方式来分，会有同步、异步。

这里有几个概念需要统一下语言：接口、客户端、服务端

接口：如果使用的是消息机制，那么接口就是由消息通道、类型和消息格式组成的;如果是基于 HTTP ，则是由 URL、HTTP 动词和请求响应的格式来组成;当然，也可以是提供一组方法的类;
客户端、服务端：说起客户端，第一印象容易想到浏览器、移动 APP ，这里的客户端是指在调用和被调用的调用方，服务端就是被调用方。而接口的定义是由服务端来进行定义。

在前后端分离之前的单体应用中，当接口方法有变化时，进行代码编译就知道哪些地方需要调整，或者在 IDE 中进行接口方法引用的查找，也能很容易处理。

在微服务中，不同的服务可能是不同的团队来进行开发，服务端接口的修改、滚动发布等都需要有很好的兼容性和可用性。

一种方式是在接口中向下兼容，但时间越长代码就会变得越复杂，比如：

另一种方式就是不向下兼容，所有的客户端需要进行代码的调整来适应新的接口。在客户端代码还没有完全调整完之前，新老接口需要共存，共存有两种方式：

所以，一个设计良好的接口可以在暴露有用功能的同时隐藏实现细节，对于细节，可以进行扩展，修改，并不会影响到客户端的调用，这就要求在接口设计之前，需要先进行定义，经过多轮评审后再进行编码实现。

好的设计自带防腐层。

因为客户端和服务端是互相独立的，服务端有时在特定时间内无法完全响应客户端的请求，可能是自己本身的故障，也可能是超过了负载。这时，客户端请求就会被阻塞，无限地等待。

有几种方式可以来解决这个问题：

现在有一些成熟的框架可以方便进行熔断的处理，比如：.NET 中的 Polly、Spring Cloud 中的 Sentinel、Hystrix 。

在传统软件中，经常使用环境变量和配置文件来进行静态地址的配置，而部署在云端的分布式微服务程序中，地址是动态的，那客户端怎么能找到这些地址呢?这就需要用到服务发现。

服务发现就是客户端不再依赖一个静态的固定地址去寻找服务端，而是根据一个路由名称在服务注册表去寻找服务端地址，服务端部署后会将地址写入服务注册表。

在微服务框架中，也有相关的框架来实现服务发现，比如：.NET 中的 consul 、Spring Cloud 中的 Eureka、Nacos 等。

对于实时性要求不高的场景，可以采用异步消息的方式来实现。比如删除数据时，需要删除数据中对应的附件信息、各种操作的日志记录、流程流转中需要发送消息通知等。

使用异步消息有下面几个好处：

现在流行的开源中间件有 RabbitMQ、ActiveMQ、RokcetMQ、Kafka 等，选择这些中间件时需要考虑：

很多工作流引擎使用的是消息驱动机制，流程在流转过程中需要保证消息是顺序处理的，否则流程数据可能出现错乱，如何在保证消息顺序处理的情况下又能横向进行扩展，这是一个挑战。在 Kafka 中可以使用分片的方式进行解决。

上面介绍的是服务间通信的一些常用方式，了解了基本逻辑，在具体实践时，无论是使用 .NET 技术栈还是 Java 技术栈来做微服务，就都不是什么难事了。