架構設計基礎：單服務.集羣.分佈式，基本區別和聯繫

1、分佈式簡介

一、架構簡介

如今的互聯網，幾乎常見的複雜系統都會使用分佈式架構，若是在不清楚概念以前，剛接觸分佈式架構這個名詞會感受十分的高大上，其實在對比單服務，集羣服務以後，你就會發現本質上都是同樣的。

絮叨一句：所謂Java架構師，基本就是看被單服務，集羣，分佈式不斷暴打的頻率，架構師由於被虐頻率高，天然作出來的系統架構坑少，新手不能作架構的緣由，因此你該懂的。

言歸正傳，分佈式架構對於Java開發來講基本算是分水嶺，能不能從開發層面跳出來，就看你工做個三五年以後，對分佈式系統理解到什麼程度。單服務應用，基於單服務作集羣化部署，這種操做運維能夠自行搭建環境，因此基本對能力要求不算高。可是如何設計出彈性、配置化、分佈化、高性能、高容錯、安全的分佈式系統，的確是一件頗有挑戰的事情。

二、集羣和分佈式

首先須要理清楚單服務，集羣，分佈式這幾種不一樣架構的區別。

單服務和集羣

一張圖，你品，你細品：

業務體量小，全部服務和應用部署在一臺服務上，節省成本，這是單服務結構。當業務量逐漸增大，把一臺服務進行水平擴展，作一個服務羣，每臺服務稱爲集羣的一個節點，到這就是集羣服務。集羣服務要面對的一個問題就是：請求分配，天然須要一個調度組件來均衡服務器壓力，這也被稱爲負載均衡。

補刀一句：作到集羣模式的應用，在程序員面試的時候已經會被拿來作高格調的自吹自擂了，其實單服務和集羣的本質區別就是：在處理請求的時候多了一個分配服務的過程，如今你還以爲跟人吹集羣很高端嗎？

分佈式

一張圖，你品，你細品：

這個概念解釋起來就不容易了，單服務到集羣，是部署上的改變，在代碼層面改動極小，集羣模式會加入更多的服務監控，爲了快速的判斷哪一個服務宕機。

首先要解釋一下上圖：常見的電商系統架構(部分業務)，訂單，倉儲，物流。

• 用戶在訂單服務下單，天然須要校驗庫存；
• 下單成功以後，須要追蹤訂單物流；
• 商家須要倉儲服務管理上架商品，發貨等；
• 若是訂單服務出現高併發，能夠水平擴展，作訂單服務的集羣化；

這是一個基礎的業務場景，特色：多應用服務，多數據庫存儲，且服務之間有通訊行爲，在個別服務壓力大的狀況下能夠水平擴展集羣化部署。

分佈式結構就是按照業務系統的功能，拆分紅獨立的子服務，能夠獨立運行，且服務之間通訊和交互。帶來的好處也是很是的多，例如：下降業務間的耦合度，方便開發維護，水平擴展，複用性高等等。

補刀一句：不要出現思惟上的錯覺，認爲分佈式系統的邊界大於集羣，若是把一個分佈式總體看作一個服務，針對這個分佈式服務作集羣化部署，邏輯上是說的通的，只是這樣違背分佈式系統的初衷，好比後臺服務，沒有那麼大的高併發，天然不用浪費資源。

三、一句總結

分佈式和集羣模式磨刀霍霍的根本緣由，都是爲了解決兩個問題：提升系統吞吐量和高可用性，只是兩種模式站在的角度和業務場景不一樣，例如業務單調的高併發場景，業務複雜但不具有併發的場景，固然也有這兩種業務場景同時具有的。

補刀一句：針對系統架構和選型，各大公司也確實沒有統一的標準，可是都強調寫代碼的規範和邏輯，這樣作的根本緣由就是方便後續的系統架構更改。

2、分佈式技術棧

上面聊完了基本概念，如今聊聊分佈式系統中的技術體系。這個話題依舊有點飄逸。分佈式是一種架構思惟和模式，並不必定非要使用特定的框架，如今很火的幾個框架，SpringCloud,Dubbo，AliCloud等等，這些的出現都是給架構提供了更多的選擇。

