1. 背景
在微服務架構中,每個微服務通常有多個實例扎瓶,每個實例具有不同的位置所踊,而且實例會動態(tài)變化,比如在負載發(fā)生變化時服務會進行擴容或縮容概荷,失敗或者更新秕岛,服務實力的配置變化等,都會導致服務實例地址的變化误证。因此使用微服務架構開發(fā)的應用继薛,必須通過服務注冊和發(fā)現技術解決此問題。
2. 服務發(fā)現
使用發(fā)現服務來發(fā)現web空間提供的服務愈捅。發(fā)現服務是一個目錄服務遏考,服務在其中注冊,并根據它的屬性進行查找改鲫,簡單的說就通過服務發(fā)現找你你想調用具體應用的物理信息(ip诈皿, port等)。
有兩種主要的服務發(fā)現模式:客戶端服務發(fā)現像棘, 服務端服務發(fā)現
上圖展示了客戶端發(fā)現模式的架構稽亏,簡單來說:
Service Registry 類似企業(yè)黃頁,保存了所有服務的信息缕题, client通過注冊表找到對應的企業(yè)電話(是一個list)截歉, 然后客戶端使用自身提供的負載均衡算法,選擇需要的電話烟零。
當然client可以保存查找過的地址(緩存)而不需要每次都去Service Registry 獲缺袼伞咸作; 因為服務的實例(企業(yè)信息,電話)可能終止(從Registry刪除)宵睦, 或者新的服務實例加入(新的企業(yè))记罚,使得本地緩存和Registry可能有差異,(從分布式CAP的角度壳嚎,對于服務發(fā)現桐智,可用性比數據一致性更加重要,AP勝過CP烟馅,后文會簡單介紹CAP)说庭, 需要服務實例的注冊表通過心跳機制進行更新。
服務端服務發(fā)現模式
本質上就是LB從客戶端解耦了出來郑趁, 常見的服務發(fā)現Eureka, etcd刊驴, Consul,Zookkeeper寡润,最近阿里出了Nacos捆憎, 本文不詳細介紹工具的使用。
3. 服務注冊
服務注冊分為梭纹,Self-Registration Pattern 和 Third-party registration pattern攻礼。之前沒了解過Thrid-party,本文主要介紹Self-Registration
以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)圖疯淫。