.Net Core服務治理Consul健康檢查
繼續上一篇的話題,順便放上一篇的傳送門:點這裡。
健康檢查
經過之前的操作,我的consul已經支持自動擴展,並且調用也很靠譜。但是這裡有個問題,一旦服務列表裡的某個服務掛瞭,consul並不知道,還是會把實際無效的地址返回給我,就算重啟consul容器也無法刷新到最新的狀態。所以,咱們要監控服務可用性,主動區分出不可用服務,這種手段,就稱之為健康檢查。
進入編碼環節。老規矩,還是進入到之前我封裝好的註冊方法,在註冊時增加健康檢查的內容:
client.Agent.ServiceRegister(new AgentServiceRegistration() { ID = $"server {ip}:{port}", Name = "shenzhen-ma", Address = ip, Port = int.Parse(port), Tags = new string[] { weight }, Check = new AgentServiceCheck() { Interval = TimeSpan.FromSeconds(10),//每隔10秒發起檢查 HTTP = $"http://{ip}:{port}/v1/client/base/index",//檢查請求地址 Timeout = TimeSpan.FromSeconds(5),//超時時長5秒 DeregisterCriticalServiceAfter = TimeSpan.FromSeconds(10)//超過10秒還沒能連接到服務,就開始註銷本服務 } });
變色部分就是健康檢查的配置瞭。根據上面的配置,consul會周期性發起健康檢查,並且根據結果自動移除不可用的服務。
這次我要嚴謹一些,用真實的遠程服務器來模擬生產環境。手頭服務器太多,很多有項目在跑。仔細翻瞭翻,發現還有兩臺相對空閑的服務器,一臺是win server,另一臺centos,嘿嘿,正好。centos做consul服務器,win服務器用來做下遊調用方。
先把consul搞起來:
進去訪問下:
OK瞭,現在轉到另一臺服務器跑幾個客戶端。這裡偷個懶,直接把可運行文件拷貝過去,哈哈:
看下consul控制臺:
還是熟悉的shenzhen-ma,兩個服務已經穩穩的待在分組列表裡瞭。註意我框起來的位置,它表示服務已經通過瞭健康檢查。這時候我把5051這個程序關掉,再來看看:
5051狀態自動更新成failing,而且沒過一會兒,它就會自動移除。5050這時候去再去訪問,就訪問不到5051瞭:
再然後偷偷把5051跑起來,重新調用:
又可以訪問瞭不是?
新實例啟動自動發現,實例狀態異常自動剔除,下端調用無需任何調整,舒坦。起碼我這個懶人覺得很舒服。
tips:新的服務默認狀態是failing,註冊成功後會馬上發起一次檢查,成功後才會變更狀態。而且服務註銷沒有那麼快,耗時一般都會比設置的時間長。
最後一點
關於consul寫瞭3篇瞭,要是都看完,想在項目裡用起來是沒問題的,不過要上生產環境仍然有個隱患:單點故障。你想啊,consul這麼能幹,萬一它掛瞭可咋整。。。。所以集群是必要的,而且集群之後的服務註冊、調用自然就不能和單體一樣。這問題三言兩語還說不清,後面再寫吧。
到此這篇關於.Net Core服務治理Consul健康檢查的文章就介紹到這瞭。希望對大傢的學習有所幫助,也希望大傢多多支持WalkonNet。
推薦閱讀:
- Consul的搭建和.Net5的註冊和獲取方法(Win10簡單版)
- 一文詳解Golang中consul的基本使用
- windows下搭建Consul集群
- 基於nginx實現上遊服務器動態自動上下線無需reload的實現方法
- Docker容器Consul部署概述