1、服務(wù)注冊發(fā)現(xiàn)

服務(wù)注冊就是維護一個服務(wù)列表，它在管理系統(tǒng)內(nèi)所有的服務(wù)地址，當(dāng)新的服務(wù)啟動后，它會向服務(wù)列表提交自己的服務(wù)地址，服務(wù)的調(diào)用法可以直接向服務(wù)列表發(fā)送服務(wù)列表獲取請求，就能獲得所有的服務(wù)地址，只需要選取需要的服務(wù)即可。

現(xiàn)在的服務(wù)注冊工具有很多，例如ZooKeeper，Consul，Etcd、Netflix、Eureka

服務(wù)注冊有兩種形式： 客戶端注冊 和 第三方注冊。

（1）客戶端注冊： 客戶端注冊是服務(wù)自身負責(zé)注冊與注銷，當(dāng)服務(wù)啟動后向注冊中心提交服務(wù)地址，當(dāng)服務(wù)下線時注銷自己，期間還需要和注冊中心發(fā)送心跳數(shù)據(jù)，心跳機制是注冊中心用來判斷服務(wù)是否存在的機制，通常是由注冊中心進行心跳監(jiān)聽。

客戶端注冊的缺點： 注冊與服務(wù)功能相耦合。

（2）第三方注冊： 第三方注冊是由一個獨立的注冊服務(wù) Registrar 負責(zé)注冊與注銷工作，當(dāng)服務(wù)開啟時，通知 Registrar 進行注冊操作，然后 Registrar 負責(zé)向注冊中心發(fā)起注冊工作，同時維護服務(wù)與注冊中心的心跳，當(dāng)服務(wù)不可用時，Registrar 發(fā)起銷毀工作。

第三方注冊的缺點： Registrar 必須是一個高可用的系統(tǒng)，否則注冊工作無法進行。

服務(wù)發(fā)現(xiàn)有兩種形式：客戶端發(fā)現(xiàn) 和 第三方發(fā)現(xiàn)

（1）客戶端發(fā)現(xiàn)： 客戶端負責(zé)查詢可用服務(wù)地址，也負責(zé)負載均衡的實現(xiàn)。這種方式是最為直接也最為方便的一種方式，但它的缺點在于多語言時需要重復(fù)編寫相同邏輯。

（2）服務(wù)端發(fā)現(xiàn)： 服務(wù)端需要額外添加Router服務(wù)，服務(wù)請求會先發(fā)送到Router，然后Router負責(zé)查詢服務(wù)與負載均衡，這種方式的缺點在于必須保證Router的高可用。

---

2、API網(wǎng)關(guān)

API Gateway 是一個服務(wù)器，也可以說是進入系統(tǒng)的唯一通道，API Gateway內(nèi)部封裝了一個系統(tǒng)的架構(gòu)，并提供API給客戶端，它能過實現(xiàn)的功能也非常多，例如授權(quán)、監(jiān)控、負載均衡、緩存、請求分片和管理、靜態(tài)響應(yīng)處理等。

API Gateway的作用主要是負責(zé)請求轉(zhuǎn)發(fā)、合成和協(xié)議轉(zhuǎn)換，所有來自客戶端的請求都必須經(jīng)過Gateway，然后路由到對應(yīng)的微服務(wù)上，它可以調(diào)用多個微服務(wù)來處理一個請求以及聚合多個服務(wù)的結(jié)果，也可以在web協(xié)議與內(nèi)部使用的非web友好型協(xié)議進行轉(zhuǎn)換，例如HTTP協(xié)議、WebSocket協(xié)議。

（1）請求轉(zhuǎn)發(fā)： 服務(wù)轉(zhuǎn)發(fā)主要是對客戶端發(fā)起的安裝微服務(wù)的請求負載到不同的服務(wù)上。
（2）響應(yīng)合并： 將業(yè)務(wù)上需要多個接口共同作用的工作統(tǒng)合并成一次調(diào)用對外統(tǒng)一提供服務(wù)。
（3）協(xié)議轉(zhuǎn)換： 重點是支持SOAP、JMS、Rest間的協(xié)議轉(zhuǎn)換
（4）數(shù)據(jù)轉(zhuǎn)換： 重點是支持XML和JSON之間的格式轉(zhuǎn)換
（5）安全認證：

