編者按：微服務(wù)是現(xiàn)今常見的一個理想模式，然而它們可能不該有這一地位。本文作者 Sean Kelly 解讀了關(guān)于微服務(wù)的5個謬誤，并告訴你究竟什么樣的企業(yè)才適合采用微服務(wù)架構(gòu)。

 

有一段時間，好像人人都對微服務(wù)推崇不已。每打開一次新聞訂閱，你都免不了會看見有些從來沒聽說過的公司大肆鼓吹微服務(wù)如何救他們的工程組織于水火之中。你所在的公司也很可能受到了微服務(wù)宣傳的狂轟濫炸。這些神奇的小東西好像真的無所不能，恰恰是你公司里那個龐大而老舊的數(shù)據(jù)庫的救星。

當(dāng)然了，現(xiàn)在回過頭來看，這些話簡直假得沒邊。這種后見之明的魅力就在于，它總是相當(dāng)接近于我們在幾個月以前以為自己擁有的2.0眼力。

我在本文中將總結(jié)幾個最主要的謬論以及微服務(wù)運(yùn)動中出的各種岔子，這些素材來源于一位公司員工。他所在的公司也被微服務(wù)無所不能、趁早打散整合應(yīng)用才是上策的論調(diào)席卷其中。雖然我這篇博文的本意并不是“微服務(wù)就是很差勁”，但我還是希望每一個讀者看完以后都能從多角度考慮一下微服務(wù)架構(gòu)對他們來說是否適合。

到底什么是“微服務(wù)”呢？

雖然有些支持者已經(jīng)逐條編出了一套蠻合理的微服務(wù)條件，但對于微服務(wù)包括什么不包括什么，實在是沒有一個明確的定義。

再回到它的名字來說，這自然不是一塊龐然大物。但在實踐中，它的實際含義是一種盡可能少涉及不同領(lǐng)域的一種微型服務(wù)，這樣做的目的是只專注于其使用者設(shè)定的目標(biāo)而精簡步驟。舉一個具體的例子吧，如果你開了一家有登錄功能的銀行，你最不想做的事情就應(yīng)該是獲得讀取用戶金融交易記錄的權(quán)限。你會把這個功能扔進(jìn)“交易服務(wù)”之類的部分里去（要記住起名字也不是件簡單的事啊）。

此外，人們在提及微服務(wù)時，他們還暗指那些需要和其他服務(wù)遠(yuǎn)程交互的服務(wù)。既然它們是各不相同的進(jìn)程，又經(jīng)常是各自不在同一個位置，一般就需要使用REST（代表性狀態(tài)轉(zhuǎn)移）服務(wù)或者某種RPC（遠(yuǎn)端進(jìn)程調(diào)用）協(xié)議使這些進(jìn)程能夠遠(yuǎn)程交互。

一開始這事看起來很簡單。似乎我們只需要把這些小東西放進(jìn)REST的應(yīng)用程序接口之類的東西，然后它們就會在網(wǎng)上交互啦。然而我的經(jīng)驗表明，人們深信不疑的這五個“事實”其實并不是真的。

1、微服務(wù)會讓代碼更加整潔。

2、編寫單一目的程序很簡單。

3、它們比整合性的程序更快。

4、工程師們在不同代碼庫下工作比較簡單。

5、這是搞定自動擴(kuò)展的最簡便方式（包括Docker在內(nèi)）。

謬誤#1 代碼更整潔

“就算沒有這個網(wǎng)絡(luò)邊界，你也完全有理由把代碼寫得更好。”

最顯而易見的事實是，要寫出更整潔或者更可持續(xù)的代碼，微服務(wù)或者其他建構(gòu)技術(shù)堆棧的方式并不是必要條件。沒錯，程序涉及的方面少了，你偷懶或者不經(jīng)思考就敲代碼的幾率也會下降。然而這個說法就像是，把人們想要的東西都下架了，犯罪幾率就會下降一樣。你并沒有解決問題，只是排除掉了很多可能性罷了。

