面向領(lǐng)域的微服務(wù)架構(gòu)

時(shí)間：2020-11-22 20:58:12

關(guān)鍵字：架構(gòu) 嵌入式

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]近來(lái)，一些關(guān)于面向服務(wù)架構(gòu)的話題，特別是針對(duì)微服務(wù)架構(gòu)的弊端這個(gè)話題上進(jìn)行了大量的討論。雖然在幾年前，微服務(wù)架構(gòu)受到很多人的青睞，因?yàn)樗鼈兲峁┝嗽S多好處，如獨(dú)立部署的靈活性、明確的所有權(quán)、系統(tǒng)穩(wěn)定性的改善以及更好的分離問(wèn)題等優(yōu)點(diǎn)。但是不久，就開(kāi)始有人吐槽微服務(wù)會(huì)大幅增加系統(tǒng)復(fù)雜性，有時(shí)甚至連一些簡(jiǎn)單的功能都難以構(gòu)建。

近來(lái)，一些關(guān)于面向服務(wù)架構(gòu)的話題，特別是針對(duì)微服務(wù)架構(gòu)的弊端這個(gè)話題上進(jìn)行了大量的討論。雖然在幾年前，微服務(wù)架構(gòu)受到很多人的青睞，因?yàn)樗鼈兲峁┝嗽S多好處，如獨(dú)立部署的靈活性、明確的所有權(quán)、系統(tǒng)穩(wěn)定性的改善以及更好的分離問(wèn)題等優(yōu)點(diǎn)。但是不久，就開(kāi)始有人吐槽微服務(wù)會(huì)大幅增加系統(tǒng)復(fù)雜性，有時(shí)甚至連一些簡(jiǎn)單的功能都難以構(gòu)建。

隨著Uber發(fā)展，我們目前擁有了大約2200個(gè)關(guān)鍵的微服務(wù)，并且也親身經(jīng)歷了這些權(quán)衡。在過(guò)去的兩年里，Uber一直在試圖降低微服務(wù)的復(fù)雜性的同時(shí)仍然保持著微服務(wù)架構(gòu)的優(yōu)勢(shì)。我們希望通過(guò)這篇博文介紹我們對(duì)微服務(wù)架構(gòu)的通用方法，我們稱之為“面向領(lǐng)域的微服務(wù)架構(gòu)”（DOMA）。

由于這些缺點(diǎn)，近年來(lái)也有一些批評(píng)微服務(wù)架構(gòu)的聲音，但是卻很少有人主張徹底拒絕微服務(wù)架構(gòu)。運(yùn)營(yíng)收益太重要了，而且似乎沒(méi)有有效的替代方案。我們介紹DOMA的目的是為了給那些希望降低整體系統(tǒng)復(fù)雜性，同時(shí)又保持微服務(wù)架構(gòu)相關(guān)靈活性的組織提供一些經(jīng)驗(yàn)建議。

這篇文章主要解釋了什么是DOMA，以及Uber采用這種架構(gòu)的原因，它對(duì)平臺(tái)和產(chǎn)品團(tuán)隊(duì)帶來(lái)哪些好處。最后，給想要采用這種架構(gòu)的團(tuán)隊(duì)一些建議。

什么是微服務(wù)

微服務(wù)是面向服務(wù)架構(gòu)的延伸。與2000年代相當(dāng)大的“服務(wù)”相比，微服務(wù)是代表一組小型功能的應(yīng)用程序。這些應(yīng)用通過(guò)網(wǎng)絡(luò)托管，并暴露出一個(gè)明確定義接口。其他應(yīng)用程序通過(guò)進(jìn)行遠(yuǎn)程過(guò)程調(diào)用（RPC）方式來(lái)調(diào)用這個(gè)接口。

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

當(dāng)我們以這種方式來(lái)思考微服務(wù)時(shí)，可能會(huì)質(zhì)疑為什么我們會(huì)采用微服務(wù)架構(gòu)。答案通常是獨(dú)立部署和擴(kuò)展。對(duì)于一個(gè)大型的單體應(yīng)用程序，應(yīng)用被迫一次性部署或發(fā)布所有的代碼。應(yīng)用程序的每一個(gè)新版本都可能涉及許多更改。部署變得風(fēng)險(xiǎn)大、耗時(shí)長(zhǎng)。任何人都可以使整個(gè)系統(tǒng)癱瘓。

