服務注冊的方式有幾種？針對這個問題，今天小編總結這篇有關服務注冊與注冊工具的文章，可供感興趣的小伙伴們參考借鑒，希望對大家有所幫助。

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設,霍城企業(yè)網(wǎng)站建設,霍城品牌網(wǎng)站建設,網(wǎng)站定制,霍城網(wǎng)站建設報價,網(wǎng)絡營銷,網(wǎng)絡優(yōu)化,霍城網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

客戶端注冊（zookeeper）

客戶端注冊是服務自身要負責注冊與注銷的工作。當服務啟動后向注冊中心注冊自身，當服務下線時注銷自己。期間還需要和注冊中心保持心跳。心跳不一定要客戶端來做，也可以由注冊中心負責（這個過程叫探活）。這種方式的缺點是注冊工作與服務耦合在一起，不同語言都要實現(xiàn)一套注冊邏輯。

第三方注冊（獨立的服務 Registrar）

第三方注冊由一個獨立的服務Registrar負責注冊與注銷。當服務啟動后以某種方式通知Registrar，然后 Registrar 負責向注冊中心發(fā)起注冊工作。同時注冊中心要維護與服務之間的心跳，當服務不可用時，向注冊中心注銷服務。這種方式的缺點是 Registrar 必須是一個高可用的系統(tǒng)，否則注冊工作沒法進展。

客戶端發(fā)現(xiàn)

客戶端發(fā)現(xiàn)是指客戶端負責查詢可用服務地址，以及負載均衡的工作。這種方式最方便直接，而且也方便做負載均衡。再者一旦發(fā)現(xiàn)某個服務不可用立即換另外一個，非常直接。缺點也在于多語言時的重復工作，每個語言實現(xiàn)相同的邏輯。

服務端發(fā)現(xiàn)

服務端發(fā)現(xiàn)需要額外的 Router 服務，請求先打到 Router，然后 Router 負責查詢服務與負載均衡。

這種方式雖然沒有客戶端發(fā)現(xiàn)的缺點，但是它的缺點是保證 Router 的高可用。

API 網(wǎng)關
API Gateway 是一個服務器，也可以說是進入系統(tǒng)的唯一節(jié)點。這跟面向對象設計模式中的Facade 模式很像。API Gateway 封裝內(nèi)部系統(tǒng)的架構，并且提供 API 給各個客戶端。它還可能有其他功能，如授權、監(jiān)控、負載均衡、緩存、請求分片和管理、靜態(tài)響應處理等。下圖展示了一個適應當前架構的 API Gateway。

API Gateway 負責請求轉發(fā)、合成和協(xié)議轉換。所有來自客戶端的請求都要先經(jīng)過 API Gateway，然后路由這些請求到對應的微服務。API Gateway 將經(jīng)常通過調(diào)用多個微服務來處理一個請求以及聚合多個服務的結果。它可以在 web 協(xié)議與內(nèi)部使用的非 Web 友好型協(xié)議間進行轉換，如HTTP 協(xié)議、WebSocket 協(xié)議。

請求轉發(fā)

服務轉發(fā)主要是對客戶端的請求安裝微服務的負載轉發(fā)到不同的服務上響應合并

把業(yè)務上需要調(diào)用多個服務接口才能完成的工作合并成一次調(diào)用對外統(tǒng)一提供服務。

協(xié)議轉換

重點是支持 SOAP，JMS，Rest 間的協(xié)議轉換。

數(shù)據(jù)轉換

重點是支持 XML 和 Json 之間的報文格式轉換能力（可選）

安全認證

1. 基于 Token 的客戶端訪問控制和安全策略

2. 傳輸數(shù)據(jù)和報文加密，到服務端解密，需要在客戶端有獨立的 SDK 代理包

3. 基于 Https 的傳輸加密，客戶端和服務端數(shù)字證書支持

