最近，業(yè)界圍繞面向服務(wù)的架構(gòu)，尤其是微服務(wù)架構(gòu)的弊端進(jìn)行了大量討論。幾年前，由于許多用戶(hù)關(guān)注微服務(wù)架構(gòu)的眾多優(yōu)勢(shì)，例如獨(dú)立部署形式的靈活性，明確的所有權(quán)，系統(tǒng)穩(wěn)定性的改進(jìn)，以及關(guān)注點(diǎn)的更好分離，許多企業(yè)很快采用了微服務(wù)架構(gòu)。而現(xiàn)在關(guān)于微服務(wù)會(huì)大大增加其復(fù)雜性的趨勢(shì)，有時(shí)甚至使瑣碎的功能也難以構(gòu)建的話(huà)題，引發(fā)了不少用戶(hù)的討論。

[[335051]]

Uber近年來(lái)一直在使用微服務(wù)，現(xiàn)在Uber已經(jīng)增長(zhǎng)到大約2200個(gè)關(guān)鍵微服務(wù)，這個(gè)過(guò)程中Uber做了不少的權(quán)衡。Uber表示，在過(guò)去的兩年中，他們嘗試降低微服務(wù)的復(fù)雜性，同時(shí)仍保持微服務(wù)架構(gòu)的優(yōu)勢(shì)。這篇文章詳細(xì)介紹了Uber對(duì)微服務(wù)架構(gòu)的通用方法，Uber將其稱(chēng)為“面向域的微服務(wù)架構(gòu)”(簡(jiǎn)稱(chēng)：DOMA)。

面對(duì)微服務(wù)的不足，批評(píng)微服務(wù)架構(gòu)的話(huà)題喧囂塵上，但很少有用戶(hù)主張完全拒絕微服務(wù)架構(gòu)。因?yàn)檫\(yùn)營(yíng)收益太重要了，似乎還有針對(duì)微服務(wù)的更好替代品。Uber使用DOMA通用方法的目標(biāo)是為降低總體系統(tǒng)復(fù)雜性，同時(shí)保持與微服務(wù)架構(gòu)相關(guān)聯(lián)的靈活性的企業(yè)，提供微服務(wù)向前發(fā)展的道路。

什么是微服務(wù)?

微服務(wù)是面向服務(wù)的架構(gòu)的擴(kuò)展。與過(guò)去大型的整體“服務(wù)”相反，微服務(wù)代表一組范圍狹窄的功能的應(yīng)用程序。這些應(yīng)用程序是托管的，并且可以通過(guò)網(wǎng)絡(luò)使用，并公開(kāi)定義明確的接口。其他應(yīng)用程序通過(guò)進(jìn)行“ 遠(yuǎn)程過(guò)程調(diào)用 ”(RPC)來(lái)調(diào)用這個(gè)接口。

微服務(wù)架構(gòu)的關(guān)鍵特征是代碼的托管，調(diào)用和部署方式。如果我們考慮大型的整體應(yīng)用程序，通常會(huì)將它們分為具有明確定義的接口的封裝組件。這些接口將被直接稱(chēng)為進(jìn)程內(nèi)接口，而不是通過(guò)網(wǎng)絡(luò)。通過(guò)這種方式，我們可以開(kāi)始將微服務(wù)當(dāng)做具有性能問(wèn)題(網(wǎng)絡(luò)I/O和序列化/反序列化)的庫(kù)，以便調(diào)用其任何功能。

當(dāng)我們以這種方式考慮微服務(wù)時(shí)，我們可能會(huì)思考為什么我們會(huì)完全采用微服務(wù)架構(gòu)?答案通常是獨(dú)立部署和擴(kuò)展。對(duì)于大型的整體應(yīng)用程序，企業(yè)不得不一次部署或釋放所有代碼。應(yīng)用程序的每個(gè)新版本都可能涉及許多更改，而且部署變得既危險(xiǎn)又費(fèi)時(shí)。任何差池都可能使整個(gè)系統(tǒng)癱瘓。