換句話說(shuō)，業(yè)務(wù)采用微服務(wù)是以犧牲性能為代價(jià)來(lái)獲取運(yùn)營(yíng)利益。業(yè)務(wù)還必須承擔(dān)維護(hù)支持微服務(wù)所需的基礎(chǔ)設(shè)施的成本。事實(shí)證明，在很多情況下，這種權(quán)衡是很有意義的，但這也是反對(duì)過(guò)早采用微服務(wù)架構(gòu)的有力論據(jù)。

動(dòng)機(jī)

面向領(lǐng)域的微服務(wù)架構(gòu)

在Uber，我們也采用了微服務(wù)架構(gòu)，因?yàn)槲覀儯ù蠹s在2012-2013年）主要有兩個(gè)單體服務(wù)，遇到了很多通過(guò)微服務(wù)來(lái)解決的運(yùn)營(yíng)問(wèn)題。

可用性風(fēng)險(xiǎn)。單體代碼庫(kù)內(nèi)的一次回滾就會(huì)使整個(gè)系統(tǒng)（在本例中是Uber的全部）癱瘓。
部署風(fēng)險(xiǎn)大，成本高。在需要頻繁回滾的情況下，執(zhí)行這些操作既困難又耗時(shí)。
不平滑的關(guān)注點(diǎn)分離。在龐大的代碼庫(kù)中，很難保持良好的關(guān)注點(diǎn)分離。尤其在一個(gè)指數(shù)級(jí)增長(zhǎng)的環(huán)境中，權(quán)宜之計(jì)有時(shí)會(huì)導(dǎo)致邏輯和組件之間的界限不清。
執(zhí)行效率低下。這些問(wèn)題加在一起，使得團(tuán)隊(duì)很難獨(dú)立自主地執(zhí)行任務(wù)。

隨著Uber從10多個(gè)工程師發(fā)展到100多個(gè)工程師，多個(gè)團(tuán)隊(duì)擁有技術(shù)棧的碎片時(shí)，這種單一的架構(gòu)將團(tuán)隊(duì)的命運(yùn)捆綁在一起，使得獨(dú)立運(yùn)作變得困難。

因此，我們采用了微服務(wù)架構(gòu)。最終，我們的系統(tǒng)變得更加靈活，這使得團(tuán)隊(duì)能夠更加自主。

系統(tǒng)的可靠性。在微服務(wù)架構(gòu)中，整體系統(tǒng)的可靠性上升。單個(gè)服務(wù)可以在不影響整個(gè)系統(tǒng)的情況下宕機(jī)（并被回滾）。
關(guān)注點(diǎn)的分離。從架構(gòu)上來(lái)看，微服務(wù)架構(gòu)迫使你去問(wèn) "這個(gè)服務(wù)為什么存在？"更加清晰地定義不同組件的角色。
明確所有權(quán)。代碼擁有者變得更加清楚。服務(wù)通常由個(gè)人、團(tuán)隊(duì)或組織級(jí)別擁有，從而實(shí)現(xiàn)更快的增長(zhǎng)。
自主執(zhí)行。獨(dú)立的部署更清晰的所屬權(quán)限，讓不同的產(chǎn)品和平臺(tái)團(tuán)隊(duì)能夠自主執(zhí)行。
開(kāi)發(fā)人員的速度。應(yīng)用團(tuán)隊(duì)可以獨(dú)立部署他們的代碼，這使得他們能夠按照自己的項(xiàng)目進(jìn)度來(lái)執(zhí)行。

毫不夸張地說(shuō)，如果沒(méi)有微服務(wù)架構(gòu)，Uber不可能達(dá)到今天所保持的規(guī)模和執(zhí)行質(zhì)量。

然而，隨著公司規(guī)模的進(jìn)一步擴(kuò)大，從100多名工程師到1000多名工程師，我們開(kāi)始注意到一系列與系統(tǒng)復(fù)雜性大大增加的相關(guān)問(wèn)題。在微服務(wù)架構(gòu)下，人們用單一的整體代碼庫(kù)換取了黑盒，黑盒的功能隨時(shí)可能發(fā)生變化，很容易造成意外情況。

例如，工程師們不得不通過(guò)12個(gè)不同團(tuán)隊(duì)大約50個(gè)服務(wù)來(lái)調(diào)查問(wèn)題的根本原因。

