iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 25
0
Software Development

從零開始土炮MQ系列 第 25

九、需求與框架規劃(3) - 軔性 Resilience

9.2 軔性 Resilience

在前面監控的部份,作為單一系統使用,基本上是可行的。但,若要運用在實際環境,還是有些問題,需要解決。

因異常終止的原因,造成其他相依服務的異常,必然會造成使用者的困擾。所以必需 確保系統在不管在何種情況下,都能持續提供服務。這種特性,又稱為不死性復原力軔性

需求四、當系統異常終止後,可自己重新啟動。

要達到這個目標,就需要額外建立一個服務,姑且先稱為 Manager。在 Node 中,增加一個 EchoLift 的元件,負責跟 Manager 的溝通。

https://ithelp.ithome.com.tw/upload/images/20191011/20107551cqItVSlpqw.png

Manager 這個服務本身的責任很單純,就是週期性的固定詢問 Node 的狀態。當 Node 無回應時,就必需進行處理,移除無反應的服務與重新啟動服務。

對本機而言,只要有權限,一個服務可以輕易控制其他服務。所以當 Node 發生異生,Manager 就可以直接刪除、建立 Node 的服務。

但對於兩支服務放置於不同主機的情形下,就沒有那麼容易。就需要再一個服務Agent來負責 Node 的移除與啟動。同时,它也可能作為 Node-EchoLift 與 Manager 的溝通橋樑。

https://ithelp.ithome.com.tw/upload/images/20191011/20107551pgWwXPkBa8.png

可是這樣又延伸另一個問題,ManagerAgent 要如何得知道對方的位置?最簡易的方式,就是採用 Configuration 的方式,記錄對方的位置。

當儲存在 Manager 的 configuration 之中,表示 Manager 需要主動去訪查 Agent ,Node 數量少還可以,數量一多,維運時的管理就會變成一個負擔。

依筆者的想法,將 Manager 的連線位置記錄於 Agent 的 configuration 是比較好的作法,考量點如下:

  • Manager 的角色,偏向管理,所以 Agent 啟動時,應主動跟 Manager 報備。
  • Manager 放置主機的位置可能會變更,如果 Agent 指向的是一個 Domain Name,就可以在最小影響下,變更 Manager 的主機位置。

相關的作法有 Service Registory、Service Mash、Service Disvery ,這些後面會簡單提到。有興趣的人,可以看 Rick 大寫的 聊聊分散式系統


上一篇
九、需求與框架規劃(2) - 監控
下一篇
九、需求與框架規劃(4) - 軔性 Resilience
系列文
從零開始土炮MQ30

尚未有邦友留言

立即登入留言