Martian-cloud 传染机制原理详解

一、基本概念

1.1 传统分布式服务模型

传统分布式系统采用"生产者->注册中心->消费者"模型：

• 生产者将接口注册到注册中心
• 消费者从注册中心发现服务
• 通过注册中心实现服务调用

1.2 传染机制模型

传染机制摒弃了注册中心，采用类似病毒传播的方式：

• 将接口视为"病毒"
• 将服务视为"宿主"
• 服务之间只要有直接或间接联系，最终都会"感染"所有接口

二、实现原理

2.1 服务连接方式

部署时需要规划服务之间的连接关系，配置文件中指定谁连接谁。连接方式灵活多样，只需确保：

• 任何服务都不落单
• 形成完整的连接网络
• 不建议过度复杂的连接方式（如"五花大绑"）

2.2 服务启动过程

以三个服务A、B、C为例（连接方式为A→B→C）：

1. 启动A服务

   • 其他服务未启动，A连接不到B
   • A的本地接口缓存表为空

2. 启动C服务

   • B未启动，C孤立
   • C的本地接口缓存表为空

3. 启动B服务

   • B被A发现，A从B获取接口

   • A的本地缓存更新为B的接口

   • A发起广播：
     a. 从本地缓存提取服务的ip和端口（此时只有B）
     b. 将自己的所有接口广播给这些服务（A→B）
     c. A的本地缓存更新为包含自身和B的接口

   • B同时会去发现C：
     a. B从C获取接口
     b. B的本地缓存更新为C的接口
     c. B发起广播（B→C）
     d. B的本地缓存更新为包含自身和C的接口

4. 后续传染过程

   • 服务会定期轮询：
     a. 从已连接服务获取接口（或从本地缓存随机选一个服务获取）
     b. 向这些服务广播自己的接口（已广播过的忽略）
   • A再次轮询时会从B获取C的接口，并向C广播自己的接口
   • 最终所有服务都会互相"感染"所有接口

三、容错机制

3.1 自私机制

• 每个服务只关心自己的连接状态
• 发现本地缓存的接口连接不上时，自行从本地移除
• 不关心其他服务的状态

3.2 投票机制

• 服务内部维护投票计数器
• 当发现某个接口连接不上时，给对应服务投一票
• 连接恢复时票数清零
• 票数积累到阈值时，将该服务的所有接口从本地缓存清除

3.3 误判处理

• 补偿机制：服务在清除其他服务接口时，会通知被清除的服务
• 被通知的服务会将通知方从已广播列表移除
• 如果通知无法送达，视为服务确实不可用

3.4 触发下线投票的条件

当调用接口出现以下异常时，会进行投票：

1. ConnectException - 无法建立连接
2. UnknownHostException - 无法解析地址
3. SocketTimeoutException - 连接超时（非读取超时）

3.5 垃圾回收机制

• 定时扫描本地缓存
• 清理已被下线的服务接口

四、特殊场景处理

4.1 中间服务宕机

• 初始连接链条（如A→B→C）仅在启动时有效
• 运行后，服务会从本地缓存随机选择服务获取接口
• 广播也是针对本地缓存中的服务
• 因此中间服务宕机不会阻断传染机制

4.2 新增服务

• 只需将新服务连接到任意一个运行中的服务
• 新服务会快速"感染"所有接口
• 其他服务也会通过轮询机制发现新服务

五、总结

Martian-cloud传染机制通过以下特点实现去中心化的服务发现：

1. 服务间直接传染接口，无需注册中心
2. 灵活的初始连接配置
3. 定期轮询和广播机制确保接口传播
4. 完善的容错机制处理服务异常
5. 良好的扩展性支持服务动态加入

这种机制特别适合需要高可用性和去中心化的分布式系统场景，能够有效避免单点故障问题。