把代碼內(nèi)部建構(gòu)在占有部分域的邏輯性服務(wù)上是現(xiàn)在的一種常見做法。這一方法化用了微服務(wù)的一個重要概念：在明確管理域的同時保持核心商業(yè)邏輯不會分散到不同部分。此外，使用這一方法也防止了網(wǎng)絡(luò)被過度占用的情況，因此也不會有其引發(fā)的潛在錯誤出現(xiàn)。

基于其仿照了圍繞微服務(wù)建立的服務(wù)導(dǎo)向型結(jié)構(gòu)，這一方法的額外收益是一旦你決定要改用微服務(wù)方式，很多設(shè)計工作都已經(jīng)提前完成了，對于域的理解也已經(jīng)足夠充分可以具體化了。一個嚴(yán)密的服務(wù)導(dǎo)向型架構(gòu)會從代碼本身出發(fā)，隨時間推移向堆棧中的物理拓?fù)渫卣埂?/p>

謬誤#2 更簡單

“分散式交互永遠(yuǎn)都不會簡單。”

一開始這樣做看上去會很簡單，但是大多數(shù)域（尤其是那些需要創(chuàng)建原型、依原型為中心發(fā)展并逐步重新定義域的新公司來說）都不會任你雕琢然后裝進(jìn)不同的小盒子里的。一個域的給定部分經(jīng)常需要獲取其他部分的數(shù)據(jù)以正常運(yùn)作，當(dāng)他們需要委派在域外寫入數(shù)據(jù)的權(quán)限時，這就變得更難了。一旦突破了自己的影響范圍，需要把其他部分也卷入到儲存修飾數(shù)據(jù)的請求列中，就進(jìn)入了分散式事務(wù)（有時也稱作長事務(wù)）處理的領(lǐng)域。

在給定請求中牽涉多個遠(yuǎn)程設(shè)備這一步驟困難重重。你是能并行調(diào)用，還是只能逐個完成呢？ 你是否了解這一連串環(huán)節(jié)中任何節(jié)點(diǎn)都可能會出現(xiàn)的可能錯誤（應(yīng)用層面和網(wǎng)絡(luò)層面皆有可能）？ 這對于請求列來說又意味著什么呢？ 分散式事務(wù)處理的每一部分都需要自我解決可能出現(xiàn)的問題的途徑，這工作量可不小，既得了解可能出現(xiàn)的問題，還得決定應(yīng)該如何解決這些問題。

謬誤#3 更快速

“只要多應(yīng)用一些附加規(guī)則，你就可以讓整合應(yīng)用的表現(xiàn)大大提高。”

想要去除這一謬誤還是有些困難的，因為事實上減少任務(wù)和加載物數(shù)量等等之后個人系統(tǒng)總會變得更快。

但這一說法終究是不具備普遍性的，我不懷疑那些轉(zhuǎn)向微服務(wù)的人們在服務(wù)速度提高的同時也發(fā)現(xiàn)了個人代碼路徑的孤立，但你得了解到你也是在許多調(diào)用之間加入了網(wǎng)絡(luò)部分。互聯(lián)網(wǎng)永遠(yuǎn)都不會像共駐代碼調(diào)用的速度那么快，雖然很多時候它是“足夠快”的。

此外，關(guān)于提高性能的說法中，很多實際上都完全是在吹捧技術(shù)堆棧的一種新語言，而不僅是關(guān)于在外部構(gòu)建代碼以運(yùn)用微服務(wù)的概念。用Scala或者Go（兩種微服務(wù)建構(gòu)的常用工具）的語言重寫Ruby on Rails, Django或者NodeJS這些老軟件本來就會基于其所用技術(shù)帶來性能上的提升。但是這些語言并不“在意”你是否把他們運(yùn)載的進(jìn)程叫做“微”服務(wù)，他們只是因為編譯方式等因素而有更好的表現(xiàn)而已。

而且，對于初創(chuàng)公司的大部分應(yīng)用，CPU或者內(nèi)存的性能幾乎從來都不是問題。問題在于產(chǎn)出比，而額外的網(wǎng)絡(luò)調(diào)用只會增大你的投入產(chǎn)出比。

謬誤#4 對工程師來說更簡單

“一批在孤立代碼庫中工作的工程師只會招致‘不怪我’綜合癥。”

