一、分散式簡介
1、架構簡介
現在的網際網路，幾乎常見的複雜系統都會使用分散式架構，如果在不清楚概念之前，剛接觸分散式架構這個名詞會感覺十分的高大上，其實在對比單服務，叢集服務之後，你就會發現本質上都是一樣的。
絮叨一句：所謂Java架構師，基本就是看被單服務，叢集，分散式不斷暴打的頻率，架構師因為被虐頻率高，自然做出來的系統架構坑少，新手不能做架構的原因，所以你該懂的。
言歸正傳，分散式架構對於Java開發來說基本算是分水嶺，能不能從開發層面跳出來，就看你工作個三五年之後，對分散式系統理解到什麼程度。單服務應用，基於單服務做叢集化部署，這種操作運維可以自行搭建環境，所以基本對能力要求不算高。但是如何設計出彈性、配置化、分佈化、高效能、高容錯、安全的分散式系統，的確是一件很有挑戰的事情。
2、叢集和分散式
首先需要理清楚單服務，叢集，分散式這幾種不同架構的區別。
單服務和叢集
一張圖，你品，你細品：
業務體量小，所有服務和應用部署在一臺服務上，節省成本，這是單服務結構。當業務量逐漸增大，把一臺服務進行水平擴充套件，做一個服務群，每臺服務稱為叢集的一個節點，到這就是叢集服務。叢集服務要面對的一個問題就是：請求分配，自然需要一個排程元件來均衡伺服器壓力，這也被稱為負載均衡。
補刀一句：做到叢集模式的應用，在程式設計師面試的時候已經會被拿來做高格調的自吹自擂了，其實單服務和叢集的本質區別就是：在處理請求的時候多了一個分配服務的過程，現在你還覺得跟人吹叢集很高階嗎？
分散式
一張圖，你品，你細品：
這個概念解釋起來就不容易了，單服務到叢集，是部署上的改變，在程式碼層面改動極小，叢集模式會加入更多的服務監控，為了快速的判斷哪個服務當機。
首先要解釋一下上圖：常見的電商系統架構(部分業務)，訂單，倉儲，物流。
- 使用者在訂單服務下單，自然需要校驗庫存；
- 下單成功之後，需要追蹤訂單物流；
- 商家需要倉儲服務管理上架商品，發貨等；
- 如果訂單服務出現高併發，可以水平擴充套件，做訂單服務的叢集化；
這是一個基礎的業務場景，特點：多應用服務，多資料庫儲存，且服務之間有通訊行為，在個別服務壓力大的情況下可以水平擴充套件叢集化部署。
分散式結構就是按照業務系統的功能，拆分成獨立的子服務，可以獨立執行，且服務之間通訊和互動。帶來的好處也是非常的多，例如：降低業務間的耦合度，方便開發維護，水平擴充套件，複用性高等等。
補刀一句：不要出現思維上的錯覺，認為分散式系統的邊界大於叢集，如果把一個分散式整體看做一個服務，針對這個分散式服務做叢集化部署，邏輯上是說的通的，只是這樣違背分散式系統的初衷，比如後臺服務，沒有那麼大的高併發，自然不用浪費資源。
3、一句總結
分散式和叢集模式磨刀霍霍的根本原因，都是為了解決兩個問題：提高系統吞吐量和高可用性，只是兩種模式站在的角度和業務場景不同，例如業務單調的高併發場景，業務複雜但不具備併發的場景，當然也有這兩種業務場景同時具備的。
補刀一句：針對系統架構和選型，各大公司也確實沒有統一的標準，但是都強調寫程式碼的規範和邏輯，這樣做的根本原因就是方便後續的系統架構更改。
二、分散式技術棧
上面聊完了基本概念，現在聊聊分散式系統中的技術體系。這個話題依舊有點飄逸。分散式是一種架構思維和模式，並不一定非要使用特定的框架，現在很火的幾個框架，SpringCloud,Dubbo，AliCloud等等，這些的出現都是給架構提供了更多的選擇。
補刀一句：架構體系和框架，一定是可以分的開概念，框架更多是方便架構快速落地和實現。
1、服務架構
作為開發人員，分散式系統要處理的問題非常多，但是主流的模組有下面幾個：
- 閘道器控制
閘道器主要涉及到請求校驗，聚合API，路由配置，鑑權管理，安全，灰度釋出等等。常用的Zuul元件。
- 配置中心
動態資源配置載入，例如執行時流量管理，環境切換，靜態資源管理等。常用Nacos和config元件。
- 服務管理
分散式中最難管理的模組，也最容易出錯，首先多服務執行情況下，需要保證服務間的互動正常，避免請求在鏈路的某個服務上積壓，出現異常還要及時熔斷，進行服務降級，高併發到峰值時，要配置限流策略，還有最難處理的分散式事務。這裡也被稱為服務容錯設計，常用Eureka、Hystrix、Sentinel、Dubbo等元件。
補刀一句：分散式系統中真正的核心內容，即使一個很牛的架構師，搭建的分散式環境也是在業務發展中不斷優化的，不會一成不變。
2、容器化運維
作為運維人員：部署分散式系統的確是一件極其繁雜的事情，這時就應景誕生了容器化運維。
- 部署環境
有的服務需要部署公有云(就是常說的幾家大公司雲服務)，有的要部署私有云（自己公司搭建，只服務自己業務的雲服務），混合雲就是上述兩種環境都需要部署服務。總之，現在不這麼說，會顯得自己很低調。
- 容器化技術
將服務打包部署在Docker容器中，如果需要臨時擴充套件，把Docker容器映象快速部署到多個伺服器上即可，如果對這個概念比較懵，就好比自己電腦裡面多個虛擬機器，可以基於一個虛擬機器映象檔案，快速複製多個。Docker一大特色就是：搭建一次，到處執行。
補刀一句：此處必須要感嘆一句，Java一直火那麼久是有原因的，後續的很多技術出現都在參考這個基本理念。
- 環境監控
分散式系統的應用非常複雜，所以要對監控做的非常到位，這裡不僅僅要對服務監控，硬體環境同樣重要。快速擴充套件，定位當機服務。
三、資料儲存
上面一直沒有提到這個超大模組，意識必須清楚，任何系統最複雜的邏輯莫過於資料儲存，從開發層面看：一個架構的核心價值就是在於資料的管理。
1、基礎描述
基於上面分散式的概念，資料庫的理解方式也是同樣。分散式資料庫可以解決單個資料庫儲存的IO或CPU瓶頸而誕生的。常用的模式如下：
- 關係型
應用整合一個資料庫代理的中介軟體，把資料基於特定策略路由到不同的資料庫表中，取資料的時候在以同樣的邏輯查詢。很經典的sharding-jdbc元件，分庫分表的模式。
- 分散式
上面關聯式資料庫的分庫分表處理，是比較顯式且刻意的，在分散式資料庫中，天然的支援，且具有良好的水平擴充套件能力。例如：Hbase、mongodb、Greenplum分散式數倉等等。
2、資料庫選型
分散式系統架構和分散式資料儲存相輔相成，不管架構選型還是儲存選型，都沒有可建議的標準，這裡只能用一句很有用的廢話來描述：基於自己的技術認知範圍，和業務場景綜合考量。
四、最後總結
如何架構分散式系統，這說不好，但是如何判斷分散式架構是否好，這很好說：服務良好的擴充套件性，高可用性，例如高併發業務隨時擴充套件，提高系統可用性，處理能力，這是必須具備的基礎特性。
| 推薦參考文章 |
|---|
| 微服務架構：專案技術選型簡介，架構圖解說明 |
| 微服務架構：業務架構設計，系統分層管理 |
| 微服務架構：資料庫選型簡介，業務資料規劃設計 |
| 微服務架構：中介軟體整合，公共服務封裝 |
| 微服務架構：SpringCloud 基礎元件應用設計 |
| 微服務架構：通過業務、應用、技術、儲存，聊聊架構 |
| 微服務應用：分庫分表模式下，資料庫擴容方案 |
| 微服務應用：Shard-Jdbc分庫分表，擴容方案實現 |