摘要：本書概括以軟件系統(tǒng)為例，重點講解了應(yīng)用架構(gòu)中的物理設(shè)計問題，即如何將軟件系統(tǒng)拆分為模塊化系統(tǒng)。容器獨立模塊不依賴于具體容器，采用輕量級容器，如獨立部署模塊可獨立部署可用性模式發(fā)布接口暴露外部配置使用獨立的配置文件用于不同的上下文。

本文為讀書筆記，對書中內(nèi)容進行重點概括，并將書中的模塊化結(jié)合微服務(wù)、Java9 Jigsaw談?wù)劺斫狻?/p>

以Java軟件系統(tǒng)為例，重點講解了應(yīng)用架構(gòu)中的物理設(shè)計問題，即如何將軟件系統(tǒng)拆分為模塊化系統(tǒng)。所以內(nèi)容組織包括為什么需要模塊化，圍繞如何實現(xiàn)模塊化講述了模塊化模式，最后在模塊化基礎(chǔ)上使用OSGi技術(shù)實現(xiàn)動態(tài)模塊化。

先談?wù)剳?yīng)用架構(gòu)的邏輯設(shè)計和物理設(shè)計。
邏輯設(shè)計是關(guān)于語言結(jié)構(gòu)的，指類、方法之間的關(guān)系，組織結(jié)構(gòu)。物理設(shè)計是關(guān)于軟件中的物理實體，即部署單元和他們之間的關(guān)系，是關(guān)于如何將系統(tǒng)拆分為模塊系統(tǒng)的。

模塊定義：
軟件模塊是獨立可部署的、可管理的、進程內(nèi)可重用的、無狀態(tài)的軟件單元?？晒芾砑茨K可以安裝、卸載和更新。
在Java中，模塊就是jar包。
與分布式服務(wù)不同的是，這里的模塊是進程內(nèi)重用，需要與想用其功能的進程一起部署，而服務(wù)是一次部署被多個client使用。

僅關(guān)注高層抽象是不夠的，只強調(diào)代碼質(zhì)量也是不夠的，模塊化能填補高層架構(gòu)與底層代碼之間的空白，增加設(shè)計的靈活性，幫助實現(xiàn)高適應(yīng)性、高可維護性的系統(tǒng)架構(gòu)。

模塊是內(nèi)聚的，變化將局限在模塊的實現(xiàn)細節(jié)中，即能封裝變化，所以能減小復(fù)雜性，降低維護成本。

模塊化提供了指導(dǎo)和規(guī)律，讓我們可以在最小化依賴的同時又能最大化重用的潛能，幫助我們平衡模塊的重量級和粒度。這里粒度指一個系統(tǒng)要拆分的各個部分的范圍大小，重量級指模塊對其他環(huán)境依賴的程度。最大化重用會使得可用復(fù)雜化，設(shè)計軟件時，圍繞模塊的重量級和粒度的權(quán)衡是很重要的因素，對系統(tǒng)的模塊化都是與項目上下文相關(guān)并且要符合當(dāng)時的情況。一些特定級別的重用已經(jīng)很成熟了，如ORM框架，Netty框架等。

跨應(yīng)用重用是服務(wù)的最佳用武之地，但通常是粗粒度的，即所做的事情超出我們的需要，如果需要跨應(yīng)用重用一些需要的行為呢？沒有模塊的情況下，我們的選擇是將其暴露為服務(wù)或者復(fù)制類的代碼，兩者都不理想，模塊化就是另一種選擇，在粒度上，模塊是比服務(wù)更小的單元且是部署單元。

基本模式

管理關(guān)系：設(shè)計模塊之間的關(guān)系

模塊重用：強調(diào)模塊級別的重用

模塊內(nèi)聚：模塊的行為應(yīng)該只服務(wù)于一個目的

依賴模式

非循環(huán)關(guān)系：模塊之間的關(guān)系非循環(huán)依賴

等級化模塊：模塊關(guān)系是等級化的，物理分層旨在為組成應(yīng)用的分層創(chuàng)建多個模塊，更多是與職責(zé)相關(guān)，而等級與理解系統(tǒng)的結(jié)構(gòu)和關(guān)系更為密切，比分層更為細粒度，一個分層可能會有多個等級。

物理分層：模塊關(guān)系不影響物理分層，如展現(xiàn)、領(lǐng)域、DAO。

容器獨立：模塊不依賴于具體容器，采用輕量級容器，如Spring

獨立部署：模塊可獨立部署

可用性模式

發(fā)布接口：暴露API

外部配置：使用獨立的配置文件用于不同的上下文。外部化配置增加了模塊的重用行，但降低的易用性。如一個提供連接池的模塊，user，password通過配置文件配置而不是硬編碼在模塊中，這就方便重用，但會使得易用性降低，因為使用之前必須配置對應(yīng)的上下文

