《Java應用架構設計:模塊化模式與OSGi》讀書筆記

本文爲讀書筆記，對書中內容進行重點歸納，並將書中的模塊化結合微服務、Java9 Jigsaw談談理解。

本書歸納

以Java軟件系統爲例，重點講解了應用架構中的物理設計問題，即如何將軟件系統拆分爲模塊化系統。因此內容組織包括爲何須要模塊化，圍繞如何實現模塊化講述了模塊化模式，最後在模塊化基礎上使用OSGi技術實現動態模塊化。

內容總結

模塊化定義

先談談應用架構的邏輯設計和物理設計。
邏輯設計是關於語言結構的，指類、方法之間的關係，組織結構。物理設計是關於軟件中的物理實體，即部署單元和他們之間的關係，是關於如何將系統拆分爲模塊系統的。

模塊定義：
軟件模塊是獨立可部署的、可管理的、進程內可重用的、無狀態的軟件單元。可管理即模塊能夠安裝、卸載和更新。
在Java中，模塊就是jar包。
與分佈式服務不一樣的是，這裏的模塊是進程內重用，須要與想用其功能的進程一塊兒部署，而服務是一次部署被多個client使用。

模塊化的理由

• 僅關注高層抽象是不夠的，只強調代碼質量也是不夠的，模塊化能填補高層架構與底層代碼之間的空白，增長設計的靈活性，幫助實現高適應性、高可維護性的系統架構。
• 模塊是內聚的，變化將侷限在模塊的實現細節中，即能封裝變化，因此能減少複雜性，下降維護成本。
• 模塊化提供了指導和規律，讓咱們能夠在最小化依賴的同時又能最大化重用的潛能，幫助咱們平衡模塊的重量級和粒度。這裏粒度指一個系統要拆分的各個部分的範圍大小，重量級指模塊對其餘環境依賴的程度。最大化重用會使得可用複雜化，設計軟件時，圍繞模塊的重量級和粒度的權衡是很重要的因素，對系統的模塊化都是與項目上下文相關而且要符合當時的狀況。一些特定級別的重用已經很成熟了，如ORM框架，Netty框架等。
• 跨應用重用是服務的最佳用武之地，但一般是粗粒度的，即所作的事情超出咱們的須要，若是須要跨應用重用一些須要的行爲呢？沒有模塊的狀況下，咱們的選擇是將其暴露爲服務或者複製類的代碼，二者都不理想，模塊化就是另外一種選擇，在粒度上，模塊是比服務更小的單元且是部署單元。

模塊化模式

• 基本模式

  • 管理關係：設計模塊之間的關係
  • 模塊重用：強調模塊級別的重用
  • 模塊內聚：模塊的行爲應該只服務於一個目的

• 依賴模式

  • 非循環關係：模塊之間的關係非循環依賴
  • 等級化模塊：模塊關係是等級化的，物理分層旨在爲組成應用的分層建立多個模塊，更可能是與職責相關，而等級與理解系統的結構和關係更爲密切，比分層更爲細粒度，一個分層可能會有多個等級。
  • 物理分層：模塊關係不影響物理分層，如展示、領域、DAO。
  • 容器獨立：模塊不依賴於具體容器，採用輕量級容器，如Spring
  • 獨立部署：模塊可獨立部署

• 可用性模式

  • 發佈接口：暴露API
  • 外部配置：使用獨立的配置文件用於不一樣的上下文。外部化配置增長了模塊的重用行，但下降的易用性。如一個提供鏈接池的模塊，user，password經過配置文件配置而不是硬編碼在模塊中，這就方便重用，但會使得易用性下降，由於使用以前必須配置對應的上下文
  • 默認實現：爲模塊接口提供默認實現，並提供擴展機制，默認實現有助於在重用和易用之間取得平衡。如dubbo的擴展點機制
  • 模塊門面：爲底層細粒度模塊建立一個門面，提供高層API協調一組細粒度模塊的行爲

• 擴展性模式

  • 抽象化模塊：依賴於抽象而不是具體，典型的例子如經過Spring注入具體實現，bean裏面依賴的屬性是接口
  • 實現工廠：經過實現工廠創建適當的對象引用，如Spring的裝配
  • 分離抽象：將抽象類與實現類放在各自的模塊中，從而能用新的實現替換已有的實現，幫助建立靈活和可擴展的系統

• 通用模式

  • 就近異常：異常定義應該接近拋出他們的模塊
  • 等級化構建：按照模塊的等級構建
  • 測試模塊：每一個模塊應該有一個對應的測試模塊

模塊化與OSGi

OSGi是Java平臺中的動態模塊系統，定義了一個模塊化單元，稱之爲bundle，是一個jar文件。bundle會在同一個JVM中進行部署和交互，在進程內跨bundle交互，而且可動態部署bundle。
OSGi只是提供一個運行時環境，使得在Java平臺中實現模塊化成爲可能。

書中好詞好句

自上而下的架構

架構的目標是減小變化的成本和影響

軟件傾向於隨着時間變得腐化，隨着時間流逝，變化會悄然發生並以難以預料的方式考驗着設計

技術債用來描述爲了知足進度或用戶指望而作出的設計讓步，與財務債同樣，也須要支付利息，在未來的開發中要付出額外的努力。咱們能夠選擇繼續支付利息或用更好的設計重構來償還本金，儘管償還本金須要成本，可是會下降未來要支付的利息。

複雜性阻止咱們以優雅的方式使軟件系統適應需求的變化。

最大化重用會使得可用複雜化。即軟件模塊的可重用性越高，則其易用性越差。

模塊化與微服務

經過上文的描述，咱們已經瞭解了模塊化思想，那與現在的微服務是什麼關係呢？
微服務也是可獨立部署於容器的，每一個微服務僅關注於完成一件任務並很好地完成該任務，每一個任務表明着一個小的業務能力。各個微服務之間經過輕量級協議(RESTful API接口, 輕量級消息機制）交互通訊。與模塊化強調的進程內重用不一樣，微服務屬於分佈式服務，經過RPC協議在進程間重用。

類似點：
二者都是可獨立部署的，重視邏輯的可複用性，強調一個大的軟件系統須要拆分爲各個部分，保持高內聚低耦合，實現更好的軟件架構。

我的理解:
微服務架構更勝一籌於模塊化架構思想。提出模塊化架構的本書（中文版）發版於2013年，微服務的概念源於2014年，二者目的類似，現現在已有大量企業對已有系統進行改造或實施微服務架構，開發人員對微服務的認知逐漸深刻，大的市場環境已經採用了微服務架構。又微服務已是一個較小且完整的業務部署單元，不會將其拆分爲多個模塊化單元在同一進程中部署，就算拆分也是將其拆分爲更細粒度的微服務。

雖然實施微服務須要具有完善的基礎設施，如容器化、服務註冊發現、配置管理、監控等DevOps開發運維一體化設施，但隨着應用雲化的日益普及，相關設施不斷完善，如SpringCloud，其實施的門檻已經較低了。

且動態模塊化技術如OSGi還沒有普及，因此，我的認爲微服務架構比模塊化架構更優。

模塊化與Java9 Jigsaw

Java 9Java 平臺模塊化項目（Jigsaw ）參考 https://mp.weixin.qq.com/s/Sr...

參考

微服務相關：
https://www.ibm.com/developer...
https://martinfowler.com/micr...

我的博客：https://my.oschina.net/hebaod...