補刀一句：架構體系和框架，必定是能夠分的開概念，框架更可能是方便架構快速落地和實現。

一、服務架構

做爲開發人員，分佈式系統要處理的問題很是多，可是主流的模塊有下面幾個：

• 網關控制

網關主要涉及到請求校驗，聚合API，路由配置，鑑權管理，安全，灰度發佈等等。經常使用的Zuul組件。

• 配置中心

動態資源配置加載，例如運行時流量管理，環境切換，靜態資源管理等。經常使用Nacos和config組件。

• 服務管理

分佈式中最難管理的模塊，也最容易出錯，首先多服務運行狀況下，須要保證服務間的交互正常，避免請求在鏈路的某個服務上積壓，出現異常還要及時熔斷，進行服務降級，高併發到峯值時，要配置限流策略，還有最難處理的分佈式事務。這裏也被稱爲服務容錯設計，經常使用Eureka、Hystrix、Sentinel、Dubbo等組件。

補刀一句：分佈式系統中真正的核心內容，即便一個很牛的架構師，搭建的分佈式環境也是在業務發展中不斷優化的，不會一成不變。

二、容器化運維

做爲運維人員：部署分佈式系統的確是一件極其繁雜的事情，這時就應景誕生了容器化運維。

• 部署環境

有的服務須要部署公有云(就是常說的幾家大公司雲服務)，有的要部署私有云（本身公司搭建，只服務本身業務的雲服務），混合雲就是上述兩種環境都須要部署服務。總之，如今不這麼說，會顯得本身很低調。

• 容器化技術

將服務打包部署在Docker容器中，若是須要臨時擴展，把Docker容器鏡像快速部署到多個服務器上便可，若是對這個概念比較懵，就比如本身電腦裏面多個虛擬機，能夠基於一個虛擬機鏡像文件，快速複製多個。Docker一大特點就是：搭建一次，處處運行。

補刀一句：此處必需要感嘆一句，Java一直火那麼久是有緣由的，後續的不少技術出現都在參考這個基本理念。

• 環境監控

分佈式系統的應用很是複雜，因此要對監控作的很是到位，這裏不只僅要對服務監控，硬件環境一樣重要。快速擴展，定位宕機服務。

3、數據存儲

上面一直沒有提到這個超大模塊，意識必須清楚，任何系統最複雜的邏輯莫過於數據存儲，從開發層面看：一個架構的核心價值就是在於數據的管理。

一、基礎描述

基於上面分佈式的概念，數據庫的理解方式也是一樣。分佈式數據庫能夠解決單個數據庫存儲的IO或CPU瓶頸而誕生的。經常使用的模式以下：

• 關係型

應用集成一個數據庫代理的中間件，把數據基於特定策略路由到不一樣的數據庫表中，取數據的時候在以一樣的邏輯查詢。很經典的sharding-jdbc組件，分庫分表的模式。

• 分佈式

上面關係數據庫的分庫分表處理，是比較顯式且刻意的，在分佈式數據庫中，自然的支持，且具備良好的水平擴展能力。例如：Hbase、mongodb、Greenplum分佈式數倉等等。

二、數據庫選型

分佈式系統架構和分佈式數據存儲相輔相成，無論架構選型仍是存儲選型，都沒有可建議的標準，這裏只能用一句頗有用的廢話來描述：基於本身的技術認知範圍，和業務場景綜合考量。

4、最後總結

如何架構分佈式系統，這說很差，可是如何判斷分佈式架構是否好，這很好說：服務良好的擴展性，高可用性，例如高併發業務隨時擴展，提升系統可用性，處理能力，這是必須具有的基礎特性。

推薦參考文章
微服務架構：項目技術選型簡介，架構圖解說明
微服務架構：業務架構設計，系統分層管理
微服務架構：數據庫選型簡介，業務數據規劃設計
微服務架構：中間件集成，公共服務封裝
微服務架構：SpringCloud 基礎組件應用設計
微服務架構：經過業務、應用、技術、存儲，聊聊架構
微服務應用：分庫分表模式下，數據庫擴容方案
微服務應用：Shard-Jdbc分庫分表，擴容方案實現