在介紹了為什么微服務(wù)應(yīng)該由事件驅(qū)動(dòng)的簡(jiǎn)介博客之后，我想采取一些其他步驟，并在有關(guān)博客的同時(shí)準(zhǔn)備我即將進(jìn)行的一系列演講（請(qǐng)參閱jBCNconf和Red Hat Summit，舊金山 ）。 在Twitter @christianposta上關(guān)注我，了解該項(xiàng)目的更新。 在本文中，我們討論了雕刻整體的第一部分。

我將在這些文章中深入探討的整體內(nèi)容來(lái)自Ticket Monster教程 ，該教程很長(zhǎng)時(shí)間以來(lái)一直是如何使用Java EE和Red Hat技術(shù)構(gòu)建出色應(yīng)用程序的典型示例。 我們之所以使用Ticket Monster，是因?yàn)樗且豢顚懙煤芎玫膽?yīng)用程序，可以很好地跨越“非平凡的”和“示例過(guò)于復(fù)雜”的界限。 出于說(shuō)明目的，它是完美的，我們可以具體指出它，并使用真實(shí)的示例代碼討論某些方法的優(yōu)缺點(diǎn)。 請(qǐng)根據(jù)進(jìn)一步的討論仔細(xì)研究領(lǐng)域和當(dāng)前架構(gòu) 。

看看上面的當(dāng)前架構(gòu)，我們可以發(fā)現(xiàn)事情已經(jīng)很好地解決了。 我們具有UI組件，業(yè)務(wù)服務(wù)和長(zhǎng)期持久性存儲(chǔ)，它們之間很好地分離和解耦，但打包為單個(gè)可部署文件（在這種情況下為WAR文件）。 如果我們檢查源代碼，就會(huì)發(fā)現(xiàn)代碼具有類似的 結(jié)構(gòu) 。 如果我們要部署它，則對(duì)任何組件的任何更改都將決定整個(gè)可部署程序的構(gòu)建，測(cè)試和發(fā)布。 進(jìn)行微服務(wù)的先決條件之一是組件的自治性 ，因此可以在不中斷系統(tǒng)其余部分的情況下隔離地開發(fā)，測(cè)試和部署它們。 那么，如果我們僅在此處劃分不同的層并獨(dú)立部署，該怎么辦？ 那么我們可以實(shí)現(xiàn)某些自主權(quán)嗎？

過(guò)去，我們已經(jīng)花了很多時(shí)間爭(zhēng)論這種類型的體系結(jié)構(gòu)，這似乎是有道理的。 我們希望能夠根據(jù)其需求擴(kuò)展各個(gè)組件。 如果我們需要處理更多的Web請(qǐng)求，請(qǐng)擴(kuò)展Web層。 如果這些服務(wù)開始成為瓶頸，則可以擴(kuò)展業(yè)務(wù)服務(wù)層。 與其余應(yīng)用程序/服務(wù)無(wú)關(guān)地處理和管理數(shù)據(jù)庫(kù)以及數(shù)據(jù)訪問(wèn)層。 將UI邏輯與中間層和數(shù)據(jù)訪問(wèn)“分離”是一個(gè)很好的指導(dǎo)原則，但不要將其與要求的層混淆。

