七点讲透分布式架构的前世今生，面试官都不知道的概念来了
一、前言
以前我們聊過分布式架構的演進過程，那本文我們就來聊一聊目前主流的分布式架構和分布式架構中常見理論以及如何才能設計出高可用的分布式架構好了，基本上就是它的前世今生了。
分布式架構中，SOA和微服務架構是最常見兩種分布式架構，而且目前服務網格的概念也越來越火了，那我們本文就先從這些常見架構開始。
看完這些，你去面試，我可以保證，你的底氣一定很足。
二、SOA架構解析
?SOA 全稱是: Service Oriented Architecture，中文釋義為 “面向服務的架構”，它是一種設計理念，其中包含多個服務， 服務之間通過相互依賴最終提供一系列完整的功能。各個服務通常以獨立的形式部署運行，服務之間通過網絡進行調用。架構圖如下：
?
跟 SOA 相提并論的還有一個概念叫 ESB(企業服務總線)，簡單來說 ESB 就是一根管道，用來連接各個服務節點。ESB的存在是為了集成基于不同協議的不同服務，ESB 做了消息的轉化、解釋以及路由的工作，以此來讓不同的服務互聯互通; 隨著我們業務的越來越復雜，會發現服務越來越多，SOA架構下，它們的調用關系會變成如下形式：
?
很顯然，這樣不是我們所想要的，那這時候如果我們引入ESB的概念，項目調用就又會很清晰，如下：
?
SOA所要解決的核心問題
- 系統間的集成 : 我們站在系統的角度來看，首先要解決各個系統間的通信問題，目的是將原先系統間散亂、無規劃的網狀結構，梳理成規整、可治理的星形結構，這步的實現往往需要引入一些概念和規范，比如 ESB、以及技術規范、服務管理規范。這一步解決的核心問題是【有序】。
- 系統的服務化 : 我們站在功能的角度，需要把業務邏輯抽象成可復用、可組裝的服務，從而通過服務的編排實現業務的快速再生，目的是要把原先固有的業務功能抽象設計為通用的業務服務、實現業務邏輯的快速復用;這步要解決的核心問題是【復用】。
- 業務的服務化 : 我們站在企業的角度，要把企業職能抽象成可復用、可組裝的服務，就要把原先職能化的企業架構轉變為服務化的企業架構，以便進一步提升企業的對外服務的能力。“前面兩步都是從技術層面來解決系統調用、系統功能復用的問題”。而本步驟，則是以業務驅動把一個業務單元封裝成一項服務。要解決的核心問題是?【高效】。
三、微服務（MicroServices）架構解析
?微服務架構和 SOA 架構非常類似,微服務只是 SOA 的升華，只不過微服務架構強調的是“業務需要徹底的組件化及服務化”，原先單個業務系統會被拆分為多個可以獨立開發、設計、部署運行的小應用。這些小應用間通過服務化完成交互和集成。
組件表示的就是一個可以獨立更換和升級的單元，就像 PC 中的 CPU、內存、顯卡、硬盤一樣，獨立且可以更換升級而不影響其他單元。若我們把 PC 中的各個組件以服務的方式構建，那么這臺 PC 只需要維護主板（可以理解為ESB）和一些必要的外部設備就可以。
CPU、內存、硬盤等都是以組件方式提供服務，例如PC 需要調用 CPU 做計算處理，只需知道 CPU 這個組件的地址就可以了。
?
微服務的特征
四、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 更好的結合等。
服務網格的特征
六、分布式架構的基本理論
?在說 CAP、BASE 理論之前，我們先要了解下分布式一致性的問題。 實際上對于不同業務的服務，我們對數據一致性的要求是不一樣的，如 12306，它要求數據的嚴格一致性， 不能把票賣給用戶以后卻發現沒有座位了 ;
再比如銀行轉賬， 我們通過銀行轉賬的時候，一般都會收到一個提示 : 轉賬申請將會在 24 小時內到賬。實際上這個場景滿足的是最終錢只要轉賬成功了即可，同時如果錢沒匯出去還要保證資金不丟失。所以說，用戶在使用不同的服務的時候對數據一致性的要求是不一樣的。
關于分布式一致性問題
?分布式系統中要解決的一個非常重要的問題就是數據的復制。 在我們的日常開發經驗中，相信大多數開發人員都遇過這樣的問題 : 在做數據庫讀寫分離的場景中，假設客戶端 A 將系統中的一個值 V 由 V1 變更為 V2，但客戶端 B 無法立即讀取到 V 的最新值，而需要在一段時間之后才能讀取到。這再正常不過了，因為數據庫復制之間存是在延時的。
?
所謂分布式一致性的問題，就是指在分布式環境中引入數據復制機制后，不同數據節點之間可能會出現的、且無法依靠計算機應用程序自身解決的數據不一致的情況。
簡單來說， 數據一致性就是指在對一個副本數據進行變更的時候，必須確保也能夠更新其它的副本，否則不同副本之間的數據將出現不一致。 那么如何去解決這個問題呢？
按照正常的思路，我們可能會想到既然是網絡延遲導致的問題，那么我們就把同步動作進行阻塞，用戶 2 在查詢的時候必須要等數據同步完成以后再來做。
但這個方案會非常影響性能。如果同步的數據比較多或比較頻繁，那么阻塞操作可能會導致整個新系統不可用。故我們沒有辦法找到一種既能夠滿足數據一致性、 又不影響系統性能的方案，所以就誕生了一個一致性的級別:
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(基本可用)
?表示在分布式系統出現不可預知的故障時，允許瞬時部分可用性
Soft-state(軟狀態).
?表示系統中的數據存在中間狀態，并 且這個中間狀態的存在不會影響系統的整體可用性，也就是表示系統允許在不同節點的數據副本之間進行數據同步過程中存在延時; 比如訂單狀態，有一個待支付、支付中、 支付成功、支付失敗， 那么支付中就是一個中間狀態，這 個中間狀態在支付成功以后，在支付表中的狀態同步給訂單狀態之前，中間會存在一個時間內的不一致。
Eventually consistent(數據的最終一致性)
?表示的是所有數據副本在一段時間的同步后最終都能達到一個一致的狀態，因此最終一致性的本質是要保證數據最終達到一致， 而不需要實時保證系統數據的強一致。
?BASE 理論的核心思想是 : 即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。
七、分布式架構下的高可用設計
避免單點故障
應用的高可用性
分布式架構下的可伸縮設計
加速靜態內容訪問速度的 CDN
?CDN 全稱是 Content Delivery Network，中文釋義是內容分發網絡。CDN 的作用是把用戶需要的內容分發到離用戶最近的地方進行響應，這樣用戶能夠快速獲取所需要的內容。
CDN 本質上就是一種網絡緩存技術，能夠把一些相對穩定的資源放到距離最終用戶較近的地方，一方面可以節省整個廣域網的帶寬消耗，另外一方面也可以提升用戶的訪問速度、改善用戶體驗。現實系統中我們一般會把靜態的文件(圖片、腳本、靜態頁面等)放到 CDN 中。
?
什么情況下用 CDN？
?最適合的是那些不會經常變化的內容，比如圖片，js 文件， CSS 文件，圖片文件包括程序模板中CSS 文件中用到的背景圖片，還有就是作為網站內容組成部分的那些圖片等等。
灰度發布
?我們的應用即使經過了測試部門的測試，也仍然很難全面覆蓋用戶的使用場景，為了保證萬無一失，我們在進行發布的時候一般都會采用灰度發布，也就是會對新應用進行分批發布，逐步擴大新應用在整個及集群中的比例直到最后全部完成。灰度發布是說針對新應用在用戶體驗方面完全無感知。
?灰度發布系統的作用在于，可以根據自己的配置，來將用 戶的流量導到新上線的系統上，來快速驗證新的功能， 而一旦出問題，也可以馬上的回滾發布，簡單的說，就是一套 A/B Test 系統。
總結
以上是生活随笔為你收集整理的七点讲透分布式架构的前世今生，面试官都不知道的概念来了的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 报表被老板吐槽又多又丑？因为你没有掌握这
- 下一篇： 30分钟后的飞鸽传书