如何理解面向領域的微服務架構

本篇內容主要講解“如何理解面向領域的微服務架構”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解面向領域的微服務架構”吧!

什么是微服務

微服務是面向服務架構的延伸。與2000年代相當大的 "服務 "相比，微服務是代表一組小型功能的應用程序。這些應用通過網絡托管，并暴露出一個明確定義接口。其他應用程序通過進行遠程過程調用（RPC）方式來調用這個接口。

微服務架構的特點是代碼的托管、調用和部署方式。比如大型的單體應用，它們通常會被分割成具有明確定義接口的封裝組件。然后，這些接口就可以直接在進程中調用，而不是通過網絡。通過這種方法，我們將微服務看作一個性能受到影響的庫（網絡I/O和序列化/反序列化），以便調用它的任何功能。

當我們以這種方式來思考微服務時，可能會質疑為什么我們會采用微服務架構。答案通常是獨立部署和擴展。對于一個大型的單體應用程序，應用被迫一次性部署或發布所有的代碼。應用程序的每一個新版本都可能涉及許多更改。部署變得風險大、耗時長。任何人都可以使整個系統癱瘓。

換句話說，業務采用微服務是以犧牲性能為代價來獲取運營利益。業務還必須承擔維護支持微服務所需的基礎設施的成本。事實證明，在很多情況下，這種權衡是很有意義的，但這也是反對過早采用微服務架構的有力論據。

動機

在Uber，我們也采用了微服務架構，因為我們（大約在2012-2013年）主要有兩個單體服務，遇到了很多通過微服務來解決的運營問題。

•  可用性風險。單體代碼庫內的一次回滾就會使整個系統（在本例中是Uber的全部）癱瘓。

•  部署風險大，成本高。在需要頻繁回滾的情況下，執行這些操作既困難又耗時。

•  不平滑的關注點分離。在龐大的代碼庫中，很難保持良好的關注點分離。尤其在一個指數級增長的環境中，權宜之計有時會導致邏輯和組件之間的界限不清。

•  執行效率低下。這些問題加在一起，使得團隊很難獨立自主地執行任務。

隨著Uber從10多個工程師發展到100多個工程師，多個團隊擁有技術棧的碎片時，這種單一的架構將團隊的命運捆綁在一起，使得獨立運作變得困難。

因此，我們采用了微服務架構。最終，我們的系統變得更加靈活，這使得團隊能夠更加自主。

•  系統的可靠性。在微服務架構中，整體系統的可靠性上升。單個服務可以在不影響整個系統的情況下宕機（并被回滾）。

•  關注點的分離。從架構上來看，微服務架構迫使你去問 "這個服務為什么存在？"更加清晰地定義不同組件的角色。

•  明確所有權。代碼擁有者變得更加清楚。服務通常由個人、團隊或組織級別擁有，從而實現更快的增長。

•  自主執行。獨立的部署 更清晰的所屬權限，讓不同的產品和平臺團隊能夠自主執行。

•  開發人員的速度。應用團隊可以獨立部署他們的代碼，這使得他們能夠按照自己的項目進度來執行

毫不夸張地說，如果沒有微服務架構，Uber不可能達到今天所保持的規模和執行質量。

然而，隨著公司規模的進一步擴大，從100多名工程師到1000多名工程師，我們開始注意到一系列與系統復雜性大大增加的相關問題。在微服務架構下，人們用單一的整體代碼庫換取了黑盒，黑盒的功能隨時可能發生變化，很容易造成意外情況。

例如，工程師們不得不通過12個不同團隊大約50個服務來調查問題的根本原因。

理解服務之間的依賴關系可能會變得相當困難，因為服務之間的調用可能會深入許多層。第n個依賴關系的延遲峰值可能會導致上游的一連串問題。如果沒有合適的工具，就不可能看到實際發生的情況，這讓調試變得困難。

為了構建一個簡單的功能，工程師往往需要跨多個服務工作，所有這些服務都由不同的個人和團隊所擁有。這就需要跨部門跨團隊的合作，在會議、設計和代碼審查上花費時間。由于團隊在彼此的服務中構建代碼，修改彼此的數據模型，甚至代表服務所有者執行部署，早期對服務所有權的明確界限劃分受到了影響。網絡化的單體可能會形成，看似獨立的服務都必須一起部署才能安全地執行任何變更。