換句話(huà)說(shuō)，企業(yè)采用微服務(wù)來(lái)獲得運(yùn)營(yíng)的價(jià)值，而以性能為代價(jià)。企業(yè)還必須承擔(dān)維護(hù)支持微服務(wù)所需的基礎(chǔ)架構(gòu)的成本。事實(shí)證明，在很多情況下，這種權(quán)衡是有道理的，但這也是反對(duì)過(guò)早采用微服務(wù)架構(gòu)的理由之一。

緣起

Uber采用微服務(wù)架構(gòu)，因?yàn)榇蠹s在2012年至2013年，Uber擁有兩個(gè)整體服務(wù)，并且微服務(wù)的使用解決了許多運(yùn)營(yíng)問(wèn)題。

可用性風(fēng)險(xiǎn)。單一代碼庫(kù)中的單個(gè)回歸可以使整個(gè)系統(tǒng)癱瘓。

風(fēng)險(xiǎn)高昂的部署。由于頻繁需要回滾，因此執(zhí)行這些操作很痛苦且耗時(shí)。

關(guān)注點(diǎn)分離差。使用龐大的代碼庫(kù)，很難很好地保持關(guān)注點(diǎn)的分離。在指數(shù)增長(zhǎng)的環(huán)境中，權(quán)宜有時(shí)會(huì)導(dǎo)致邏輯和組件之間的邊界不清晰。

執(zhí)行效率低下。這些問(wèn)題加在一起使團(tuán)隊(duì)難以自主或獨(dú)立執(zhí)行。

換句話(huà)說(shuō)，隨著Uber的工程師人數(shù)從10增長(zhǎng)到100，擁有多個(gè)團(tuán)隊(duì)，擁有部分技術(shù)棧的整體式架構(gòu)將團(tuán)隊(duì)的命運(yùn)束縛在一起，使其難以獨(dú)立運(yùn)營(yíng)。

Uber采用了微服務(wù)架構(gòu)之后。最終，系統(tǒng)變得更加靈活，從而使團(tuán)隊(duì)更加自治。

系統(tǒng)可靠性。在微服務(wù)架構(gòu)中，總體系統(tǒng)可靠性得到提高。單個(gè)服務(wù)可以關(guān)閉(并回滾)，而無(wú)需關(guān)閉整個(gè)系統(tǒng)。

關(guān)注點(diǎn)分離。在架構(gòu)上，微服務(wù)架構(gòu)迫使Uber提出以下問(wèn)題：“為什么存在這項(xiàng)服務(wù)?”，從而更清楚地定義不同組件的角色。

清除所有權(quán)。誰(shuí)擁有什么代碼變得更加清楚。服務(wù)通常在個(gè)人，團(tuán)隊(duì)或企業(yè)級(jí)別擁有，從而實(shí)現(xiàn)更快的增長(zhǎng)。

自主執(zhí)行。獨(dú)立的部署和更清晰的所有權(quán)界限，可釋放各個(gè)產(chǎn)品和平臺(tái)團(tuán)隊(duì)的自主執(zhí)行權(quán)。

開(kāi)發(fā)人員速度。團(tuán)隊(duì)可以獨(dú)立部署代碼，這使他們能夠按照自己的節(jié)奏執(zhí)行。

毫不夸張地說(shuō)，沒(méi)有微服務(wù)架構(gòu)，Uber將無(wú)法實(shí)現(xiàn)今天維持的執(zhí)行規(guī)模和執(zhí)行質(zhì)量。

但是，隨著Uber規(guī)模的擴(kuò)大，從100名工程師增加到1000名工程師，Uber開(kāi)始注意到與系統(tǒng)復(fù)雜性大大增加相關(guān)的一系列問(wèn)題。使用微服務(wù)架構(gòu)，可以將單個(gè)整體的代碼庫(kù)換成“黑盒子”，“黑盒子”的功能可以隨時(shí)更改，并且很容易導(dǎo)致意外的發(fā)生。

要調(diào)試pick-up問(wèn)題，工程師必須在12個(gè)不同的團(tuán)隊(duì)中完成約50項(xiàng)服務(wù)。

