老司機避坑指南：如何快速搞定微服務架構?

如今，微服務架構已經成為了現代應用開發的首選。雖然它能夠解決大部分的程式問題，但是它並非一顆百試不爽的“銀彈”。

在採用這種架構之前，我們應當事先了解可能出現的各種問題及其共性，預先為這些問題準備好可重用的解決方案。

那麼，在開始深入討論微服務的不同設計模式之前，讓我們先了解一下微服務架構的一些構建原則：

• 可擴充套件性

• 可用性

• 彈性

• 獨立、自主性

• 去中心化治理

• 故障隔離

• 自動調配

• 透過 DevOps 實現持續交付

在遵循上述各條原則的同時，我們難免會碰到一些挑戰。下面我們來具體討論可能出現的各種問題、及其解決方案。

分解模式

按照業務功能分解

問題：微服務是有關鬆散耦合的服務，它採用的是單一職責原則。雖然我們在邏輯原理上都知道要將單個應用分成多個小塊，但是在實際操作中，我們又該如何將某個應用程式成功分解成若干個小的服務呢？

解決方案：有一種策略是按照業務功能進行分解。此處的業務功能是指能夠產生價值的某種業務的最小單位。那麼一組給定業務的功能劃分則取決於企業本身的型別。

例如，一家保險公司的功能通常會包括：銷售、營銷、承保、理賠處理、結算、合規等方面。每一個業務功能都可以被看作是一種面向業務、而非技術的服務。

按照子域分解

問題：按照業務功能對應用程式進行分解只是一個良好的開端，之後您可能會碰那些不易分解的所謂“神類”（God Classes）。這些類往往會涉及到多種服務。

例如，訂單類就會被訂單管理、訂單接受、訂單交付等服務所使用到，那麼我們又該如何分解呢？

解決方案：對於“神類”的問題，DDD（Domain Driven Design，領域驅動設計）能夠派上用場。

它使用子域（Subdomain）和邊界上下文（Bounded Context）的概念來著手解決。

DDD 會將企業的整個域模型進行分解，並建立出多個子域。每個子域將擁有一個模型，而該模型的範圍則被稱為邊界上下文。那麼每個微服務就會圍繞著邊界上下文被開發出來。

注意：識別子域並不是一件容易的事，我們需要透過分析業務與組織架構，識別不同的專業領域，來對企業加強了解。

刀砍模式（Strangler Pattern）

問題：前面我們討論的設計模式一般適用於針對那些“白手起家”的 Greenfield 應用進行分解。

但是我們真實接觸到的、約佔 80％ 的是 Brownfield 應用，即：一些大型的、單體應用（Monolithic Application）。

由於它們已經被投入使用、且正在執行，如果我們簡單按照上述方式，同時對它們進行小塊服務的分解，將會是一項艱鉅的任務。

解決方案：此時，刀砍模式（Strangler Pattern）就能派上用場了。我們可以把扼殺模式想象為用刀砍去纏在樹上的藤蔓。

該方案適用於那些反覆進行呼叫的 Web 應用程式。對於每一個 URI（統一資源識別符號）的呼叫來說，單個服務可以被分解為不同的域和單獨的子服務。其設計思想是一次僅處理一個域。

這樣，我們就可以在同一個 URI 空間內並行地建立兩套獨立的應用程式。最終，在新的應用重構完成後，我們就能“刀砍”或替換掉原來的應用程式，直到最後我們可以完全關閉掉原來的單體應用。

整合模式

API 閘道器模式

問題：當一個應用程式被分解成多個小的微服務時，我們需要關注如下方面。

具體如下：

• 如何透過呼叫多個微服務，來抽象出 Producer（生產者）的資訊。

• 在不同的渠道上（如電腦桌面、移動裝置和平板電腦），應用程式需要不同的資料來響應相同的後端服務，比如：UI（使用者介面）就可能會有所不同。

• 不同的 Consumer（消費者）可能需要來自可重用式微服務的不同響應格式。誰將去做資料轉換或現場操作？

• 如何處理不同型別的協議？特別是一些可能不被 Producer 微服務所支援的協議。

解決方案：API 閘道器將有助於解決在微服務實施過程中所涉及到的上述關注點。

