5.1 大系統(tǒng)小做原則

5.1.1 持續(xù)交付架構(gòu)要求

1. 為測(cè)試而設(shè)計(jì)，強(qiáng)調(diào)研發(fā)的服務(wù)或功能需要易于測(cè)試。
2. 為部署而設(shè)計(jì)，強(qiáng)調(diào)研發(fā)的服務(wù)或功能需要易于部署。
3. 為監(jiān)控而設(shè)計(jì)，系統(tǒng)設(shè)計(jì)要易于監(jiān)控，且易于收集數(shù)據(jù)。
4. 為擴(kuò)展而設(shè)計(jì)，需要支持團(tuán)隊(duì)規(guī)模的擴(kuò)展，同時(shí)支持系統(tǒng)自身的擴(kuò)展。
5. 為失效而設(shè)計(jì)，考慮一旦部署失敗，如何優(yōu)雅的快速進(jìn)行處理。

5.1.2 系統(tǒng)拆分原則

大系統(tǒng)應(yīng)該由很多組件（component）或服務(wù)（service）組成。它們通常以jar/war/dll/gem等形式出現(xiàn)，其粒度比類（class）要大，但是要比整個(gè)系統(tǒng)小很多。組件通常在比編譯構(gòu)建或者部署時(shí)被集成在一起，而服務(wù)可以由多個(gè)組件構(gòu)成，能獨(dú)立啟動(dòng)運(yùn)行，并在運(yùn)行時(shí)與整個(gè)系統(tǒng)進(jìn)行通信，成為整個(gè)系統(tǒng)的一個(gè)組成部分。

對(duì)系統(tǒng)進(jìn)行拆分的原則

1. 作為系統(tǒng)的一部分，每個(gè)組件或服務(wù)有清晰的業(yè)務(wù)職責(zé)，可以被獨(dú)立修改，甚至被另一種實(shí)現(xiàn)方案替代
2. “高內(nèi)聚，低耦合”，使整個(gè)系統(tǒng)易于維護(hù)，每個(gè)組件或服務(wù)只知道盡可能少的信息，完成相對(duì)獨(dú)立的單一功能。
3. 整個(gè)系統(tǒng)易于構(gòu)建與測(cè)試。
4. 使團(tuán)隊(duì)成員之間的溝通協(xié)作更順暢

5.2 常見(jiàn)架構(gòu)模式

5.2.1 微核架構(gòu)

微核架構(gòu)(microcore architecture)又稱插件架構(gòu)(plugin architecture),指軟件的核心框架相對(duì)較小，而其主要業(yè)務(wù)功能和業(yè)務(wù)邏輯都通過(guò)插件實(shí)現(xiàn)，插件間的通信只通過(guò)核心框架進(jìn)行。
優(yōu)點(diǎn)

• 良好的功能延伸性（extensibility）：需要什么功能，開(kāi)發(fā)一個(gè)插件即可。
• 易發(fā)布：插件可以獨(dú)立地加載和卸載，是它比較容易發(fā)布。
• 易測(cè)試：功能之間是隔離的，可以對(duì)插件進(jìn)行隔離測(cè)試。
• 可定制性高：適應(yīng)不同的開(kāi)發(fā)需要。
• 可以漸進(jìn)式地開(kāi)發(fā)：逐步增加功能。

劣勢(shì)

• 擴(kuò)展性差（scalability），內(nèi)核通常是一個(gè)獨(dú)立單元，不容易做成分布式，但對(duì)客戶端軟件來(lái)說(shuō)，這不是個(gè)嚴(yán)重問(wèn)題。
• 開(kāi)發(fā)難度相對(duì)較高。

• 高度依賴框架，框架升級(jí)后導(dǎo)致大量改造工作。

  
  
  image.png

5.2.2 微服務(wù)架構(gòu)

將單一應(yīng)用分成一組小的服務(wù)，服務(wù)之間相互協(xié)調(diào)配合，為用戶提供最終價(jià)值。每個(gè)服務(wù)在獨(dú)立的進(jìn)程中運(yùn)行。服務(wù)之間通過(guò)restful api 交互。每個(gè)服務(wù)可以獨(dú)立構(gòu)構(gòu)建部署。
優(yōu)點(diǎn)

• 擴(kuò)展性良好，各個(gè)服務(wù)之間低耦合。
• 易部署
• 易開(kāi)發(fā)
• 易于獨(dú)立單元測(cè)試

缺點(diǎn)

• 可能會(huì)被拆分的過(guò)細(xì)，導(dǎo)致大量微服務(wù)，變得凌亂而笨重，網(wǎng)絡(luò)開(kāi)銷大。
• 一次外部請(qǐng)求會(huì)涉及多個(gè)內(nèi)部服務(wù)，問(wèn)題調(diào)試難于診斷。
• 為原子操作帶來(lái)困難，例如事務(wù)類操作。