由于服務(wù)之間的調(diào)用可能會(huì)深入很多層，因此了解服務(wù)之間的依賴(lài)性可能會(huì)變得非常困難。第n個(gè)依賴(lài)項(xiàng)中的延遲峰值可能會(huì)導(dǎo)致上游問(wèn)題的級(jí)聯(lián)。如果沒(méi)有合適的工具，就不可能看到實(shí)際發(fā)生的事情，從而使調(diào)試變得困難。

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

為了構(gòu)建簡(jiǎn)單的功能，工程師經(jīng)常必須跨多個(gè)服務(wù)工作，所有這些服務(wù)均由不同的個(gè)人和團(tuán)隊(duì)擁有。這就需要大量的協(xié)作以及花在會(huì)議，設(shè)計(jì)和代碼審查上的時(shí)間。當(dāng)團(tuán)隊(duì)在彼此的服務(wù)中構(gòu)建代碼，修改彼此的數(shù)據(jù)模型，甚至代表服務(wù)所有者執(zhí)行部署時(shí)，先前明確的服務(wù)所有權(quán)承諾將受到損害。可以形成網(wǎng)絡(luò)整體，其中必須將似乎獨(dú)立的所有服務(wù)一起部署以安全地執(zhí)行任何更改。

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

結(jié)果是開(kāi)發(fā)人員體驗(yàn)變慢，服務(wù)所有者不穩(wěn)定，遷移更加痛苦等等。對(duì)于已經(jīng)采用微服務(wù)架構(gòu)的企業(yè)而言，沒(méi)有回頭路。需要找到解決方案來(lái)克服這些挑戰(zhàn)

面向“域”的微服務(wù)架構(gòu)

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

因此，“面向域的微服務(wù)架構(gòu)”大量借鑒了已建立的組織代碼的方式，例如域驅(qū)動(dòng)設(shè)計(jì)，干凈架構(gòu)，面向服務(wù)的架構(gòu)，以及面向?qū)ο蠛兔嫦蚪涌诘脑O(shè)計(jì)模式。Uber將DOMA視為創(chuàng)新，因?yàn)樗窃诖笮徒M織的大型分布式系統(tǒng)中，利用既定設(shè)計(jì)原則的相對(duì)新穎的方法。

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

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

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

以下將深入研究Uber在DOMA中的實(shí)施，已經(jīng)看到的價(jià)值，以及為可能希望采用這種方法的企業(yè)提供的實(shí)用建議。

DOMA的實(shí)施

域

Uber域代表一個(gè)或多個(gè)與邏輯功能分組綁定的微服務(wù)的集合。設(shè)計(jì)域時(shí)常見(jiàn)的問(wèn)題是“域應(yīng)該有多大?” 在此Uber不提供任何指導(dǎo)。有些域可以包含數(shù)十個(gè)服務(wù)，有些域只能包含一個(gè)服務(wù)。

重要的任務(wù)是仔細(xì)考慮每個(gè)集合的邏輯角色。例如，Uber的地圖搜索服務(wù)構(gòu)成一個(gè)域，票價(jià)服務(wù)是一個(gè)領(lǐng)域，匹配平臺(tái)(匹配駕駛員)是一個(gè)域。這些也不總是遵循企業(yè)的組織結(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ān)注點(diǎn)”。另外，可以將層設(shè)計(jì)視為“大規(guī)模依賴(lài)管理”。

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

可以將頂層看作是特定的用戶(hù)體驗(yàn)(比如移動(dòng)功能)，而底層看作是通用的業(yè)務(wù)功能(比如賬戶(hù)管理)。這為我們思考故障面和域集成等問(wèn)題提供了有益的啟發(fā)。