雖然在測試階段，讓小團(tuán)隊集中在小問題上看起來比較簡單，但這最終會經(jīng)常帶來很多其他問題。你解決問題的空間會縮小，收獲也會縮水。

最大的問題是，不管要做什么，就算做出最小的改變，你也得同時運(yùn)行越來越多的服務(wù)。這意味著單單這種讓工程師在本地運(yùn)行所有程序的方法，也需要你投入精力和時間來打造和維護(hù)。像Docker這樣的工具可以把這件事變得更簡單，但是隨著程序的改動，還是需要有人來進(jìn)行維護(hù)。

此外，這也會讓寫入測驗變得更加困難，因為編寫一套合適的綜合測試要求編寫者了解所有給定交互會涉及到的服務(wù)、捕捉到所有可能的錯誤案例等等。單單是了解系統(tǒng)就要花掉更多的時間，而這些時間本來是可以用來改進(jìn)系統(tǒng)的。雖然我從來都不會跟程序員說花在理解系統(tǒng)上的時間是無謂的，但我絕對會勸告人們不要在確定自己需要之前過早提高系統(tǒng)的復(fù)雜程度。

最終，它還會帶來人際問題。橫跨多個服務(wù)、需要多次調(diào)節(jié)的漏洞真的能讓人心力交瘁，因為它需要多組工程師協(xié)調(diào)、同步努力來解決。還可能出現(xiàn)這種情況：人們都覺得自己不應(yīng)該負(fù)責(zé)，盡可能地把問題都推給別的組。而當(dāng)工程師們在同一個代碼庫中工作時，他們對于彼此的了解會不斷深化，系統(tǒng)本身也會隨之不斷發(fā)展，他們會精誠協(xié)作解決問題，而不是各據(jù)一方互不往來。

謬誤#5 可擴(kuò)展性更強(qiáng)

“擴(kuò)展微服務(wù)和擴(kuò)展整合程序其實是一樣簡單的。”

不是說將服務(wù)分成離散單元然后通過Docker這樣的工具來擴(kuò)展不是一個平行擴(kuò)展的好方法，但是要說這種方法只能用于微服務(wù)，那可就不對了。整合應(yīng)用也完全可以用這種辦法。你可以創(chuàng)建一個整合應(yīng)用的邏輯集合，只用來處理流量的一個子集。比如，你的內(nèi)置程序接口請求、儀表前段和背景工作服務(wù)器可以共用一個代碼庫，但是你不用分別解決這三個子集的問題。

這一點(diǎn)的好處是，在微服務(wù)中，你可以將單個集群調(diào)整到其給定的工作負(fù)載，以及單獨(dú)擴(kuò)展它們以響應(yīng)給定工作負(fù)載的流量激增。所以，在一開始微服務(wù)引導(dǎo)你使用這種方法的時候，你應(yīng)該知道它也完全適用于擴(kuò)展整合應(yīng)用的堆棧。

那你應(yīng)該在什么時候用微服務(wù)？

“在你們的整個工程師團(tuán)體都準(zhǔn)備好之后。”

讓我們來復(fù)習(xí)一遍應(yīng)該什么時候轉(zhuǎn)而使用這一方法（或者是，如果你的公司剛開始運(yùn)行，該怎么判斷這是否是正確的開始方式）并以此作為結(jié)尾。

要構(gòu)建一個嚴(yán)密的、可工作的微服務(wù)方式，最重要的那一步就是搞清楚你在哪一領(lǐng)域工作。如果你現(xiàn)在還不了解或者還在努力弄懂，微服務(wù)可能對你來說將是弊大于利。然而，如果你已經(jīng)有了深刻的理解，并且知道了邊界在哪里、相關(guān)性如何，那么微服務(wù)方式對你來說可能是正確的選擇。

另外一件需要掌握的事情是你的工作流——具體來講，是工作流與分散式事務(wù)如何關(guān)聯(lián)。如果你知曉每一種類的請求在你的系統(tǒng)中運(yùn)行的路徑，還了解這些路徑可能出錯的位置、方式和原因，那么你就可以開始建立處理請求的分散式模型了。

