主流分佈式架構的風流韻事...

1、前言

​　　上篇文章，咱們聊到了分佈式架構的演進過程，那本文咱們就來聊一聊目前主流的分佈式架構和分佈式架構中常見理論以及如何才能設計出高可用的分佈式架構好了。分佈式架構中，SOA和微服務架構是最多見兩種分佈式架構，並且目前服務網格的概念也愈來愈火了。那咱們本文就先從這些常見架構開始。

2、SOA架構解析

​　　SOA 全稱是: Service Oriented Architecture，中文釋義爲 「面向服務的架構」，它是一種設計理念，其中包含多個服務， 服務之間經過相互依賴最終提供一系列完整的功能。各個服務一般以獨立的形式部署運行，服務之間 經過網絡進行調用。架構圖以下：

​　　跟 SOA 相提並論的還有一個概念叫 ESB(企業服務總線)，簡單來講 ESB 就是一根管道，用來鏈接各個服務節點。ESB的存在是爲了集成基於不一樣協議的不一樣服務，ESB 作了消息的轉化、解釋以及路由的工做，以此來讓不一樣的服務互聯互通; 隨着咱們業務的愈來愈複雜，會發現服務愈來愈多，SOA架構下，它們的調用關係會變成以下形式：

　　很顯然，這樣不是咱們所想要的，那這時候若是咱們引入ESB的概念，項目調用就又會很清晰，以下：

SOA所要解決的核心問題

• 系統間的集成 : 咱們站在系統的角度來看，首先要解決各個系統間的通訊問題，目的是將原先系統間散亂、無規劃的網狀結構，梳理成規整、可治理的星形結構，這步的實現每每須要引入一些概念和規範，好比 ESB、以及技術規範、服務管理規範。這一步解決的核心問題是【有序】。
• 系統的服務化 : 咱們站在功能的角度，須要把業務邏輯抽象成可複用、可組裝的服務，從而經過服務的編排實現業務的快速再生，目的是要把原先固有的業務功能抽象設計爲通用的業務服務、實現業務邏輯的快速複用;這步要解決的核心問題是【複用】。
• 業務的服務化 : 咱們站在企業的角度，要把企業職能抽象成可複用、可組裝的服務，就要把原先職能化的企業架構轉變爲服務化的企業架構，以便進一步提高企業的對外服務的能力。「前面兩步都是從技術層面來解決系統調用、系統功能複用的問題」。而本步驟，則是以業務驅動把一個業務單元封裝成一項服務。要解決的核心問題是 【高效】。

3、微服務（MicroServices）架構解析

​　　微服務架構和 SOA 架構很是相似,微服務只是 SOA 的昇華，只不過微服務架構強調的是「業務須要完全的組件化及服務化」，原先單個業務系統會被拆分爲多個能夠獨立開發、設計、部署運行的小應用。這些小應用間經過服務化完成交互和集成。 組件表示的就是一個能夠獨立更換和升級的單元，就像 PC 中的 CPU、內存、顯卡、硬盤同樣，獨立且能夠更換升級而不影響其餘單元。若咱們把 PC 中的各個組件以服務的方式構建，那麼這臺 PC 只須要維護主板（能夠理解爲ESB）和一些必要的外部設備就能夠。CPU、內存、硬盤等都是以組件方式提供服務，例如PC 須要調用 CPU 作計算處理，只需知道 CPU 這個組件的地址就能夠了。

微服務的特徵

1. 經過服務實現組件化
2. 按業務能力來劃分服務和開發團隊
3. 去中心化
4. 基礎設施自動化(devops、自動化部署)

4、SOA 和微服務架構的差異

​　　微服務再也不強調傳統SOA架構裏面比較重的ESB企業服務總線，同時以 SOA 的思想進入到單個業務系統內部實現真正的組件化。

​　　Docker 容器技術的出現，爲微服務提供了很是便利的條件，好比更小的部署單元，每一個服務能夠經過相似 Spring Boot 或者 Node 等技術獨立運行。

​ 　　還有一個點你們應該能夠分析出來，SOA 注重的是系統集成，而微服務關注的是徹底分離。

