帶你了解微服務核心:服務治理之--服務注冊和發(fā)現

1. 背景

在微服務架構中,每個微服務通常有多個實例扎瓶,每個實例具有不同的位置所踊,而且實例會動態(tài)變化,比如在負載發(fā)生變化時服務會進行擴容或縮容概荷,失敗或者更新秕岛,服務實力的配置變化等,都會導致服務實例地址的變化误证。因此使用微服務架構開發(fā)的應用继薛,必須通過服務注冊和發(fā)現技術解決此問題。

image

2. 服務發(fā)現

使用發(fā)現服務來發(fā)現web空間提供的服務愈捅。發(fā)現服務是一個目錄服務遏考,服務在其中注冊,并根據它的屬性進行查找改鲫,簡單的說就通過服務發(fā)現找你你想調用具體應用的物理信息(ip诈皿, port等)。

有兩種主要的服務發(fā)現模式:客戶端服務發(fā)現像棘, 服務端服務發(fā)現

image

上圖展示了客戶端發(fā)現模式的架構稽亏,簡單來說:

Service Registry 類似企業(yè)黃頁,保存了所有服務的信息缕题, client通過注冊表找到對應的企業(yè)電話(是一個list)截歉, 然后客戶端使用自身提供的負載均衡算法,選擇需要的電話烟零。

當然client可以保存查找過的地址(緩存)而不需要每次都去Service Registry 獲缺袼伞咸作; 因為服務的實例(企業(yè)信息,電話)可能終止(從Registry刪除)宵睦, 或者新的服務實例加入(新的企業(yè))记罚,使得本地緩存和Registry可能有差異,(從分布式CAP的角度壳嚎,對于服務發(fā)現桐智,可用性比數據一致性更加重要,AP勝過CP烟馅,后文會簡單介紹CAP)说庭, 需要服務實例的注冊表通過心跳機制進行更新。

服務端服務發(fā)現模式

image

本質上就是LB從客戶端解耦了出來郑趁, 常見的服務發(fā)現Eureka, etcd刊驴, Consul,Zookkeeper寡润,最近阿里出了Nacos捆憎, 本文不詳細介紹工具的使用。

3. 服務注冊

服務注冊分為梭纹,Self-Registration Pattern 和 Third-party registration pattern攻礼。之前沒了解過Thrid-party,本文主要介紹Self-Registration

image

以Eureka為例栗柒, 通過DiscoveryClient這個annotaition, 在應用啟動時知举,被加載到容器中瞬沦,并注冊到注冊中心,然后通過CacheRefreshThread 和 HeartbeatThread 執(zhí)行刷新注冊信息到本地和續(xù)約任務雇锡,思路不是復雜逛钻,對于服務注冊,簡單帶過锰提。

4. CAP

說說自己的理解曙痘,引用我知乎上關于CAP的回答,舉個例子立肘, 服務或者存儲部署的機器是分region或者zone的边坤, 比如,北京移動機房谅年,北京聯(lián)通機房茧痒, 上海鐵通機房,正常情況下雖然處于不同的網絡或者運營商融蹂,但是實際是可以聯(lián)通的旺订。 但是如果部署在一個機房弄企,那么出口的網絡,光纖斷了(也可能是入口負責調度的如nginx等不可用了等)区拳,或者運營商提供的網絡出了問題拘领,那么會造成整個服務的不可訪問的問題, 所以要分區(qū)樱调, 分到不同的機房约素, 不同的運營商。就類似分region或者分zone本涕。

這樣如果一個機房出了問題业汰,或者一個一個網絡出了問題,還可以訪問其他的網絡或者機房了菩颖, 這樣就提高了分區(qū)容錯性(P)样漆。

順著這樣一個思路, 是不是越多機房(全國各個城市晦闰,國外的)放祟,越多運營網絡越好?越多可用性(A)提高了呻右, 這個就帶來了一個新的問題跪妥, 如果訪問分不到不同的機房或者網絡,數據存儲到了對應的機房声滥,機房見的訪問速度和跨城市的訪問延遲比較大眉撵, 這樣寫入到上海聯(lián)通機房的數據同步到北京移動機房的速度就會比較長,這樣造成一個新的問題就是落塑,上個用戶如果落到北京機房查詢相關的數據纽疟,這個時候上海機房的數據可能還沒有來得及復制到北京機房, 這樣造成了一個問題就是一致性(C)的問題憾赁。

所以正常情況下污朽, 都是在A -- 可用性和C--一致性之前的權衡, 是要更多的機房保證可用性龙考,還是為了快速的節(jié)點同步保證一致性蟆肆。

架構本身就是基于業(yè)務形態(tài)的平衡的權衡, 在CAP這個問題中晦款,就是A與C的權衡炎功。

5. RDF(Resource Description Framework), OSLC(Open Services for Lifecycle Collaboration)

從領域模型柬赐, 領域規(guī)范角度亡问, 服務注冊和發(fā)現解決了服務實現服務可發(fā)現的狀態(tài); 在大型公司公,不同的領域州藕,可能由于異構系統(tǒng)束世,工具,異構平臺床玻,不同的UI風格等毁涉,服務注冊和發(fā)現沒解決注冊服務之前關聯(lián)和集成關系的問題,比如現在流行的All in one, 期望整合資源锈死,整合系統(tǒng)贫堰, 解決系統(tǒng)集成的問題,更大范圍的拉通和透明化待牵。

那么就需要借鑒OLCS和RDF的經驗其屏, 通過建立領域模型,規(guī)范來解決系統(tǒng)間集成的問題缨该。核心的思路就是Linked Data偎行, 通過讓各個系統(tǒng)無縫鏈接起來。