具體如下：

• API 閘道器是任何微服務呼叫的統一入口。

• 它像代理服務一樣，能夠將一個微服務請求路由到其相關的微服務處，並抽象出 Producer 的細節。

• 它既能將一個請求扇出（fan out，輸出）到多個服務上，也能彙總多個結果，併發回給 Consumer。

• 鑑於通用 API 無法解決 Consumer 的所有請求，該方案能夠為每一種特定型別的客戶端建立細粒度的 API。

• 它也可以將某種協議請求（如：AMQP）轉換為另一種協議（如：HTTP），反之亦然，從而方便了 Producer 和 Consumer 的處理。

• 它也可以將認證與授權儲存庫從微服務中解除安裝出去。

聚合器模式

問題：雖然我們已經在 API 閘道器模式中討論瞭如何解決聚合資料的問題，不過我們仍將做進一步的討論。

當我們將業務功能分解成多個較小的邏輯程式碼塊時，有必要思考每個服務的返回資料是如何進行協作的。

顯然，該責任不會留給 Consumer，那麼我們就需要理解 Producer 應用的內部實現。

解決方案：聚合器模式將有助於解決該問題。它涉及到如何聚合來自不同服務的資料，然後向 Consumer 傳送最終響應。

具體說來，我們有如下兩種實現方法：

• 複合微服務（Composite Microservice）將會去呼叫全部所需的微服務，整合各種資料，並在回傳之前轉換資料。

• API 閘道器（API Gateway）也能對多個微服務的請求進行 Partition（分割槽），並在傳送給 Consumer 之前聚合資料。

我們建議：如果您用到了任何業務邏輯的話，請選用複合微服務；否則請採用 API 閘道器方案。

客戶端 UI 合成模式

問題：當各種服務按照業務功能和子域被分解開發時，它們需要根據使用者體驗的預期效果，從一些不同的微服務中提取資料。

在過去的單體應用中，我們只要從 UI 到後端服務的唯一呼叫中獲取所有的資料，並重新整理和提交到 UI 頁面上便可。如今，情況則不同了。

解決方案：對於微服務來說，UI 必須被設計成單屏、單頁面的多段、多區域的結構。

每一段都會去呼叫單獨的後端微服務，以提取資料。像 Angular JS 和 React JS 之類的框架都能夠實現為特定的服務合成 UI 元件。

透過被稱為單頁應用（Single Page Applications，SPA）的方式，它們能夠使得應用程式僅重新整理螢幕的特定區域，而不是整個頁面。

資料庫模式

按服務分配資料庫

問題：您可能會碰到如何定義資料庫架構的微服務問題。

下面是具體的關注點：

• 服務必須是鬆散耦合的，以便能夠被二次開發、部署和獨立擴容。

• 各個業務交易需要在橫跨多個服務時，仍保持不變。

• 某些業務交易需要從多個服務中查詢到資料。

• 資料庫有時需要根據規模需求被複制與分片。

• 不同的服務具有不同的資料儲存需求。

解決方案：為了解決上述需求，我們需要透過設計為每個微服務配備一個獨享的資料庫模式。

即：該資料庫僅能被其對應微服務的 API 單獨訪問，而不能被其他服務直接訪問到。

例如，對於關係型資料庫，我們可以使用：按服務分配私有表集（private-tables-per-service）、按服務分配表結構（schema-per-service）、或按服務分配資料庫伺服器（database-server-per-service）。

每個微服務應該擁有一個單獨的資料庫 ID，以便它們在獨享訪問的同時，禁止再訪問其他的服務表集。

按服務共享資料庫

問題：上面討論的按服務分配資料庫是一種理想的微服務模式，它一般被前面提到的 Greenfield 應用和 DDD 式的開發。但是，如果我們面對的是需要採用微服務的單體應用就沒那麼容易了。

解決方案：按服務共享資料庫的模式雖然有些違背微服務的理念，但是它對於將前面提到的 Brownfield 應用（非新建應用）分解成較小的邏輯塊是比較適用的。

在該模式下，一個資料庫可以匹配不止一個的微服務，當然也至多 2～3 個，否則會影響到擴容、自治性和獨立性。

命令查詢職責隔離（CQRS）

