服务发现两种方式
- 服务及其客户直接与服务注册表交互
- 通过部署基础设施来处理服务发现（例如网关）
应用层服务发现模式
自注册模式
服务实例向服务注册表注册自己。
客户端发现模式
客户端从服务注册表检索可用服务实例的列表，并在它们之间进行负载均衡。
好处：服务发现机制与具体的部署平台无关
弊端：需要为使用的每种编程语言提供服务发现库。
平台层服务发现模式
第三方注册模式
服务实例由第三方自动注册到服务注册表。
服务端发现
客户端向路由器发出请求，路由器负责服务发现。
好处：服务发现所有方面由部署平台处理，不受语言限制
弊端：仅限支持使用该平台部署的服务
基于异步消息模式的通信
推荐使用消息代理
好处：
- 松耦合，直接发送到特定通道即可，不需要通过服务发现感知服务实例的网络位置
- 消息缓存。消息在被处理之前可以被一直缓存
- 灵活的通信
- 明确的进程间通信
弊端：
- 潜在的性能瓶颈
- 潜在的单点故障
- 额外的操作复杂性。消息系统需要独立安装、配置、运维
消息架构的设计难题
消息的顺序
多个接收方实例可视为一个消费组
在此示例中，每个Order事件消息都将orderid作为其分片键。特定订单的每个事件都发布到同一个分片，而且该分片中的消息始终由同一个接收方实例读取。因此，这样做就能够保证按顺序处理这些消息。
重复消息
解决方式：
- 处理程序保证幂等处理
- 跟踪消息并丢弃重复
事务性消息
使用数据库表作为消息队列
两种方式：
- 通过轮询模式发布事件 通过轮询数据库中的发件箱来发布消息
-
使用事务日志拖尾模式发布事件
使用异步消息提高可用性
使用异步交互模式
复制数据
具体工作过程：
