單體架構,SOA架構,微服務架構,分布式架構,叢集架構

單體架構

什麼是單體架構

一個歸檔包（例如war格式或者Jar格式）包含了應用所有功能的應用程式，我們通常稱之為單體應用。架構單體應用的方法論，我們稱之為單體應用架構，這是一種比較傳統的架構風格。。

單體架構示例圖

QQ截圖20180517151958.png

單體架構的缺陷

1.複雜性高

整個項目包含的子產品非常多，子產品的邊界模糊，依賴關系不清晰，代碼品質參差不齊,整個項目非常複雜。每次修改代碼都心驚膽戰，甚至添加一個簡單的功能，或者修改一個BUG都會造成隐含的缺陷。

2.技術債務逐漸上升

随着時間推移、需求變更和人員更疊，會逐漸形成應用程式的技術債務，并且越積越多。已使用的系統設計或代碼難以修改，因為應用程式的其他子產品可能會以意料之外的方式使用它。

3.部署速度逐漸變慢

随着代碼的增加，建構和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修複都會導緻我們需要重新部署整個應用。全量部署的方式耗時長、影響範圍大、風險高，這使得單體應用項目上線部署的頻率較低，進而又導緻兩次釋出之間會有大量功能變更和缺陷修複，出錯機率較高。

4.擴充能力受限，無法按需伸縮

單體應用隻能作為一個整體進行擴充，無法結合業務子產品的特點進行伸縮。

5.阻礙技術創新

單體應用往往使用統一的技術平台或方案解決所有問題，團隊的每個成員都必須使用相同的開發語言和架構，想要引入新的架構或技術平台非常困難。

由于單體架構的缺陷日益明顯，是以越來越多的公司采用微服務架構範式解決上面提到的單體架構中的問題。

不同于建構單一、龐大的應用，微服務架構将應用拆分為一套小且互相關聯的服務。

SOA架構

SOA是

Service-Oriented Architecture

的英文縮寫，就是面向服務的架構。這裡的服務可以了解為service層業務服務。

單一應用架構

當網站流量很小時，隻需一個應用，将所有功能都部署在一起，以減少部署節點和成本。

垂直應用架構

當通路量逐漸增大，單一應用增加機器帶來的加速度越來越小，将應用拆成互不相幹的幾個應用，以提升效率。

分布式服務架構

當垂直應用越來越多，應用之間互動不可避免，将核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。

流動計算架構

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基于通路壓力實時管理叢集容量，提高叢集使用率。

此時，用于提高機器使用率的SOA服務治理方案是關鍵。

Dubbo就是SOA服務治理方案的核心架構。

總結：dubbo不僅可以對服務進行治理，而且還可以對服務進行調用。

微服務架構

什麼是微服務架構

簡而言之，微服務架構風格的開發方法，是以開發一組小型服務的方式來開發一個獨立的應用系統的。其中每個小型服務都運作在自己的程序中，并經常采用HTTP資源API輕量的機制來互相通信。

這些服務圍繞業務功能進行建構，并能通過全自動的部署機制來進行獨立部署。這些微服務可以使用不同的語言來編寫，并且可以使用不同的資料存儲技術。對這些微服務我們僅做最低限度的集中管理。

微服務架構示例圖

QQ截圖20180517201613.png

微服務架構的特性

每個微服務可獨立運作在自己的程序裡

一系列獨立運作的微服務共同建構起整個系統

每個服務為獨立的業務開發，一個微服務隻關注某個特定的功能，如訂單管理、使用者管理等

微服務之間通過一些輕量的通信機制進行通信，如REST API接口進行調用

可以使用不同的語言與存儲技術

全自動的部署機制

微服務架構的優勢

1.易于開發和維護

一個微服務隻關注一個特定的業務功能，是以它的業務清晰、代碼量較少。開發和維護單個微服務相對比較簡單，整個應用是由若幹個微服務建構而成，是以整個應用也會維持在可控狀态；

2.單個微服務啟動較快

單個微服務代碼量較少，是以啟動會比較快；

3.局部修改容易部署

單體應用隻要有修改，就要重新部署整個應用，微服務解決了這樣的問題。一般來說，對某個微服務進行修改，隻需要重新部署這個服務即可；

4.技術棧不受限

在微服務中，我們可以結合項目業務及團隊的特點，合理地選擇技術棧

5.按需伸縮

微服務架構的挑戰

1.運維要求較高

更多的服務意味着更多的運維投入。在單體架構中隻需要保證一個應用的正常運作；而在微服務中，需要保證幾十甚至幾百個服務的正常運作與協作，帶來了巨大的挑戰；

2.分布式固有的複雜性

使用微服務建構的是分布式系統。對于一個分布式系統，系統容錯、網絡延遲、分布式事務等都帶來了巨大的挑戰；

3.接口調整成本高

微服務之間通過接口進行通信。如果修改某個微服務的API，可能所有使用了該接口的微服務都需要做調整；

4.重複勞動

很多服務可能都會使用到相同的功能。而這個功能并沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發這一功能，導緻代碼重複。

微服務設計原則

單一職責原則

服務自治原則

輕量級通信原則

接口明确原則

微服務和SOA的差別

微服務架構強調的第一個重點就是業務系統需要徹底的元件化和服務化

微服務不再強調傳統SOA架構裡面比較重的ESB企業服務總線，同時SOA的思想進入到單個業務系統内部實作真正的元件化。

分布式-微服務-叢集的差別

分布式

QQ截圖20180517203448.png

service A、B、C、D 分别是業務元件，通過API Geteway進行業務通路。

将一個大的系統劃分為多個業務子產品，業務子產品分别部署到不同的機器上，各個業務子產品之間通過接口進行資料互動。

差別分布式的方式是根據不同機器不同業務。

注：分布式需要做好事務管理。

叢集模式

QQ截圖20180517203458.png

叢集模式是不同伺服器部署同一套服務對外通路，實作服務的負載均衡。

差別叢集的方式是根據部署多台伺服器業務是否相同。

注：叢集模式需要做好session共享，確定在不同伺服器切換的過程中不會因為沒有擷取到session而中止退出服務。

一般配置Nginx*的負載容器實作：靜态資源緩存、Session共享可以附帶實作，Nginx支援5000個并發量。

分布式是否屬于微服務?

答案是肯定的。微服務的意思也就是将子產品拆分成一個獨立的服務單元通過接口來實作資料的互動。

微服務的設計是為了不因為某個子產品的更新和BUG影響現有的系統業務。

微服務與分布式的細微差别是，微服務的應用不一定是分散在多個伺服器上，他也可以是同一個伺服器。

QQ截圖20180517203925.png

分布式和微服的架構很相似，隻是部署的方式不一樣而已。