值得注意的是，在這個(gè)圖表中，功能常常從特定的“向下”到更普遍的“向下”。可以想象，隨著需求的發(fā)展，一個(gè)簡(jiǎn)單的特性最終會(huì)越來(lái)越像一個(gè)平臺(tái)。事實(shí)上，這種向下的遷移是意料之中的，而且Uber的許多核心業(yè)務(wù)平臺(tái)一開(kāi)始只是針對(duì)乘客或司機(jī)的特定功能，隨著我們發(fā)展了更多的業(yè)務(wù)線(xiàn)，它們變得越來(lái)越普遍(比如Uber Eats或Uber Freight)。

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

• 基礎(chǔ)設(shè)施層。提供任何工程團(tuán)隊(duì)可以使用的功能。這是Uber對(duì)諸如存儲(chǔ)或網(wǎng)絡(luò)等重大工程問(wèn)題的解答。
• 業(yè)務(wù)層。提供Uber作為一個(gè)組織可以使用的功能，但這并不特定于特定的產(chǎn)品類(lèi)別或業(yè)務(wù)(LOB)，如乘車(chē)、餐飲或貨運(yùn)。
• 產(chǎn)品層。提供與特定產(chǎn)品類(lèi)別或LOB相關(guān)的功能，但與移動(dòng)應(yīng)用程序無(wú)關(guān)，比如“請(qǐng)求搭車(chē)”邏輯，它被多個(gè)搭車(chē)應(yīng)用程序(Rider、Rider“Lite”、m.uber.com等)利用。
• 演示層。提供與面向消費(fèi)者的應(yīng)用程序(移動(dòng)/web)中存在的特性直接相關(guān)的功能。
• 邊緣層。安全向外界開(kāi)放優(yōu)步服務(wù)。這一層也支持移動(dòng)應(yīng)用程序。

如您所見(jiàn)，后續(xù)的每一層都代表了越來(lái)越具體的功能分組，并且具有越來(lái)越小的故障面(換句話(huà)說(shuō)，更少的組件依賴(lài)于該層內(nèi)的功能)。

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

術(shù)語(yǔ)“網(wǎng)關(guān)API”在微服務(wù)架構(gòu)中已經(jīng)是一個(gè)廣泛建立的概念。Uber的定義與已建立的定義差別不大，除了傾向于將網(wǎng)關(guān)專(zhuān)門(mén)看作底層服務(wù)集合(稱(chēng)之為域)的單個(gè)入口點(diǎn)之外。網(wǎng)關(guān)的成功依賴(lài)于API設(shè)計(jì)的成功。

上圖說(shuō)明了網(wǎng)關(guān)的高級(jí)圖。它抽象出域的內(nèi)部細(xì)節(jié)——多個(gè)服務(wù)、數(shù)據(jù)表、ETL管道等。只有接口—RPC api、消息傳遞事件和查詢(xún)被公開(kāi)給其他域。

由于上游使用者只在單個(gè)服務(wù)上操作，因此通過(guò)上游服務(wù)只接受單個(gè)依賴(lài)項(xiàng)(而不是依賴(lài)于某個(gè)域中可能存在的多個(gè)下游服務(wù))，網(wǎng)關(guān)在未來(lái)的遷移、可發(fā)現(xiàn)性和系統(tǒng)復(fù)雜性的整體降低方面提供了許多好處。如果從面向?qū)ο笤O(shè)計(jì)的角度來(lái)考慮網(wǎng)關(guān)，那么它們就是接口定義，它使Uber能夠根據(jù)底層“實(shí)現(xiàn)”(在本例中是底層微服務(wù)的集合)來(lái)做任何想做的事情。

擴(kuò)展

擴(kuò)展表示一種擴(kuò)展域的機(jī)制。擴(kuò)展的基本定義是，它提供了一種機(jī)制來(lái)擴(kuò)展基礎(chǔ)服務(wù)的功能，而不改變?cè)摲?wù)的實(shí)際實(shí)現(xiàn)，也不影響其總體可靠性。在Uber，提供兩種不同的擴(kuò)展模型：邏輯擴(kuò)展和數(shù)據(jù)擴(kuò)展。擴(kuò)展的概念允許Uber將架構(gòu)擴(kuò)展到多個(gè)團(tuán)隊(duì)，從而能夠彼此獨(dú)立地工作。

