【單體架構(gòu)】

1. 什么是單體架構(gòu)

一個歸檔包（例如war格式）包含了應(yīng)用所有功能的應(yīng)用程序，我們通常稱之為單體應(yīng)用。架構(gòu)單體應(yīng)用的方法論，我們稱之為單體應(yīng)用架構(gòu)。

2. 單體架構(gòu)示例圖

3. 單體架構(gòu)的缺陷

- 復(fù)雜性高。整個項目包含的模塊非常多，模塊的邊界模糊，依賴關(guān)系不清晰，代碼質(zhì)量參差不齊……整個項目非常復(fù)雜。每次修改代碼都心驚膽戰(zhàn)，甚至添加一個簡單的功能，或者修改一個BUG都會造成隱含的缺陷。

- 技術(shù)債務(wù)。隨著時間推移、需求變更和人員更迭，會逐漸形成應(yīng)用程序的技術(shù)債務(wù)，并且越積越多。已使用的系統(tǒng)設(shè)計或代碼難以修改，因為應(yīng)用程序的其他模塊可能會以意料之外的方式使用它。

- 部署頻率低。隨著代碼的增加，構(gòu)建和部署的時間也會增加。而在單體應(yīng)用中，每次功能的變更或缺陷的修復(fù)都會導(dǎo)致我們需要重新部署整個應(yīng)用。全量部署的方式耗時長、影響范圍大、風(fēng)險高，這使得單體應(yīng)用項目上線部署的頻率較低，從而又導(dǎo)致兩次發(fā)布之間會有大量功能變更和缺陷修復(fù)，出錯概率較高。

- 擴展能力受限。單體應(yīng)用只能作為一個整體進行擴展，無法結(jié)合業(yè)務(wù)模塊的特點進行伸縮。

- 阻礙技術(shù)創(chuàng)新。單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺或方案解決所有問題，團隊的每個成員都必須使用相同的開發(fā)語言和架構(gòu)，想要引入新的框架或技術(shù)平臺非常困難。

由于單體架構(gòu)的缺陷日益明顯，所以越來越多的公司采用微服務(wù)架構(gòu)范式解決上面提到的單體架構(gòu)中的問題。

不同于構(gòu)建單一、龐大的應(yīng)用，微服務(wù)架構(gòu)將應(yīng)用拆分為一套小且互相關(guān)聯(lián)的服務(wù)。

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

1. 什么是微服務(wù)架構(gòu)

簡而言之，微服務(wù)架構(gòu)風(fēng)格的開發(fā)方法，是以開發(fā)一組小型服務(wù)的方式來開發(fā)一個獨立的應(yīng)用系統(tǒng)的。其中每個小型服務(wù)都運行在自己的進程中，并經(jīng)常采用HTTP資源API輕量的機制來相互通信。

這些服務(wù)圍繞業(yè)務(wù)功能進行構(gòu)建，并能通過全自動的部署機制來進行獨立部署。這些微服務(wù)可以使用不同的語言來編寫，并且可以使用不同的數(shù)據(jù)存儲技術(shù)。對這些微服務(wù)我們僅做最低限度的集中管理。

2. 微服務(wù)架構(gòu)示例圖

3. 微服務(wù)架構(gòu)的特性

- 每個微服務(wù)可獨立運行在自己的進程里；

- 一系列獨立運行的微服務(wù)共同構(gòu)建起整個系統(tǒng)；

- 每個服務(wù)為獨立的業(yè)務(wù)開發(fā)，一個微服務(wù)只關(guān)注某個特定的功能，如訂單管理、用戶管理等；

- 微服務(wù)之間通過一些輕量的通信機制進行通信，如REST API進行調(diào)用；

- 可以使用不同的語言與存儲技術(shù)；

- 全自動的部署機制；

4. 微服務(wù)架構(gòu)的優(yōu)勢

- 易于開發(fā)和維護。一個微服務(wù)只關(guān)注一個特定的業(yè)務(wù)功能，所以它的業(yè)務(wù)清晰、代碼量較少。開發(fā)和維護單個微服務(wù)相對比較簡單，整個應(yīng)用是由若干個微服務(wù)構(gòu)建而成，所以整個應(yīng)用也會維持在可控狀態(tài)；

- 單個微服務(wù)啟動較快。單個微服務(wù)代碼量較少，所以啟動會比較快；

- 局部修改容易部署。單體應(yīng)用只要有修改，就要重新部署整個應(yīng)用，微服務(wù)解決了這樣的問題。一般來說，對某個微服務(wù)進行修改，只需要重新部署這個服務(wù)即可；

- 技術(shù)棧不受限。在微服務(wù)中，我們可以結(jié)合項目業(yè)務(wù)及團隊的特點，合理地選擇技術(shù)棧；

5. 微服務(wù)架構(gòu)的挑戰(zhàn)

- 運維要求較高。更多的服務(wù)意味著更多的運維投入。在單體架構(gòu)中只需要保證一個應(yīng)用的正常運行；而在微服務(wù)中，需要保證幾十甚至幾百個服務(wù)的正常運行與協(xié)作，帶來了巨大的挑戰(zhàn)；

- 分布式固有的復(fù)雜性。使用微服務(wù)構(gòu)建的是分布式系統(tǒng)。對于一個分布式系統(tǒng)，系統(tǒng)容錯、網(wǎng)絡(luò)延遲、分布式事務(wù)等都帶來了巨大的挑戰(zhàn)；

- 接口調(diào)整成本高。微服務(wù)之間通過接口進行通信。如果修改某個微服務(wù)的API，可能所有使用了該接口的微服務(wù)都需要做調(diào)整；

- 重復(fù)勞動。很多服務(wù)可能都會使用到相同的功能。而這個功能并沒有達到分解為一個微服務(wù)的程度，這個時候，可能各個服務(wù)都會開發(fā)這一功能，導(dǎo)致代碼重復(fù)。

【總結(jié)】

構(gòu)建復(fù)雜的應(yīng)用的確非常困難。單體式的架構(gòu)更適合輕量級的簡單應(yīng)用。如果你用它來開發(fā)復(fù)雜應(yīng)用，那真的會很糟糕。微服務(wù)架構(gòu)模式可以用來構(gòu)建復(fù)雜應(yīng)用，當(dāng)然，這種架構(gòu)模型也有自己的缺點和挑戰(zhàn)。