同時對于工作流的了解也算是一種監(jiān)控。關(guān)于監(jiān)控的學(xué)問可比“微服務(wù)與整合應(yīng)用孰優(yōu)孰劣”大多了，但它仍然應(yīng)該是你進(jìn)行編程工作時的重點(diǎn)。要弄懂你系統(tǒng)的各個部分中為什么有的表現(xiàn)不佳甚至頻出錯誤，你得有大量數(shù)據(jù)以供調(diào)遣。如果你建立了一個堅實的監(jiān)控系統(tǒng)，你就能隨著系統(tǒng)運(yùn)作增進(jìn)對其各部分的平行了解。

最終，當(dāng)你能夠給你的工程團(tuán)隊展現(xiàn)出真真切切的價值時，微服務(wù)就能給你帶來公司成長、規(guī)模擴(kuò)大以及收入增加了。雖然創(chuàng)造和嘗試是很有趣的，但在一天工作結(jié)束的時候，對很多公司來說最重要的東西還是他們的底線在哪。如果你因為看到一篇博客說整合應(yīng)用不怎么樣而推遲上線一個可以給公司帶來盈利的新功能，那你得好好跟公司交代一下了。有時候這些抉擇是值得的，而有些時候不是。選擇好自己的戰(zhàn)場，打你該打的技術(shù)仗，這樣以后你才能游刃有余。

摘要：

我希望下次再有人給你推薦微服務(wù)時，你會考慮到這些新的條件和問題。如我開頭所說，我寫這篇文章不是為了告訴你微服務(wù)是不好的，而是說，不假思索地采用微服務(wù)會給未來的發(fā)展埋下隱患。

如果你要問我提倡哪種，我會建議先通過定義清晰的代碼模塊構(gòu)建內(nèi)部服務(wù)。如果未來有需要，再把他們分置到不同的服務(wù)中。這一方法不是唯一解，也不是解決代碼混亂的靈丹妙藥，然而比起在沒做好充足準(zhǔn)備之前就開始應(yīng)付一大堆的微服務(wù)來說，這一方法可以讓你前進(jìn)得更快一些。

 

翻譯來自：蟲洞翻翻  譯者ID：韓念欣

編者按：微服務(wù)是現(xiàn)今常見的一個理想模式，然而它們可能不該有這一地位。本文作者Sean Kelly解讀了關(guān)于微服務(wù)的5個謬誤，并告訴你究竟什么樣的企業(yè)才適合采用微服務(wù)架構(gòu)。

有一段時間，好像人人都對微服務(wù)推崇不已。每打開一次新聞訂閱，你都免不了會看見有些從來沒聽說過的公司大肆鼓吹微服務(wù)如何救他們的工程組織于水火之中。你所在的公司也很可能受到了微服務(wù)宣傳的狂轟濫炸。這些神奇的小東西好像真的無所不能，恰恰是你公司里那個龐大而老舊的數(shù)據(jù)庫的救星。

當(dāng)然了，現(xiàn)在回過頭來看，這些話簡直假得沒邊。這種后見之明的魅力就在于，它總是相當(dāng)接近于我們在幾個月以前以為自己擁有的2.0眼力。

我在本文中將總結(jié)幾個最主要的謬論以及微服務(wù)運(yùn)動中出的各種岔子，這些素材來源于一位公司員工。他所在的公司也被微服務(wù)無所不能、趁早打散整合應(yīng)用才是上策的論調(diào)席卷其中。雖然我這篇博文的本意并不是“微服務(wù)就是很差勁”，但我還是希望每一個讀者看完以后都能從多角度考慮一下微服務(wù)架構(gòu)對他們來說是否適合。

到底什么是“微服務(wù)”呢？

雖然有些支持者已經(jīng)逐條編出了一套蠻合理的微服務(wù)條件，但對于微服務(wù)包括什么不包括什么，實在是沒有一個明確的定義。

再回到它的名字來說，這自然不是一塊龐然大物。但在實踐中，它的實際含義是一種盡可能少涉及不同領(lǐng)域的一種微型服務(wù)，這樣做的目的是只專注于其使用者設(shè)定的目標(biāo)而精簡步驟。舉一個具體的例子吧，如果你開了一家有登錄功能的銀行，你最不想做的事情就應(yīng)該是獲得讀取用戶金融交易記錄的權(quán)限。你會把這個功能扔進(jìn)“交易服務(wù)”之類的部分里去（要記住起名字也不是件簡單的事啊）。

