如何快速搞定微服務架構?

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

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

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

可擴充套件性

可用性

彈性

獨立、自主性

去中心化治理

故障隔離

自動調配

通過 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 的處理。

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

程式設計師面試社群：236283328

聚合器模式

問題：雖然我們已經在 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，是一種常見的實現方式。

程式設計師面試社群：236283328

健康檢查

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

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

解決方案：每個服務都需要有一個端點，通過諸如 /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）、和持續交付方式等。