微服务架构中的进程间通信

应用层服务发现机制

Eureka 高可用的服务注册表

应用层服务发现的好处：可以处理多平台部署的问题
弊端：你需要为你使用的每种编程语言提供服务发现库；开发者负责设置和管理服务注册表，这会分散一定的精力。因此，最好使用部署基础设施提供的服务发现机制

平台层服务发现模式

Docker 和 k8s等部署平台都有内置的服务注册表和服务发现机制。部署平台为每个服务提供DNS名称、虚拟IP地址和解析为VIP地址的DNS名称。客户端向DNS和VIP发出请求，部署平台自动将请求路由到其中一个可用服务实例。因此，服务注册、发现和请求路由完全由部署平台处理，还包括负载均衡

VIP：虚拟IP

好处：完全由部署平台处理；服务端和客户端不包含任何服务发现的代码
弊端：仅限于支持使用该平台部署的服务。

基于异步消息模式的通信

由于通信是异步的，因此客户端不会堵塞和等待回复
消息的顺序、检测和丢弃重复的消息，以及作为数据库事务的一部分发送和接收消息

无代理的消息架构
消息的构成：
消息头部和消息主体构成；标题是名称与值对的集合，描述正在发生发送的数据的元数据。除此之外，消息头部还包含其他信息，比如：发件人或消息船体基础设施生成的唯一消息ID，以及可选的返回地址，该地址指定发送回复的消息通道。消息正文以文本或二进制格式发送的数据。

消息的类型：
文档：仅包含数据的通用消息，接收者决定如何解释它。对命令式消息的回复是文档消息的一种使用场景
命令：类似RPC请求，指定要调用的操作及参数
事件：领域事件，标识领域对象的状态发生了变动，，例如：Order、Customer

消息通道：消息通过消息通道进行交换，发送方中的业务逻辑调用发送端接口，该接口底层封装通信机制，发送端由消息发送适配器实现。

类型：
点对点：一对一交互方式；常用于命令式消息
发布-订阅：一对多的交互方式

无代理消息： ZeroMQ是一种流行的无代理消息技术，它既是规范，也是一组适用于不同变成语言的库，支持各种传输协议，包括：TCP/UNIX风格的套接字和多播。

好处：
允许更轻的网络流量和更低的延迟。中间省略了消息代理的网络延迟
消除了消息代理可能成为性能瓶颈或单点故障的可能性
具有较低的复杂操作性，因为不需要设置和维护消息代理

弊端：
服务需要了解彼此的位置
可用性降低，消息交换时，双方都需要在线
在实现确保消息成功投递等较复杂功能的挑战性很大

有代理的消息架构：RabbitMQ、Kafka、Apache ActiveMQ

好处：
松耦合：发送方不需要知道接收方的网络位置
消息缓存：消息代理缓冲消息，直到消息接收方能够处理他们
灵活的通道
明确的进程间通信

弊端：
潜在的性能瓶颈：幸运的是，许多消息代理都支持高度的横向扩展
潜在的单点故障：幸运的是，大多数消息代理都是高可用的
额外的操作复杂性：消息系统是一个必须独立安装、配置和运维的系统组件

选择消息代理，需要考虑的因素：
支持的变成语言
支持的消息标准
消息排序
投递保证
持久性
耐久性
可扩展性
延迟
竞争性接收方

深入探究下基于消息的架构可能遇到的一些设计问题：
处理并发和消息顺序