SOA架構解析

SOA 全稱是: Service Oriented Architecture，中文釋義為 “面向服務的架構”，它是一種設計理念，其中包含多個服務， 服務之間通過相互依賴最終提供一系列完整的功能。各個服務通常以獨立的形式部署執行，服務之間 通過網路進行呼叫。架構圖如下：

隨著我們業務的越來越複雜，會發現服務越來越多，SOA架構下，它們的呼叫關係會變成如下形式：

跟 SOA 相提並論的還有一個 ESB(企業服務匯流排)，簡單來說 ESB 就是一根管道，用來連線各個服務節點。ESB的存在是為了整合基於不同協議的不同服務，ESB 做了訊息的轉化、解釋以及路由的工作，以此來讓不同的服務互聯互通。引入ESB匯流排後的架構如下：

SOA所要解決的核心問題

• 系統間的整合 : 我們站在系統的角度來看，首先要解決各個系統間的通訊問題，目的是將原先系統間散亂、無規劃的網狀結構，梳理成規整、可治理的星形結構，這步的實現往往需要引入一些概念和規範，比如 ESB、以及技術規範、服務管理規範; 這一步解決的核心問題是【有序】

  。

• 系統的服務化 : 我們站在功能的角度，需要把業務邏輯抽象成可複用、可組裝的服務，從而通過服務的編排實現業務的快速再生，目的是要把原先固有的業務功能抽象設計為通用的業務服務、實現業務邏輯的快速複用;這步要解決的核心問題是【複用】。

• 業務的服務化 : 我們站在企業的角度，要把企業職能抽象成可複用、可組裝的服務，就要把原先職能化的企業架構轉變為服務化的企業架構，以便進一步提升企業的對外服務的能力。“前面兩步都是從技術層面來解決系統呼叫、系統功能複用的問題”。而本步驟，則是以業務驅動把一個業務單元封裝成一項服務。要解決的核心問題是 【高效】。

微服務（Microservices）架構解析

微服務架構和 SOA 架構非常類似,微服務只是的 SOA 昇華，只不過微服務架構強調的是“業務需要徹底的元件化及服務化”，原單個業務系統會被拆分為多個可以獨立開發、設計、部署執行的小應用。這些小應用間通過服務化完成互動和整合。 元件表示的就是一個可以獨立更換和升級的單元，就像 PC 中的 CPU、記憶體、顯示卡、硬碟一樣，獨立且可以更換升級而不影響其他單元。若我們把 PC 中的各個元件以服務的方式構 建，那麼這臺 PC 只需要維護主機板（可以理解為ESB）和一些必要的外部裝置就可以。CPU、記憶體、硬碟等都是以元件方式提供服務，例如PC 需要呼叫 CPU 做計算處理，只需知道 CPU 這個元件的地址就可以了。

微服務的特徵

1. 通過服務實現元件化  

2. 按業務能力來劃分服務和開發團隊

3. 去中心化

4. 基礎設施自動化(devops、自動化部署)

SOA 和微服務架構的差別

微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時以 SOA 的思想進入到單個業務系統內部實 現真正的元件化。Docker 容器技術的出現，為微服務提供了非常便利的條件，比如更小的部署單元，每個服務可以通過類似 Spring Boot 或者 Node 等技術獨立執行。還有一個點大家應該可以分析出來，SOA 注重的是系統整合，而微服務關注的是完全分離。

服務網格（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. 解耦應用程式的重試/超時、監控、追蹤和服務發現

 分散式架構的基本理論

在說 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 理論的核心思想是 : 即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。

分散式架構下的高可用設計

避免單點故障

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/BTest 系統。