理解服務(wù)之間的依賴關(guān)系可能會(huì)變得相當(dāng)困難，因?yàn)榉?wù)之間的調(diào)用可能會(huì)深入許多層。第n個(gè)依賴關(guān)系的延遲峰值可能會(huì)導(dǎo)致上游的一連串問(wèn)題。如果沒(méi)有合適的工具，就不可能看到實(shí)際發(fā)生的情況，這讓調(diào)試變得困難。

面向領(lǐng)域的微服務(wù)架構(gòu)

Jaeger于2018年中發(fā)布的Uber微服務(wù)架構(gòu)

為了構(gòu)建一個(gè)簡(jiǎn)單的功能，工程師往往需要跨多個(gè)服務(wù)工作，所有這些服務(wù)都由不同的個(gè)人和團(tuán)隊(duì)所擁有。這就需要跨部門(mén)跨團(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ò)化的單體可能會(huì)形成，看似獨(dú)立的服務(wù)都必須一起部署才能安全地執(zhí)行任何變更。

面向領(lǐng)域的微服務(wù)架構(gòu)

大約在2018年Uber的復(fù)雜流程示例，在DOMA之前需要10個(gè)接觸點(diǎn)才能進(jìn)行簡(jiǎn)單集成。

這樣所帶來(lái)的結(jié)果就是開(kāi)發(fā)進(jìn)度變慢、服務(wù)所屬不穩(wěn)定、遷移更困難等。對(duì)于已經(jīng)采用微服務(wù)架構(gòu)的企業(yè)來(lái)說(shuō)，已經(jīng)沒(méi)有回頭路了。這就變成了“有了它們不能活，沒(méi)有它們不能活”。

面向領(lǐng)域的微服務(wù)架構(gòu)

如果我們可以將微服務(wù)視為I / O綁定的庫(kù)，而將“微服務(wù)架構(gòu)”視為大型的分布式應(yīng)用程序，則可以使用眾所周知的架構(gòu)來(lái)思考如何組織代碼。

因此，“面向領(lǐng)域的微服務(wù)體系結(jié)構(gòu)”大量借鑒了組織代碼的既定方法，例如域驅(qū)動(dòng)設(shè)計(jì)，清晰架構(gòu)，面向服務(wù)的體系架構(gòu)以及面向?qū)ο蠛兔嫦蚪涌诘脑O(shè)計(jì)模式。我們認(rèn)為DOMA僅是創(chuàng)新，因?yàn)樗窃诖笮蛻?yīng)用的分布式系統(tǒng)中利用既定設(shè)計(jì)原則的相對(duì)新穎的方法。

DOMA相關(guān)的核心原理和術(shù)語(yǔ)如下：

圍繞相關(guān)微服務(wù)的集合，稱為域。
域的集合稱之為層。域所屬的層確定了允許該域內(nèi)的微服務(wù)承擔(dān)什么依賴性，稱為層設(shè)計(jì)。
為域提供接口，這些域被視為集合的單個(gè)入口點(diǎn)，稱為網(wǎng)關(guān)。
確定每個(gè)域都應(yīng)該與其他域不可知，一個(gè)域不應(yīng)該具有與其代碼庫(kù)或數(shù)據(jù)模型內(nèi)部硬編碼的另一個(gè)域相關(guān)的邏輯。由于團(tuán)隊(duì)經(jīng)常需要在另一個(gè)團(tuán)隊(duì)的域中包含邏輯（例如，自定義驗(yàn)證邏輯或數(shù)據(jù)模型上的某些元上下文），因此我們提供了一種擴(kuò)展架構(gòu)，以支持該域中定義明確的擴(kuò)展點(diǎn)。

通過(guò)提供系統(tǒng)的體系結(jié)構(gòu)，域網(wǎng)關(guān)和預(yù)定義的擴(kuò)展點(diǎn)，DOMA打算將微服務(wù)體系結(jié)構(gòu)從復(fù)雜的東西轉(zhuǎn)變?yōu)榭衫斫獾臇|西：結(jié)構(gòu)化的一組靈活，可重用和分層的組件。

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

Uber的措施

面向領(lǐng)域的微服務(wù)架構(gòu)

域

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

層設(shè)計(jì)