此外，人們在提及微服務(wù)時，他們還暗指那些需要和其他服務(wù)遠(yuǎn)程交互的服務(wù)。既然它們是各不相同的進(jìn)程，又經(jīng)常是各自不在同一個位置，一般就需要使用REST（代表性狀態(tài)轉(zhuǎn)移）服務(wù)或者某種RPC（遠(yuǎn)端進(jìn)程調(diào)用）協(xié)議使這些進(jìn)程能夠遠(yuǎn)程交互。

一開始這事看起來很簡單。似乎我們只需要把這些小東西放進(jìn)REST的應(yīng)用程序接口之類的東西，然后它們就會在網(wǎng)上交互啦。然而我的經(jīng)驗表明，人們深信不疑的這五個“事實”其實并不是真的。

1、微服務(wù)會讓代碼更加整潔。

2、編寫單一目的程序很簡單。

3、它們比整合性的程序更快。

4、工程師們在不同代碼庫下工作比較簡單。

5、這是搞定自動擴(kuò)展的最簡便方式（包括Docker在內(nèi)）。

謬誤#1 代碼更整潔

“就算沒有這個網(wǎng)絡(luò)邊界，你也完全有理由把代碼寫得更好。”

最顯而易見的事實是，要寫出更整潔或者更可持續(xù)的代碼，微服務(wù)或者其他建構(gòu)技術(shù)堆棧的方式并不是必要條件。沒錯，程序涉及的方面少了，你偷懶或者不經(jīng)思考就敲代碼的幾率也會下降。然而這個說法就像是，把人們想要的東西都下架了，犯罪幾率就會下降一樣。你并沒有解決問題，只是排除掉了很多可能性罷了。

把代碼內(nèi)部建構(gòu)在占有部分域的邏輯性服務(wù)上是現(xiàn)在的一種常見做法。這一方法化用了微服務(wù)的一個重要概念：在明確管理域的同時保持核心商業(yè)邏輯不會分散到不同部分。此外，使用這一方法也防止了網(wǎng)絡(luò)被過度占用的情況，因此也不會有其引發(fā)的潛在錯誤出現(xiàn)。

基于其仿照了圍繞微服務(wù)建立的服務(wù)導(dǎo)向型結(jié)構(gòu)，這一方法的額外收益是一旦你決定要改用微服務(wù)方式，很多設(shè)計工作都已經(jīng)提前完成了，對于域的理解也已經(jīng)足夠充分可以具體化了。一個嚴(yán)密的服務(wù)導(dǎo)向型架構(gòu)會從代碼本身出發(fā)，隨時間推移向堆棧中的物理拓?fù)渫卣埂?/p>

謬誤#2 更簡單

“分散式交互永遠(yuǎn)都不會簡單。”

一開始這樣做看上去會很簡單，但是大多數(shù)域（尤其是那些需要創(chuàng)建原型、依原型為中心發(fā)展并逐步重新定義域的新公司來說）都不會任你雕琢然后裝進(jìn)不同的小盒子里的。一個域的給定部分經(jīng)常需要獲取其他部分的數(shù)據(jù)以正常運(yùn)作，當(dāng)他們需要委派在域外寫入數(shù)據(jù)的權(quán)限時，這就變得更難了。一旦突破了自己的影響范圍，需要把其他部分也卷入到儲存修飾數(shù)據(jù)的請求列中，就進(jìn)入了分散式事務(wù)（有時也稱作長事務(wù)）處理的領(lǐng)域。

在給定請求中牽涉多個遠(yuǎn)程設(shè)備這一步驟困難重重。你是能并行調(diào)用，還是只能逐個完成呢？ 你是否了解這一連串環(huán)節(jié)中任何節(jié)點(diǎn)都可能會出現(xiàn)的可能錯誤（應(yīng)用層面和網(wǎng)絡(luò)層面皆有可能）？ 這對于請求列來說又意味著什么呢？ 分散式事務(wù)處理的每一部分都需要自我解決可能出現(xiàn)的問題的途徑，這工作量可不小，既得了解可能出現(xiàn)的問題，還得決定應(yīng)該如何解決這些問題。