1)服務發(fā)現

服務發(fā)現是OSLC重要特性之一贰拿,也是不太容易理解的地方蛤袒。OSLC技術規(guī)范中的服務接口不是以“固定API”的形式標識,而是通過服務發(fā)現的方式由客戶端進行層層解析得出膨更。對于客戶端而言妙真,只需要知道基礎服務的入口地址,即可根據OLSC協(xié)議荚守,逐步發(fā)現所需要的服務珍德。

從領域模型的角度,領域的scenario可以通過規(guī)范有效的組織起來矗漾,業(yè)務場景的鏈路或者pattern可以規(guī)范化菱阵,后續(xù)不管是支撐系統(tǒng)變化(從系統(tǒng)A改成系統(tǒng)B),服務版本升級缩功,只要符合領域規(guī)范,相關系統(tǒng)不需要做任何系統(tǒng)適配都办。一方面解決系統(tǒng)集成問題的同時也解決了系統(tǒng)的依賴性嫡锌。

舉個例子, 地圖行業(yè)琳钉,現在有一些坐標規(guī)范势木,但是缺乏某些應用場景的領域模型規(guī)范,比如歌懒,駕車場景啦桌,導航,自動駕駛?等甫男,如果第三方企業(yè)想要調用LBS的某些應用場景且改,需要引入web service, SDK等板驳, 以web service為例又跛,米兔如果想用地圖,當時處于不同用戶的使用習慣的角度若治,同時支持了高德和百度慨蓝,那么在沒有領域規(guī)范的情況下,需要對高德和百度的API進行適配端幼。如果另一個應用由于某些原因從一個地圖遷移到另一個礼烈,需要進行很大的適配。

如果介入OSLC的思路婆跑,如果規(guī)范了領域模型會有什么變化呢此熬?開發(fā)只關注resource和對應的資源操作能力(linked data)編程對象就是rdf中的屬性和資源(針對接口、規(guī)范編程)洽蛀,那么不管切換什么地圖應用摹迷,底層代碼不需要做任何更改。

這個思路也類似于Oauth郊供,數據庫driver峡碉,但是OSLC思路的高度會更高一個level,在解決領域問題時驮审,面臨的問題會更復雜鲫寄,不僅僅是一個接口的問題。

如下是一個服務發(fā)現的關聯(lián)圖疯淫。

image

轉載于:http://www.reibang.com/p/0c3bd308bcba

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末地来,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子熙掺,更是在濱河造成了極大的恐慌未斑,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,941評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件币绩,死亡現場離奇詭異蜡秽,居然都是意外死亡,警方通過查閱死者的電腦和手機缆镣,發(fā)現死者居然都...
    沈念sama閱讀 93,397評論 3 395
  • 文/潘曉璐 我一進店門芽突,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人董瞻,你說我怎么就攤上這事寞蚌。” “怎么了?”我有些...
    開封第一講書人閱讀 165,345評論 0 356
  • 文/不壞的土叔 我叫張陵挟秤,是天一觀的道長壹哺。 經常有香客問我,道長煞聪,這世上最難降的妖魔是什么斗躏? 我笑而不...
    開封第一講書人閱讀 58,851評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮昔脯,結果婚禮上啄糙,老公的妹妹穿的比我還像新娘。我一直安慰自己云稚,他們只是感情好隧饼,可當我...
    茶點故事閱讀 67,868評論 6 392
  • 文/花漫 我一把揭開白布采蚀。 她就那樣靜靜地躺著代芜,像睡著了一般。 火紅的嫁衣襯著肌膚如雪眉菱。 梳的紋絲不亂的頭發(fā)上鲸拥,一...
    開封第一講書人閱讀 51,688評論 1 305
  • 那天拐格,我揣著相機與錄音,去河邊找鬼刑赶。 笑死捏浊,一個胖子當著我的面吹牛,可吹牛的內容都是我干的撞叨。 我是一名探鬼主播金踪,決...
    沈念sama閱讀 40,414評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼牵敷!你這毒婦竟也來了胡岔?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 39,319評論 0 276
  • 序言:老撾萬榮一對情侶失蹤枷餐,失蹤者是張志新(化名)和其女友劉穎靶瘸,沒想到半個月后,有當地人在樹林里發(fā)現了一具尸體毛肋,經...
    沈念sama閱讀 45,775評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡奕锌,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,945評論 3 336
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現自己被綠了村生。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,096評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡饼丘,死狀恐怖趁桃,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤卫病,帶...
    沈念sama閱讀 35,789評論 5 346
  • 正文 年R本政府宣布油啤,位于F島的核電站,受9級特大地震影響蟀苛,放射性物質發(fā)生泄漏益咬。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,437評論 3 331
  • 文/蒙蒙 一帜平、第九天 我趴在偏房一處隱蔽的房頂上張望幽告。 院中可真熱鬧,春花似錦裆甩、人聲如沸冗锁。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,993評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽冻河。三九已至,卻和暖如春茉帅,著一層夾襖步出監(jiān)牢的瞬間叨叙,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,107評論 1 271
  • 我被黑心中介騙來泰國打工堪澎, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留擂错,地道東北人。 一個月前我還...
    沈念sama閱讀 48,308評論 3 372
  • 正文 我出身青樓全封,卻偏偏與公主長得像马昙,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子刹悴,可洞房花燭夜當晚...
    茶點故事閱讀 45,037評論 2 355

推薦閱讀更多精彩內容