【文章內(nèi)容簡介】 內(nèi)部隱藏。 將聚合和限界上下文映射成服務(wù) 聚合和限界上下文都提供了高內(nèi)聚的單元，并且提供設(shè)計良好的接口。聚合涉及一個單一領(lǐng)域概念的自包含狀態(tài)機(jī)，而限界上下文則代表一組相關(guān)的聚合。聚合和限 界上下文都可以作為微服務(wù)的邊界。考慮到初期盡量減少服務(wù)的數(shù)量，建議使用范圍更大的限界上下文來作為微服務(wù)邊界，熟悉后，可以進(jìn)一步使用聚合拆分。 第二章、規(guī)劃遷移 是否應(yīng)該使用微服務(wù) ? 微服務(wù)不應(yīng)作為一個目標(biāo)，使用微服務(wù)也不會讓你獲得勝利。采用微服務(wù)的決定一定是經(jīng)過深思熟慮的。從單體應(yīng)用遷移到微服務(wù)應(yīng)用應(yīng)該有充分的理由，例如獲得當(dāng)前單體應(yīng)用不具備的能力。在考慮想微服務(wù)架構(gòu)遷移之前，需要明確三個問題： 你希望從微服務(wù)中獲得什么 ? 除了微服務(wù)，還有什么其它的解決方案 ? 你怎么衡量微服務(wù)帶來的成效 ? 微服務(wù)不是免費的，它可能會引起組織系統(tǒng)性的變化，需要引入更多的運(yùn)維組件，改變現(xiàn)有的開發(fā)方式等等。因此需要充分考慮 ROI，以判斷一個遷移是否值得。 微服務(wù)帶來的好處主要有以下幾點，但請注意，帶來的這些好處大部分都可以通過其它方式獲得。 提升團(tuán)隊自治性 非常多的企業(yè)證明了團(tuán)隊自治帶來的好處。自治的團(tuán)隊通常不會很大，確保團(tuán)隊內(nèi)成員彼此都非常熟悉，自治團(tuán)隊在一個較小的范圍內(nèi)工作。業(yè)界有一些關(guān)于團(tuán)隊規(guī)模的范例，如亞馬遜的兩個披薩模型。如果正確使用團(tuán)隊自治性，會激發(fā)團(tuán)隊 成員成長并提升效率。當(dāng)團(tuán)隊擁有微服務(wù)的全部控制權(quán)，就會提升團(tuán)隊在整個組織中的自治性。 自治性不是微服務(wù)獨有的，有很多方式可以獲得自治。團(tuán)隊的自治主要涉及分配給團(tuán)隊的職責(zé)，而與使用什么樣的架構(gòu)關(guān)系不大。比如可以通過將代碼倉庫中的一部分授權(quán)給一個團(tuán)隊來促進(jìn)團(tuán)隊的自治。 加快上市時間 將變更的執(zhí)行和部署聚焦到各自獨立的微服務(wù)中，可以做到不用和其它服務(wù)協(xié)調(diào)發(fā)布時間，同時多個團(tuán)隊可以并行的處理待辦任務(wù)列表，這讓功能面世的時間大幅度加快。 當(dāng)然，不使用微服務(wù)也可以做到加快上市時間。如優(yōu)化上線流程等也會起 到一定的效果。通過對現(xiàn)有上線流程的分析，判斷是否可以通過調(diào)整任務(wù)執(zhí)行的順序，或者采用并行的方式來加快流程執(zhí)行的速度。 為負(fù)載更有效的擴(kuò)縮 每個微服務(wù)都可以獨立的進(jìn)行擴(kuò)縮，這樣會更加有效。因為我們只需要擴(kuò)展對處理當(dāng)前復(fù)雜有瓶頸的部分。當(dāng)負(fù)載降低，可以對這部分再進(jìn)行縮容。 如果不使用微服務(wù)，有很多方法可以應(yīng)對負(fù)載升高的情況。最簡單的就是使用配置更高的機(jī)器。另外，傳統(tǒng)的通過多個單體應(yīng)用的拷貝來進(jìn)行水平擴(kuò)展的方案也是非常有效的，雖然它對于數(shù)據(jù)庫的瓶頸沒有幫助。 提升魯棒性 例如多租戶的 SaaS 系 統(tǒng)，這類系統(tǒng)對可用性的要求很高，一旦出現(xiàn)宕機(jī)，影響范圍將會非常廣泛。通過使用微服務(wù)，將一個系統(tǒng)根據(jù)功能解耦成若干個獨立的服務(wù)，也就是說，當(dāng)一個功能出現(xiàn)問題時，不會影響其它服務(wù)的功能。這里需要注意的是，微服務(wù)提供的魯棒性不是免費的，并且由于服務(wù)部署在不同的機(jī)器上，這也會增加調(diào)用失敗的風(fēng)險。 如果不使用微服務(wù)，通過拷貝多個單體應(yīng)用進(jìn)行負(fù)載均衡也可以有效的提升系統(tǒng)的魯棒性。另一方面，系統(tǒng)的不穩(wěn)定通常都是人為的，如果系統(tǒng)存在很多人工的操作，則使用自動化的手段在很大程度上解決問題。 擴(kuò)展開發(fā)人員的數(shù)量 《 人月神話》中提到，只有將工作分割成互不影響的小塊，才能夠通過增加人數(shù)來加快發(fā)布進(jìn)度。微服務(wù)通過明確的邊界，限制了其自身的范圍和對其它服務(wù)的依賴。因此可以支持大量的開發(fā)人員。僅僅使用微服務(wù)通常是不夠的，還需要結(jié)合團(tuán)隊自治和服務(wù)所有權(quán)。 另一種不使用微服務(wù)的方法是實現(xiàn)模塊化的單體應(yīng)用，不同的團(tuán)隊擁有單體中的不同模塊。只要它們對外暴露的接口是穩(wěn)定的，那么就可以獨自的演化。 擁抱新技術(shù) 單體應(yīng)用限制了新技術(shù)的使用，因為通常它只使用一種開發(fā)語言，使用特定的部署平臺、運(yùn)維系統(tǒng)和一種數(shù)據(jù)庫。而微服務(wù)中的每一個獨立的服務(wù)都可以根據(jù)自身的特點進(jìn)行技術(shù)選型。成熟的微服務(wù)組織通常會限制可使用的技術(shù)棧。 在這一點上，單體應(yīng)用沒有太好的辦法。 什么時候不應(yīng)該使用微服務(wù) ? 在一些場景中是不適合使用微服務(wù)的，如下： 不了解的領(lǐng)域：服務(wù)邊界如果劃分有誤，則帶來的代價可能是非常高昂的，可能會導(dǎo)致服務(wù)間的高度耦合，則要比單體應(yīng)用更加糟糕。如果對業(yè)務(wù)領(lǐng)域尚不了解，不應(yīng)盲目的進(jìn)行服務(wù)拆分，而是應(yīng)該先學(xué)習(xí)領(lǐng)域知識。 初創(chuàng)系統(tǒng)：很多企業(yè)在系統(tǒng)初始階段就會考慮使用微服務(wù)架構(gòu)，但在實際實現(xiàn)時，都會先采用單體應(yīng)用。微服務(wù)對于擴(kuò)張來說是一個很好的選擇，但在初始階段，功能尚處于試驗階段，會根據(jù)用戶的需求不斷調(diào)整。一些功能可能會重寫，另一些功能可能會刪掉。另一方面，初始階段的資金有限，應(yīng)該將關(guān)注點放在產(chǎn)品本身上，單體應(yīng)用易于開發(fā)和測試，部署拓?fù)湟卜浅：唵?，相比微服?wù)不需要花費太多的資源和精力。通常來說，一個已經(jīng)存在的棕域系統(tǒng)相比一個新的綠域系統(tǒng)來說，更加容易拆分。 客戶自己安裝和管理的軟件：如果軟件打包后分發(fā)給客戶自行安裝和 管理，那么不應(yīng)該使用微服務(wù)。因為微服務(wù)的安裝和運(yùn)維非常復(fù)雜，客戶可能沒有安裝和管理微服務(wù)架構(gòu)應(yīng)用的能力。 沒有充分理由的情況下：這個前面也提到過，微服務(wù)作為一個分布式系統(tǒng)，使用起來