為什麼需要服務註冊中心？ 隨著服務數量的擴張，我們需要服務呼叫方能夠自動感知到服務提供方的位址，當我們對服務提供方進行橫向擴充套件的時候，服務呼叫方能夠自動感知到，這就需要服務提供方能夠在啟動或者關閉的時候自動向註冊中心註冊，而服務呼叫方直接詢問註冊中心就可以知道具體的服務提供方的位址列表，服務呼叫方可以自己根據特定的路由演算法做負載均衡， 或者服務呼叫方根本不需要知道服務提供方的具體位址，統一發給乙個**系統，由這個**系統**給對應的服務呼叫方。所以為了支援服務的彈性擴充套件，我們需要乙個獨立系統做服務發現和負載均衡，目前做服務發現有三種**模式
集中**模式一般是在服務呼叫方和服務提供方之間部署一套獨立的**系統來接收呼叫方的請求，然後配合網域名稱系統和特定的負載均衡策略以及路由演算法，**到對應的服務提供方，這個**系統一般由硬體f5裝置加7層軟體負載nginx配合網域名稱系統來使用，這種模式，有集中治理，運維簡單，而且和語言棧無關的優點，但是目前這個**系統存在單點問題，而且配置比較麻煩，由於服務呼叫者沒有之間呼叫服務提供方，所以網路上存在多一跳的開銷，目前國內主要有攜程等公司在使用
這種模式是前面兩種模式的乙個折中，將這個**放到主機的乙個獨立程式上，所有這個主機上的應用共享這個**，應用一般部署在docker容器中，主機可以是乙個物理機也可以是虛擬機器。在這個**上進行路由和負載均衡，這個模式也需要乙個模式二中獨立的註冊中心來輔助**程式做服務發現，這種模式兼具上面兩種模式的優點，但是運維較複雜，目前國內只有唯品會有這種模式的探索
邊車模式,sidecar,將乙個單獨的程序用來處理,日誌,健康,限流,服務發現等功能,和應用層完全分離,目前如果我們大多lib等軟體包的形式和應用整合來實現限流和監控,這樣增加了應用依賴,每次lib包公升級都需要將應用重新編譯發布,而邊車模式下我們可以將邏輯層和控制層分開部署.
邊車模式進化後,將這個獨立程式集群化,就成了servicemesh,也就是cncf所推薦的新一代微服務架構,將這個**程式下沉為乙個基礎服務,作為平台開放給應用程式
演化路徑
目前開源的servicemesh實現有istio
註冊中心提供了兩個服務,乙個是讓服務提供方註冊,就是寫資料,另乙個是讓服務呼叫方查詢,就是讀資料,當註冊中心集群部署後,每個節點
都可以對外提供讀寫服務,每一次寫請求都會同步到其他節點,這樣才能讓其他節點提供的讀服務正確,如果節點之間的資料複製出現不一致,那麼將導致服務呼叫方獲取到的服務提供者列表中要麼出現已經下線的節點,要麼少提供了乙個正常的節點,
提供了下線的節點,服務呼叫者可以通過重試機制呼叫其他節點,出現少提供乙個正常節點則導致服務提供方的流量不均勻,這些都是可以接受的,何況各個節點最終都會同步成功,也就是資料最終一致性,所以我們希望註冊中心是高可用的,最好能滿足最終一致性,而zookeeper是典型的cp設計,在網路分割槽情況下不可用,當節點超過半數掛掉不可用,違背了註冊中心不能因為自身任何原因破壞服務本身的可連通性
我們看下下圖zookeeper三機房5節點部署的情況下,如果機房3和機房1機房2網路出現分割槽成為孤島,zookeeper和機房3裡的其他應用不能和外部通訊,zookeeper由於聯絡不是leader將不可用,雖然zookeeper整個集群中其他4個節點依然可以對外提供服務,但是zookeeper為了保證在腦裂的情況下資料一致性,機房3的節點5將不能進行讀寫服務,這個時候機房3內的應用a雖然不能
呼叫其他機房的服務b但是可以呼叫機房3內的服務b,但是由於zookeeper5不能讀寫,所以機房內也不能讀寫,這對應用來說是完全不能接受的,我們有時候為了效能考慮還好主動修改路由策略讓應用盡量同機房呼叫,試想一下如果三個機房都出現網路分割槽相互成為孤島,那麼整個應用將不可用
[上傳失敗...(image-269105-1558422945065)]
zookeeper需要和所有的服務保持長連線,而隨著服務的頻繁發布,以及服務的健康檢查,會導致zookeeper壓力越來越大,而zookeeper並不能通過橫向擴充套件節點解決,可以提供的方案是按照業務進行拆分到不同的zookeeper集群
服務提供方是否可用,不能僅僅通過zookeeper的session是否存活判斷,tcp活性並不能反映服務的真實健康狀態,而需要完整的健康體系,cpu,記憶體,服務是否可用,資料庫是否能聯通等
指標consule
zookeeper
etcd
eureka
服務監控檢測
服務狀態,記憶體,硬碟
長連線keepalived
連線心跳
需要配置
多資料中心
支援不支援
不支援不支援
kv儲存
支援支援
支援不支援
一致性gossip
paxos
raft
無 cap
cacp
cpap
使用介面(多語言能力)
支援http和dns
客戶端http/grpc
watch支援
全量/支援long polling
支援支援 long polling
支援 long polling/大部分增量
自身監控
metrics
—metrics
metrics
安全acl /https
aclhttps支援（弱）
— spring cloud整合
已支援已支援
已支援已支援
微服務 Consul（服務註冊發現）
類似dns伺服器會根據我們的網域名稱解析出乙個ip位址，然後去請求這個ip來獲取我們想要的資料，它可以讓我們只需說我想要什麼服務即可，而不必去關心服務提供者的具體網路位置 ip 位址 埠等 目前，服務發現主要分為兩種模式，客戶端模式與服務端模式 在客戶端模式下，首先要到服務註冊中心獲取服務列表，然後...
微服務學習筆記 服務發現和註冊
服務的發現和註冊有兩種模式 這種模式下，服務端直接自己向註冊中心進行註冊 自註冊模式 而客戶端也直接通過查詢註冊中心獲取服務例項的位址來呼叫服務 客戶端有時可能會快取服務例項 這種模式的好處在於，他可以處理多平台部署問題，即如果在k8s上部署了一些服務，另一些服務在其他的遺留環境下，那麼使用這種模式...
微服務 服務註冊發現（三）Consule
consul 集群 在consul方案中，每個提供服務的節點上都要部署和執行consul的agent，所有執行consul agent節點的集合構成consul cluster。consul agent有兩種執行模式 server和client。這裡的server和client只是consul集群層...