5、服務網格（Service Mesh）架構解析

​　　17 年年末，非侵入式的 Service Mesh 技術慢慢走向了成熟。Service Mesh ，中文釋義「服務網格」，又叫服務邊車，做爲服務間通訊的基礎設施層在系統中存在。若是要用一句話來解釋什麼叫 Service Mesh，咱們能夠將它比做是應用程序或者說微服務間的 TCP/IP層，負責服務間的網絡調用、熔斷、限流和監控。咱們都知道在編寫應用程序時程序猿通常都無須關心 TCP/IP 這一層（好比提供 HTTP 協議的 Restful 應用），一樣若是使用服務網格咱們也就不須要關係服務間的那些原來是由應用程序或者其餘框架實現的事情(熔斷、限流、監控等)，如今只要交給 Service Mesh 就能夠了。服務網格架構圖以下：

​　　目前流行的 Service Mesh 開源軟件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（開源 Linkerd 的公司）又發佈了基於 Kubernetes 的 Service Mesh 開源項目 Conduit。

​　　關於微服務和服務網格的區別，我這樣理解：微服務更注重服務之間的生態，專一於服務治理等方面，而服務網格更專一於服務之間的通訊，以及和 DevOps 更好的結合等。

服務網格的特徵

1. 應用程序間通信的中間層
2. 輕量級網絡代理
3. 應用程序無感知
4. 解耦應用程序的重試/超時、監控、追蹤和服務發現

6、分佈式架構的基本理論

​　　在說 CAP、BASE 理論以前，咱們先要了解下分佈式一致性的問題。 實際上對於不一樣業務的服務，咱們對數據一致性的要求是不同的，如 12306，它要求數據的嚴格一致性， 不能把票賣給用戶之後卻發現沒有座位了 ; 再好比銀行轉帳， 咱們經過銀行轉帳的時候，通常都會收到一個提示 : 轉帳申請將會在 24 小時內到帳。實際上這個場景知足的是最終錢只要轉帳成功了便可，同時若是錢沒匯出去還要保證資金不丟失。因此說，用戶在使用不一樣的服務的時候對數據一致性的要求是不同的。

關於分佈式一致性問題

​　　分佈式系統中要解決的一個很是重要的問題就是數據的複製。 在咱們的平常開發經驗中，相信大多數開發人員都遇過這樣的問題 : 在作數據庫讀寫分離的場景中，假設客戶端 A 將系統中的一個值 V 由 V1 變動爲 V2，但客戶端 B 沒法當即讀取到 V 的最新值，而須要在一段時間以後才能讀取到。這再正常不過了，由於數據庫複製之間存是在延時的。

​　　所謂分佈式一致性的問題，就是指在分佈式環境中引入數據複製機制後，不一樣數據節點之間可能會出現的、且沒法依靠計算機應用程序自身解決的數據不一致的狀況。簡單來講， 數據一致性就是指在對一個副本數據進行變動的時候，必須確保也可以更新其它的副本，不然不一樣副本之間的數據將出現不一致。 那麼如何去解決這個問題呢？按照正常的思路，咱們可能會想到既然是網絡延遲致使的問題，那麼咱們就把同步動做進行阻塞，用戶 2 在查詢的時候必需要等數據同步完成之後再來作。但這個方案會很是影響性能。若是同步的數據比較多或比較頻繁，那麼阻塞操做可能會致使整個新系統不可用。故咱們沒有辦法找到一種既可以知足數據一致性、 又不影響系統性能的方案，因此就誕生了一個一致性的級別:

1. 強一致性 : 這種一致性級別是最符合用戶直覺的，它要求系統寫入的是什麼，讀出來的也要是什麼，用戶體驗好，但實現起來每每對系統的性能影響較大。
2. 弱一致性 : 這種一致性級別約束了系統在寫入成功後， 不保證當即能夠讀到寫入的值，也不保證多久以後數據 可以達到一致，但會盡量地保證到某個時間級別(如秒級別)後，數據可以達到一致狀態。
3. 最終一致性 : 最終一致性實際上是弱一致性的一個特例，系統會保證在必定時間內，可以達到數據一致的狀態。這裏之因此將最終一致性單獨提出來，是由於它是弱一致性中很是推崇的一種一致性模型，也是業界在大型分佈式系統的數據一致性上用的比較多的一致性模型。

