如今，微服務架構(gòu)已經(jīng)成為了現(xiàn)代應用開發(fā)的首選。雖然它能夠解決大部分的程序問題，但是它并非一顆百試不爽的“銀彈”。
在采用這種架構(gòu)之前，我們應當事先了解可能出現(xiàn)的各種問題及其共性，預先為這些問題準備好可重用的解決方案。
那么，在開始深入討論微服務的不同設計模式之前，讓我們先了解一下微服務架構(gòu)的一些構(gòu)建原則：
可擴展性
可用性
彈性
獨立、自主性
去中心化治理
故障隔離
自動調(diào)配
通過 DevOps 實現(xiàn)持續(xù)交付
在遵循上述各條原則的同時，我們難免會碰到一些挑戰(zhàn)。下面我們來具體討論可能出現(xiàn)的各種問題、及其解決方案。
分解模式
按照業(yè)務功能分解
問題：微服務是有關松散耦合的服務，它采用的是單一職責原則。雖然我們在邏輯原理上都知道要將單個應用分成多個小塊，但是在實際操作中，我們又該如何將某個應用程序成功分解成若干個小的服務呢?
解決方案：有一種策略是按照業(yè)務功能進行分解。此處的業(yè)務功能是指能夠產(chǎn)生價值的某種業(yè)務的最小單位。那么一組給定業(yè)務的功能劃分則取決于企業(yè)本身的類型。
例如，一家保險公司的功能通常會包括：銷售、營銷、承保、理賠處理、結(jié)算、合規(guī)等方面。每一個業(yè)務功能都可以被看作是一種面向業(yè)務、而非技術(shù)的服務。
按照子域分解
問題：按照業(yè)務功能對應用程序進行分解只是一個良好的開端，之后您可能會碰那些不易分解的所謂“神類”(God Classes)。這些類往往會涉及到多種服務。
例如，訂單類就會被訂單管理、訂單接受、訂單交付等服務所使用到，那么我們又該如何分解呢?
解決方案：對于“神類”的問題，DDD(Domain Driven Design，領域驅(qū)動設計)能夠派上用場。
它使用子域(Subdomain)和邊界上下文(Bounded Context)的概念來著手解決。
DDD 會將企業(yè)的整個域模型進行分解，并創(chuàng)建出多個子域。每個子域?qū)碛幸粋€模型，而該模型的范圍則被稱為邊界上下文。那么每個微服務就會圍繞著邊界上下文被開發(fā)出來。
注意：識別子域并不是一件容易的事，我們需要通過分析業(yè)務與組織架構(gòu)，識別不同的專業(yè)領域，來對企業(yè)加強了解。
刀砍模式(Strangler Pattern)
問題：前面我們討論的設計模式一般適用于針對那些“白手起家”的 Greenfield 應用進行分解。
但是我們真實接觸到的、約占 80% 的是 Brownfield 應用，即：一些大型的、單體應用(Monolithic Application)。
由于它們已經(jīng)被投入使用、且正在運行，如果我們簡單按照上述方式，同時對它們進行小塊服務的分解，將會是一項艱巨的任務。
解決方案：此時，刀砍模式(Strangler Pattern)就能派上用場了。我們可以把扼殺模式想象為用刀砍去纏在樹上的藤蔓。
該方案適用于那些反復進行調(diào)用的 Web 應用程序。對于每一個 URI(統(tǒng)一資源標識符)的調(diào)用來說，單個服務可以被分解為不同的域和單獨的子服務。其設計思想是一次僅處理一個域。
這樣，我們就可以在同一個 URI 空間內(nèi)并行地創(chuàng)建兩套獨立的應用程序。最終，在新的應用重構(gòu)完成后，我們就能“刀砍”或替換掉原來的應用程序，直到最后我們可以完全關閉掉原來的單體應用。
集成模式
API 網(wǎng)關模式
問題：當一個應用程序被分解成多個小的微服務時，我們需要關注如下方面。
具體如下：
如何通過調(diào)用多個微服務，來抽象出 Producer(生產(chǎn)者)的信息。
在不同的渠道上(如電腦桌面、移動設備和平板電腦)，應用程序需要不同的數(shù)據(jù)來響應相同的后端服務，比如：UI(用戶界面)就可能會有所不同。
不同的 Consumer(消費者)可能需要來自可重用式微服務的不同響應格式。誰將去做數(shù)據(jù)轉(zhuǎn)換或現(xiàn)場操作?
如何處理不同類型的協(xié)議?特別是一些可能不被 Producer 微服務所支持的協(xié)議。
解決方案：API 網(wǎng)關將有助于解決在微服務實施過程中所涉及到的上述關注點。
具體如下：
API 網(wǎng)關是任何微服務調(diào)用的統(tǒng)一入口。
它像代理服務一樣，能夠?qū)⒁粋€微服務請求路由到其相關的微服務處，并抽象出 Producer 的細節(jié)。
它既能將一個請求扇出(fan out，輸出)到多個服務上，也能匯總多個結(jié)果，并發(fā)回給 Consumer。
鑒于通用 API 無法解決 Consumer 的所有請求，該方案能夠為每一種特定類型的客戶端創(chuàng)建細粒度的 API。
它也可以將某種協(xié)議請求(如：AMQP)轉(zhuǎn)換為另一種協(xié)議(如：HTTP)，反之亦然，從而方便了 Producer 和 Consumer 的處理。
它也可以將認證與授權(quán)存儲庫從微服務中卸載出去。
聚合器模式
問題：雖然我們已經(jīng)在 API 網(wǎng)關模式中討論了如何解決聚合數(shù)據(jù)的問題，不過我們?nèi)詫⒆鲞M一步的討論。
當我們將業(yè)務功能分解成多個較小的邏輯代碼塊時，有必要思考每個服務的返回數(shù)據(jù)是如何進行協(xié)作的。
顯然，該責任不會留給 Consumer，那么我們就需要理解 Producer 應用的內(nèi)部實現(xiàn)。
解決方案：聚合器模式將有助于解決該問題。它涉及到如何聚合來自不同服務的數(shù)據(jù)，然后向 Consumer 發(fā)送最終響應。
具體說來，我們有如下兩種實現(xiàn)方法：
復合微服務(Composite Microservice)將會去調(diào)用全部所需的微服務，整合各種數(shù)據(jù)，并在回傳之前轉(zhuǎn)換數(shù)據(jù)。
API 網(wǎng)關(API Gateway)也能對多個微服務的請求進行 Partition(分區(qū))，并在發(fā)送給 Consumer 之前聚合數(shù)據(jù)。
我們建議：如果您用到了任何業(yè)務邏輯的話，請選用復合微服務;否則請采用 API 網(wǎng)關方案。
客戶端 UI 合成模式
問題：當各種服務按照業(yè)務功能和子域被分解開發(fā)時，它們需要根據(jù)用戶體驗的預期效果，從一些不同的微服務中提取數(shù)據(jù)。
在過去的單體應用中，我們只要從 UI 到后端服務的唯一調(diào)用中獲取所有的數(shù)據(jù)，并刷新和提交到 UI 頁面上便可。如今，情況則不同了。
解決方案：對于微服務來說，UI 必須被設計成單屏、單頁面的多段、多區(qū)域的結(jié)構(gòu)。
每一段都會去調(diào)用單獨的后端微服務，以提取數(shù)據(jù)。像 Angular JS 和 React JS 之類的框架都能夠?qū)崿F(xiàn)為特定的服務合成 UI 組件。
通過被稱為單頁應用(Single Page Applications，SPA)的方式，它們能夠使得應用程序僅刷新屏幕的特定區(qū)域，而不是整個頁面。
數(shù)據(jù)庫模式
按服務分配數(shù)據(jù)庫
問題：您可能會碰到如何定義數(shù)據(jù)庫架構(gòu)的微服務問題。
下面是具體的關注點：
服務必須是松散耦合的，以便能夠被二次開發(fā)、部署和獨立擴容。
各個業(yè)務交易需要在橫跨多個服務時，仍保持不變。
某些業(yè)務交易需要從多個服務中查詢到數(shù)據(jù)。
數(shù)據(jù)庫有時需要根據(jù)規(guī)模需求被復制與分片。
不同的服務具有不同的數(shù)據(jù)存儲需求。
解決方案：為了解決上述需求，我們需要通過設計為每個微服務配備一個獨享的數(shù)據(jù)庫模式。
即：該數(shù)據(jù)庫僅能被其對應微服務的 API 單獨訪問，而不能被其他服務直接訪問到。
例如，對于關系型數(shù)據(jù)庫，我們可以使用：按服務分配私有表集(private-tables-per-service)、按服務分配表結(jié)構(gòu)(schema-per-service)、或按服務分配數(shù)據(jù)庫服務器(database-server-per-service)。
每個微服務應該擁有一個單獨的數(shù)據(jù)庫 ID，以便它們在獨享訪問的同時，禁止再訪問其他的服務表集。
按服務共享數(shù)據(jù)庫
問題：上面討論的按服務分配數(shù)據(jù)庫是一種理想的微服務模式，它一般被前面提到的 Greenfield 應用和 DDD 式的開發(fā)。但是，如果我們面對的是需要采用微服務的單體應用就沒那么容易了。
解決方案：按服務共享數(shù)據(jù)庫的模式雖然有些違背微服務的理念，但是它對于將前面提到的 Brownfield 應用(非新建應用)分解成較小的邏輯塊是比較適用的。
在該模式下，一個數(shù)據(jù)庫可以匹配不止一個的微服務，當然也至多 2～3 個，否則會影響到擴容、自治性和獨立性。
命令查詢職責隔離(CQRS)
問題：對于按服務分配數(shù)據(jù)庫的模式而言，我們?nèi)绾卧谖⒎盏募軜?gòu)中，實現(xiàn)對多個服務進行聯(lián)合查詢數(shù)據(jù)的需求呢?
解決方案：CQRS 建議將應用程序拆分成兩個部分：命令和查詢。命令部分主要處理創(chuàng)建、更新和刪除之類的請求;查詢部分則利用物化視圖(Materialized Views)來處理各種查詢。
它通常配合事件溯源模式(Event Sourcing Pattern)一起創(chuàng)建針對任何數(shù)據(jù)的變更事件。而物化視圖則通過訂閱事件流，來保持更新。
Saga 模式
問題：當每個服務都有自己的數(shù)據(jù)庫，而且業(yè)務交易橫跨多個服務時，我們該如何確保整體業(yè)務數(shù)據(jù)的一致性呢?
例如：對于某個帶有客戶信用額度標識的電商應用而言，它需要確保新的訂單不會超出客戶的信用額度。
但是，由于訂單和客戶分屬不同的數(shù)據(jù)庫，應用程序無法簡單地實現(xiàn)本地交易的 ACID(原子性、一致性、隔離性、持久性)特性。
解決方案：Saga 代表了一個高層次的業(yè)務流程，它是由一個服務中的多個子請求，并伴隨著逐個更新的數(shù)據(jù)所組成。在某個請求失敗時，它的補償請求會被執(zhí)行。
實現(xiàn)方式有如下兩種：
編排(Choreography)：沒有中央?yún)f(xié)調(diào)器，每個服務都會產(chǎn)生并偵聽其他服務的事件，以決定是否應采取行動。
協(xié)調(diào)(Orchestrator)：由一個中央?yún)f(xié)調(diào)器(對象)負責集中處理某個事件(Saga)的決策，和業(yè)務邏輯的排序。
觀測模式
日志聚合
問題：我們來考慮這樣一個用例：某個應用程序包括了那些在多臺機器上運行的多個服務實例，各種請求橫跨在這些多個服務實例之中。同時，每個服務實例都會生成一種標準格式的日志文件。
那么我們?nèi)绾吾槍δ硞€特定的請求，通過各種日志來理解該應用程序的行為呢?
解決方案：顯然，我們需要一個集中化的日志服務，將各個服務實例的日志予以聚合，以便用戶對日志進行搜索和分析。他們可以針對日志中可能出現(xiàn)的某些消息，配置相應的警告。
例如：PCF(Pivotal Cloud Foundry)平臺擁有一個日志聚合器，它從每種元素(如：路由器、控制器等)中收集與應用相關的日志。而 AWS Cloud Watch 也具有相似的功能。
性能指標
問題：當各種服務組合隨著微服務架構(gòu)變得越來越復雜時，監(jiān)控交易的完整性，并能夠在出現(xiàn)問題時及時發(fā)出警告，就顯得尤為重要了。那么我們該如何收集與應用相關的性能指標呢?
解決方案：為了收集不同操作的統(tǒng)計信息，并提供相應的報告和警告。
我們一般會用兩種模式來聚集各項指標：
推式：將各項指標推給專門的指標服務，如：NewRelic 和 AppDynamics。
拉式：從指標服務處拉取各項指標，如：Prometheus。
分布式跟蹤
問題：在微服務架構(gòu)中，橫跨多個服務的請求是比較常見的。某個服務需要通過橫跨多個服務去執(zhí)行一到多項操作，才能處理一些特定的請求。
那么，我們該如何通過跟蹤某個端到端的請求，以獲知出現(xiàn)的問題呢?
解決方案：我們需要一種具有特性的服務。
具體特性服務如下：
為每個外部請求分配一個唯一的 ID。
將該外部請求 ID 傳給所有的服務。
在所有的日志消息中都包含該外部請求 ID。
在集中式服務中，記錄處理外部請求的相關信息，包括：開始時間、結(jié)束時間、和執(zhí)行時間。
Spring Cloud Slueth + Zipkin Server，是一種常見的實現(xiàn)方式。
健康檢查
問題：我們在實施微服務架構(gòu)的過程中，可能會碰到某個服務雖已啟動，但是無法處理交易的情況。
那么，我們該如何通過負載均衡的模式，來確保請求不會“落入”失敗的實例中呢?
解決方案：每個服務都需要有一個端點，通過諸如 /health 的參數(shù)，對應用進行健康檢查。
該 API 需要能夠檢查主機的狀態(tài)，其他服務與基礎設施的連接性，以及任何特定的邏輯關系。
Spring Boot Actuator 不但能夠?qū)崿F(xiàn)端點的健康檢查，還能夠被定制實施。
橫切關注點模式(Cross-Cutting Concern Patterns)
外部配置
問題：通常情況下，一個服務需要去調(diào)用其他的服務和數(shù)據(jù)庫。在諸如開發(fā)、QA(Quality Assurance，質(zhì)量保證)、UAT(User Acceptance Test，用戶驗收測試)、和生產(chǎn)環(huán)境中，端點的 URL、或某些配置的屬性會有所不同。
因此，有時候我們需要對這些服務的各種屬性進行重構(gòu)、和重新部署。那么我們?nèi)绾伪苊庠谂渲米兏行薷拇a呢?
解決方案：外部化(externalize)所有的配置，包括各個端點的 URL 和信任憑據(jù)，以保證應用程序在啟動時、或運行中能夠加載它們。
Spring Cloud 配置服務器提供了向 GitHub 進行屬性外部化的選項，并將其作為環(huán)境屬性予以加載。
此法保證了應用程序能夠在啟動時就被訪問到，或是在不重啟服務器的情況下實現(xiàn)刷新。
服務發(fā)現(xiàn)模式
問題：當微服務初具規(guī)模時，我們需要考慮如下兩個關于調(diào)用服務方面的問題。
具體問題如下：
由于采用了容器技術(shù)，IP 地址往往被動態(tài)地分配給不同的服務實例。因此，每次當 IP 地址發(fā)生變化時，Consumer 服務可能會受到影響，需要我們手動更改。
Consumer 需要記住每個服務的 URL，這就倒退成了緊耦合的狀態(tài)。
那么，Consumer 或路由器該如何獲知所有可用的服務實例與位置呢?
解決方案：我們需要創(chuàng)建一個服務注冊表，來保存每個 Producer 服務的元數(shù)據(jù)(Meta Data)。
一個服務實例在啟動時，應當被注冊到表中;而在關閉時，需從表中被注銷。
Consumer 或路由器通過查詢該注冊表，就能夠找到服務的位置。Producer 服務也需要對該注冊表進行健康檢查，以確保能夠消費到那些可用的、且正在運行的服務實例。
我們一般有兩種服務發(fā)現(xiàn)的類型：客戶端和服務器端。使用客戶端發(fā)現(xiàn)的例子是 Netflix Eureka;而使用服務器端發(fā)現(xiàn)的例子是 AWS ALB。
斷路器模式
問題：有時候，某個服務在調(diào)用其他服務，以獲取數(shù)據(jù)的時候，會出現(xiàn)下游服務(Downstream Service)“掉線”的情況。
它一般會帶來兩種結(jié)果：
該請求持續(xù)發(fā)往該掉線服務，直至網(wǎng)絡資源耗盡和性能降低。
用戶產(chǎn)生不可預料的、較差的使用體驗。
那么我們該如何避免服務的連鎖故障，并妥善處置呢?
解決方案：Consumer 應該通過一個代理來調(diào)用某項遠程服務，就像電路中的斷路器一樣。
當出現(xiàn)持續(xù)失敗的數(shù)量超過設定閾值時，斷路器就會“跳閘”一段時間，從而導致所有調(diào)用遠程服務的嘗試被立即切斷。
在超過設定時間之后，斷路器只允許有限數(shù)量的測試請求通過。而如果這些請求成功了，那么斷路器將恢復正常運行;否則判定為故障依舊，并重新開始新的定時周期。
Netflix Hystrix 就很好地使用了該斷路器模式。它可以在斷路器“跳閘”的時候，幫助您定義一種回退機制，以提供更好的用戶體驗。
藍綠部署模式
問題：在微服務架構(gòu)中，一個應用程序可以有多個微服務。如果我們?yōu)榱瞬渴鹨粋€增強版，而停止所有的服務，那么停機時間一旦過長，就會對業(yè)務造成影響。
況且，這對于回退來說也將會是一場噩夢。那么我們該如何避免、或減少部署過程中服務的停機時間呢?
解決方案：我們可以采用藍綠部署的策略，以減少或消除停機時間。在藍、綠兩個相同的生產(chǎn)環(huán)境中，我們假設綠色環(huán)境有著當前真實的實例，而藍色環(huán)境具有應用程序的最新版本。
在任何時候，只有一個環(huán)境能夠處理所有真實的流量，并對外提供服務。如今，所有的云服務平臺都能提供基于藍綠部署的選項。
當然，我們還可以采用許多其他的微服務架構(gòu)模式，如：Sidecar 模式、鏈式微服務(Chained Microservice)、分支微服務(Branch Microservice)、事件溯源模式(Event Sourcing Pattern)、和持續(xù)交付方式等。(來源51CTO)
