最近在瞭解一些概念思想，如果有不對的地方歡迎指出。

系統演變過程：單機結構–主從(高可用、讀寫分離)–叢集結構(負載均衡)–分散式(高併發)

單機結構
舉例：一個清掃阿姨，可以打掃一間屋子。

專案應用場景：一個系統業務量很小，所有程式碼都放到一個專案中，部署在一臺伺服器上。整個專案都由這一臺伺服器提供，這就是單機結構。

缺點：處理能力有限，業務增長到一定程度，單機的硬體資源將無法滿足業務需求，所以就演變出了叢集模式。

主從結構
舉例：有一天阿姨請假了，怎麼辦？再聘用一個阿姨，B是A的備份。

專案應用場景：主從結構，一主一從，從是主的備份。為了達到高可用，主負責寫，從負責讀，實現讀寫分離。

叢集結構
舉例：隨著屋子增多，一個阿姨打掃搞不定了，又招來幾個阿姨，一起打掃。

專案應用場景：單機處理達到瓶頸的時候，就把單機複製幾份，這樣就構成“叢集”。叢集中每臺伺服器就叫做這個叢集的一個“節點”，所有節點構成一個叢集。每個節點都提供相同的服務，那麼這樣系統的能力就提升了好幾倍。但問題是使用者請求究竟由哪個節點來處理呢？最好能夠讓此時此刻負載較小的節點來處理，這樣使得每個節點的壓力都比較平均。要實現這樣的功能，就需要在所有的節點之前增加一個“排程者”的角色，使用者的請求都先交給他，然後他根據當前所有節點的負載情況，決定將這個請求交給哪個節點處理。這個“排程者”就是【負載均衡伺服器】。

優點：系統擴充套件非常容易，隨著業務擴充套件，叢集增加節點就好了，彈性擴容。

缺點：業務到達一定程度，不管如何增加節點都無法提升整個系統的效能。這個時候就引入了微服務結果了。

分散式
舉例：請了很多工人，給他們分工，有清掃樓道衛生間的、有擦玻璃的、維修的……構成了保潔公司，大家為了一個目標，就是承包整個大廈的保潔工作。

改變服務要需要思考的點：從單機結構到叢集結構，程式碼基本無需要做任何修改，僅僅是需要部署多臺伺服器，每臺伺服器上執行相同的程式碼就行。但是，當你要從叢集結構演進到微服務結構的時候，之前的那套程式碼要發生較大的改動。所以對於新系統我們建議，系統設計之初就採用微服務架構，這樣後期運維的成本更低。但如果老系統需要升級成微服務結構的話，那就得對程式碼進行大幅度的改造了。所以，對於老系統而言，究竟是繼續保持叢集模式，還是升級成微服務架構，需要深思熟慮，權衡投入產出比。

專案應用場景：分散式結構就是將一個完整的系統，按照業務功能，拆分成一個個獨立的子系統，在分散式結構中，每個子系統就被稱為“服務”。這些子系統能夠獨立執行在web容器中，它們之間通過RPC方式通訊。

優點：
1、系統之間耦合度大大降低，可以實現獨立開發、獨立部署、獨立測試，系統與系統之間的邊界非常明確，排查錯誤定位準確，開發效率大大提升。
2、系統耦合度降低，更易於擴充套件。可以根據業務靈活的對每個服務的節點擴充套件。
3、服務的複用性更高。

微服務
優點：業務解耦方便擴容，模組重用，方便程式碼管理和優化。
缺點：系統之間的關係變得複雜，業務增多，底層的模組需要高可用和併發，需要分散式Session框架的支援，分層後也增加測試的複雜度（分散式服務框架要解決的問題）
所以分散式框架都會且不僅限於實現下列功能：
微服務釋出（HTTP/RPC）
服務呼叫代理及客戶端軟負載
基於Token的安全認證框架
服務治理（服務註冊/管理/配置推送等）
服務監控（呼叫鏈分析）
測試平臺

分散式：不同模組部署在不同伺服器上
作用：分散式解決網站高併發帶來問題

叢集：多臺伺服器部署相同應用構成一個叢集
作用：通過負載均衡裝置共同對外提供服務

SOA：業務系統分解為多個元件，讓每個元件都獨立提供離散，自治，可複用的服務能力，通過服務的組合和編排來實現上層的業務流程
作用：簡化維護,降低整體風險,伸縮靈活

微服務：架構設計概念,各服務間隔離（分散式也是隔離）,自治（分散式依賴整體組合）其它特性(單一職責,邊界,非同步通訊,獨立部署)是分散式概念的跟嚴格執行SOA到微服務架構的演進過程

參考資料：https://www.zhihu.com/question/20004877
https://blog.csdn.net/heatdeath/article/details/79038795