Martian-cloud传染机制的原理 – 作者:1784955689-安全小百科

Martian-cloud传染机制的原理 – 作者:1784955689

先解释下什么是传染机制

常规的分布式采用的是【生产者->注册中心->消费者】模型，生产者将接口给注册中心，消费者从注册中心发现其他的服务，实现调用
传染机制就是丢弃注册中心，可以把接口看做病毒，服务看做是人，服务之间只要有直接或者间接的联系，最终都会被染上病毒（接口）

如何实现的

假如现在有三个服务

此时，需要发布这三个服务，那我们可以先规划下，将他们连在一起，连在一起的意思是在配置里写好谁连谁。

连接方式可以是这样【图1】

也可以是这样【图2】

也可以是这样【图3】

总之，只要别让任何服务落单就行，随便怎么连，你甚至可以来一个五花大绑（不过不建议）

—————————————————————–

连接以后就到发布阶段了，那么发布的时候，这些服务之间会发生什么呢？

发布时会发生什么

我们拿【图1】来举例

1. 首先我们启动A服务，启动后由于其他服务还未启动，所以A连接不到B，所以此时A的本地接口缓存表是空的，如下图

2. 为了避免大家觉得过程过于理想，所以接下来我启动C，而不是启动B

C启动后，由于B还没启动，所以他无法被发现，此时他是孤立的，所以本地缓存的接口依然如下：

3. 接下来就是启动B了，当B启动后，会立刻被A发现，所以A会从B获取一次接口，此时本地缓存如下：

A获取到接口以后还会再做一件事，那就是发广播，流程如下：

由于本地缓存的是接口，而很多接口都来自同一个服务，所以需要从本地缓存中先提取出这些服务的ip和端口号
经过了第1步以后，会得到一批ip和端口号（按照本示例来说，提取出来的就是B的ip和端口） A会将自己的所有接口（是自己的所有接口，不是本地缓存的接口）广播给这批IP和端口号，（按照本示例来说，A会把自己的接口广播给B）

经过广播以后，此时本地接口缓存变成了下面这样：

上面是A发现B的过程，那么C的接口如何传染给别人呢？

我们刚才都是用【图1】在举例，所以在【图1】我们可以看出B连接的是C，所以当B启动时，除了被A发现完成上面讲述的一系列流程，他还会去发现C，发现C以后，他会从C获取一次接口，所以本地缓存如下：

B拿到接口后，依然会像A一样发起一次广播，广播以后本地缓存就变成了这样：

接下来就有意思了，A和C是如何传染的？

很简单，我们先来回顾一下服务启动时的过程：

从连接的服务上获取接口【如果服务已经启动了，那就是随机从本地缓存的接口中提取一个服务，去获取那个服务上缓存的接口】
给这些服务发起广播【已经被广播过的服务直接忽略】

其实，这个流程是轮询的，并不是一次性的，所以接下来就轮到A再次执行这个过程了，当他再次执行这个过程的时候，他会从B获取到C的接口，然后将自己的接口广播给C，所以此刻变成了这样：

这样一来，所有的服务都被对方发现了。

服务宕机怎么办

1. 首先是自私机制

所谓的自私机制，就是每个服务只顾自己，不管别人，每个服务如果发现自己本地缓存的接口连接不上，那就会从本地把他下掉，至于别人，他是不管的。

2. 投票机制

这是每个服务的内部投票，跟外面无关，如果一个服务发现他本地缓存的某个接口连接不上，那么他就会给这个接口指向的服务投一票，让它从本机下线，当调通后会把票数清0，当票数积累到一定程度时，这个服务的所有接口都会被从当前服务上清理掉。【每个服务都有一套这样的机制，来维护自己的本地接口缓存】

3. 如果（下线某个服务的决定）是误判怎么办

有一个补偿机制，就是每个服务在下掉别的服务的时候，都会给被下掉的那个服务发一个通知，让他把自己从已广播列表中移除（比如A服务调不通B服务的接口，当票数累积到一定程度后，A会把B的接口全部清理掉，清理后A会给B发一个通知，让B把A从已广播列表移除，这样如果B服务没挂，那么B在下一次轮询时会把接口重新广播给A）

如果B服务明明没挂，但是A服务连续调不通，而且连下线通知都无法通知到B服务，那我只能说B服务活该了，即使是误判也比留着报错影响性能好吧。

4. 调不通的情况有很多，不一定是服务挂了，那么什么样的情况会给服务投下线票

很简单，当调用接口时，出现了以下三种异常，就会投票