層設(shè)計(jì)回答了“什么服務(wù)可以調(diào)用其他什么服務(wù)？”的問(wèn)題。在Uber的微服務(wù)架構(gòu)中，我們可以將層設(shè)計(jì)視為“規(guī)?；年P(guān)注點(diǎn)分離”，或者，我們可以將層設(shè)計(jì)視為“規(guī)模化的依賴管理”。

層設(shè)計(jì)描述了一種機(jī)制，用于考慮Uber的故障影響范圍和跨服務(wù)依賴的產(chǎn)品特異性。當(dāng)域從底層移到頂層時(shí)，它們?cè)谥袛嗟那闆r下會(huì)影響較少的服務(wù)，并代表更多特定的產(chǎn)品使用案例。相反，底層的功能具有更多的依存關(guān)系，因此趨向于具有更大的影響半徑，并代表了更通用的業(yè)務(wù)功能集。下圖說(shuō)明了此概念。

面向領(lǐng)域的微服務(wù)架構(gòu)

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

值得注意的是，功能經(jīng)常會(huì)從這個(gè)圖表中 "向下 "移動(dòng)，從具體到更普遍?？梢韵胂?，一個(gè)簡(jiǎn)單的功能，隨著需求的變多，最終會(huì)變成越來(lái)越多的平臺(tái)。事實(shí)上，這種向下遷移是意料之中的，Uber的許多核心業(yè)務(wù)平臺(tái)一開(kāi)始都是針對(duì)騎手或司機(jī)的功能，隨著我們開(kāi)發(fā)出更多的業(yè)務(wù)線，它們也有了更多的依賴性，就會(huì)變得越來(lái)越通用（比如Uber Eats或Uber Freight）。

在Uber內(nèi)部，我們建立了以下五個(gè)層次。

基礎(chǔ)設(shè)施層。提供任何工程項(xiàng)目都可以使用的功能。這是Uber對(duì)諸如存儲(chǔ)或網(wǎng)絡(luò)等重大工程問(wèn)題的處理。
業(yè)務(wù)層。提供應(yīng)用可以使用的Uber功能，但并非特定于特定產(chǎn)品類別或業(yè)務(wù)線（LOB）的功能，例如乘車，進(jìn)餐或貨運(yùn)。
產(chǎn)品層。提供與特定產(chǎn)品類別或LOB相關(guān)但與移動(dòng)應(yīng)用程序無(wú)關(guān)的功能，例如由多個(gè)面向應(yīng)用程序的Rides所利用的“請(qǐng)求乘車”邏輯（Rider，Rider“Lite”，m.uber.com等）。
演示層。提供直接與面向消費(fèi)者的應(yīng)用程序（移動(dòng)/網(wǎng)絡(luò)）中存在的功能相關(guān)的功能。
邊緣層。將Uber服務(wù)安全地暴露給外界。該層也支持移動(dòng)應(yīng)用程序。

每層代表著越來(lái)越具體的功能分組，并且影響半徑越來(lái)越?。ɑ蛘邠Q句話說(shuō)，更少的組件取決于該層中的功能）。

網(wǎng)關(guān)

在微服務(wù)架構(gòu)中相信大家對(duì)“API網(wǎng)關(guān)”這個(gè)術(shù)語(yǔ)并不陌生。而在DOMA中我們的定義的網(wǎng)關(guān)其實(shí)與大家所熟知的“API網(wǎng)關(guān)”的概念相差無(wú)幾，只是我們傾向于將網(wǎng)關(guān)專門(mén)視為進(jìn)入基礎(chǔ)服務(wù)集合（稱為域）的單個(gè)入口點(diǎn)。網(wǎng)關(guān)的成功取決于API設(shè)計(jì)的成功。

面向領(lǐng)域的微服務(wù)架構(gòu)

由于上游使用者僅在單一服務(wù)上運(yùn)行，因此網(wǎng)關(guān)在遷移，服務(wù)發(fā)現(xiàn)以及整體系統(tǒng)復(fù)雜度方面提供了許多好處，上游服務(wù)僅需一個(gè)依賴項(xiàng)，而不是對(duì)域中可能存在的幾個(gè)下游服務(wù)的依賴。如果我們從面向?qū)ο笤O(shè)計(jì)的角度考慮網(wǎng)關(guān)，那么它們就是接口定義，它使我們能夠根據(jù)底層“實(shí)現(xiàn)”（在本例中為底層微服務(wù)的集合）做我們想做的任何事情。

