Martian-cloud傳染機制的原理是什么

Martian-cloud傳染機制的原理是什么，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

先解釋下什么是傳染機制

• 常規的分布式采用的是【生產者->注冊中心->消費者】模型，生產者將接口給注冊中心，消費者從注冊中心發現其他的服務，實現調用

• 傳染機制就是丟棄注冊中心，可以把接口看做病毒，服務看做是人，服務之間只要有直接或者間接的聯系，最終都會被染上病毒（接口）

如何實現的

假如現在有三個服務

此時，需要發布這三個服務，那我們可以先規劃下，將他們連在一起，連在一起的意思是在配置里寫好誰連誰。

連接方式可以是這樣【圖1】

也可以是這樣【圖2】

也可以是這樣【圖3】

總之，只要別讓任何服務落單就行，隨便怎么連，你甚至可以來一個五花大綁（不過不建議）

-----------------------------------------------------------------

連接以后就到發布階段了，那么發布的時候，這些服務之間會發生什么呢？

發布時會發生什么

我們拿【圖1】來舉例

1. 首先我們啟動A服務，啟動后由于其他服務還未啟動，所以A連接不到B，所以此時A的本地接口緩存表是空的，如下圖

2. 為了避免大家覺得過程過于理想，所以接下來我啟動C，而不是啟動B

C啟動后，由于B還沒啟動，所以他無法被發現，此時他是孤立的，所以本地緩存的接口依然如下：

3. 接下來就是啟動B了，當B啟動后，會立刻被A發現，所以A會從B獲取一次接口，此時本地緩存如下：

A獲取到接口以后還會再做一件事，那就是發廣播，流程如下：

1. 由于本地緩存的是接口，而很多接口都來自同一個服務，所以需要從本地緩存中先提取出這些服務的ip和端口號

2. 經過了第1步以后，會得到一批ip和端口號（按照本示例來說，提取出來的就是B的ip和端口） A會將自己的所有接口（是自己的所有接口，不是本地緩存的接口）廣播給這批IP和端口號，（按照本示例來說，A會把自己的接口廣播給B）

經過廣播以后，此時本地接口緩存變成了下面這樣：

上面是A發現B的過程，那么C的接口如何傳染給別人呢？

我們剛才都是用【圖1】在舉例，所以在【圖1】我們可以看出B連接的是C，所以當B啟動時，除了被A發現完成上面講述的一系列流程，他還會去發現C，發現C以后，他會從C獲取一次接口，所以本地緩存如下：

B拿到接口后，依然會像A一樣發起一次廣播，廣播以后本地緩存就變成了這樣：

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

很簡單，我們先來回顧一下 服務啟動時的過程：

1. 從連接的服務上獲取接口【如果服務已經啟動了，那就是隨機從本地緩存的接口中提取一個服務，去獲取那個服務上緩存的接口】

2. 給這些服務發起廣播【已經被廣播過的服務直接忽略】

其實，這個流程是輪詢的，并不是一次性的， 所以接下來就輪到A再次執行這個過程了，當他再次執行這個過程的時候，他會從B獲取到C的接口，然后將自己的接口廣播給C，所以此刻變成了這樣：

這樣一來，所有的服務都被對方發現了。

服務宕機怎么辦

1. 首先是自私機制

所謂的自私機制，就是每個服務只顧自己，不管別人，每個服務如果發現自己本地緩存的接口連接不上，那就會從本地把他下掉，至于別人，他是不管的。

2. 投票機制

這是每個服務的內部投票，跟外面無關，如果一個服務發現他本地緩存的某個接口連接不上，那么他就會給這個接口指向的服務投一票，讓它從本機下線，當調通后會把票數清0，當票數積累到一定程度時，這個服務的所有接口都會被從當前服務上清理掉。【每個服務都有一套這樣的機制，來維護自己的本地接口緩存】

3. 如果（下線某個服務的決定）是誤判怎么辦

有一個補償機制，就是每個服務在下掉別的服務的時候，都會給被下掉的那個服務發一個通知，讓他把自己從已廣播列表中移除（比如A服務調不通B服務的接口，當票數累積到一定程度后，A會把B的接口全部清理掉，清理后A會給B發一個通知，讓B把A從已廣播列表移除，這樣如果B服務沒掛，那么B在下一次輪詢時 會把接口重新廣播給A）

如果B服務明明沒掛，但是A服務連續調不通，而且連下線通知都無法通知到B服務，那我只能說B服務活該了，即使是誤判也比留著報錯影響性能好吧。

4. 調不通的情況有很多，不一定是服務掛了，那么什么樣的情況會給服務投下線票

很簡單，當調用接口時，出現了以下三種異常，就會投票

• ConnectException ，連接不上，這不是404之類的，而是根本連不上這個ip:port

• UnknownHostException，無法解析地址，提供的 ip:port 無法被解析識別

• SocketTimeoutException，連接超時，不是read time out，而是 connect time out

5. 然后是垃圾回收機制

垃圾回收很簡單，就是定時去本地緩存中掃描出被下線的服務的接口，然后刪除掉。

上面這這一套機制，可以保證當服務宕機以后，接口會自動從其他的服上下線

被鏈接的那個服務宕機了 如何實現傳染

假如B掛了，這個鏈條就斷了，傳染是否會受影響呢？

其實不會，因為這個鏈條 只是啟動時有用，啟動后就作廢了，拿A來說，A只有啟動時會去B獲取接口，下次輪詢的時候，是從本地緩存的接口中隨機挑選一個服務 去獲取，所以鏈條不會斷。

至于廣播，也是廣播給本地緩存的服務，并不是配置的這個服務。

所以宕機是不會影響接口傳染的

要新添一個服務咋辦

很簡單，只需要將他連接到正在運行的 任意一個服務上即可，很快它就會渾身染滿病毒（接口）

關于Martian-cloud傳染機制的原理是什么問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。