謬誤#3 更快速

“只要多應(yīng)用一些附加規(guī)則，你就可以讓整合應(yīng)用的表現(xiàn)大大提高。”

想要去除這一謬誤還是有些困難的，因為事實上減少任務(wù)和加載物數(shù)量等等之后個人系統(tǒng)總會變得更快。

但這一說法終究是不具備普遍性的，我不懷疑那些轉(zhuǎn)向微服務(wù)的人們在服務(wù)速度提高的同時也發(fā)現(xiàn)了個人代碼路徑的孤立，但你得了解到你也是在許多調(diào)用之間加入了網(wǎng)絡(luò)部分。互聯(lián)網(wǎng)永遠(yuǎn)都不會像共駐代碼調(diào)用的速度那么快，雖然很多時候它是“足夠快”的。

此外，關(guān)于提高性能的說法中，很多實際上都完全是在吹捧技術(shù)堆棧的一種新語言，而不僅是關(guān)于在外部構(gòu)建代碼以運(yùn)用微服務(wù)的概念。用Scala或者Go（兩種微服務(wù)建構(gòu)的常用工具）的語言重寫Ruby on Rails, Django或者NodeJS這些老軟件本來就會基于其所用技術(shù)帶來性能上的提升。但是這些語言并不“在意”你是否把他們運(yùn)載的進(jìn)程叫做“微”服務(wù)，他們只是因為編譯方式等因素而有更好的表現(xiàn)而已。

而且，對于初創(chuàng)公司的大部分應(yīng)用，CPU或者內(nèi)存的性能幾乎從來都不是問題。問題在于產(chǎn)出比，而額外的網(wǎng)絡(luò)調(diào)用只會增大你的投入產(chǎn)出比。

謬誤#4 對工程師來說更簡單

“一批在孤立代碼庫中工作的工程師只會招致‘不怪我’綜合癥。”

雖然在測試階段，讓小團(tuán)隊集中在小問題上看起來比較簡單，但這最終會經(jīng)常帶來很多其他問題。你解決問題的空間會縮小，收獲也會縮水。

最大的問題是，不管要做什么，就算做出最小的改變，你也得同時運(yùn)行越來越多的服務(wù)。這意味著單單這種讓工程師在本地運(yùn)行所有程序的方法，也需要你投入精力和時間來打造和維護(hù)。像Docker這樣的工具可以把這件事變得更簡單，但是隨著程序的改動，還是需要有人來進(jìn)行維護(hù)。

此外，這也會讓寫入測驗變得更加困難，因為編寫一套合適的綜合測試要求編寫者了解所有給定交互會涉及到的服務(wù)、捕捉到所有可能的錯誤案例等等。單單是了解系統(tǒng)就要花掉更多的時間，而這些時間本來是可以用來改進(jìn)系統(tǒng)的。雖然我從來都不會跟程序員說花在理解系統(tǒng)上的時間是無謂的，但我絕對會勸告人們不要在確定自己需要之前過早提高系統(tǒng)的復(fù)雜程度。

最終，它還會帶來人際問題。橫跨多個服務(wù)、需要多次調(diào)節(jié)的漏洞真的能讓人心力交瘁，因為它需要多組工程師協(xié)調(diào)、同步努力來解決。還可能出現(xiàn)這種情況：人們都覺得自己不應(yīng)該負(fù)責(zé)，盡可能地把問題都推給別的組。而當(dāng)工程師們在同一個代碼庫中工作時，他們對于彼此的了解會不斷深化，系統(tǒng)本身也會隨之不斷發(fā)展，他們會精誠協(xié)作解決問題，而不是各據(jù)一方互不往來。

謬誤#5 可擴(kuò)展性更強(qiáng)

“擴(kuò)展微服務(wù)和擴(kuò)展整合程序其實是一樣簡單的。”