實(shí)際上 ，實(shí)際發(fā)生的是，所有這些“分層的”架構(gòu)組件，由于其所有關(guān)注點(diǎn)分離等，都非常容易屈服于數(shù)據(jù)和數(shù)據(jù)庫(kù)的異想天開。 我們可以添加所需的所有CPU，所需的所有中間層和UI層，但是無(wú)論我們的網(wǎng)絡(luò)，計(jì)算，內(nèi)存等發(fā)展速度如何，此類系統(tǒng)的瓶頸通常是競(jìng)爭(zhēng)性的領(lǐng)域模型，最終數(shù)據(jù)庫(kù)。 這里的“域模型”壓力很大……從事微服務(wù)的互聯(lián)網(wǎng)公司可能沒有復(fù)雜，模棱兩可和相互矛盾的域模型，例如FSI或保險(xiǎn)或零售商，可能……例如，twitter的域很簡(jiǎn)單……發(fā)布并顯示推文……但是，這在如此大規(guī)模的情況下變得復(fù)雜了……企業(yè)開始同時(shí)遇到這兩個(gè)問(wèn)題。.領(lǐng)域模型及其復(fù)雜性與如何進(jìn)行擴(kuò)展一樣重要（并且通常會(huì)阻礙擴(kuò)展工作）。 因此，現(xiàn)在您只是想“我們將僅使用像MongoDB這樣的NoSQL數(shù)據(jù)庫(kù)，以便我們可以擴(kuò)展后端”……現(xiàn)在您遇到了更多問(wèn)題。

那我們的團(tuán)隊(duì)呢？ 像這樣設(shè)計(jì)系統(tǒng)的另一部分是，我們可以讓專家團(tuán)隊(duì)以不同的速度，不同的位置，不同的工具等獨(dú)立地在這些層上工作。他們只需要彼此共享一個(gè)接口，就可以自主工作。 這在某種程度上起到了法律作用：

設(shè)計(jì)系統(tǒng)……受約束的組織只能產(chǎn)生設(shè)計(jì)，這些設(shè)計(jì)是這些組織的通信結(jié)構(gòu)的副本

不幸的是，我覺得事實(shí)恰恰相反。 并不是通過(guò)這種架構(gòu)，我們可以為團(tuán)隊(duì)和效率的專業(yè)化創(chuàng)造機(jī)會(huì)。 因?yàn)槲覀兊慕M織結(jié)構(gòu)迫使我們降低了系統(tǒng)架構(gòu)。 就像我們有獨(dú)立的數(shù)據(jù)庫(kù)團(tuán)隊(duì)，UI團(tuán)隊(duì)，安全性，操作，QA，構(gòu)建和發(fā)布等一樣。 這是我們組織數(shù)十年來(lái)的組織方式。 但是，如果您看看實(shí)踐微服務(wù)的公司的成功之處，則它們的組織結(jié)構(gòu)會(huì)有很大不同 。

讓我們看看會(huì)發(fā)生什么。 以Ticket Monster應(yīng)用程序?yàn)槔?#xff0c;該業(yè)務(wù)要求我們更改網(wǎng)站管理的方式。 他們要求我們添加一些額外的字段，以跟蹤與音樂(lè)會(huì)在網(wǎng)站上的添加和刪除頻率有關(guān)，因?yàn)樗麄兿Ｍ槍?duì)時(shí)間，地點(diǎn)，地點(diǎn)，天氣等。如果企業(yè)希望向管理用戶顯示此預(yù)測(cè)分析，則可能涉及UI團(tuán)隊(duì)。 當(dāng)然，這將涉及更改應(yīng)用程序的業(yè)務(wù)服務(wù)層。 這肯定會(huì)影響數(shù)據(jù)庫(kù)的更改。 我們想在我們的應(yīng)用程序中添加一些功能，以在所有層次上甚至在所有涉及的團(tuán)隊(duì)之間施加連鎖反應(yīng)。 現(xiàn)在，我們必須讓項(xiàng)目經(jīng)理與所有相關(guān)團(tuán)隊(duì)協(xié)調(diào)和跟蹤會(huì)議。 我們需要?jiǎng)?chuàng)建票證，以使UI和數(shù)據(jù)庫(kù)團(tuán)隊(duì)能夠做的所有事情都不會(huì)涉及質(zhì)量保證，安全性，操作等。 所有這些都在我們所有團(tuán)隊(duì)之間創(chuàng)建了復(fù)雜的同步點(diǎn)，現(xiàn)在我們必須協(xié)調(diào)各層的所有更改，構(gòu)建和發(fā)布（并將所有內(nèi)容一起部署！）。 這不是我們想要的自治類型。 我們不能彼此獨(dú)立地進(jìn)行更改，實(shí)際上，我們已經(jīng)變得非常脆弱。

