單機
單機架構很好理解，例如你要部署一套CRM項目，這個項目包含的服務有：用於應用操作的Web站點、用於存儲文件的FTP服務、Oracle數據庫服務都部署在一台服務器上。總而言圍繞這個項目的所有服務都部署在一台服務器上就是單機架構方式。
結構參考圖：
集群
單機架構的硬件資源有限對於業務量比較大的情況是很難適用的，所以便可以在此基礎之上實施集群架構方式。例如，部署在IIS上的Web應用隨着業務量的增加，應用的處理能力下降，此時可以准備多台新的服務器設備並將Web應用分別部署在新的服務器上，這樣的模式就構成了一個“集群”。集群形成那么在集群中的每台服務器就相當於集群中的一個“節點”，每個節點都必須保證提供的是相同的服務。
構建集群后引發的問題，用戶通過客戶端操作發送請求到服務器，那么會使用集群中哪台服務器處理請求呢？並且選擇的依據是什么？那么基於集群的這種問題，誕生了一個“調度者”負載均衡服務器。顧名思義通過負載均衡服務器的調度處理會在集群中選擇一個負載較小的服務器來處理用戶的請求。
集群的架構的優勢在於我們無需改動任何的項目代碼，只需要新增服務器部署相同的應用並配置好負載均衡，就可以很好的減輕隨着業務增量帶來的系統壓力，並且可以直接在單機架構上直接進行調整。
結構參考圖：
此圖在單機架構上針對Web應用服務器實施了集群並通過負載均衡來調度處理請求，並將圍繞項目的其他的服務獨立到單獨服務器上，相比單機架構而言很大程度減少了服務器的壓力。
分布式
個人認為集群架構出發點是以增加硬件設備進行擴展，而分布式是以應用系統的業務功能作為出發點，並將每個業務功能拆分成一個完全獨立子系統，專業名稱稱為“服務”。多個子系統通過一個主體容器將它們承載，各個子系統直接使用RPC方式進行通信。
舉個例子，假設需要開發一個在線商城。按照微服務的思想，我們需要按照功能模塊拆分成多個獨立的服務，如：用戶服務、產品服務、訂單服務、后台管理服務、數據分析服務等等。這一個個服務都是一個個獨立的項目，可以獨立運行。如果服務之間有依賴關系，那么通過RPC方式調用。
結構參考圖：
在前面講到單機架構到集群並且集群進行擴展都是非常方便的，代碼基本無需要作任何修改，你要做的僅僅是多部署幾台服務器，每台服務器上運行相同的代碼並且配置好負載均衡就行了。但是集群結構演進到微服務結構的時候，之前的那套代碼就需要發生較大的改動了。所以對於新系統我們建議，系統設計之初就采用微服務架構，這樣后期運維的成本更低。但如果一套老系統需要升級成微服務結構的話，那就得對代碼大動干戈了。所以，對於老系統而言，究竟是繼續保持集群模式，還是升級成微服務架構，這需要你們的架構師深思熟慮、權衡投入產出比。
個人認為分布式會是主流的架構方式，另外分布式架構最常見最熱門的應用場景就是微服務架構。通過分布式架構可以將項目中每個核心功能單元化從而降低耦合程度，項目每個核心功能可以交由專業的供應商進行開發、或者由公司不同的團隊開發，總而言專業人做專業事，每個單位可以獨立進行、部署、測試，在進度和分工上有很大的優勢和效率。並且分布式架構有很好的復用性、移植性，例如開發一個訂單服務或者權限服務，可以給其他項目進行使用，無需重復造輪子。
生活場景類比
通過單機、集群、分布式的架構概念我們可以通過生活中的情景進行類比，來更好的理解概念，描述如下：
白手起家時的你在阿里巴巴附近開了一間川菜館，因為剛剛起步且客流量並不是很大，所以你在廚房你只聘請了一位工作人員，該工作人不不僅炒菜還要負責配菜、切菜等廚房的各種工作，這個時候的場景其實就相當於我們服務器架構中的單機架構。
在開店的第三個月后你的生意開始好了起來，這個時候你打算請多名廚工工作，但是廚工的工作都還是綜合的還要負責配菜、切菜等廚房的各種工作，只是人手增加了，這個時候的場景其實就相當於我們服務器架構中的集群架構。
在開店一年后有了很好的口碑和回頭客，你打算將業務擴展承接一些酒席。那么此時不光工作量增加工作的類型也多元化，為了使餐館有條不紊的運作，你將廚房的工作進行職責分工開放不同的崗位，此時就有了專門炒菜的廚師、專門切菜的案頭、專門清潔人員，這個時候的場景其實就相當於我們服務器架構中的分布式架構，所有員工各自出力負責各自的工作圍繞着相同的生意。