擴(kuò)展

擴(kuò)展表示一種擴(kuò)展域的機(jī)制。擴(kuò)展的基本定義是，它提供了一種擴(kuò)展基礎(chǔ)服務(wù)功能的機(jī)制，而無(wú)需更改該服務(wù)的實(shí)際實(shí)現(xiàn)，也不會(huì)影響其整體可靠性。在Uber，我們提供了兩種不同的擴(kuò)展模型：邏輯擴(kuò)展和數(shù)據(jù)擴(kuò)展。擴(kuò)展的概念使我們能夠?qū)⒓軜?gòu)擴(kuò)展到能夠獨(dú)立工作的多個(gè)團(tuán)隊(duì)。

邏輯擴(kuò)展

邏輯擴(kuò)展提供了一種擴(kuò)展服務(wù)的底層邏輯機(jī)制。對(duì)于邏輯擴(kuò)展，我們使用提供程序或插件模式的變體，其接口是以服務(wù)為基礎(chǔ)定義的。這樣一來(lái)使得擴(kuò)展團(tuán)隊(duì)可以在不修改底層平臺(tái)核心代碼的情況下，以接口驅(qū)動(dòng)的方式實(shí)現(xiàn)擴(kuò)展邏輯。

例如，一個(gè)驅(qū)動(dòng)上線。通常，我們會(huì)進(jìn)行各種檢查以確保允許驅(qū)動(dòng)上線（安全檢查，合規(guī)性等）。這些都由一個(gè)單獨(dú)的團(tuán)隊(duì)擁有。一種實(shí)現(xiàn)方法是讓每個(gè)團(tuán)隊(duì)在同一端點(diǎn)編寫(xiě)邏輯，但這可能會(huì)增加復(fù)雜性。每次檢查都需要自定義且完全不相關(guān)的邏輯。

對(duì)于邏輯擴(kuò)展，“上線”端點(diǎn)將定義一個(gè)接口，他們希望每個(gè)擴(kuò)展都符合預(yù)定義的請(qǐng)求類型和響應(yīng)。每個(gè)團(tuán)隊(duì)都將注冊(cè)一個(gè)負(fù)責(zé)執(zhí)行此邏輯的擴(kuò)展。在這種情況下，他們可能簡(jiǎn)單地獲取一些關(guān)于驅(qū)動(dòng)程序的上下文況，然后返回布爾值，來(lái)判斷驅(qū)動(dòng)程序是否可以上線?！吧暇€”端點(diǎn)將簡(jiǎn)單地遍歷這些響應(yīng)，并確定它們其中是否有問(wèn)題。

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

數(shù)據(jù)擴(kuò)展

數(shù)據(jù)擴(kuò)展提供了一種將任意數(shù)據(jù)附加到接口的機(jī)制，來(lái)避免核心平臺(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è)任意上下文。Protobuf的任何實(shí)現(xiàn)都會(huì)有一些基礎(chǔ)設(shè)施開(kāi)銷，以換取更強(qiáng)的類型化。為了更簡(jiǎn)單的實(shí)現(xiàn)，我們可以直接使用JSON字符串來(lái)表示任意數(shù)據(jù)。

面向領(lǐng)域的微服務(wù)架構(gòu)

自定義擴(kuò)展

在邏輯和數(shù)據(jù)擴(kuò)展之外，Uber的很多團(tuán)隊(duì)都推出了自己適合自己領(lǐng)域的擴(kuò)展模式。例如，與我們的展示架構(gòu)綁定的很多集成都使用了基于DAG的任務(wù)執(zhí)行邏輯。

效益

面向領(lǐng)域的微服務(wù)架構(gòu)

Uber幾乎每個(gè)主要領(lǐng)域都在一定程度上受到了DOMA的影響。在過(guò)去的一年里，我們主要關(guān)注Uber的業(yè)務(wù)層，它為我們的各個(gè)業(yè)務(wù)線提供了通用的邏輯。

DOMA在Uber還很年輕，我們很高興能在未來(lái)分享更多的數(shù)據(jù)和我們架構(gòu)的深入案例。不過(guò)，在簡(jiǎn)化開(kāi)發(fā)人員體驗(yàn)和降低整體系統(tǒng)復(fù)雜度方面，早期的跡象是非常積極的。