問題：對於按服務分配資料庫的模式而言，我們如何在微服務的架構中，實現對多個服務進行聯合查詢資料的需求呢？

解決方案：CQRS 建議將應用程式拆分成兩個部分：命令和查詢。命令部分主要處理建立、更新和刪除之類的請求；查詢部分則利用物化檢視（Materialized Views）來處理各種查詢。

它通常配合事件溯源模式（Event Sourcing Pattern）一起建立針對任何資料的變更事件。而物化檢視則透過訂閱事件流，來保持更新。

Saga 模式

問題：當每個服務都有自己的資料庫，而且業務交易橫跨多個服務時，我們該如何確保整體業務資料的一致性呢？

例如：對於某個帶有客戶信用額度標識的電商應用而言，它需要確保新的訂單不會超出客戶的信用額度。

但是，由於訂單和客戶分屬不同的資料庫，應用程式無法簡單地實現本地交易的 ACID（原子性、一致性、隔離性、永續性）特性。

解決方案：Saga 代表了一個高層次的業務流程，它是由一個服務中的多個子請求，並伴隨著逐個更新的資料所組成。在某個請求失敗時，它的補償請求會被執行。

實現方式有如下兩種：

• 編排（Choreography）：沒有中央協調器，每個服務都會產生並偵聽其他服務的事件，以決定是否應採取行動。

• 協調（Orchestrator）：由一箇中央協調器（物件）負責集中處理某個事件（Saga）的決策，和業務邏輯的排序。

觀測模式

日誌聚合

問題：我們來考慮這樣一個用例：某個應用程式包括了那些在多臺機器上執行的多個服務例項，各種請求橫跨在這些多個服務例項之中。同時，每個服務例項都會生成一種標準格式的日誌檔案。

那麼我們如何針對某個特定的請求，透過各種日誌來理解該應用程式的行為呢？

解決方案：顯然，我們需要一個集中化的日誌服務，將各個服務例項的日誌予以聚合，以便使用者對日誌進行搜尋和分析。他們可以針對日誌中可能出現的某些訊息，配置相應的警告。

例如：PCF（Pivotal Cloud Foundry）平臺擁有一個日誌聚合器，它從每種元素（如：路由器、控制器等）中收集與應用相關的日誌。而 AWS Cloud Watch 也具有相似的功能。

效能指標

問題：當各種服務組合隨著微服務架構變得越來越複雜時，監控交易的完整性，並能夠在出現問題時及時發出警告，就顯得尤為重要了。那麼我們該如何收集與應用相關的效能指標呢？

解決方案：為了收集不同操作的統計資訊，並提供相應的報告和警告。

我們一般會用兩種模式來聚集各項指標：

• 推式：將各項指標推給專門的指標服務，如：NewRelic 和 AppDynamics。

• 拉式：從指標服務處拉取各項指標，如：Prometheus。

分散式跟蹤

問題：在微服務架構中，橫跨多個服務的請求是比較常見的。某個服務需要透過橫跨多個服務去執行一到多項操作，才能處理一些特定的請求。

那麼，我們該如何透過跟蹤某個端到端的請求，以獲知出現的問題呢？

解決方案：我們需要一種具有特性的服務。

具體特性服務如下：

• 為每個外部請求分配一個唯一的 ID。

• 將該外部請求 ID 傳給所有的服務。

• 在所有的日誌訊息中都包含該外部請求 ID。

• 在集中式服務中，記錄處理外部請求的相關資訊，包括：開始時間、結束時間、和執行時間。

Spring Cloud Slueth + Zipkin Server，是一種常見的實現方式。

健康檢查

問題：我們在實施微服務架構的過程中，可能會碰到某個服務雖已啟動，但是無法處理交易的情況。

那麼，我們該如何透過負載均衡的模式，來確保請求不會“落入”失敗的例項中呢？

解決方案：每個服務都需要有一個端點，透過諸如 /health 的引數，對應用進行健康檢查。

該 API 需要能夠檢查主機的狀態，其他服務與基礎設施的連線性，以及任何特定的邏輯關係。

Spring Boot Actuator 不但能夠實現端點的健康檢查，還能夠被定製實施。