這樣所帶來的結果就是開發進度變慢、服務所屬不穩定、遷移更困難等。對于已經采用微服務架構的企業來說，已經沒有回頭路了。這就變成了 "有了它們不能活，沒有它們不能活"。

面向領域的微服務架構

如果我們可以將微服務視為I / O綁定的庫，而將“微服務架構”視為大型的分布式應用程序，則可以使用眾所周知的架構來思考如何組織代碼。

因此，“面向領域的微服務體系結構”大量借鑒了組織代碼的既定方法，例如 域驅動設計 ， 清晰架構 ， 面向服務的體系架構 以及面向對象和面向接口的設計模式。 我們認為DOMA僅是創新，因為它是在大型應用的分布式系統中利用既定設計原則的相對新穎的方法。

DOMA相關的核心原理和術語如下：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2.  圍繞相關微服務的集合，稱為 域

3.  域的集合稱之為層。域所屬的層確定了允許該域內的微服務承擔什么依賴性，稱為 層設計

4.  為域提供接口，這些域被視為集合的單個入口點，稱為 網關

5.  確定每個域都應該與其他域不可知，一個域不應該具有與其代碼庫或數據模型內部硬編碼的另一個域相關的邏輯。由于團隊經常需要在另一個團隊的域中包含邏輯（例如，自定義驗證邏輯或數據模型上的某些元上下文），因此我們提供了一種 擴展架構 ，以支持該域中定義明確的擴展點。

通過提供系統的體系結構，域網關和預定義的擴展點，DOMA打算將微服務體系結構從復雜的東西轉變為可理解的東西：結構化的一組靈活，可重用和分層的組件。

這篇文章的其余部分將深入研究Uber在DOMA中的實施，我們已經看到的好處以及為可能希望采用這種方法的公司提供的實用建議。

Uber的措施

域

Uber域代表一個或多個與邏輯功能分組綁定的微服務的集合。設計域時常見的問題是“域應該有多大？”有些域可以包含數十個服務，有些域只能包含單個服務。重要的任務是仔細考慮每個集合的 邏輯 角色。例如，我們的地圖搜索服務構成一個域，票價服務是一個域，匹配平臺（匹配騎手和駕駛員）是一個域。這些也不總是遵循公司的組織結構。Uber Maps組織本身分為三個域，在三個不同的網關后面有80個微服務。

層設計

層設計回答了“什么服務可以調用其他什么服務？”的問題。在Uber的微服務架構中，我們可以將層設計視為“規模化的關注點分離”，或者，我們可以將層設計視為“規模化的依賴管理”。

層設計描述了一種機制，用于考慮Uber的故障影響范圍和跨服務依賴的產品特異性。 當域從底層移到頂層時，它們在中斷的情況下會影響較少的服務，并代表更多特定的產品使用案例。 相反，底層的功能具有更多的依存關系，因此趨向于具有更大的影響半徑，并代表了更通用的業務功能集。下圖說明了此概念。

可以將頂層視為具體的用戶體驗（例如移動功能），將底層視為通用的業務功能（例如帳戶管理或市場行程）。層僅取決于其下的層，這為我們提供了一種有用的啟發式方法，可以思考影響范圍和區域集成等問題。

值得注意的是，功能經常會從這個圖表中 "向下 "移動，從具體到更普遍。可以想象，一個簡單的功能，隨著需求的變多，最終會變成越來越多的平臺。事實上，這種向下遷移是意料之中的，Uber的許多核心業務平臺一開始都是針對騎手或司機的功能，隨著我們開發出更多的業務線，它們也有了更多的依賴性，就會變得越來越通用（比如Uber Eats或Uber Freight）。

在Uber內部，我們建立了以下五個層次。

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2.  基礎設施層。 提供任何工程項目都可以使用的功能。這是Uber對諸如存儲或網絡等重大工程問題的處理。

3.  業務層。 提供應用可以使用的Uber功能，但并非特定于特定產品類別或業務線（LOB）的功能，例如乘車，進餐或貨運。

4.  產品層。 提供與特定產品類別或LOB相關但與移動應用程序無關的功能，例如由多個面向應用程序的Rides所利用的“請求乘車”邏輯（Rider，Rider“ Lite”，m.uber.com）等）。

5.  演示層。 提供直接與面向消費者的應用程序（移動/網絡）中存在的功能相關的功能。

6.  邊緣層。 將Uber服務安全地暴露給外界。該層也支持移動應用程序。