邏輯擴(kuò)展

邏輯擴(kuò)展為擴(kuò)展服務(wù)的底層邏輯提供了一種機(jī)制。對(duì)于邏輯擴(kuò)展，Uber使用provider or plugin模式的變體，并在逐個(gè)服務(wù)的基礎(chǔ)上定義接口。這使得擴(kuò)展團(tuán)隊(duì)能夠以接口驅(qū)動(dòng)的方式實(shí)現(xiàn)擴(kuò)展邏輯，而無(wú)需修改底層平臺(tái)的核心代碼。

如，一個(gè)司機(jī)上線(xiàn)(go online)。通常，我們會(huì)進(jìn)行各種檢查，來(lái)確保司機(jī)可以運(yùn)營(yíng)(安全檢查、合規(guī)等)。每一個(gè)都屬于一個(gè)單獨(dú)的團(tuán)隊(duì)。實(shí)現(xiàn)這一點(diǎn)的一種方法是讓每個(gè)團(tuán)隊(duì)在相同的端點(diǎn)編寫(xiě)邏輯，但這可能會(huì)引入復(fù)雜性。每個(gè)檢查都需要定制的、完全不相關(guān)的邏輯。

對(duì)于邏輯擴(kuò)展，“go online”端點(diǎn)將定義一個(gè)接口，希望每個(gè)擴(kuò)展都符合預(yù)定義的請(qǐng)求類(lèi)型和響應(yīng)。每個(gè)團(tuán)隊(duì)將注冊(cè)一個(gè)負(fù)責(zé)執(zhí)行此邏輯的擴(kuò)展。在這種情況下，它們可能只是取一些關(guān)于驅(qū)動(dòng)程序的上下文，然后返回一個(gè)bool，說(shuō)明驅(qū)動(dòng)程序是否可以上線(xiàn)。go online端點(diǎn)將簡(jiǎn)單地遍歷這些響應(yīng)，并確定其中是否有錯(cuò)誤。

這將核心代碼與每個(gè)擴(kuò)展解耦，并提供擴(kuò)展之間的隔離，而不知道其他邏輯正在執(zhí)行。圍繞它構(gòu)建更多的功能很容易，比如可觀(guān)察性或特性標(biāo)記。

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

數(shù)據(jù)擴(kuò)展提供了將任意數(shù)據(jù)附加到接口，來(lái)避免核心平臺(tái)數(shù)據(jù)模型膨脹的機(jī)制。對(duì)于數(shù)據(jù)擴(kuò)展，Uber利用了Protobuf的Any功能，讓團(tuán)隊(duì)可以向請(qǐng)求添加任意數(shù)據(jù)。服務(wù)通常會(huì)存儲(chǔ)這些數(shù)據(jù)或?qū)⑵鋫鬟f給邏輯擴(kuò)展，便于核心平臺(tái)永遠(yuǎn)不會(huì)對(duì)這個(gè)任意上下文進(jìn)行反序列化(從而“knowing about”)。Protobuf的Any實(shí)現(xiàn)帶來(lái)了一些基礎(chǔ)設(shè)施開(kāi)銷(xiāo)，以換取更強(qiáng)的類(lèi)型。對(duì)于更簡(jiǎn)單的實(shí)現(xiàn)，可以簡(jiǎn)單地使用JSON字符串表示任意數(shù)據(jù)。

自定義

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

價(jià)值所在

Uber的幾乎每個(gè)主要域都在某種程度上受到了DOMA的影響。在過(guò)去的一年里，Uber主要關(guān)注業(yè)務(wù)層，它為不同的業(yè)務(wù)線(xiàn)提供了通用的邏輯。

DOMA在Uber還很年輕，然而從簡(jiǎn)化開(kāi)發(fā)人員體驗(yàn)和降低整個(gè)系統(tǒng)復(fù)雜性的角度來(lái)看，它的早期表現(xiàn)非常積極。

產(chǎn)品與平臺(tái)