橫切關注點模式（Cross-Cutting Concern Patterns）

外部配置

問題：通常情況下，一個服務需要去呼叫其他的服務和資料庫。在諸如開發、QA（Quality Assurance，質量保證）、UAT（User Acceptance Test，使用者驗收測試）、和生產環境中，端點的 URL、或某些配置的屬性會有所不同。

因此，有時候我們需要對這些服務的各種屬性進行重構、和重新部署。那麼我們如何避免在配置變更中修改程式碼呢？

解決方案：外部化（externalize）所有的配置，包括各個端點的 URL 和信任憑據，以保證應用程式在啟動時、或執行中能夠載入它們。

Spring Cloud 配置伺服器提供了向 GitHub 進行屬性外部化的選項，並將其作為環境屬性予以載入。

此法保證了應用程式能夠在啟動時就被訪問到，或是在不重啟伺服器的情況下實現重新整理。

服務發現模式

問題：當微服務初具規模時，我們需要考慮如下兩個關於呼叫服務方面的問題。

具體問題如下：

• 由於採用了容器技術，IP 地址往往被動態地分配給不同的服務例項。因此，每次當 IP 地址發生變化時，Consumer 服務可能會受到影響，需要我們手動更改。

•  Consumer 需要記住每個服務的 URL，這就倒退成了緊耦合的狀態。

那麼，Consumer 或路由器該如何獲知所有可用的服務例項與位置呢？

解決方案：我們需要建立一個服務登錄檔，來儲存每個 Producer 服務的後設資料（Meta Data）。

一個服務例項在啟動時，應當被註冊到表中；而在關閉時，需從表中被登出。

Consumer 或路由器透過查詢該登錄檔，就能夠找到服務的位置。Producer 服務也需要對該登錄檔進行健康檢查，以確保能夠消費到那些可用的、且正在執行的服務例項。

我們一般有兩種服務發現的型別：客戶端和伺服器端。使用客戶端發現的例子是 Netflix Eureka；而使用伺服器端發現的例子是 AWS ALB。

斷路器模式

問題：有時候，某個服務在呼叫其他服務，以獲取資料的時候，會出現下游服務（Downstream Service）“掉線”的情況。

它一般會帶來兩種結果：

• 該請求持續發往該掉線服務，直至網路資源耗盡和效能降低。

• 使用者產生不可預料的、較差的使用體驗。

那麼我們該如何避免服務的連鎖故障，並妥善處置呢？

解決方案：Consumer 應該透過一個代理來呼叫某項遠端服務，就像電路中的斷路器一樣。

當出現持續失敗的數量超過設定閾值時，斷路器就會“跳閘”一段時間，從而導致所有呼叫遠端服務的嘗試被立即切斷。

在超過設定時間之後，斷路器只允許有限數量的測試請求透過。而如果這些請求成功了，那麼斷路器將恢復正常執行；否則判定為故障依舊，並重新開始新的定時週期。

Netflix Hystrix 就很好地使用了該斷路器模式。它可以在斷路器“跳閘”的時候，幫助您定義一種回退機制，以提供更好的使用者體驗。

藍綠部署模式

問題：在微服務架構中，一個應用程式可以有多個微服務。如果我們為了部署一個增強版，而停止所有的服務，那麼停機時間一旦過長，就會對業務造成影響。

況且，這對於回退來說也將會是一場噩夢。那麼我們該如何避免、或減少部署過程中服務的停機時間呢？

解決方案：我們可以採用藍綠部署的策略，以減少或消除停機時間。在藍、綠兩個相同的生產環境中，我們假設綠色環境有著當前真實的例項，而藍色環境具有應用程式的最新版本。

在任何時候，只有一個環境能夠處理所有真實的流量，並對外提供服務。如今，所有的雲服務平臺都能提供基於藍綠部署的選項。

當然，我們還可以採用許多其他的微服務架構模式，如：Sidecar 模式、鏈式微服務（Chained Microservice）、分支微服務（Branch Microservice）、事件溯源模式（Event Sourcing Pattern）、和持續交付方式等。

本文作者：Rajesh Bhojwani，陳峻編譯

原文連結：https://mp.weixin.qq.com/s/gsY6MgmNND1MQmYka0b-Cw