• 基于token的客戶端訪問控制和安全策略
• 傳輸數(shù)據(jù)和報文加密，到服務(wù)端解密，需要在客戶端有獨立的SDK代理包
• 基于HTTPS的傳輸加密，客戶端和服務(wù)端的數(shù)字證書支持
• 基于OAuth2.0的服務(wù)安全認證（授權(quán)碼、客戶端、密碼模式等）

---

3、配置中心

配置中心是作用于系統(tǒng)的參數(shù)配置，它需要滿足高效獲取，實時感知，分布式訪問的條件。

例如Zookeeper配置中心，采用的是數(shù)據(jù)加載到內(nèi)存，實現(xiàn)高效獲取，通過 節(jié)點監(jiān)聽機制 實現(xiàn)實時感知

---

4、事件調(diào)度

事件調(diào)度是為了解決高并發(fā)環(huán)境下，快速反饋機制的實現(xiàn)。

事件調(diào)度通過消息隊列來解決快速反饋問題，常用的消息隊列有kafka（只在乎高并發(fā)，不在乎性能），activemq、rabbitmq等等…

---

5、服務(wù)追蹤

服務(wù)跟蹤是隨著微服務(wù)數(shù)量的增長，需要跟蹤請求在微服務(wù)之間的流轉(zhuǎn)情況而采取策略。

例如 Spring Cloud Sleuth就是一種服務(wù)追蹤組件，它在日志中引入唯一ID，確保微服務(wù)調(diào)用之間的唯一性，這樣就能跟蹤請求在服務(wù)間的流轉(zhuǎn)情況。

（1）實現(xiàn)請求跟蹤： 為了實現(xiàn)請求跟蹤，當(dāng)請求發(fā)送到分布式系統(tǒng)的入口端點時，只需要服務(wù)跟蹤框架為其創(chuàng)建一個唯一標(biāo)識，同時在分布式系統(tǒng)流轉(zhuǎn)時維持這個標(biāo)識，直到完成請求，這個唯一標(biāo)識就是Trace ID，通過Trace ID的記錄，就能將請求過程日志關(guān)聯(lián)起來。

（2）統(tǒng)計各處理單元的時間延遲： 當(dāng)請求達到各個服務(wù)組件時，或者處理邏輯到達某個狀態(tài)時，通過唯一標(biāo)識來記錄它的開始、具體過程以及結(jié)束，這個標(biāo)識就是Span ID，對于每個Span都有開始和結(jié)束兩個節(jié)點，通過記錄span的開始和結(jié)束時間戳來統(tǒng)計出該Span的時間延遲，它還能存儲其它數(shù)據(jù)，例如事件名稱，請求信息等。

---

6、服務(wù)熔斷（Hystrix）

服務(wù)熔斷是為了防止基礎(chǔ)微服務(wù)因某個服務(wù)異常而產(chǎn)生的聯(lián)級故障，進而造成系統(tǒng)崩潰的情況，這種現(xiàn)象叫做服務(wù)雪崩效應(yīng)。

（1）熔斷器

當(dāng)發(fā)生服務(wù)雪崩時，就可以用到熔斷器，熔斷器的原理是在一段時間內(nèi)監(jiān)聽到許多類似的錯誤出現(xiàn)，會強迫其以后的多個調(diào)用快速失效，不再訪問遠程服務(wù)器，從而防止應(yīng)用程序不斷嘗試執(zhí)行可能會失敗的操作，使得應(yīng)用程序繼續(xù)執(zhí)行而不用等待修正錯誤，或浪費CPU去等待長時間的超時產(chǎn)生。

（2）斷路器

斷路器是一種熔斷器的實現(xiàn)，當(dāng) Hystrix Command 請求后，服務(wù)失敗數(shù)量超過一定比例（默認一半），斷路器就切換到 Open狀態(tài)，這時斷路器會直接攔截所有請求，讓請求以錯誤的狀態(tài)返回給用戶，一段時間后（默認保持5秒），自動切換到 Half-Open 狀態(tài)，這時會判斷下一次請求的返回情況，若請求成功則恢復(fù)到 Closed 狀態(tài)，否則重開 Open 狀態(tài)。

---

7、API管理

有一種工具叫 Swagger API 管理工具