每層代表著越來越具體的功能分組，并且影響半徑越來越小（或者換句話說，更少的組件取決于該層中的功能）。

網關

在微服務架構中相信大家對“API網關”這個術語并不陌生。而在DOMA中我們的定義的網關其實與大家所熟知的“API網關”的概念相差無幾，只是我們傾向于將網關專門視為 進入 基礎服務集合（稱為 域） 的 單個入口點****。 網關的成功取決于API設計的成功。

由于上游使用者僅在單一服務上運行，因此網關在遷移，服務發現以及整體系統復雜度方面提供了許多好處，上游服務僅需一個依賴項，而不是對域中可能存在的幾個下游服務的依賴。如果我們從面向對象設計的角度考慮網關，那么它們就是接口定義，它使我們能夠根據底層“實現”（在本例中為底層微服務的集合）做我們想做的任何事情。

擴展

擴展表示一種 擴展 域的機制。擴展的基本定義是，它提供了一種擴展基礎服務功能的機制，而無需更改該服務的實際實現，也不會影響其整體可靠性。在Uber，我們提供了兩種不同的擴展模型： 邏輯擴展 和 數據擴展 。擴展的概念使我們能夠將架構擴展到能夠獨立工作的多個團隊。

邏輯擴展

邏輯擴展提供了一種擴展服務的底層邏輯機制。對于邏輯擴展，我們使用 提供程序 或 插件 模式的變體，其接口是以服務為基礎定義的。這樣一來使得擴展團隊可以在不修改底層平臺核心代碼的情況下，以接口驅動的方式實現擴展邏輯。

例如，一個驅動上線。通常，我們會進行各種檢查以確保允許驅動上線（安全檢查，合規性等）。這些都由一個單獨的團隊擁有。一種實現方法是讓每個團隊在同一端點編寫邏輯，但這可能會增加復雜性。每次檢查都需要自定義且完全不相關的邏輯。

對于邏輯擴展，“上線”端點將定義一個接口，他們希望每個擴展都符合預定義的請求類型和響應。每個團隊都將注冊一個負責執行此邏輯的擴展。在這種情況下，他們可能簡單地獲取一些關于驅動程序的上下文況，然后返回布爾值，來判斷驅動程序是否可以上線。“上線”端點將簡單地遍歷這些響應，并確定它們其中是否有問題。

這就將核心代碼與每個擴展解耦，并提供了擴展之間的隔離，它不知道其他邏輯在執行什么。圍繞這一點，就能很容易建立更多的功能，比如可觀察性或者是特征標志等。

數據擴展

數據擴展提供了一種將任意數據附加到接口的機制，來避免核心平臺數據模型中的臃腫。對于數據擴展，我們利用Protobuf的 Any 功能，這樣團隊可以將任意數據添加到請求中。服務通常會存儲這些數據或將其傳遞給邏輯擴展，這樣核心平臺就永遠不會負責反序列化（從而 "知道"）這個任意上下文。Protobuf的任何實現都會有一些基礎設施開銷，以換取更強的類型化。為了更簡單的實現，我們可以直接使用JSON字符串來表示任意數據。

自定義擴展

在邏輯和數據擴展之外，Uber的很多團隊都推出了自己適合自己領域的擴展模式。例如，與我們的展示架構綁定的很多集成都使用了基于DAG的任務執行邏輯。

效益

Uber幾乎每個主要領域都在一定程度上受到了DOMA的影響。在過去的一年里，我們主要關注Uber的業務層，它為我們的各個業務線提供了通用的邏輯。

DOMA在Uber還很年輕，我們很高興能在未來分享更多的數據和我們架構的深入案例。不過，在簡化開發人員體驗和降低整體系統復雜度方面，早期的跡象是非常積極的。

產品與平臺

DOMA是Uber整個產品和平臺團隊達成共識的結果。平臺支持成本往往下降了一個數量級。產品團隊從護欄和加速開發中獲益。

例如，我們擴展架構的一個早期平臺消費者通過采用擴展架構，減少了代碼審查、規劃和消費者學習曲線的時間，能夠將一個新功能的優先級和集成時間從三天下降到三個小時。

降低復雜度

以前產品團隊要利用一個領域，需要調用許多下游服務，現在只需要調用一個服務。通過減少入駐新功能的接觸點數量，平臺能夠將入駐時間縮短25-50%。此外，我們能夠將2200個微服務劃分為70個域。其中大約有50%已經實施，其中大部分有一些未來采用的計劃。

