微服務架構的核心技術問題

1. 微服務架構的核心技術問題

在業務規模化和研發效能提高等因素的驅動下，從單塊應用向微服務架構的轉型(以下圖所示)，已經成爲不少企業(尤爲是互聯網企業)數字化轉型的趨勢。

在微服務模式下，企業內部服務少則幾個到幾十個，多則上百個，每一個服務通常都以集羣方式部署，這時天然產生兩個問題(以下圖所示)：

1、服務發現：服務的消費方(Consumer)如何發現服務的提供方(Provider)？

2、負載均衡：服務的消費方如何以某種負載均衡策略訪問集羣中的服務提供方實例？

做爲架構師，若是你理解了這兩個問題，能夠說就理解了微服務架構在技術上的最核心問題。

 

2. 三種服務發現模式

---

服務發現和負載均衡並非新問題，業界其實已經探索和總結出一些經常使用的模式，這些模式的核心實際上是代理(Proxy，以下圖因此)，以及代理在架構中所處的位置，

在服務消費方和服務提供方之間增長一層代理，由代理負責服務發現和負載均衡功能，消費方經過代理間接訪問目標服務。根據代理在架構上所處的位置不一樣，當前業界主要有三種不一樣的服務發現模式：

2.1 模式一：傳統集中式代理

 

這是最簡單和傳統作法，在服務消費者和生產者之間，代理做爲獨立一層集中部署，由獨立團隊(通常是運維或框架)負責治理和運維。經常使用的集中式代理有硬件負載均衡器(如F5)，或者軟件負載均衡器(如Nginx)，F5(4層負載)+Nginx(7層負載)這種軟硬結合兩層代理也是業內常見作法，兼顧配置的靈活性(Nginx比F5易於配置)。

這種方式一般在DNS域名服務器的配合下實現服務發現，服務註冊(創建服務域名和IP地址之間的映射關係)通常由運維人員在代理上手工配置，服務消費方僅依賴服務域名，這個域名指向代理，由代理解析目標地址並作負載均衡和調用。

國外知名電商網站eBay，雖然體量巨大，但其內部的服務發現機制仍然是基於這種傳統的集中代理模式，國內公司如攜程，也是採用這種模式。

2.2 模式二：客戶端嵌入式代理

這是不少互聯網公司比較流行的一種作法，代理(包括服務發現和負載均衡邏輯)以客戶庫的形式嵌入在應用程序中。這種模式通常須要獨立的服務註冊中心組件配合，服務啓動時自動註冊到註冊中心並按期報心跳，客戶端代理則發現服務並作負載均衡。

Netflix開源的Eureka(註冊中心)[附錄1]和Ribbon(客戶端代理)[附錄2]是這種模式的典型案例，國內阿里開源的Dubbo也是採用這種模式。

2.3 模式三：主機獨立進程代理

這種作法是上面兩種模式的一個折中，代理既不是獨立集中部署，也不嵌入在客戶應用程序中，而是做爲獨立進程部署在每個主機上，一個主機上的多個消費者應用能夠共用這個代理，實現服務發現和負載均衡，以下圖所示。這個模式通常也須要獨立的服務註冊中心組件配合，做用同模式二。

Airbnb的SmartStack[附錄3]是這種模式早期實踐產品，國內公司惟品會對這種模式也有探索和實踐。

 

3. 三種服務發現模式的比較

---

上面介紹的三種服務發現模式各有優劣，沒有絕對的好壞，能夠認爲是三種不一樣的架構風格，在不一樣的公司都有成功實踐。下表總結三種服務發現模式的優劣比較，業界案例和適用場景建議，供架構師選型參考：

 

4. 服務網格ServiceMesh

---

所謂的ServiceMesh，其實本質上就是上面提到的模式三~主機獨立進程模式，這個模式其實並不新鮮，業界(國外的Airbnb和國內的惟品會等)早有實踐，那麼爲何如今這個概念又流行起來了呢？我認爲主要緣由以下：