產(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ì)從護(hù)欄和加速開(kāi)發(fā)中獲益。

例如，我們擴(kuò)展架構(gòu)的一個(gè)早期平臺(tái)消費(fèi)者通過(guò)采用擴(kuò)展架構(gòu)，減少了代碼審查、規(guī)劃和消費(fèi)者學(xué)習(xí)曲線的時(shí)間，能夠?qū)⒁粋€(gè)新功能的優(yōu)先級(jí)和集成時(shí)間從三天下降到三個(gè)小時(shí)。

降低復(fù)雜度

以前產(chǎn)品團(tuán)隊(duì)要利用一個(gè)領(lǐng)域，需要調(diào)用許多下游服務(wù)，現(xiàn)在只需要調(diào)用一個(gè)服務(wù)。通過(guò)減少入駐新功能的接觸點(diǎn)數(shù)量，平臺(tái)能夠?qū)⑷腭v時(shí)間縮短25-50%。此外，我們能夠?qū)?200個(gè)微服務(wù)劃分為70個(gè)域。其中大約有50%已經(jīng)實(shí)施，其中大部分有一些未來(lái)采用的計(jì)劃。

未來(lái)的遷移

在Uber，我們計(jì)算過(guò)微服務(wù)的半衰期是1.5年，也就是說(shuō)每1.5年我們就有50%的微服務(wù)流失。如果沒(méi)有網(wǎng)關(guān)，微服務(wù)架構(gòu)很容易因?yàn)檫@種流失而陷入“遷移地獄”。不斷變化的微服務(wù)需要不斷進(jìn)行上游遷移。網(wǎng)關(guān)使團(tuán)隊(duì)能夠避免對(duì)底層領(lǐng)域服務(wù)的依賴性，這意味著這些服務(wù)可以在不強(qiáng)制進(jìn)行上游遷移的情況下發(fā)生變化。

Uber在去年最大的兩次平臺(tái)重寫(xiě)都發(fā)生在網(wǎng)關(guān)背后。這些平臺(tái)有數(shù)百個(gè)依賴于它們的服務(wù)，這些服務(wù)將不得不遷移現(xiàn)有的平臺(tái)。在這些情況下，遷移的成本會(huì)非常高，使得的平臺(tái)重寫(xiě)變得不可行。

新的業(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ù)線的成本太高。

一些建議

面向領(lǐng)域的微服務(wù)架構(gòu)

本節(jié)為可能想采用DOMA的公司提供一些實(shí)用的建議。這里的指導(dǎo)原則是，根據(jù)我們的經(jīng)驗(yàn)，一個(gè)成熟的、經(jīng)過(guò)深思熟慮的微服務(wù)架構(gòu)源于在正確的時(shí)間向正確的方向悄悄推敲?，F(xiàn)實(shí)情況是，對(duì)于一個(gè)人的整個(gè)微服務(wù)架構(gòu)來(lái)說(shuō)，真正的“重寫(xiě)”是永遠(yuǎn)不可能的。

因此，我們認(rèn)為微服務(wù)架構(gòu)的演進(jìn)更像是“修剪樹(shù)籬”，使其最終正確成長(zhǎng)，而不是自上而下或一次性的架構(gòu)（或重新架構(gòu)）工作。這是一個(gè)動(dòng)態(tài)和漸進(jìn)的過(guò)程。

創(chuàng)業(yè)公司

驅(qū)動(dòng)性的問(wèn)題應(yīng)該是“我們應(yīng)該在什么時(shí)候采用微服務(wù)架構(gòu)？”和“它對(duì)我們的組織有意義嗎？”正如我們?cè)谏厦嫠吹降哪菢?，雖然微服務(wù)為擁有大量工程師的組織提供了運(yùn)營(yíng)上的好處，但這也換來(lái)了復(fù)雜性的增加，會(huì)使功能的構(gòu)建更加困難。

在小型公司中，運(yùn)營(yíng)效益可能無(wú)法抵消架構(gòu)復(fù)雜性的增加。此外，微服務(wù)架構(gòu)通常需要專門(mén)的工程資源來(lái)支持，這對(duì)于早期階段的公司來(lái)說(shuō)可能超出了預(yù)算，否則從優(yōu)先級(jí)的角度來(lái)看是次優(yōu)的。

