做個微服務筆記，今天就先不講故事了！
注意：領取大廠面試題、Java全套核心面試要點等資料，私信霸哥【資料】免費領取
1、什麼是微服務
在介紹微服務時，首先得先理解什麼是微服務，顧名思義，微服務得從兩個方面去理解，什麼是"微"、什麼是"服務"， 微 狹義來講就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來 只需要2個披薩就夠了 ）。 而所謂服務，一定要區別於系統，服務一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。
2、爲什麼需要微服務？
在傳統的IT行業軟件大多都是各種獨立系統的堆砌，這些系統的問題總結來說就是擴展性差，可靠性不高，維護成本高。到後面引入了SOA服務化，但是，由於 SOA 早期均使用了總線模式，這種總線模式是與某種技術棧強綁定的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間。最終 SOA 看起來很美，但卻成爲了企業級奢侈品，中小公司都望而生畏。
服務註冊發現
服務註冊就是維護一個登記簿，它管理系統內所有的服務地址。當新的服務啓動後，它會向登記簿交待自己的地址信息。服務的依賴方直接向登記簿要 Service Provider 地址就行了。當下用於服務註冊的工具非常多 ZooKeeper，Consul，Etcd, 還有 Netflix 家的 eureka 等。服務註冊有兩種形式：客戶端註冊和第三方註冊。
1、客戶端註冊（zookeeper）
客戶端註冊是服務自身要負責註冊與註銷的工作。當服務啓動後向註冊中心註冊自身，當服務下線時註銷自己。期間還需要和註冊中心保持心跳。心跳不一定要客戶端來做，也可以由註冊中心負責（這個過程叫探活）。這種方式的缺點是註冊工作與服務耦合在一起，不同語言都要實現一套註冊邏輯。
2、第三方註冊（獨立的服務 Registrar）
第三方註冊由一個獨立的服務Registrar負責註冊與註銷。當服務啓動後以某種方式通知Registrar，然後 Registrar 負責向註冊中心發起註冊工作。同時註冊中心要維護與服務之間的信條，當服務不可用時，向註冊中心註銷服務。這種方式的缺點是 Registrar 必須是一個高可用的系統，否則註冊工作沒法進展。
3、客戶端發現
客戶端發現是指客戶端負責查詢可用服務地址，以及負載均衡的工作。這種方式最方便直接，而且也方便做負載均衡。再者一旦發現某個服務不可用立即換另外一個，非常直接。缺點也在於多語言時的重複工作，每個語言實現相同的邏輯。
4、服務端發現
服務端發現需要額外的 Router 服務，請求先打到 Router，然後 Router 負責查詢服務與負載均衡。這種方式雖然沒有客戶端發現的缺點，但是它的缺點是保證 Router 的高可用。
5、Consul
6、Eureka
7、SmartStack
8、Etcd
API 網關
API Gateway 是一個服務器，也可以說是進入系統的唯一節點。這跟面向對象設計模式中的Facade 模式很像。API Gateway 封裝內部系統的架構，並且提供 API 給各個客戶端。它還可能有其他功能，如授權、監控、負載均衡、緩存、請求分片和管理、靜態響應處理等。下圖展示了一個適應當前架構的 API Gateway。
API Gateway 負責請求轉發、合成和協議轉換。所有來自客戶端的請求都要先經過 API Gateway，然後路由這些請求到對應的微服務。API Gateway 將經常通過調用多個微服務來處理一個請求以及聚合多個服務的結果。它可以在 web 協議與內部使用的非 Web 友好型協議間進行轉換，如HTTP 協議、WebSocket 協議。
1、請求轉發
服務轉發主要是對客戶端的請求安裝微服務的負載轉發到不同的服務上。
2、響應合併
把業務上需要調用多個服務接口才能完成的工作合併成一次調用對外統一提供服務。
3、協議轉換
重點是支持 SOAP，JMS，Rest 間的協議轉換。
4、數據轉換
重點是支持 XML 和 Json 之間的報文格式轉換能力（可選）。
5、安全認證
- 基於 Token 的客戶端訪問控制和安全策略
- 傳輸數據和報文加密，到服務端解密，需要在客戶端有獨立的 SDK 代理包
- 基於 Https 的傳輸加密，客戶端和服務端數字證書支持
- 基於 OAuth2.0 的服務安全認證(授權碼，客戶端，密碼模式等）
配置中心
配置中心一般用作系統的參數配置，它需要滿足如下幾個要求：高效獲取、實時感知、分佈式訪問。
1、zookeeper 配置中心
實現的架構圖如下所示，採取數據加載到內存方式解決高效獲取的問題，藉助 zookeeper 的節點監聽機制來實現實時感知。
2、配置中心數據分類
事件調度（kafka）
消息服務和事件的統一調度，常用用 kafka ，activemq 等。
服務跟蹤（starter-sleuth）
隨着微服務數量不斷增長，需要跟蹤一個請求從一個微服務到下一個微服務的傳播過程， Spring Cloud Sleuth 正是解決這個問題，它在日誌中引入唯一 ID，以保證微服務調用之間的一致性，這樣你就能跟蹤某個請求是如何從一個微服務傳遞到下一個。
1、爲了實現請求跟蹤，當請求發送到分佈式系統的入口端點時，只需要服務跟蹤框架爲該請求創建一個唯一的跟蹤標識，同時在分佈式系統內部流轉的時候，框架始終保持傳遞該唯一標識，直到返回給請求方爲止，這個唯一標識就是前文中提到的 Trace ID。通過 Trace ID 的記錄，我們就能將所有請求過程日誌關聯起來。
2、爲了統計各處理單元的時間延遲，當請求達到各個服務組件時，或是處理邏輯到達某個狀態時，也通過一個唯一標識來標記它的開始、具體過程以及結束，該標識就是我們前文中提到的 Span ID，對於每個 Span 來說，它必須有開始和結束兩個節點，通過記錄開始 Span 和結束 Span 的時間戳，就能統計出該 Span 的時間延遲，除了時間戳記錄之外，它還可以包含一些其他元數據，比如：事件名稱、請求信息等。
3、在快速入門示例中，我們輕鬆實現了日誌級別的跟蹤信息接入，這完全歸功於spring-cloudstarter-sleuth 組件的實現。在 Spring Boot 應用中，通過在工程中引入 spring-cloudstarter-sleuth 依賴之後， 它會自動的爲當前應用構建起各通信通道的跟蹤機制，比如：
- 通過諸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 綁定器實現的消息中間件）傳遞的請求。
- 通過 Zuul 代理傳遞的請求。
- 通過 RestTemplate 發起的請求。
服務熔斷（Hystrix）
在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。
熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以後的多個調用快速失敗，不再訪問遠程服務器，從而防止應用程序不斷地嘗試執行可能會失敗的操作，使得應用程序繼續執行而不用等待修正錯誤，或者浪費 CPU時間去等到長時間的超時產生。熔斷器也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次嘗試調用操作。
Hystrix 斷路器機制
斷路器很好理解, 當 Hystrix Command 請求後端服務失敗數量超過一定比例(默認 50%)，斷路器會切換到開路狀態(Open)。這時所有請求會直接失敗而不會發送到後端服務. 斷路器保持在開路狀態一段時間後(默認 5 秒)，自動切換到半開路狀態(HALF-OPEN)。這時會判斷下一次請求的返回情況，如果請求成功，斷路器切回閉路狀態(CLOSED)，否則重新切換到開路狀態(OPEN)。Hystrix 的斷路器就像我們家庭電路中的保險絲，一旦後端服務不可用，斷路器會直接切斷請求鏈，避免發送大量無效請求影響系統吞吐量，並且斷路器有自我檢測並恢復的能力。
