本文講的是<b>将Java EE單體應用打造成微服務</b>【編者的話】如何将單體應用拆分成微服務相信是很多人共同的疑問,本文作者就技術群組織結構等方面為我們提供了一個思路,一起來看看吧~
<a href="http://dockerone.com/uploads/article/20160731/f93625a23b1eb27102c0ce9ae8f5009e.png" target="_blank"></a>
過去我們花了大量的時間論證這一類型的架構,而這些工作似乎是有意義的。我們希望能夠按照各個元件自己的需求來進行擴充。如果我們需要處理更多的web請求那就向外擴充web層就好了。如果那些服務開始陷入瓶頸,那就擴充業務服務層。與資料庫以及資料通路層打交道和管理維護對于整個應用/服務的其他部分而言是相對獨立的。從中間層和資料通路中“解耦”出來UI邏輯是一個不錯的指導原則,但是不要把它和必需的分層搞混淆了。
實踐中的真實情況是所有這些“分層”的架構化元件,針對所有對它的單獨關注來看很容易殒命于資料和資料庫引發的怪問題。我們可以盡情地添加所需的CPU,中間件和UI,但是無論我們的網絡、計算、記憶體等等變得如何快速,對于這類系統的瓶頸往往都在于域模型和最終的資料庫的互相競争。這裡面的壓力便是“域模型”———網際網路公司所踐行的微服務可能不會擁有像FSI或者保險、零售商那樣複雜、模糊而又沖突的域模型。比如,推特有一個簡單的域:釋出和展示推文。但是這一案例也會在大規模場景下變得複雜———一些企業正開始同時遭遇這兩方面問題的困擾———域模型及其複雜性與如何擴充它同等重要(并且常常會
在努力擴充時有所妨礙)。是以如今你單純想着“我們隻要用一個像MongoDB這樣的NoSQL資料庫就能實作後端的擴充性”的話———你現在恐怕會遇到更多問題。
那說說我們的團隊?像這樣架構一個系統的另外一部分是因為這樣我們就能在這些分層上配置設定各個專業的團隊以不同的效率,在不同地方,用不同的工具等相對獨立地進行工作。他們隻需要和其他人共享一個接口,然後便能自主進行他們的工作。這裡用到一點康威定律:
設計系統的組織,其産生的設計和架構等價于組織間的溝通結構。
讓我們一起來看看到底發生了什麼。以Ticket Monster為例,業務要求我們改變所處理網站的管理方式。他們要求我們添加一些相關的額外字段來追蹤音樂會在網站上添加和删除的頻繁程度,因為他們想據此添加一些預測分析,基于時間,位置,天氣等決定在未來添加該活動是否是一個好主意。如果業務想要給管理使用者展示這個預測分析的話,這可能還會涉及到UI團隊。這也必将涉及改變應用的業務邏輯層,并且它肯定會導緻資料庫的變動。我們想給我們的應用添加一些功能特性,而這引發了所有分層的波動效應,而更為重要的是,涉及到了整個團隊。如今我們不得不需要項目經理為所有相關團隊協調和跟進會議。我們需要在建立票單的時候保證UI和團隊做什麼事情不會讓QA,安全,運維等全部介入。所有這一切造就了我們各個團隊之間的複雜同步處境,而如今我們不得不協調我們分層的全部變動,建構和釋出(并且一切都同時部署!)。這不是我們想要的那種自治。我們無法互相獨立地做出變動,事實上,我們已經變得相當脆弱。
針對我們的Ticket Monster應用,讓我們改為将功能切分成可拼接的各個“垂直頻道”而不是以技術或者組織層面。每一個垂直頻道有它自己的“UI”(或者UI元件),“業務服務”和“資料庫”,它們用于管理網站的特定功能。(然而,在第一步裡,我們将把UI留作一個單體,然後将它背後的子產品切分開來。我們會回過頭來切分UI,盡管這有其自己的挑戰。)Ticket Monster還允許使用者檢視和預訂音樂會票。讓我們将這塊功能切分到它自己的垂直頻道裡。它可能也有忠誠度,推薦,搜尋,廣告,個性化等等。我們将這些都切分到它們自己的垂直頻道裡,每個都擁有它們自己的資料庫,UI,和內建點(REST服務,後端,等等)。如果我們需要對網站忠誠度這塊功能做出變動的話,我不需要去重新部署整個單體的業務服務層或是任何相關的服務,比如搜尋。我可以從UI到DB部署忠誠度這塊的功能而無需再被迫觸發其他服務的變動。在理想情況下,一個團隊擁有和運維的每個服務都将如此。
<a href="http://dockerone.com/uploads/article/20160731/06430b3f538dd7bd8bb1a1898b7b1fca.png" target="_blank"></a>
<b>原文釋出時間為:</b>2016-07-31
<b>本文作者:</b>吳佳興
<b>本文來自雲栖社群合作夥伴Dockerone.io,了解相關資訊可以關注Dockerone.io。</b>
<b></b>
<b>原文标題:</b><b>将Java EE單體應用打造成微服務</b>