• 跨服務(wù)的組合業(yè)務(wù)場(chǎng)景測(cè)試比較困難，需要同時(shí)啟動(dòng)多個(gè)微服務(wù)。
  公共類庫(kù)的升級(jí)管理比較困難。

  
  
  image.png

5.2.3 巨石應(yīng)用（monolithic application）

也被稱作巨石架構(gòu)，指由單一結(jié)構(gòu)體組成的軟件應(yīng)用，其用戶接口和數(shù)據(jù)訪問(wèn)代碼都綁定在同一語(yǔ)言平臺(tái)的同意應(yīng)用程序
優(yōu)勢(shì)

• 利于開(kāi)發(fā)和調(diào)試。
• 部署才走本身比較簡(jiǎn)單
• 很容易擴(kuò)展

劣勢(shì)

• 對(duì)整體程序不熟悉的人來(lái)說(shuō)，容易產(chǎn)生混亂的代碼，污染整個(gè)應(yīng)用，給老代碼學(xué)習(xí)和理解帶來(lái)苦難。
• 難與新技術(shù)共同使用
• 只能將整個(gè)應(yīng)用作為一個(gè)整體進(jìn)行擴(kuò)展

• 持續(xù)部署非常困難。

  
  
  image.png

5.3 架構(gòu)改造實(shí)施模式

5.3.1 拆遷者模式

指根據(jù)當(dāng)前的業(yè)務(wù)需求，對(duì)軟件架構(gòu)重新設(shè)計(jì)，并組織單獨(dú)的團(tuán)隊(duì)，重新開(kāi)發(fā)一個(gè)全新的版本，一次性完全替換原有的遺留系統(tǒng)。
模式的好處
沒(méi)有歷史包袱。
風(fēng)險(xiǎn)

• 原業(yè)務(wù)需求遺漏
• 市場(chǎng)環(huán)境變化，由于新版本架構(gòu)無(wú)法一蹴而就，當(dāng)市場(chǎng)需求發(fā)生變化時(shí)，會(huì)錯(cuò)失良機(jī)。
• 人力資源消耗大

• 閉門(mén)造車

  
  
  image.png

5.3.2 絞殺者模式

指保持原來(lái)的遺留系統(tǒng)不變，當(dāng)需要開(kāi)發(fā)新的功能時(shí)，重新開(kāi)發(fā)一個(gè)服務(wù)，實(shí)現(xiàn)新功能。通過(guò)不斷構(gòu)建新的服務(wù)，逐步使遺留系統(tǒng)失效，并最終替換。
優(yōu)勢(shì)

• 不會(huì)遺漏原有需求
• 可以穩(wěn)定地提供價(jià)值，頻繁地交付版本，可以讓你根號(hào)地監(jiān)控其改造進(jìn)展
• 避免閉門(mén)造車

劣勢(shì)

• 架構(gòu)改造的時(shí)間跨度變大

• 產(chǎn)生一定的迭代成本

  
  
  image.png

5.3.3 修善者模式

指將遺留系統(tǒng)的部分功能與其余功能隔離，以新的架構(gòu)進(jìn)行單獨(dú)改善。在改善的同時(shí)，需要保證與其他部分仍能協(xié)同工作。
優(yōu)勢(shì)

• 系統(tǒng)外部無(wú)感知
• 不會(huì)遺漏原有需求
• 可以隨時(shí)停下改造工作，響應(yīng)高優(yōu)先級(jí)的業(yè)務(wù)需求。
• 避免閉門(mén)造車現(xiàn)象

劣勢(shì)

• 架構(gòu)改造的時(shí)間跨度變大

• 會(huì)有更多額外的架構(gòu)改造迭代成本

  
  
  image.png
  
  
  image.png

5.3.4 數(shù)據(jù)庫(kù)的拆分方法
步驟

1. 詳細(xì)了解數(shù)據(jù)庫(kù)結(jié)構(gòu)，包括外鍵玉樹(shù)，共享的可變數(shù)據(jù)以及事務(wù)性邊界等如圖5-10（a）
2. 先拆分?jǐn)?shù)據(jù)庫(kù)，并按照12.3.2節(jié)的介紹進(jìn)行數(shù)據(jù)遷移，如圖5-10（b）
3. 數(shù)據(jù)庫(kù)雙寫(xiě)無(wú)誤后，找到程序架構(gòu)中的縫隙，如圖5-10c

4. 將拆分出來(lái)的程序模塊和數(shù)據(jù)庫(kù)組合在一起，形成微服務(wù)。如圖5-10d

   
   
   image.png