DOMA是Uber跨產(chǎn)品和平臺(tái)團(tuán)隊(duì)一致努力的結(jié)果。平臺(tái)支持成本通常會(huì)下降一個(gè)數(shù)量級(jí)。產(chǎn)品團(tuán)隊(duì)受益于guard rails和加速的開(kāi)發(fā)。

例如，我們的擴(kuò)展架構(gòu)的早期平臺(tái)使用者能夠通過(guò)采用擴(kuò)展架構(gòu)減少代碼審查、規(guī)劃和用戶(hù)學(xué)習(xí)曲線(xiàn)的時(shí)間，將優(yōu)先級(jí)和集成新特性的時(shí)間從三天減少到三小時(shí)。

降低復(fù)雜性

以前的產(chǎn)品團(tuán)隊(duì)必須調(diào)用大量的下游服務(wù)來(lái)利用一個(gè)域;現(xiàn)在只需要調(diào)用一個(gè)。通過(guò)減少加載新功能的接觸點(diǎn)數(shù)量，平臺(tái)能夠減少25-50%的登陸時(shí)間。此外，能夠?qū)?200個(gè)微服務(wù)劃分為70個(gè)域。其中大約有50%已經(jīng)實(shí)現(xiàn)，而且大多數(shù)都有未來(lái)采用的計(jì)劃。

未來(lái)的遷移

在Uber，計(jì)算出微服務(wù)的半衰期是1.5年，這意味著每1.5年我們的微服務(wù)就會(huì)有50%的變動(dòng)。如果沒(méi)有網(wǎng)關(guān)，微服務(wù)架構(gòu)很容易因此陷入“遷移的噩夢(mèng)”。不斷變化的微服務(wù)需要不斷進(jìn)行上游遷移。

網(wǎng)關(guān)使團(tuán)隊(duì)能夠避免對(duì)基礎(chǔ)域服務(wù)的依賴(lài)，這意味著這些服務(wù)可以在不強(qiáng)制上游遷移的情況下進(jìn)行更改。

這些平臺(tái)有數(shù)百個(gè)依賴(lài)于它們的服務(wù)，而這些服務(wù)將不得不遷移現(xiàn)有的消費(fèi)者。在這些情況下，遷移的成本會(huì)非常高，使得重寫(xiě)一個(gè)完整的平臺(tái)變得不可行。

新的業(yè)務(wù)和產(chǎn)品線(xiàn)

實(shí)踐證明，使用DOMA設(shè)計(jì)的平臺(tái)具有更高的可擴(kuò)展性和易于維護(hù)性。Uber采納DOMA的大多數(shù)團(tuán)隊(duì)之所以這樣做，是因?yàn)橹С中碌臉I(yè)務(wù)線(xiàn)變得太昂貴了。

實(shí)用建議

Uber為希望采用DOMA的公司提供一些實(shí)用建議。指導(dǎo)原則是，根據(jù)Uber的經(jīng)驗(yàn)，一個(gè)成熟的、深思熟慮的微服務(wù)架構(gòu)來(lái)自于在正確的時(shí)間朝著正確的方向緩慢推進(jìn)。現(xiàn)實(shí)情況是，對(duì)于整個(gè)微服務(wù)架構(gòu)而言，真正的“重寫(xiě)”是不可能的。

因此，Uber認(rèn)為發(fā)展微服務(wù)架構(gòu)更像是“修剪園藝”，一步步上線(xiàn)正確增長(zhǎng)，而不是自上而下或一次性架構(gòu)(或重新架構(gòu))。這是一個(gè)動(dòng)態(tài)的，漸進(jìn)的過(guò)程。

初創(chuàng)企業(yè)

驅(qū)動(dòng)問(wèn)題應(yīng)該是“何時(shí)應(yīng)采用微服務(wù)架構(gòu)?” 以及“這對(duì)企業(yè)有意義嗎?” 如上所述，盡管微服務(wù)為擁有大量工程師的企業(yè)帶來(lái)了運(yùn)營(yíng)優(yōu)勢(shì)，但這種做法的代價(jià)是復(fù)雜性的增加，復(fù)雜性的增加使功能的構(gòu)建更加困難。

