文章目錄
面向面試的博客，以問答式Q/A方式呈現。
Question1：談一談 服務註冊與服務發現 ？
Answer1：
服務註冊就是維護一個登記簿，它管理系統內所有的服務地址。當新的服務啓動後，它會向登記簿交待自己的地址信息。服務的依賴方直接向登記簿要Service Provider地址就行了。當下用於服務註冊的工具非常多，如ZooKeeper，Consul，Etcd, 還有 Netflix 家的 eureka 等。服務註冊有兩種形式：客戶端註冊和第三方註冊。
客戶端註冊 （zookeeper ）
客戶端註冊是服務自身要負責註冊與註銷的工作。當服務啓動後向註冊中心註冊自身，當服務下線時註銷自己。期間還需要和註冊中心保持心跳。心跳不一定要客戶端來做，也可以由註冊中心負責（這個過程叫探活）。這種方式的缺點是註冊工作與服務耦合在一起，不同語言都要實現一套註冊邏輯。
客戶端註冊如下圖所示：
對於上圖解釋：
需要註冊的服務Sevice，直接於服務註冊中心Service Register打交道，兩者之間有三個方法，包括註冊register()、心跳heartbeat()、註銷/取消註冊unregister()，在這裏，需要註冊服務與註冊中心耦合在一起，不符合低耦合的設計思想，且看第三方註冊(獨立的服務Register)。
第三方註冊 （ 獨立的服務 Registrar ）
第三方註冊由一個獨立的服務Registrar負責註冊與註銷。當服務啓動後以某種方式通知Registrar，然後 Registrar 負責向註冊中心發起註冊工作。同時註冊中心要維護與服務之間的心跳，當服務不可用時，向註冊中心註銷服務。這種方式的缺點是 Registrar 必須是一個高可用的系統，否則註冊工作沒法進展。
第三方註冊如下圖所示：
對於上圖解釋：
需要註冊的服務Sevice，與獨立的第三方服務Registrar打交道，當服務啓動後以某種方式通知Registrar，期間Registrar每隔固定時間向服務Service發出心跳檢查heartcheck，檢查服務是否存活。
這樣一來，服務Service可以去完全自己的業務邏輯，不需要在額外註冊、額外註銷、實時心跳通知服務註冊中心。
由獨立的服務Registrar直接於服務註冊中心Service Register打交道，兩者之間有三個方法，包括註冊register()、心跳heartbeat()、註銷/取消註冊unregister()。當服務啓動後通知Registrar，Registrar向服務註冊中心註冊該服務；服務啓動後，Registrar按間隔時間對服務進行心跳檢查heartcheck，若服務存活，調用heartbeat()彙報給服務註冊中心，若服務不存活，調用unregsister()向服務註冊中心註銷該服務。
小結：第三方註冊使用獨立的服務Registrar，將註冊服務於註冊中心分離開來，符合低耦合的設計思想，當然，這種方式相對於客戶端註冊要額外提供一個高可用的Registrar系統。
客戶端發現
客戶端發現是指客戶端負責查詢可用服務地址，以及負載均衡的工作。這種方式最方便直接，而且也方便做負載均衡。再者一旦發現某個服務不可用立即換另外一個，非常直接。缺點也在於多語言時的重複工作，每個語言實現相同的邏輯。
客戶端發現如下圖所示：
對於上圖解釋：
運行中的服務Sevice作爲客戶端Client，使用http請求直接與服務端打交道，直接查詢可用服務地址，用來實現負載均衡的工作。這種方式設計簡單，但是客戶端服務與服務端耦合在一起，不符合低耦合的設計思想，且看服務端註冊。
服務端發現
服務端發現需要額外的 Router 服務，請求先打到 Router，然後 Router 負責查詢服務與負載均衡。這種方式雖然沒有客戶端發現的缺點，但是它的缺點是保證 Router 的高可用。
服務端發現如下圖所示：
對於上圖解釋：
運行中的服務Sevice作爲客戶端Client，通過使用request請求與Router路由溝通，由 Router 負責查詢服務與負載均衡，服務Service不再過問查詢服務和負載均衡的事。
小結：服務端註冊，通過Router路由來代替客戶端查詢服務端，減輕客戶端Service負擔，當然，這種方式相對於客戶端發現要要額外提供一個高可用的Router系統。
Question2：介紹一下“API網關/API Gateway”?
Answer2：
API Gateway 是一個服務器，也可以說是進入系統的唯一節點。這跟面向對象設計模式中的Facade 模式很像。API Gateway 封裝內部系統的架構，並且提供 API 給各個客戶端。它還可能有其他功能，如授權、監控、負載均衡、緩存、請求分片和管理、靜態響應處理等。下圖展示了一個適應當前架構的 API Gateway。
上圖表示，API網關要監控幾乎所有其他的業務模塊，shopping cart service購物車服務、shopping service購物服務、inventory service庫存清單服務、recommendation service推薦服務、order service訂單服務、review service評論服務、product catalog service產品種類服務。
API Gateway 負責請求轉發、合成和協議轉換。所有來自客戶端的請求都要先經過 API Gateway，然後路由這些請求到對應的微服務。API Gateway 將經常通過調用多個微服務來處理一個請求以及聚合多個服務的結果。它可以在 web 協議與內部使用的非 Web 友好型協議間進行轉換，如HTTP 協議、WebSocket 協議。
請求轉發
服務轉發主要是對客戶端的請求安裝微服務的負載轉發到不同的服務上。
響應合併
把業務上需要調用多個服務接口才能完成的工作合併成一次調用對外統一提供服務。
協議轉換
重點是支持 SOAP，JMS，Rest 間的協議轉換。
數據轉換
重點是支持 XML 和 Json 之間的報文格式轉換能力（可選）。
安全認證
- 基於 Token 的客戶端訪問控制和安全策略
- 傳輸數據和報文加密，到服務端解密，需要在客戶端有獨立的 SDK 代理包
- 基於 Https 的傳輸加密，客戶端和服務端數字證書支持
- 基於 OAuth2.0 的服務安全認證(授權碼，客戶端，密碼模式等）
Question3：簡要介紹一下微服務架構配置中心？
Answer3：
配置中心一般用作系統的參數配置，它需要滿足如下幾個要求：高效獲取、實時感知、分佈式訪問。
舉例：zookeeper 配置中心
實現的架構圖如下所示，採取數據加載到內存方式解決高效獲取的問題，藉助 zookeeper 的節點監聽機制來實現實時感知。
上圖表示，配置中心zookeeper，一旦有任何信息變更，會被觀察者watcher觀察到，然後通知業務邏輯層，再到接入層。
配置中心數據分類
上圖表示，配置中心(conf center，全稱configuration center)包括服務配置、各類開關、業務配置。
服務配置包括數據庫服務配置、隊列服務配置、緩存服務配置等；
各類開關包括各類功能開關、各類業務開關、各類服務開關；
業務配置如上圖，包括模塊A application src A（app src A1+app src A2），模塊B application src B（app src B1+app src B2）等。
Question4：簡述一下 事件調度 （kafka ）？
Answer4：
消息服務和事件的統一調度，常用用 kafka ，activemq 等。
Question5：簡要介紹一下 服務跟蹤 （ starter-sleuth ）？
Answer5：
隨着微服務數量不斷增長，需要跟蹤一個請求從一個微服務到下一個微服務的傳播過程， SpringCloud Sleuth 正是解決這個問題，它在日誌中引入唯一 ID，以保證微服務調用之間的一致性，這樣你就能跟蹤某個請求是如何從一個微服務傳遞到下一個。
- 爲了實現請求跟蹤，當請求發送到分佈式系統的入口端點時，只需要服務跟蹤框架爲該請求創建一個唯一的跟蹤標識，同時在分佈式系統內部流轉的時候，框架始終保持傳遞該唯一標識，直到返回給請求方爲止，這個唯一標識就是前文中提到的 Trace ID。通過 Trace ID 的記錄，我們就能將所有請求過程日誌關聯起來。
- 爲了統計各處理單元的時間延遲，當請求達到各個服務組件時，或是處理邏輯到達某個狀態時，也通過一個唯一標識來標記它的開始、具體過程以及結束，該標識就是我們前文中提到的 Span ID，對於每個 Span 來說，它必須有開始和結束兩個節點，通過記錄開始 Span 和結束 Span 的時間戳，就能統計出該 Span 的時間延遲，除了時間戳記錄之外，它還可以包含一些其他元數據，比如：事件名稱、請求信息等。
- 在快速入門示例中，我們輕鬆實現了日誌級別的跟蹤信息接入，這完全歸功於spring-cloud-starter-sleuth 組件的實現。在 Spring Boot 應用中，通過在工程中引入 spring-cloud-starter-sleuth 依賴之後， 它會自動的爲當前應用構建起各通信通道的跟蹤機制，比如：
（1）通過諸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 綁定器實現的消息中間件）傳遞的請求。
（2）通過 Zuul 代理傳遞的請求。
（3）通過 RestTemplate 發起的請求。
Question6：介紹一下服務熔斷 （Hystrix ）？
Answer6：
在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。
熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以後的多個調用快速失敗，不再訪問遠程服務器，從而防止應用程序不斷地嘗試執行可能會失敗的操作，使得應用程序繼續執行而不用等待修正錯誤，或者浪費 CPU時間去等到長時間的超時產生。熔斷器也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次嘗試調用操作。
Hystrix 斷路器機制
斷路器很好理解, 當 Hystrix Command 請求後端服務失敗數量超過一定比例(默認 50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會發送到後端服務. 斷路器保持在開路狀態一段時間後(默認 5 秒), 自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回情況,如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN). Hystrix 的斷路器就像我們家庭電路中的保險絲, 一旦後端服務不可用, 斷路器會直接切斷請求鏈, 避免發送大量無效請求影響系統吞吐量, 並且斷路器有自我檢測並恢復的能力。