不是說將服務(wù)分成離散單元然后通過Docker這樣的工具來擴(kuò)展不是一個平行擴(kuò)展的好方法，但是要說這種方法只能用于微服務(wù)，那可就不對了。整合應(yīng)用也完全可以用這種辦法。你可以創(chuàng)建一個整合應(yīng)用的邏輯集合，只用來處理流量的一個子集。比如，你的內(nèi)置程序接口請求、儀表前段和背景工作服務(wù)器可以共用一個代碼庫，但是你不用分別解決這三個子集的問題。

這一點(diǎn)的好處是，在微服務(wù)中，你可以將單個集群調(diào)整到其給定的工作負(fù)載，以及單獨(dú)擴(kuò)展它們以響應(yīng)給定工作負(fù)載的流量激增。所以，在一開始微服務(wù)引導(dǎo)你使用這種方法的時候，你應(yīng)該知道它也完全適用于擴(kuò)展整合應(yīng)用的堆棧。

那你應(yīng)該在什么時候用微服務(wù)？

“在你們的整個工程師團(tuán)體都準(zhǔn)備好之后。”

讓我們來復(fù)習(xí)一遍應(yīng)該什么時候轉(zhuǎn)而使用這一方法（或者是，如果你的公司剛開始運(yùn)行，該怎么判斷這是否是正確的開始方式）并以此作為結(jié)尾。

要構(gòu)建一個嚴(yán)密的、可工作的微服務(wù)方式，最重要的那一步就是搞清楚你在哪一領(lǐng)域工作。如果你現(xiàn)在還不了解或者還在努力弄懂，微服務(wù)可能對你來說將是弊大于利。然而，如果你已經(jīng)有了深刻的理解，并且知道了邊界在哪里、相關(guān)性如何，那么微服務(wù)方式對你來說可能是正確的選擇。

另外一件需要掌握的事情是你的工作流——具體來講，是工作流與分散式事務(wù)如何關(guān)聯(lián)。如果你知曉每一種類的請求在你的系統(tǒng)中運(yùn)行的路徑，還了解這些路徑可能出錯的位置、方式和原因，那么你就可以開始建立處理請求的分散式模型了。

同時對于工作流的了解也算是一種監(jiān)控。關(guān)于監(jiān)控的學(xué)問可比“微服務(wù)與整合應(yīng)用孰優(yōu)孰劣”大多了，但它仍然應(yīng)該是你進(jìn)行編程工作時的重點(diǎn)。要弄懂你系統(tǒng)的各個部分中為什么有的表現(xiàn)不佳甚至頻出錯誤，你得有大量數(shù)據(jù)以供調(diào)遣。如果你建立了一個堅實的監(jiān)控系統(tǒng)，你就能隨著系統(tǒng)運(yùn)作增進(jìn)對其各部分的平行了解。

最終，當(dāng)你能夠給你的工程團(tuán)隊展現(xiàn)出真真切切的價值時，微服務(wù)就能給你帶來公司成長、規(guī)模擴(kuò)大以及收入增加了。雖然創(chuàng)造和嘗試是很有趣的，但在一天工作結(jié)束的時候，對很多公司來說最重要的東西還是他們的底線在哪。如果你因為看到一篇博客說整合應(yīng)用不怎么樣而推遲上線一個可以給公司帶來盈利的新功能，那你得好好跟公司交代一下了。有時候這些抉擇是值得的，而有些時候不是。選擇好自己的戰(zhàn)場，打你該打的技術(shù)仗，這樣以后你才能游刃有余。

摘要：

我希望下次再有人給你推薦微服務(wù)時，你會考慮到這些新的條件和問題。如我開頭所說，我寫這篇文章不是為了告訴你微服務(wù)是不好的，而是說，不假思索地采用微服務(wù)會給未來的發(fā)展埋下隱患。

如果你要問我提倡哪種，我會建議先通過定義清晰的代碼模塊構(gòu)建內(nèi)部服務(wù)。如果未來有需要，再把他們分置到不同的服務(wù)中。這一方法不是唯一解，也不是解決代碼混亂的靈丹妙藥，然而比起在沒做好充足準(zhǔn)備之前就開始應(yīng)付一大堆的微服務(wù)來說，這一方法可以讓你前進(jìn)得更快一些。

翻譯來自：蟲洞翻翻 譯者ID：韓念欣