在初創(chuàng)企業(yè)中，運(yùn)營(yíng)收益可能無(wú)法抵消架構(gòu)復(fù)雜性的增加。此外，微服務(wù)架構(gòu)通常需要專(zhuān)用的工程資源來(lái)支持，這對(duì)于早期公司來(lái)說(shuō)可能超出預(yù)算，或者從優(yōu)先級(jí)的角度來(lái)看不是優(yōu)秀選擇。

考慮到這一點(diǎn)，完全擱置一段時(shí)間的微服務(wù)并非沒(méi)有道理。如果企業(yè)確實(shí)選擇采用微服務(wù)，則應(yīng)考慮“將微服務(wù)視為大型分布式應(yīng)用程序”的類(lèi)比，并考慮要構(gòu)建的微服務(wù)之間的關(guān)注點(diǎn)分離。此外，請(qǐng)注意第一個(gè)微服務(wù)可能真正地描述了業(yè)務(wù)的核心，因此可能是最重要的。

中型企業(yè)

對(duì)于中型企業(yè)，已經(jīng)有了成熟的團(tuán)隊(duì)，而關(guān)注點(diǎn)之間的明確區(qū)分變得模糊不清，那么不同功能和平臺(tái)之間的微服務(wù)架構(gòu)就變得更加有用。

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

平臺(tái)化的早期投資可能會(huì)在未來(lái)帶來(lái)回報(bào)。如果一個(gè)人能夠創(chuàng)造出完全與產(chǎn)品無(wú)關(guān)的商業(yè)平臺(tái)，并且在核心平臺(tái)服務(wù)中避免任意的產(chǎn)品邏輯，那么就有可能避免技術(shù)債務(wù)。此時(shí)采用擴(kuò)展來(lái)實(shí)現(xiàn)這個(gè)目標(biāo)是有意義的。

鑒于微服務(wù)的數(shù)量可能仍然很低，將它們聚在一起可能沒(méi)有意義。然而，這里值得注意的是，Uber的DOMA實(shí)現(xiàn)上下文中的域可以包含單個(gè)服務(wù)，因此以“面向域”的方式思考仍然是有用的。

大型企業(yè)

較大的企業(yè)組織可能擁有數(shù)百名工程師和微服務(wù)以及數(shù)個(gè)依賴(lài)項(xiàng)。至此，DOMA完全發(fā)揮了作用。可能會(huì)有明顯的微服務(wù)集群，可以很容易地將它們組合在一起，并在它們前面放置網(wǎng)關(guān)。傳統(tǒng)服務(wù)通常需要開(kāi)始進(jìn)行重構(gòu)或重寫(xiě)，然后再進(jìn)行遷移。這意味著，如果網(wǎng)關(guān)已經(jīng)存在，網(wǎng)關(guān)將很快開(kāi)始提供易于遷移方面的價(jià)值。

清晰的層次結(jié)構(gòu)也將變得越來(lái)越重要，因?yàn)槟承┓?wù)作為特定功能或功能分組的“產(chǎn)品”服務(wù)運(yùn)行，而其他服務(wù)將越來(lái)越多地支持多種產(chǎn)品，并被視為“平臺(tái)”。在此階段，保持任意產(chǎn)品邏輯與平臺(tái)的分離至關(guān)重要，這樣可以避免給平臺(tái)團(tuán)隊(duì)帶來(lái)沉重的運(yùn)營(yíng)負(fù)擔(dān)以及整個(gè)系統(tǒng)的不穩(wěn)定。

寫(xiě)在最后

Uber越來(lái)越多的團(tuán)隊(duì)采用DOMA，并且仍在積極發(fā)展DOMA。DOMA的關(guān)鍵見(jiàn)解是，微服務(wù)架構(gòu)實(shí)際上只是一個(gè)大型的分布式程序，可以將其應(yīng)用于所有軟件的原理和演進(jìn)。DOMA只是在實(shí)踐中考慮這些原則的一種方法。