面向領(lǐng)域的微服務(wù)架構(gòu)設(shè)計(jì)
最近圍繞面向服務(wù)的架構(gòu)，特別是微服務(wù)架構(gòu)的缺點(diǎn)進(jìn)行了大量的討論。在幾年前由于微服務(wù)架構(gòu)帶來的眾多好處，如獨(dú)立部署的靈活性、明確的所有權(quán)、系統(tǒng)穩(wěn)定性的改善和更好的關(guān)注點(diǎn)分離等，很多人都欣然采用了微服務(wù)架構(gòu)，但近年來人們開始抨擊微服務(wù)大大增加了復(fù)雜性，有時(shí)甚至使微服務(wù)變得更加復(fù)雜了。
隨著 Uber 發(fā)展到大約 2200 項(xiàng)關(guān)鍵的微服務(wù)，我們都親身經(jīng)歷了這些事情。在過去兩年里，Uber 試圖在降低微服務(wù)復(fù)雜性的同時(shí)，仍然保持著微服務(wù)架構(gòu)的一些優(yōu)勢(shì)。我們希望通過這篇文章介紹我們對(duì)微服務(wù)架構(gòu)的通用方法，我們稱之為 "面向領(lǐng)域的微服務(wù)架構(gòu)"（DOMA）。
雖然近年來流行批評(píng)微服務(wù)架構(gòu)，但很少有人主張徹底拒絕微服務(wù)架構(gòu)。因?yàn)槟壳八坪鯖]有或有限的替代方案。我們使用 DOMA 的目標(biāo)是為那些希望降低總體系統(tǒng)復(fù)雜性，同時(shí)保持微服務(wù)架構(gòu)靈活性的組織提供一條前進(jìn)的道路。
本文解釋了 DOMA，導(dǎo)致 Uber 采用這種架構(gòu)的原因，以及它對(duì)平臺(tái)和產(chǎn)品團(tuán)隊(duì)的好處，最后，給想采用這種架構(gòu)的團(tuán)隊(duì)提供一些建議。
什么是微服務(wù)？
微服務(wù)是面向服務(wù)架構(gòu)的擴(kuò)展。與2000年代較大的“服務(wù)”相比，微服務(wù)表示一組范圍更小的功能的應(yīng)用程序。這些應(yīng)用程序通過網(wǎng)絡(luò)托管提供，并暴露一個(gè)良好定義的接口，其他應(yīng)用程序通過創(chuàng)建一個(gè) RPC 來調(diào)用這個(gè)接口。
微服務(wù)架構(gòu)的關(guān)鍵特點(diǎn)是代碼被托管、調(diào)用和部署的方式。如果我們考慮大型的單體應(yīng)用，它們一般會(huì)被分割成具有明確定義接口的封裝組件，然后，這些接口將直接在進(jìn)程中調(diào)用，而不是通過網(wǎng)絡(luò)調(diào)用。通過這種方式，我們可以開始將微服務(wù)看成一個(gè)庫，但是為了調(diào)用它的功能函數(shù)，它的性能會(huì)受到一定影響（網(wǎng)絡(luò) I/O 和序列化/反序列化）。
當(dāng)我們以這種方式思考微服務(wù)時(shí)，我們可能會(huì)質(zhì)疑為什么我們還要采用微服務(wù)架構(gòu)。答案往往也很明確，那就是獨(dú)立部署和擴(kuò)展。對(duì)于一個(gè)大型的單體應(yīng)用，組織會(huì)被迫同時(shí)部署或發(fā)布所有代碼。但是我們知道應(yīng)用程序的每個(gè)新版本都可能涉及許多變更，這樣部署就會(huì)變得風(fēng)險(xiǎn)大、耗時(shí)長，任何人都可能使整個(gè)系統(tǒng)癱瘓。
換句話說，采用微服務(wù)是以犧牲性能為代價(jià)來獲取運(yùn)營的好處，各組織還必須承擔(dān)維護(hù)支持微服務(wù)所需的基礎(chǔ)設(shè)施的成本。事實(shí)證明，在大多數(shù)情況下，這種權(quán)衡是很有意義的，但這也是反對(duì)過早采用微服務(wù)架構(gòu)的有力論據(jù)。
動(dòng)機(jī)
在 Uber，我們采用了微服務(wù)架構(gòu)，因?yàn)槲覀兇蠹s在2012-2013年主要有兩個(gè)單體服務(wù)，然后我們也遇到了微服務(wù)解決的大部分問題。
可用性風(fēng)險(xiǎn)：單體代碼庫內(nèi)的一次回歸就會(huì)使整個(gè)系統(tǒng)癱瘓。
風(fēng)險(xiǎn)大、成本高的部署：在頻繁需要回滾的情況下，執(zhí)行這些操作既痛苦又費(fèi)時(shí)。
糟糕的關(guān)注點(diǎn)分離：在龐大的代碼庫中，很難保持良好的關(guān)注點(diǎn)分離。在一個(gè)指數(shù)級(jí)增長的環(huán)境中，一些臨時(shí)的解決方法有時(shí)會(huì)導(dǎo)致邏輯和組件之間的界限不清。
執(zhí)行效率低下：這些問題結(jié)合在一起，使得團(tuán)隊(duì)難以自主或獨(dú)立地執(zhí)行。
當(dāng) Uber 從10多個(gè)工程師發(fā)展到100多個(gè)工程師的時(shí)候，多個(gè)團(tuán)隊(duì)還擁有不同的技術(shù)棧時(shí)，單體架構(gòu)將整個(gè)團(tuán)隊(duì)都捆綁在一起了，很難獨(dú)立運(yùn)作了。所以，我們采用了微服務(wù)架構(gòu)，最終，我們的系統(tǒng)變得更加靈活，使得團(tuán)隊(duì)也更加自主了。
系統(tǒng)可靠性：在微服務(wù)架構(gòu)中，整體系統(tǒng)的可靠性會(huì)上升，單個(gè)服務(wù)可以在不影響整個(gè)系統(tǒng)的情況下宕機(jī)或回滾。
關(guān)注點(diǎn)分離：從架構(gòu)上看，微服務(wù)架構(gòu)迫使你去思考 "這個(gè)服務(wù)為什么存在？"，這就可以更清晰地定義不同組件的角色。
明確所有權(quán)：誰擁有什么代碼變得更加清晰，一個(gè)服務(wù)通常由個(gè)人、團(tuán)隊(duì)或組織級(jí)別擁有，從而實(shí)現(xiàn)更快的增長。
自主執(zhí)行：獨(dú)立部署+更清晰的所有權(quán)線，解除不同產(chǎn)品和平臺(tái)團(tuán)隊(duì)的自主執(zhí)行。
開發(fā)速度：團(tuán)隊(duì)可以獨(dú)立部署他們的代碼，這使他們能夠以自己的速度執(zhí)行。
可以毫不夸張地說，如果沒有微服務(wù)架構(gòu)，Uber 不可能達(dá)到今天的規(guī)模和執(zhí)行質(zhì)量。
然而，隨著公司規(guī)模的進(jìn)一步擴(kuò)大，工程師人數(shù)增加到1000人，我們開始注意到一系列與系統(tǒng)復(fù)雜性增加相關(guān)的問題。在微服架構(gòu)下，我們可以將單個(gè)功能的代碼庫換成一個(gè)黑盒（獨(dú)立的微服務(wù)），黑盒的功能隨時(shí)可能發(fā)生變化，很容易導(dǎo)致意外行為。
理解服務(wù)之間的依賴關(guān)系可能變得相當(dāng)困難，因?yàn)榉?wù)之間的調(diào)用可能會(huì)深入許多層，第 n 個(gè)依賴項(xiàng)中的延遲峰值可能會(huì)導(dǎo)致上游的一連串問題，如果沒有合適的工具，要了解實(shí)際發(fā)生的事情是不可能的，這就使得調(diào)試變得非常困難。
為了構(gòu)建一個(gè)簡(jiǎn)單的功能，工程師往往需要跨多個(gè)服務(wù)工作，所有這些服務(wù)都由不同的個(gè)人和團(tuán)隊(duì)擁有。這就需要廣泛的合作，在會(huì)議、設(shè)計(jì)和代碼審查上花費(fèi)時(shí)間。由于團(tuán)隊(duì)在彼此的服務(wù)中構(gòu)建代碼，修改彼此的數(shù)據(jù)模型，甚至代表服務(wù)所有者執(zhí)行部署，早期對(duì)服務(wù)所有權(quán)的明確界限的承諾受到了影響。網(wǎng)絡(luò)化的單體應(yīng)用可能會(huì)形成，看似獨(dú)立的服務(wù)都必須部署在一起才能安全地執(zhí)行一些變更。
結(jié)果是開發(fā)者體驗(yàn)變慢、服務(wù)所有者不穩(wěn)定、遷移更痛苦等。但是對(duì)于已經(jīng)采用微服務(wù)架構(gòu)的企業(yè)來說，已經(jīng)沒有回頭路了，這就變成了 "有它們不能活，沒有它們也不能活"的窘境了。
面向領(lǐng)域的微服務(wù)架構(gòu)
如果我們將微服務(wù)看作 I/O 綁定的庫，將“微服務(wù)架構(gòu)”看作一個(gè)大型的分布式應(yīng)用程序，那么我們就可以利用理解良好的架構(gòu)來思考如何組織我們的代碼。
因此“面向領(lǐng)域的微服務(wù)架構(gòu)”大量地借鑒了已有的成熟的代碼組織方式，比如Domain-driven Design，Clean Architecture，Service-Oriented Architecture，以及面向?qū)ο蠛徒涌诘脑O(shè)計(jì)模式。我們認(rèn)為 DOMA 的創(chuàng)新之處在于它是在大型組織的大型分布式系統(tǒng)中利用既有設(shè)計(jì)原則的一種相對(duì)新穎的方式。
與 DOMA 相關(guān)的核心原則和術(shù)語如下所示：
我們不以單個(gè)微服務(wù)為導(dǎo)向，而是以相關(guān)微服務(wù)的集合為導(dǎo)向，我們稱之為領(lǐng)域。
我們進(jìn)一步創(chuàng)建領(lǐng)域的集合，我們稱之為層，域所屬的層確定了該領(lǐng)域內(nèi)的微服務(wù)允許承擔(dān)哪些依賴關(guān)系，我們把這叫做層設(shè)計(jì)。
我們?yōu)轭I(lǐng)域提供清晰的接口，我們將其視為集合的單一入口點(diǎn)，我們把這些叫做網(wǎng)關(guān)。
最后，我們確定每個(gè)領(lǐng)域都應(yīng)該與其他域無關(guān)，也就是說，一個(gè)域不應(yīng)該在其代碼庫或數(shù)據(jù)模型里面硬編碼與另一個(gè)域相關(guān)的邏輯。但是由于經(jīng)常還是有團(tuán)隊(duì)需要將邏輯包含到另一個(gè)團(tuán)隊(duì)的領(lǐng)域中去，為此我們提供了一個(gè)擴(kuò)展架構(gòu)來支持域內(nèi)定義良好的擴(kuò)展點(diǎn)。
通過提供系統(tǒng)化的架構(gòu)、領(lǐng)域網(wǎng)關(guān)和預(yù)定義的擴(kuò)展點(diǎn)，DOMA 打算將微服務(wù)體系結(jié)構(gòu)從復(fù)雜的東西轉(zhuǎn)換為可理解的東西：一組靈活、可重用和分層的結(jié)構(gòu)化組件。
本文其余部分將深入探討 Uber 對(duì) DOMA 的實(shí)施，以及對(duì)可能想要采用這種方法的公司一些實(shí)用建議。
Uber 的實(shí)施
領(lǐng)域
Uber 的領(lǐng)域代表了一個(gè)或多個(gè)微服務(wù)的集合，這些微服務(wù)與功能的邏輯分組相聯(lián)系。在設(shè)計(jì)一個(gè)領(lǐng)域時(shí)，一個(gè)常見的問題是“一個(gè)領(lǐng)域應(yīng)該有多大？”，我們這里并沒有一些指導(dǎo)方案。有些領(lǐng)域可以包含幾十個(gè)服務(wù)，有些領(lǐng)域只包含一個(gè)服務(wù)。重要的任務(wù)是仔細(xì)思考每個(gè)集合的邏輯作用。例如，我們的地圖搜索服務(wù)構(gòu)成一個(gè)領(lǐng)域，票價(jià)服務(wù)是一個(gè)領(lǐng)域，匹配平臺(tái)（匹配乘客和司機(jī)）是一個(gè)領(lǐng)域。它們也不一定要按照公司的組織結(jié)構(gòu)來設(shè)計(jì)，Uber 地圖組織本身被分成三個(gè)領(lǐng)域，在3個(gè)不同的網(wǎng)關(guān)后面有80個(gè)微服務(wù)。
層設(shè)計(jì)
在 Uber 的微服務(wù)架構(gòu)中，層設(shè)計(jì)回答了 "什么服務(wù)可以調(diào)用其他什么服務(wù)？"的問題。因此，我們可以將層設(shè)計(jì)視為 "規(guī)模化的關(guān)注點(diǎn)分離"，我們也可以把層設(shè)計(jì)看作是 "規(guī)模化的依賴管理"。
層設(shè)計(jì)描述了一種考慮 Uber 服務(wù)依賴的故障爆炸半徑和產(chǎn)品特性的機(jī)制。當(dāng)領(lǐng)域從底層移動(dòng)到頂層時(shí)，它們?cè)诠收锨闆r下影響的服務(wù)較少，并且代表更具體的產(chǎn)品用例。相反，底層的功能具有更多的依賴，因此往往具有更大的爆炸半徑，并代表一組更通用的業(yè)務(wù)功能。如下圖所示：
我們可以把上層看作是具體的用戶體驗(yàn)（例如移動(dòng)端的功能特性）而底層則是通用的業(yè)務(wù)功能（如帳戶管理）。層級(jí)只依賴于它們下面的層，這給我們提供了一個(gè)有用的啟發(fā)式方法來思考爆炸半徑和領(lǐng)域整合等問題。
值得注意的是，一些功能特性經(jīng)常會(huì)從圖上的 Specific（具體）下移到 General（一般）的位置。我們可以想象，隨著需求的發(fā)展，一個(gè)簡(jiǎn)單的特性最終會(huì)變得越來越像一個(gè)平臺(tái)。事實(shí)上，這種向下的遷移是預(yù)料之中的，Uber 的許多核心業(yè)務(wù)平臺(tái)一開始時(shí)都是針對(duì)騎手或司機(jī)的功能，隨著我們開發(fā)了更多的業(yè)務(wù)線，它們也有了更多的一依賴性（比如 Uber Eats 或 Uber Freight），這些功能也變得越來越通用了。
在 Uber 內(nèi)部，我們建立了以下五個(gè)層：
基礎(chǔ)設(shè)施層：提供任何工程組織都可以使用的功能，這是 Uber 對(duì)大型工程的解決方式，比如存儲(chǔ)或網(wǎng)絡(luò)。
業(yè)務(wù)層：提供了 Uber 作為一個(gè)組織可以使用的功能，但這些功能并不針對(duì)特定的產(chǎn)品類別或業(yè)務(wù)線，如乘車、飲食或貨運(yùn)。
產(chǎn)品層：提供與特定產(chǎn)品類別或業(yè)務(wù)相關(guān)的功能，但與移動(dòng)應(yīng)用程序無關(guān)，例如“請(qǐng)求乘車”的邏輯，該邏輯被多個(gè)面向乘車的應(yīng)用程序（Rider、Rider“Lite”、m.uber.com 等）所使用。
顯示層：提供與面向消費(fèi)者的應(yīng)用（移動(dòng)/web）中存在的功能直接相關(guān)的功能。
邊緣層：安全地將 Uber 服務(wù)暴露給外部世界，。
從上面我們可以看出后續(xù)的每一層都代表著越來越具體的功能分組，并且爆炸半徑越來越小（或者說依賴該層內(nèi)部功能的組件越來越少）。
網(wǎng)關(guān)
在微服務(wù)架構(gòu)中，"網(wǎng)關(guān) API "這個(gè)術(shù)語已經(jīng)是一個(gè)廣為人知的概念。我們的定義與既定的定義沒有很大的區(qū)別，只是我們傾向于把網(wǎng)關(guān)完全看作是進(jìn)入底層服務(wù)集合的一個(gè)單一入口點(diǎn)，一個(gè)網(wǎng)關(guān)的成功依賴于 API 設(shè)計(jì)的成功。
由于上游消費(fèi)者只在一個(gè)服務(wù)上操作，網(wǎng)關(guān)在未來的遷移、可發(fā)現(xiàn)性和整體降低系統(tǒng)復(fù)雜性方面提供了許多好處，上游服務(wù)只采取單一的依賴，而不是依賴一個(gè)域內(nèi)可能存在的多個(gè)下游服務(wù)。如果我們從面向?qū)ο笤O(shè)計(jì)的角度來考慮網(wǎng)關(guān)，那么它們就是接口定義，它使我們能夠在底層的“實(shí)現(xiàn)”(在本例中是底層微服務(wù)的集合)方面做我們想做的任何事情。
擴(kuò)展
擴(kuò)展代表了一種擴(kuò)展域的機(jī)制。擴(kuò)展的基本定義是，它提供了一種機(jī)制來擴(kuò)展底層服務(wù)的功能，而不改變?cè)摲?wù)的實(shí)際實(shí)現(xiàn)，也不影響其整體可靠性。在Uber，我們提供了兩種不同的擴(kuò)展模式：邏輯擴(kuò)展和數(shù)據(jù)擴(kuò)展。擴(kuò)展的概念使我們能夠?qū)⒓軜?gòu)擴(kuò)展到多個(gè)團(tuán)隊(duì)，從而能夠相互獨(dú)立地工作。
邏輯擴(kuò)展
邏輯擴(kuò)展提供了一種機(jī)制來擴(kuò)展服務(wù)的底層邏輯。對(duì)于邏輯擴(kuò)展，我們使用的是提供者或插件模式的變體，其接口是以服務(wù)為基礎(chǔ)定義的。這使得擴(kuò)展團(tuán)隊(duì)可以在不修改底層平臺(tái)核心代碼的情況下，以接口驅(qū)動(dòng)的方式實(shí)現(xiàn)擴(kuò)展邏輯。
比如，一個(gè)司機(jī)上線，通常情況下，我們會(huì)進(jìn)行各種檢查以確保司機(jī)被允許上線（安全檢查、合規(guī)性等），其中的每一檢查項(xiàng)都是由各個(gè)團(tuán)隊(duì)負(fù)責(zé)的，一種實(shí)現(xiàn)方式是讓每個(gè)團(tuán)隊(duì)在同一個(gè)端點(diǎn)中編寫邏輯，但這可能會(huì)引入復(fù)雜性。每個(gè)檢查都需要自定義、完全不相關(guān)的邏輯。
在邏輯擴(kuò)展的情況下，“上線”端點(diǎn)將定義成一個(gè)接口，他們希望每個(gè)擴(kuò)展都符合預(yù)定義的請(qǐng)求類型和響應(yīng)，每個(gè)團(tuán)隊(duì)都會(huì)注冊(cè)一個(gè)擴(kuò)展，負(fù)責(zé)執(zhí)行這個(gè)邏輯。在這種情況下，他們可能只需了解一些有關(guān)司機(jī)的上下文，并返回一個(gè) bool，說明司機(jī)是否可以上線即可。上線的端點(diǎn)將簡(jiǎn)單地遍歷這些響應(yīng)，并確定其中所有響應(yīng)是否為 false。
這就將核心代碼與每個(gè)擴(kuò)展解耦，并提供了擴(kuò)展之間的隔離，它不知道其他邏輯在執(zhí)行什么。圍繞這一點(diǎn)，很容易構(gòu)建更多的功能，比如可觀察性或特征標(biāo)志。
數(shù)據(jù)擴(kuò)展
數(shù)據(jù)擴(kuò)展提供了一種將任意數(shù)據(jù)附加到接口的機(jī)制，以避免核心平臺(tái)數(shù)據(jù)模型的臃腫。對(duì)于數(shù)據(jù)擴(kuò)展，我們利用 Protobuf 的 Any 功能，這樣團(tuán)隊(duì)就可以將任意數(shù)據(jù)添加到請(qǐng)求中，服務(wù)通常會(huì)存儲(chǔ)這些數(shù)據(jù)或?qū)⑵鋫鬟f給邏輯擴(kuò)展，這樣核心平臺(tái)永遠(yuǎn)不會(huì)負(fù)責(zé)反序列化這個(gè) Any 的上下文，Protobuf的任何實(shí)現(xiàn)都會(huì)有一些基礎(chǔ)設(shè)施開銷，以獲取更強(qiáng)的類型，對(duì)于更簡(jiǎn)單的實(shí)現(xiàn)，可以使用 JSON 字符串來表示任意數(shù)據(jù)。
自定義
除了邏輯和數(shù)據(jù)擴(kuò)展之外，Uber 的許多團(tuán)隊(duì)都推出了適合自己領(lǐng)域的擴(kuò)展模式。例如，與我們的展示架構(gòu)層相關(guān)聯(lián)的許多集成都使用了基于 DAG 的任務(wù)執(zhí)行邏輯。
優(yōu)點(diǎn)
Uber 的幾乎每一個(gè)主要領(lǐng)域都在一定程度上受到了 DOMA 的影響，在過去的一年里，我們主要關(guān)注 Uber 的業(yè)務(wù)層，它為我們的各個(gè)業(yè)務(wù)領(lǐng)域提供了通用的邏輯。
在 Uber，DOMA 還很年輕，我們很高興將來能分享更多的數(shù)據(jù)和更深入的例子來了解我們的架構(gòu)，不過，在簡(jiǎn)化開發(fā)人員工作和降低整體系統(tǒng)復(fù)雜度方面，現(xiàn)階段的表現(xiàn)是非常積極樂觀的。
產(chǎn)品和平臺(tái)
DOMA 是 Uber 整個(gè)產(chǎn)品和平臺(tái)團(tuán)隊(duì)達(dá)成共識(shí)的結(jié)果，平臺(tái)支持成本通常下降一個(gè)數(shù)量級(jí)，產(chǎn)品團(tuán)隊(duì)也受益于開發(fā)效率的提升。
例如，我們擴(kuò)展架構(gòu)的一個(gè)早期平臺(tái)使用者通過采用擴(kuò)展架構(gòu)，減少了代碼審查、規(guī)劃和使用者學(xué)習(xí)曲線的時(shí)間，將新功能的優(yōu)先級(jí)和集成時(shí)間從三天降至三個(gè)小時(shí)。
降低復(fù)雜度
以前產(chǎn)品團(tuán)隊(duì)必須調(diào)用許多下游服務(wù)才能使用一個(gè)領(lǐng)域，現(xiàn)在他們只需要調(diào)用一個(gè)域即可。通過減少新功能的接觸點(diǎn)數(shù)量，平臺(tái)能夠?qū)⑸暇€時(shí)間縮短25-50%。此外，我們能夠?qū)?200個(gè)微服務(wù)劃分為70個(gè)領(lǐng)域，其中大約50%已經(jīng)實(shí)施，其中大部分都有一些未來使用用的計(jì)劃。
未來發(fā)展
在 Uber，我們計(jì)算過微服務(wù)的半衰期是1.5年，這意味著每1.5年就會(huì)有50%的微型服務(wù)流失。如果沒有網(wǎng)關(guān)，微服務(wù)架構(gòu)很容易由于這種流失而陷入“遷移地獄”，不斷變化的微服務(wù)不斷需要上游遷移，網(wǎng)關(guān)使團(tuán)隊(duì)能夠避免對(duì)底層領(lǐng)域服務(wù)的依賴性，這意味著這些服務(wù)可以在不強(qiáng)制進(jìn)行上游遷移的情況下進(jìn)行變更。
去年 Uber 最大的兩個(gè)平臺(tái)重寫都發(fā)生在網(wǎng)關(guān)后面，這些平臺(tái)擁有數(shù)百個(gè)依賴于它們的服務(wù)，這些服務(wù)將不得不遷移現(xiàn)有的使用者，在這些情況下，遷移的成本會(huì)非常高，這使得一個(gè)完整的平臺(tái)重寫幾乎是不可行的。
新業(yè)務(wù)和新產(chǎn)品
事實(shí)證明，使用 DOMA 設(shè)計(jì)的平臺(tái)可擴(kuò)展性更強(qiáng)，也更容易維護(hù)。Uber 的大多數(shù)團(tuán)隊(duì)之所以采用 DOMA，是因?yàn)橹С中碌臉I(yè)務(wù)線的成本已經(jīng)太高了。
實(shí)用建議
本節(jié)為希望采用 DOMA 的公司提供一些實(shí)用的建議，根據(jù)我們的經(jīng)驗(yàn)，一個(gè)成熟的、經(jīng)過深思熟慮的微服務(wù)架構(gòu)源于在正確的時(shí)間向正確的方向安靜的推進(jìn)，對(duì)于整個(gè)微服務(wù)架構(gòu)而言，是永遠(yuǎn)不可能實(shí)現(xiàn)真正的“重寫”。
因此，我們認(rèn)為微服務(wù)架構(gòu)更像是“修剪樹籬”，以便它最終能夠正確成長，而不是自上而下或一次性架構(gòu)（或重新架構(gòu)）的工作，這是一個(gè)動(dòng)態(tài)和漸進(jìn)的過程。
初創(chuàng)企業(yè)
驅(qū)動(dòng)采用微服務(wù)架構(gòu)的問題應(yīng)該是“我們什么時(shí)候應(yīng)該采用微服務(wù)架構(gòu)？”、“這對(duì)我們的組織有意義嗎？” ，正如我們?cè)谏厦嫠吹降哪菢樱m然微服務(wù)為擁有大量工程師的組織提供了很多的好處，但這也換來了復(fù)雜性的增加，會(huì)使功能的構(gòu)建更加困難。
在小型組織中，運(yùn)營效益可能無法抵消架構(gòu)復(fù)雜性的增加。此外，微服務(wù)架構(gòu)通常需要專門的工程資源來支持，這對(duì)于早期階段的公司來說可能超出了預(yù)算，或者從優(yōu)先級(jí)的角度來看不夠緊急。
考慮到這一點(diǎn)，暫緩采用微服務(wù)架構(gòu)也不是沒有道理的，如果一個(gè)公司組織確實(shí)選擇采用微服務(wù)，它應(yīng)該考慮“微服務(wù)作為大型分布式應(yīng)用”的類比，以及想要構(gòu)建的微服務(wù)之間的關(guān)注點(diǎn)分離。另外，要認(rèn)識(shí)到，第一批微服務(wù)很可能是最重要的，也是持續(xù)時(shí)間最長的，因?yàn)樗鼈冋嬲枋隽藰I(yè)務(wù)的核心。
中型企業(yè)
一旦一家公司達(dá)到了中等規(guī)模，有了多個(gè)團(tuán)隊(duì)，不同的功能和平臺(tái)之間的關(guān)注點(diǎn)明確分離就變得模糊了，微服務(wù)架構(gòu)就會(huì)變得比較有用了。
在這個(gè)階段，就可以開始考慮微服務(wù)之間的層次結(jié)構(gòu)。依賴關(guān)系管理可能變得更加重要，因?yàn)橐恍┓?wù)開始變得對(duì)業(yè)務(wù)變得越來越重要，越來越多的團(tuán)隊(duì)依賴這些服務(wù)了。
早期對(duì)平臺(tái)化的投資可能會(huì)在未來的道路上得到回報(bào)，如果能夠創(chuàng)建完全與產(chǎn)品無關(guān)的業(yè)務(wù)平臺(tái)，并避免核心平臺(tái)服務(wù)中的產(chǎn)品業(yè)務(wù)邏輯，就有可能避免很多的的技術(shù)債務(wù)了，此時(shí)采用擴(kuò)展來實(shí)現(xiàn)這一目標(biāo)可能是有意義的。
鑒于現(xiàn)階段微服務(wù)的數(shù)量可能還相對(duì)較少，將它們集中在一起可能意義不大，但是這里值得注意的是，在 Uber 的 DOMA 實(shí)現(xiàn)中，一個(gè)領(lǐng)域可以包含一個(gè)服務(wù)，所以用 "面向領(lǐng)域 "的方式來思考可能依然是有用的。
大型企業(yè)
規(guī)模較大的工程組織可能有數(shù)百名工程師和微服務(wù)以及多個(gè)依賴關(guān)系，這時(shí) DOMA 就可以發(fā)揮它的功能了。很可能會(huì)有一些明顯的微服務(wù)集群，這些集群可以很容易地組合在一起歸為一個(gè)領(lǐng)域，在它們前面有一個(gè)網(wǎng)關(guān)。遺留服務(wù)往往需要重構(gòu)或重寫，然后再進(jìn)行遷移，這個(gè)時(shí)候如果網(wǎng)關(guān)已經(jīng)到位的話，那么網(wǎng)關(guān)很快就會(huì)開始提供遷移方便方面的價(jià)值了。
明確的層次結(jié)構(gòu)也將變得越來越重要，一些服務(wù)將作為 "產(chǎn)品 "服務(wù)來運(yùn)行，以實(shí)現(xiàn)特定的功能或功能分組，而其他服務(wù)將越來越多地支持多個(gè)產(chǎn)品，并被認(rèn)為是一個(gè) "平臺(tái)"了。在這個(gè)階段，保持產(chǎn)品邏輯與平臺(tái)分離是至關(guān)重要的，以避免平臺(tái)團(tuán)隊(duì)的沉重運(yùn)營負(fù)擔(dān)以及整個(gè)系統(tǒng)的不穩(wěn)定性。
總結(jié)
隨著 Uber 越來越多的團(tuán)隊(duì)來采用 DOMA，我們?nèi)栽诜e極地推進(jìn) DOMA，DOMA 的關(guān)鍵洞察力在于，微服務(wù)架構(gòu)實(shí)際上只是一個(gè)大型的分布式程序，你可以將同樣的原則應(yīng)用于它的發(fā)展過程，就像你應(yīng)用于其他應(yīng)用程序一樣，DOMA 只是一種在實(shí)踐中思考這些原則的方法。
這項(xiàng)工作引入了業(yè)內(nèi)現(xiàn)有的多種設(shè)計(jì)模式來解決 Uber 的問題，同時(shí)也提出了一些新的模式，比如擴(kuò)展。希望本文對(duì)大家有所幫助。
原文鏈接：https://eng.uber.com/microservice-architecture/
K8S進(jìn)階訓(xùn)練營，點(diǎn)擊下方圖片了解詳情