考慮到這一點(diǎn)，在一段時(shí)間內(nèi)完全暫緩采用微服務(wù)也不是沒(méi)有道理的。如果一個(gè)組織真的選擇采用微服務(wù)，就應(yīng)該考慮“微服務(wù)作為大型分布式應(yīng)用”的類比，以及想要構(gòu)建的微服務(wù)之間的關(guān)注點(diǎn)分離。另外，要認(rèn)識(shí)到，第一批微服務(wù)很可能是最重要的，也是持續(xù)時(shí)間最長(zhǎng)的，因?yàn)樗鼈冋嬲枋隽藰I(yè)務(wù)的核心。

中等公司

一旦公司的規(guī)模達(dá)到中等，有了多個(gè)團(tuán)隊(duì)，不同的功能和平臺(tái)之間的關(guān)注點(diǎn)明確分離變得朦朧，微服務(wù)架構(gòu)就會(huì)變得更加明顯有用。

在這個(gè)階段，人們可以開(kāi)始考慮微服務(wù)之間的層次結(jié)構(gòu)。依賴性管理可能會(huì)變得更加重要，因?yàn)橐恍┓?wù)開(kāi)始對(duì)業(yè)務(wù)運(yùn)營(yíng)變得更加明顯的關(guān)鍵，越來(lái)越多的團(tuán)隊(duì)依賴這些服務(wù)。

早期對(duì)平臺(tái)化的投資可能會(huì)在未來(lái)的道路上得到回報(bào)。如果能夠創(chuàng)建完全產(chǎn)品不可知的業(yè)務(wù)平臺(tái)，避免核心平臺(tái)服務(wù)中任意的產(chǎn)品邏輯，這里就有可能避免技術(shù)債務(wù)。此時(shí)采用擴(kuò)展來(lái)實(shí)現(xiàn)這一目標(biāo)可能是有意義的。

鑒于微服務(wù)的數(shù)量可能還相當(dāng)少，將它們集中在一起可能沒(méi)有意義。不過(guò)，這里值得注意的是，在Uber的DOMA實(shí)現(xiàn)背景下，一個(gè)領(lǐng)域可以包含一個(gè)服務(wù)，所以用“面向領(lǐng)域”的方式來(lái)思考可能還是有用的。

大型公司

規(guī)模較大的工程組織可能有數(shù)百名工程師和微服務(wù)以及多個(gè)依賴關(guān)系。這時(shí)DOMA就達(dá)到了它的全部作用。很可能會(huì)有明顯的微服務(wù)集群，這些集群可以很容易地歸為域，在它們前面有一個(gè)網(wǎng)關(guān)。遺留服務(wù)往往開(kāi)始需要重構(gòu)或重寫(xiě)，然后進(jìn)行遷移，這意味著如果網(wǎng)關(guān)已經(jīng)到位的話，很快就會(huì)開(kāi)始在遷移的便利性方面提供價(jià)值。

明確的層次結(jié)構(gòu)也將變得越來(lái)越重要，一些服務(wù)將作為“產(chǎn)品”服務(wù)來(lái)運(yùn)行，以實(shí)現(xiàn)特定的功能或功能分組，而其他服務(wù)將越來(lái)越多地支持多個(gè)產(chǎn)品，并被認(rèn)為是“平臺(tái)”?，F(xiàn)階段關(guān)鍵是要保持任意產(chǎn)品邏輯與平臺(tái)的脫鉤，這樣才能避免給平臺(tái)團(tuán)隊(duì)帶來(lái)沉重的運(yùn)營(yíng)負(fù)擔(dān)以及整個(gè)系統(tǒng)的不穩(wěn)定。

最后的感想

面向領(lǐng)域的微服務(wù)架構(gòu)

隨著Uber越來(lái)越多的團(tuán)隊(duì)來(lái)采用DOMA，我們?nèi)栽诜e極地進(jìn)化DOMA。DOMA的關(guān)鍵洞察力在于，微服務(wù)架構(gòu)實(shí)際上只是一個(gè)大型的分布式程序，你可以將同樣的原則應(yīng)用于它的演進(jìn)，就像你應(yīng)用于任何軟件一樣。DOMA只是一種在實(shí)踐中思考這些原則的方法。我們希望其他人覺(jué)得它有用，我們也期待著反饋。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

面向領(lǐng)域的微服務(wù)架構(gòu)

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！