默認實現(xiàn)：為模塊接口提供默認實現(xiàn)，并提供擴展機制，默認實現(xiàn)有助于在重用和易用之間取得平衡。如dubbo的擴展點機制

模塊門面：為底層細粒度模塊創(chuàng)建一個門面，提供高層API協(xié)調(diào)一組細粒度模塊的行為

擴展性模式

抽象化模塊：依賴于抽象而不是具體，典型的例子如通過Spring注入具體實現(xiàn)，bean里面依賴的屬性是接口

實現(xiàn)工廠：通過實現(xiàn)工廠建立適當(dāng)?shù)膶ο笠?，如Spring的裝配

分離抽象：將抽象類與實現(xiàn)類放在各自的模塊中，從而能用新的實現(xiàn)替換已有的實現(xiàn)，幫助創(chuàng)建靈活和可擴展的系統(tǒng)

通用模式

就近異常：異常定義應(yīng)該接近拋出他們的模塊

等級化構(gòu)建：按照模塊的等級構(gòu)建

測試模塊：每個模塊應(yīng)該有一個對應(yīng)的測試模塊

OSGi是Java平臺中的動態(tài)模塊系統(tǒng)，定義了一個模塊化單元，稱之為bundle，是一個jar文件。bundle會在同一個JVM中進行部署和交互，在進程內(nèi)跨bundle交互，并且可動態(tài)部署bundle。
OSGi只是提供一個運行時環(huán)境，使得在Java平臺中實現(xiàn)模塊化成為可能。

自上而下的架構(gòu)

架構(gòu)的目標(biāo)是減少變化的成本和影響

軟件傾向于隨著時間變得腐化，隨著時間流逝，變化會悄然發(fā)生并以難以預(yù)料的方式考驗著設(shè)計

技術(shù)債用來描述為了滿足進度或用戶期望而做出的設(shè)計讓步，與財務(wù)債一樣，也需要支付利息，在將來的開發(fā)中要付出額外的努力。我們可以選擇繼續(xù)支付利息或用更好的設(shè)計重構(gòu)來償還本金，盡管償還本金需要成本，但是會降低將來要支付的利息。

復(fù)雜性阻止我們以優(yōu)雅的方式使軟件系統(tǒng)適應(yīng)需求的變化。

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

通過上文的描述，我們已經(jīng)了解了模塊化思想，那與如今的微服務(wù)是什么關(guān)系呢？
微服務(wù)也是可獨立部署于容器的，每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)，每個任務(wù)代表著一個小的業(yè)務(wù)能力。各個微服務(wù)之間通過輕量級協(xié)議(RESTful API接口, 輕量級消息機制）交互通信。與模塊化強調(diào)的進程內(nèi)重用不同，微服務(wù)屬于分布式服務(wù)，通過RPC協(xié)議在進程間重用。

相似點：
兩者都是可獨立部署的，重視邏輯的可復(fù)用性，強調(diào)一個大的軟件系統(tǒng)需要拆分為各個部分，保持高內(nèi)聚低耦合，實現(xiàn)更好的軟件架構(gòu)。

個人理解:
微服務(wù)架構(gòu)更勝一籌于模塊化架構(gòu)思想。提出模塊化架構(gòu)的本書（中文版）發(fā)版于2013年，微服務(wù)的概念源于2014年，兩者目的相似，現(xiàn)如今已有大量企業(yè)對已有系統(tǒng)進行改造或?qū)嵤┪⒎?wù)架構(gòu)，開發(fā)人員對微服務(wù)的認知逐漸深入，大的市場環(huán)境已經(jīng)采用了微服務(wù)架構(gòu)。又微服務(wù)已經(jīng)是一個較小且完整的業(yè)務(wù)部署單元，不會將其拆分為多個模塊化單元在同一進程中部署，就算拆分也是將其拆分為更細粒度的微服務(wù)。

雖然實施微服務(wù)需要具備完善的基礎(chǔ)設(shè)施，如容器化、服務(wù)注冊發(fā)現(xiàn)、配置管理、監(jiān)控等DevOps開發(fā)運維一體化設(shè)施，但隨著應(yīng)用云化的日益普及，相關(guān)設(shè)施不斷完善，如SpringCloud，其實施的門檻已經(jīng)較低了。

且動態(tài)模塊化技術(shù)如OSGi尚未普及，所以，個人認為微服務(wù)架構(gòu)比模塊化架構(gòu)更優(yōu)。

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

微服務(wù)相關(guān)：
https://www.ibm.com/developer...
https://martinfowler.com/micr...

個人博客：https://my.oschina.net/hebaod...