如何分析單體架構(gòu)與微服務(wù)架構(gòu)

【單體架構(gòu)】

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

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

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

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

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

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

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

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

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

    由于單體架構(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)

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

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

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

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

        - 每個(gè)微服務(wù)可獨(dú)立運(yùn)行在自己的進(jìn)程里；

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

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

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

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

        - 全自動(dòng)的部署機(jī)制；

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

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

        - 單個(gè)微服務(wù)啟動(dòng)較快。單個(gè)微服務(wù)代碼量較少，所以啟動(dòng)會(huì)比較快；

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

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

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

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

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

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

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