未來的遷移

在Uber，我們計算過微服務的半衰期是1.5年，也就是說每1.5年我們就有50%的微服務流失。如果沒有網關，微服務架構很容易因為這種流失而陷入 "遷移地獄"。不斷變化的微服務需要不斷進行上游遷移。網關使團隊能夠避免對底層領域服務的依賴性，這意味著這些服務可以在不強制進行上游遷移的情況下發生變化。

Uber在去年最大的兩次平臺重寫都發生在網關背后。這些平臺有數百個依賴于它們的服務，這些服務將不得不遷移現有的平臺。在這些情況下，遷移的成本會非常高，使得完全的平臺重變得寫不可行。

新的業務和產品線

事實證明，使用DOMA設計的平臺可擴展性更強，也更容易維護。Uber的大多數團隊之所以采用DOMA，是因為支持新業務線的成本太高。

一些建議

本節為可能想采用DOMA的公司提供一些實用的建議。這里的指導原則是，根據我們的經驗，一個成熟的、經過深思熟慮的微服務架構源于在正確的時間向正確的方向悄悄推敲。現實情況是，對于一個人的整個微服務架構來說，真正的 "重寫 "是永遠不可能的。

因此，我們認為微服務架構的演進更像是 "修剪樹籬"，使其最終正確成長，而不是自上而下或一次性的架構（或重新架構）工作。這是一個動態和漸進的過程。

創業公司

驅動性的問題應該是 "我們應該在什么時候采用微服務架構？"和 "它對我們的組織有意義嗎？" 正如我們在上面所看到的那樣，雖然微服務為擁有大量工程師的組織提供了運營上的好處，但這也換來了復雜性的增加，會使功能的構建更加困難。

在小型公司中，運營效益可能無法抵消架構復雜性的增加。此外，微服務架構通常需要專門的工程資源來支持，這對于早期階段的公司來說可能超出了預算，否則從優先級的角度來看是次優的。

考慮到這一點，在一段時間內完全暫緩采用微服務也不是沒有道理的。如果一個組織真的選擇采用微服務，就應該考慮 "微服務作為大型分布式應用 "的類比，以及想要構建的微服務之間的關注點分離。另外，要認識到，第一批微服務很可能是最重要的，也是持續時間最長的，因為它們真正描述了業務的核心。

中型

一旦公司的規模達到中等，有了多個團隊，不同的功能和平臺之間的關注點明確分離變得朦朧，微服務架構就會變得更加明顯有用。

在這個階段，人們可以開始考慮微服務之間的層次結構。依賴性管理可能會變得更加重要，因為一些服務開始對業務運營變得更加明顯的關鍵，越來越多的團隊依賴這些服務。

早期對平臺化的投資可能會在未來的道路上得到回報。如果能夠創建完全產品不可知的業務平臺，避免核心平臺服務中任意的產品邏輯，這里就有可能避免技術債務。此時采用擴展來實現這一目標可能是有意義的。

鑒于微服務的數量可能還相當少，將它們集中在一起可能沒有意義。不過，這里值得注意的是，在Uber的DOMA實現背景下，一個領域可以包含一個服務，所以用 "面向領域 "的方式來思考可能還是有用的。

大型

規模較大的工程組織可能有數百名工程師和微服務以及多個依賴關系。這時DOMA就達到了它的全部作用。很可能會有明顯的微服務集群，這些集群可以很容易地歸為域，在它們前面有一個網關。遺留服務往往開始需要重構或重寫，然后進行遷移，這意味著如果網關已經到位的話，很快就會開始在遷移的便利性方面提供價值。

明確的層次結構也將變得越來越重要，一些服務將作為 "產品 "服務來運行，以實現特定的功能或功能分組，而其他服務將越來越多地支持多個產品，并被認為是 "平臺"。現階段關鍵是要保持任意產品邏輯與平臺的脫鉤，這樣才能避免給平臺團隊帶來沉重的運營負擔以及整個系統的不穩定。

最后的感想

隨著Uber越來越多的團隊來采用DOMA，我們仍在積極地進化DOMA。DOMA的關鍵洞察力在于，微服務架構實際上只是一個大型的分布式程序，你可以將同樣的原則應用于它的演進，就像你應用于任何軟件一樣。DOMA只是一種在實踐中思考這些原則的方法。我們希望其他人覺得它有用，我們也期待著反饋。

到此，相信大家對“如何理解面向領域的微服務架構”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！