monolith

在介紹了為什么微服務應該由事件驅動的簡介博客之后，我想采取一些其他步驟，并在有關博客的同時準備我即將進行的一系列演講（在jBCNconf和Red Hat Summit上與您見面） 。舊金山 ）。 在Twitter @christianposta上關注我，了解該項目的更新。 在本文中，我們討論了雕刻整體的第一部分。

我將在這些文章中深入探討的整體內容來自Ticket Monster教程 ，該教程長期以來一直是如何使用Java EE和Red Hat技術構建出色應用程序的典型示例。 我們之所以使用Ticket Monster，是因為它是一款寫得很好的應用程序，可以很好地跨越“非平凡的”和“示例過于復雜”的界限。 出于說明目的，它是完美的，我們可以具體指出它，并使用真實的示例代碼討論某些方法的利弊。 請根據進一步的討論仔細研究領域和當前架構 。

看看上面的當前架構，我們可以發現事情已經很好地解決了。 我們具有UI組件，業務服務和長期持久性存儲，它們之間很好地分離和解耦，但打包為單個可部署文件（在這種情況下為WAR文件）。 如果我們檢查源代碼，就會發現代碼具有類似的 結構 。 如果我們要部署它，則對任何組件的任何更改都將要求構建，測試和發布整個可部署組件。 進行微服務的先決條件之一是組件的自治性 ，因此可以在不中斷系統其余部分的情況下隔離地開發，測試和部署它們。 那么，如果我們僅在此處劃分不同的層并獨立部署，該怎么辦？ 那么我們可以實現某些自主權嗎？

過去，我們已經花了很多時間爭論這種類型的體系結構，這似乎是有道理的。 我們希望能夠根據其需求擴展各個組件。 如果我們需要處理更多的Web請求，請擴展Web層。 如果這些服務開始成為瓶頸，則可以擴展業務服務層。 與其余應用程序/服務無關地處理和管理數據庫以及數據訪問層。 將UI邏輯與中間層和數據訪問“分離”是一個很好的指導原則，但不要將其與需要的層混淆。

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

那我們的團隊呢？ 架構這樣的系統的另一部分是，讓我們可以讓專家團隊以不同的速度，不同的位置，不同的工具等獨立地在這些層上工作。他們只需要彼此共享一個接口，就可以自主工作。 這在某種程度上起到了法律作用：

設計系統……受約束的組織只能產生設計，這些設計是這些組織的通信結構的副本

不幸的是，我覺得事實恰恰相反。 并不是通過這種架構，我們可以為團隊和效率的專業化創造機會。 因為我們的組織結構迫使我們降低了系統架構。 就像我們有獨立的數據庫團隊，UI團隊，安全性，操作，QA，構建和發布等一樣。 這是我們組織數十年來的組織方式。 但是，如果您看看實踐微服務的公司的成功之處，則它們的組織結構會有很大不同 。

讓我們看看會發生什么。 以Ticket Monster應用程序為例，該業務要求我們更改網站管理的方式。 他們要求我們添加一些與跟蹤Concert添加到網站的頻率有關的額外字段，因為他們希望添加預測性分析，以根據時間，位置，地點，天氣等。如果企業希望向管理用戶顯示此預測分析，則可能涉及UI團隊。 當然，這將涉及更改應用程序的業務服務層。 這肯定會影響數據庫的更改。 我們想在我們的應用程序中添加一些功能，以在所有層次上甚至在所有涉及的團隊中強制施加連鎖React。 現在，我們必須讓項目經理與所有相關團隊協調和跟蹤會議。 我們需要創建票證，以使UI和DB團隊做所有事情，而不必說質量保證，安全性，操作等。 所有這些都在我們所有團隊之間創建了復雜的同步點，現在我們必須協調我們各層的所有更改，構建和發布（并將所有內容一起部署！）。 這不是我們想要的自治類型。 我們不能彼此獨立地進行更改，實際上，我們已經變得非常脆弱。

對于我們的Ticket Monster應用程序，讓我們更喜歡將功能分為具有凝聚力的“垂直”，而不是通過技術或組織層面 。 每個行業都有其自己的“ UI”（或UI組件），“業務服務”和“數據庫”，這些特定于網站的管理功能。 （但是，對于第一步，我們將UI保留為整體，將其背后的部分分解掉。我們將重新分解UI，盡管這有其自身的挑戰）。 Ticket Monster還允許用戶查看和預訂音樂會的訂單。 讓我們將其拆分為自己的垂直字段。 它還可能具有忠誠度，推薦，搜索，廣告，個性化等。我們將這些內容劃分為各自的垂直領域，每個垂直領域都擁有自己的數據庫，UI和集成點（REST服務，后端等）。 如果我們需要更改網站的“忠誠度”功能，則無需重新部署整個整體商務服務層或任何與“搜索”相關的內容。 我可以將一部分忠誠度從UI部署到所需的數據庫，而不會影響其他服務的更改。 理想情況下，一個團隊也將擁有并運營每項服務。

這使我們在代碼內的凝聚力更好，服務之間的自治性更高。 一旦您開始了解沿著業務功能垂直領域拆分意味著什么，我們就可以為每個垂直領域探索其有限的上下文 。 或者在有限的上下文中應用CQRS是否有意義。 或基于其讀/寫模式（文檔，關系圖，數據庫）以及您是否贊成一致性還是可以容忍數據丟失/數據不一致，應使用哪種類型的數據庫。 或交易，補償，道歉等可能會是什么樣子。 不斷地..現在，我們可以根據最適合我們的單個服務的決策，而不是層或整體的最低公分母來做出這些決策。 這就是我們將在下一篇文章中繼續探討的內容！ 敬請關注！

更新資料

Twitter上的某人（感謝@herrwieger！）向我指出了這一點： 自包含系統 （SCS）闡明了我在此處寫過的這個概念。 這一點很準確，完全符合我的意思。 當我們在有限的上下文中探索每個“獨立系統”時，更有趣的事情發生了，然后只有在必要時，它才分解為更細粒度的微服務。 在討論整體時，邊界是重要的考慮因素，這就是我在這里談到的以及SCS定義的內容。

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

monolith

總結

以上是生活随笔為你收集整理的monolith_将Java EE Monolith雕刻成微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。