CAP 理論

​　　它是一個經典的分佈式系統理論。CAP 理論告訴咱們 : 一個分佈式系統不可能同時知足一致性(C:Consistency)、可用性(A:Availability)及分區容錯性(P:Partition tolerance) 這三個基本要求，最多隻能同時知足其中兩項。CAP 理論在互聯網界有着普遍的知名度，也被稱爲「帽子理論」，它是 由 Eric Brewer 教授在 2000 年舉行的 ACM 研討會提出的 一個著名猜測: 一致性(Consistency)、可用性(Availability)、分區容錯 (Partition-tolerance)三者沒法在分佈式系統中被同時知足，而且最多隻能知足兩個!

• 一致性 : 全部節點上的數據時刻保持同步
• 可用性 : 每一個請求都能接收一個響應，不管響應成功或失敗
• 分區容錯 : 系統應該持續提供服務，即便系統內部(某個節點分區)有消息丟失。好比交換機失敗、網址網絡被分紅幾個子網，造成腦裂、服務器發生網絡延遲或死機，致使某些 server 與集羣中的其餘機器失去聯繫。

　　分區是致使分佈式系統可靠性問題的固有特性，從本質上來看，CAP 理論的準確描述不該該是從 3 個特性中選取兩個，因此咱們只能被迫適應，根本沒有選擇權。CAP 並非一個普適性原理和指導思想，它僅適用於原子讀寫的 NoSql 場景中，並不適用於數據庫系統。

BASE 理論

​　　從前面的分析中咱們知道 : 在分佈式(數據庫分片或分庫存在的多個實例上)前提下，CAP 理論並不適合數據庫事務(由於更新一些錯誤的數據而致使的失敗，不管使用什麼高可用方案都是徒勞的，由於數據發生了沒法修正的錯誤)。 此外 XA 事務雖然保證了數據庫在分佈式系統下的 ACID (原子性、一致性、隔離性、持久性)特性，但同時也帶來了一 些性能方面的代價，對於併發和響應時間要求都比較高的電商平臺來講，是很難接受的。

​　　eBay 嘗試了另一條徹底不一樣的路，放寬了數據庫事務的 ACID 要求，提出了一套名爲 BASE 的新準則。BASE 全稱爲 Basically Available,Soft-state,Eventually Consistent. 系統基本可用、軟狀態、數據最終一致性。相對於 CAP 來講，它大大下降了咱們對系統的要求。

Basically Available(基本可用)

​ 表示在分佈式系統出現不可預 知的故障時，容許瞬時部分可用性

1. 好比咱們在淘寶上搜索商品，正常狀況下是在 0.5s 內返回查詢結果，可是因爲後端的系統故障致使查詢響應時間變成了 2s。
2. 再好比數據庫採用分片模式，100W 個用戶數據分在 5 個數據庫實例上，若是破壞了一個實例，那麼可用性還 有 80%，也就是 80%的用戶均可以登陸，系統仍然可用。
3. 電商大促時，爲了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。

Soft-state(軟狀態).

​　　表示系統中的數據存在中間狀態，並 且這個中間狀態的存在不會影響系統的總體可用性，也就是表示系統容許在不一樣節點的數據副本之間進行數據同步過程當中存在延時; 好比訂單狀態，有一個待支付、支付中、 支付成功、支付失敗， 那麼支付中就是一箇中間狀態，這 箇中間狀態在支付成功之後，在支付表中的狀態同步給訂單狀態以前，中間會存在一個時間內的不一致。

Eventually consistent(數據的最終一致性)

​　　表示的是全部數據副本在一段時間的同步後最終都能達到一個一致的狀態，所以最終一致性的本質是要保證數據最終達到一致， 而不須要實時保證系統數據的強一致。

​BASE 理論的核心思想是 : 即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方式來使系統達到最終一致性。

7、分佈式架構下的高可用設計

避免單點故障