1. 上述模式一和二有一些固有缺陷，模式一相對比較重，有單點問題和性能問題；模式二則有客戶端複雜，支持多語言困難，沒法集中治理的問題。模式三是模式一和二的折中，彌補了二者的不足，它是純分佈式的，沒有單點問題，性能也OK，應用語言棧無關，能夠集中治理。
2. 微服務化、多語言和容器化發展的趨勢，企業迫切須要一種輕量級的服務發現機制，ServiceMesh正是迎合這種趨勢誕生，固然這還和一些大廠(如Google/IBM等)的背後推進有關。

模式三(ServiceMesh)也被形象稱爲邊車(Sidecar)模式，以下圖，早期有一些摩托車，除了主駕駛位，還帶一個邊車位，能夠額外坐一我的。在模式三中，業務代碼進程(至關於主駕駛)共享一個代理(至關於邊車)，代理除了負責服務發現和負載均衡，還負責動態路由、容錯限流、監控度量和安全日誌等功能，這些功能是具體業務無關的，屬於跨橫切面關注點(Cross-Cutting Concerns)範疇。

在新一代的ServiceMesh架構中(下圖上方)，服務的消費方和提供方主機(或者容器)兩邊都會部署代理SideCar。ServiceMesh比較正式的術語也叫數據面板(DataPlane)，與數據面板對應的還有一個獨立部署的控制面板(ControlPlane)，用來集中配置和管理數據面板，也能夠對接各類服務發現機制(如K8S服務發現)。術語數據面板和控制面板，估計是偏網絡SDN背景的人提出來的。

上圖左下角，每一個主機上同時居住了業務邏輯代碼(綠色表示)和代理(藍色表示)，服務之間經過代理髮現和調用目標服務，造成服務之間的一種網絡狀依賴關係，控制面板則能夠配置這種依賴調用關係，也能夠調撥路由流量。若是咱們把主機和業務邏輯剝離，就出現一種網格狀架構(上圖右下角)，服務網格由此得名。

Istio[附錄4]是Google/IBM等大廠支持和推動的一個ServiceMesh標準化工做組，上圖是Istio給出的ServiceMesh參考架構。Istio專一在控制面板的架構、功能、以及控制面板和數據面板之間API的標準化，它的控制面板功能主要包括：

• Istio-Manager：負責服務發現，路由分流，熔斷限流等配置數據的管理和下發
• Mixer：負責收集代理上採集的度量數據，進行集中監控
• Istio-Auth：負責安全控制數據的管理和下發

Envoy[附錄5]是目前Istio主力支持的數據面板代理，其它主流代理如nginx/kong等也正在陸續加入這個陣營。kubernetes是目前Isito主力支持的容器雲環境。

 

5. 結論

---

1. 服務註冊發現和負載均衡是微服務架構在技術上的根本問題，解決的辦法是採用代理Proxy。根據代理在架構上的位置不一樣，服務發現代理通常有三種模式：

• 模式一：集中式代理
• 模式二：客戶端嵌入式代理
• 模式三：主機獨立進程代理

這三種模式沒有絕對的好還之分，只是三種不一樣的架構風格，各有優劣和適用場景，在不一樣企業都有成功落地案例。

2. ServiceMesh本質上就是模式三~主機獨立進程代理，它結合了模式一和模式二的優點，可是分佈式部署運維管理開銷大。Istio對ServiceMesh的架構、功能和API進行了標準化。

3. ServiceMesh還在演進中，生產落地仍有挑戰，通常企業不建議生產級使用。集中式代理最成熟，對於通常中小企業，建議從集中式代理開始，等達到必定規模和具有必定的研發運維能力，再根據須要考慮其它服務發現模式。

4. 架構師不要盲目追新，在理解微服務架構原理的基礎上，能夠學習和試點新技術，可是對於生產級應用，應該以成熟穩定，有大規模落地案例做爲選型第一準則。

6. 附錄

---

1. Netflix Eureka https://github.com/netflix/eureka
2. Netflix Ribbon https://github.com/netflix/ribbon
3. Airbnb SmartStack https://medium.com/airbnb-engineering/smartstack-service-discovery-in-the-cloud-4b8a080de619
4. Istio https://istio.io/
5. Envoy https://www.envoyproxy.io/
6. Traefik https://github.com/containous/traefik
7. Kong https://github.com/kong/kong
8. Radar https://github.com/ppdai-incubator/radar

摘自：http://www.javashuo.com/article/p-kbhgnrby-bb.html