單體架構-SOA架構-微服務架構
目錄
單體架構
一個jar包或者war包，包含了應用的所有功能的應用程式，稱之為單體應用。架構單位應用的方法論，稱之為單體應用架構，這是一種比較傳統的架構風格
單體架構的缺陷
1.複雜性高
整個專案包含的模組非常多，模組的邊界模糊，依賴關係不清晰，程式碼質量參差不齊,整個專案非常複雜。每次修改程式碼都心驚膽戰，甚至新增一個簡單的功能，或者修改一個BUG都會造成隱含的缺陷。
2.技術債務逐漸上升
隨著時間推移、需求變更和人員更迭，會逐漸形成應用程式的技術債務，並且越積越多。已使用的系統設計或程式碼難以修改，因為應用程式的其他模組可能會以意料之外的方式使用它。
隨著程式碼的增加，構建和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修復都會導致我們需要重新部署整個應用。全量部署的方式耗時長、影響範圍大、風險高，這使得單體應用專案上線部署的頻率較低，從而又導致兩次釋出之間會有大量功能變更和缺陷修復，出錯概率較高。
4.擴充套件能力受限，無法按需伸縮
單體應用只能作為一個整體進行擴充套件，無法結合業務模組的特點進行伸縮。
5.阻礙技術創新
單體應用往往使用統一的技術平臺或方案解決所有問題，團隊的每個成員都必須使用相同的開發語言和架構，想要引入新的框架或技術平臺非常困難。
由於單體架構的缺陷日益明顯，所以越來越多的公司採用微服務架構正規化解決上面提到的單體架構中的問題。
SOA架構
SOA是
Service-Oriented Architecture的英文縮寫，就是面向服務的架構。這裡的服務可以理解為service層業務服務
單一應用架構
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。
分散式服務架構
當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。
此時，用於提高機器利用率的SOA服務治理方案是關鍵。
Dubbo就是SOA服務治理方案的核心框架。
總結：dubbo不僅可以對服務進行治理，而且還可以對服務進行呼叫。
微服務架構
簡而言之，微服務架構風格的開發方法，是以開發一組小型服務的方式來開發一個獨立的應用系統的。其中每個小型服務都執行在自己的程序中，並經常採用HTTP資源API輕量的機制來相互通訊。
這些服務圍繞業務功能進行構建，並能通過全自動的部署機制來進行獨立部署。這些微服務可以使用不同的語言來編寫，並且可以使用不同的資料儲存技術。對這些微服務我們僅做最低限度的集中管理。
微服務架構的特性
- 每個微服務可獨立執行在自己的程序裡
- 一系列獨立執行的微服務共同構建起整個系統
- 每個服務為獨立的業務開發，一個微服務只關注某個特定的功能，如訂單管理、使用者管理等
- 微服務之間通過一些輕量的通訊機制進行通訊，如REST API介面進行呼叫
- 可以使用不同的語言與儲存技術
- 全自動的部署機制
微服務架構的優勢
1.易於開發和維護
一個微服務只關注一個特定的業務功能，所以它的業務清晰、程式碼量較少。開發和維護單個微服務相對比較簡單，整個應用是由若干個微服務構建而成，所以整個應用也會維持在可控狀態；
2.單個微服務啟動較快
單個微服務程式碼量較少，所以啟動會比較快；
3.區域性修改容易部署
單體應用只要有修改，就要重新部署整個應用，微服務解決了這樣的問題。一般來說，對某個微服務進行修改，只需要重新部署這個服務即可；
4.技術棧不受限
在微服務中，我們可以結合專案業務及團隊的特點，合理地選擇技術棧
5.按需伸縮
根據業務的需求靈活配置
微服務架構的挑戰
1.運維要求較高
更多的服務意味著更多的運維投入。在單體架構中只需要保證一個應用的正常執行；而在微服務中，需要保證幾十甚至幾百個服務的正常執行與協作，帶來了巨大的挑戰；
2.分散式固有的複雜性
使用微服務構建的是分散式系統。對於一個分散式系統，系統容錯、網路延遲、分散式事務等都帶來了巨大的挑戰；
3.介面調整成本高
微服務之間通過介面進行通訊。如果修改某個微服務的API，可能所有使用了該介面的微服務都需要做調整；
4.重複勞動
很多服務可能都會使用到相同的功能。而這個功能並沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發這一功能，導致程式碼重複。
微服務架構與SOA架構的區別
微服務架構強調的第一個重點就是業務系統需要徹底的元件化和服務化
微服務架構不在強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時SOA的思想進入到單個業務系統內部實現真正的元件化。
分散式-微服務-叢集的區別
service A、B、C、D 分別是業務元件，通過API Geteway進行業務訪問。將一個大的系統劃分為多個業務模組，業務模組分別部署到不同的機器上面，各個業務模組通過介面進行資料互動。
區分分散式的方式是根據不同機器的不同業務
叢集模式
叢集模式是不同的伺服器部署同一套服務對外訪問，實現服務的負載均衡
區分叢集的方式是根據部署多型伺服器業務是否相同
注意：叢集模式需要做好session共享，確保在不同伺服器切換的過程中不會因為沒有獲取到sesison而終止退出服務
分散式與微服務的關係
分散式屬於微服務，微服務的意思就是將模組拆分成一個獨立的服務單元通過介面來實現資料的互動。
微服務與分散式的細微差別是，微服務的應用不一定是分散在多個伺服器上，也可以是同一個伺服器