1. 負載均衡技術(failover/選址/硬件負載/ 軟件負載/去中心化的軟件負載(gossip(redis- cluster)))
2. 熱備(linux HA)
3. 多機房(同城災備、異地災備)

應用的高可用性

1. 故障監控(系統監控(cpu、內存)/鏈路監控/日誌監 控) 自動預警
2. 應用的容錯設計、(服務降級、限流)自我保護能力
3. 數據量(數據分片、讀寫分離)

分佈式架構下的可伸縮設計

1. 垂直伸縮
2. 提高硬件能力
3. 水平伸縮
4. 增長服務器

加速靜態內容訪問速度的 CDN

​　　CDN 全稱是 Content Delivery Network，中文釋義是內容分發網絡。CDN 的做用是把用戶須要的內容分發到離用戶最近的地方進行響應，這樣用戶可以快速獲取所須要的內容。 CDN 本質上就是一種網絡緩存技術，可以把一些相對穩定的資源放到距離最終用戶較近的地方，一方面能夠節省整個廣域網的帶寬消耗，另一方面也能夠提高用戶的訪問速度、改善用戶體驗。現實系統中咱們通常會把靜態的文件(圖片、腳本、靜態頁面等)放到 CDN 中。

1. 當用戶訪問網站頁面上的內容 URL，通過本地 DNS 系統解析，DNS 系統最終會將域名的解析權交給 CNAME 指向的 CDN 專用 DNS 服務器。

2. CDN 的 DNS 服務器將 CDN 的全局負載均衡設備 IP 地址返回用戶。

3. 用戶向 CDN 的全局負載均衡設備發起內容 URL 訪問請求。

4. CDN全局負載均衡設備根據用戶IP地址，以及用戶請求的內容URL， 選擇一臺用戶所屬區域的區域負載均衡設備，告訴用戶向這臺設備發起請求。

5. 區域負載均衡設備會爲用戶選擇一臺合適的緩存服務器提供服務。

   選擇的依據包括 : 根據用戶 IP 地址，判斷哪一臺服務器距離用戶最近。根據用戶所請求的 URL 中攜帶的內容名稱，判斷哪一臺服務器上有用戶所需內容;查詢各個服務器當前的負載狀況，判斷哪一臺服務器上有服務能力。基於以上條件的綜合分析以後，區域負載均衡設備會向全局負載均衡設備返回一臺緩存服務器的 IP 地址。

6. 局負載均衡設備把服務器的 IP 地址返回給用戶。

   用戶向緩存服務器發起請求，緩存服務器響應用戶請求，將用戶所需內容返回到用戶終端。若是這臺緩存服務器上並無用戶想要的內容，而區域均衡設備依然將它分配給了用戶，那麼這臺服務器就要向它的上一級緩存服務器請求內容，直到追溯到包含該內容的源服務器並將內容拉到本地。

什麼狀況下用 CDN？

​　　最適合的是那些不會常常變化的內容，好比圖片，js 文件， CSS 文件，圖片文件包括程序模板中CSS 文件中用到的背景圖片，還有就是做爲網站內容組成部分的那些圖片等等。

灰度發佈

​　　咱們的應用即便通過了測試部門的測試，也仍然很難全面覆蓋用戶的使用場景，爲了保證萬無一失，咱們在進行發佈的時候通常都會採用灰度發佈，也就是會對新應用進行分批發布，逐步擴大新應用在整個及集羣中的比例直到最後所有完成。灰度發佈是說針對新應用在用戶體驗方面徹底無感知。

​　　灰度發佈系統的做用在於，能夠根據本身的配置，來將用 戶的流量導到新上線的系統上，來快速驗證新的功能， 而一旦出問題，也能夠立刻的回滾發佈，簡單的說，就是一套 A/B Test 系統。

8、總結

​　　經過本文，咱們就對主流的SOA架構、微服務架構、服務網格架構作了解析，而後知道了分佈式架構中的幾個基本理論，而後還分析瞭如何設計出高可用的分佈式架構，有木有棒棒噠~ 下篇文章，咱們來經過實例來分析如何基於DDD開發咱們的微服務系統。期待不？評論區等你喲~