4. 基于 OAuth3.0 的服務安全認證(授權碼，客戶端，密碼模式等）

配置中心
配置中心一般用作系統(tǒng)的參數(shù)配置，它需要滿足如下幾個要求：高效獲取、實時感知、分布式訪問。

zookeeper 配置中心

實現(xiàn)的架構圖如下所示，采取數(shù)據(jù)加載到內(nèi)存方式解決高效獲取的問題，借助 zookeeper 的節(jié)點監(jiān)聽機制來實現(xiàn)實時感知。

配置中心數(shù)據(jù)分類

事件調(diào)度（kafka）
消息服務和事件的統(tǒng)一調(diào)度，常用用 kafka ，activemq 等。

服務跟蹤（starter-sleuth）
隨著微服務數(shù)量不斷增長，需要跟蹤一個請求從一個微服務到下一個微服務的傳播過程， Spring Cloud Sleuth 正是解決這個問題，它在日志中引入唯一 ID，以保證微服務調(diào)用之間的一致性，這樣你就能跟蹤某個請求是如何從一個微服務傳遞到下一個。

1. 為了實現(xiàn)請求跟蹤，當請求發(fā)送到分布式系統(tǒng)的入口端點時，只需要服務跟蹤框架為該請求創(chuàng)建一個唯一的跟蹤標識，同時在分布式系統(tǒng)內(nèi)部流轉的時候，框架始終保持傳遞該唯一標識，直到返回給請求方為止，這個唯一標識就是前文中提到的 Trace ID。通過 Trace ID 的記錄，我們就能將所有請求過程日志關聯(lián)起來。

2. 為了統(tǒng)計各處理單元的時間延遲，當請求達到各個服務組件時，或是處理邏輯到達某個狀態(tài)時，也通過一個唯一標識來標記它的開始、具體過程以及結束，該標識就是我們前文中提到的 Span ID，對于每個 Span 來說，它必須有開始和結束兩個節(jié)點，通過記錄開始 Span 和結束 Span 的時間戳，就能統(tǒng)計出該 Span 的時間延遲，除了時間戳記錄之外，它還可以包含一些其他元數(shù)據(jù)，比如：事件名稱、請求信息等。

3. 在快速入門示例中，我們輕松實現(xiàn)了日志級別的跟蹤信息接入，這完全歸功于spring-cloudstarter-sleuth 組件的實現(xiàn)。在 Spring Boot 應用中，通過在工程中引入 spring-cloudstarter-sleuth 依賴之后， 它會自動的為當前應用構建起各通信通道的跟蹤機制，比如：

? 通過諸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 綁定器實現(xiàn)的消息中間件）傳遞的請求。

? 通過 Zuul 代理傳遞的請求。

? 通過 RestTemplate 發(fā)起的請求。

服務熔斷（Hystrix）
在微服務架構中通常會有多個服務層調(diào)用，基礎服務的故障可能會導致級聯(lián)故障，進而造成整個系統(tǒng)不可用的情況，這種現(xiàn)象被稱為服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,并將不可用逐漸放大的過程。
熔斷器的原理很簡單，如同電力過載保護器。它可以實現(xiàn)快速失敗，如果它在一段時間內(nèi)偵測到許多類似的錯誤，會強迫其以后的多個調(diào)用快速失敗，不再訪問遠程服務器，從而防止應用程序不斷地嘗試執(zhí)行可能會失敗的操作，使得應用程序繼續(xù)執(zhí)行而不用等待修正錯誤，或者浪費 CPU時間去等到長時間的超時產(chǎn)生。熔斷器也可以使應用程序能夠診斷錯誤是否已經(jīng)修正，如果已經(jīng)修正，應用程序會再次嘗試調(diào)用操作。

Hystrix 斷路器機制

斷路器很好理解, 當 Hystrix Command 請求后端服務失敗數(shù)量超過一定比例(默認 50%), 斷路器會切換到開路狀態(tài)(Open). 這時所有請求會直接失敗而不會發(fā)送到后端服務. 斷路器保持在開路狀態(tài)一段時間后(默認 5 秒), 自動切換到半開路狀態(tài)(HALF-OPEN). 這時會判斷下一次請求的返回情況,如果請求成功, 斷路器切回閉路狀態(tài)(CLOSED), 否則重新切換到開路狀態(tài)(OPEN). Hystrix 的斷路器，就像我們家庭電路中的保險絲, 一旦后端服務不可用, 斷路器會直接切斷請求鏈, 避免發(fā)送大量無效請求影響系統(tǒng)吞吐量, 并且斷路器有自我檢測并恢復的能力。

API 管理
SwaggerAPI 管理工具。

看完上述內(nèi)容，你們對服務注冊與注冊工具有進一步的了解嗎？如果還想學到更多技能或想了解更多相關內(nèi)容，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀。

本文標題：服務注冊的方式有幾種
文章路徑：http://aaarwkj.com/article2/ipopoc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、電子商務、App開發(fā)、動態(tài)網(wǎng)站、Google、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)