對(duì)于我們的Ticket Monster應(yīng)用程序，讓我們更喜歡將功能分為具有凝聚力的“垂直”，而不是通過(guò)技術(shù)或組織層面 。 每個(gè)行業(yè)都有其自己的“ UI”（或UI組件），“業(yè)務(wù)服務(wù)”和“數(shù)據(jù)庫(kù)”，這些特定于網(wǎng)站的管理功能。 （但是，對(duì)于第一步，我們將UI保留為一個(gè)整體，將其分解成碎片。盡管有其自身的挑戰(zhàn)，我們將繼續(xù)拆分UI）。 Ticket Monster還允許用戶查看和預(yù)訂音樂(lè)會(huì)的訂單。 讓我們將其拆分為自己的垂直字段。 它還可能有忠誠(chéng)度，推薦，搜索，廣告，個(gè)性化等。我們將這些內(nèi)容劃分為各自的垂直領(lǐng)域，每個(gè)垂直領(lǐng)域都擁有自己的數(shù)據(jù)庫(kù)，UI和集成點(diǎn)（REST服務(wù)，后端等）。 如果我們需要更改網(wǎng)站的“忠誠(chéng)度”功能，則無(wú)需重新部署整個(gè)整體商務(wù)服務(wù)層或任何與“搜索”相關(guān)的內(nèi)容。 我可以將忠誠(chéng)度的一部分從UI部署到所需的數(shù)據(jù)庫(kù)，而不會(huì)影響對(duì)其他服務(wù)的更改。 理想情況下，一個(gè)團(tuán)隊(duì)也將擁有并運(yùn)營(yíng)每項(xiàng)服務(wù)。

這使我們?cè)诖a內(nèi)具有更好的凝聚力，并在服務(wù)之間具有更大的自治權(quán)。 一旦您開始了解沿著業(yè)務(wù)功能垂直領(lǐng)域拆分意味著什么，我們就可以為每個(gè)垂直領(lǐng)域探索其有限的上下文 。 或者在有限的上下文中應(yīng)用CQRS是否有意義。 還是根據(jù)其讀/寫模式（文檔？關(guān)系圖？），以及您是否贊成一致性還是可以容忍數(shù)據(jù)丟失/數(shù)據(jù)不一致，應(yīng)使用哪種類型的數(shù)據(jù)庫(kù)。 或交易，補(bǔ)償，道歉等可能會(huì)是什么樣子。 不斷地..現(xiàn)在，我們可以根據(jù)最適合我們的單個(gè)服務(wù)的決策，而不是層或整體的最低公分母來(lái)做出這些決策。 這就是我們將在下一篇文章中繼續(xù)探討的內(nèi)容！ 敬請(qǐng)關(guān)注！

更新資料

Twitter上的某人（感謝@herrwieger！）向我指出了這一點(diǎn)： 自包含系統(tǒng) （SCS）闡明了我在此處寫過(guò)的這個(gè)概念。 這一點(diǎn)很準(zhǔn)確，完全符合我的意思。 當(dāng)我們?cè)谟邢薜纳舷挛闹刑剿髅總€(gè)“獨(dú)立系統(tǒng)”時(shí)，更有趣的事情發(fā)生了，然后只有在必要時(shí)，它才分解為更精細(xì)的微服務(wù)。 在討論整體時(shí)，邊界是重要的考慮因素，這就是我在這里談到的以及SCS定義的內(nèi)容。

翻譯自: https://www.javacodegeeks.com/2016/06/carving-java-ee-monolith-microservices.html

總結(jié)

以上是生活随笔為你收集整理的将Java EE Monolith雕刻成微服务的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。