日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

公告:魔扣目錄網(wǎng)為廣大站長提供免費收錄網(wǎng)站服務,提交前請做好本站友鏈:【 網(wǎng)站目錄:http://www.ylptlb.cn 】, 免友鏈快審服務(50元/站),

點擊這里在線咨詢客服
新站提交
  • 網(wǎng)站:51998
  • 待審:31
  • 小程序:12
  • 文章:1030137
  • 會員:747

一、前言

上篇文章,我們聊到了分布式架構的演進過程,那本文我們就來聊一聊目前主流的分布式架構以及分布式架構中常見理論以及如何才能設計出高可用的分布式架構好了。分布式架構中,SOA和微服務架構是最常見兩種分布式架構,而且目前服務網(wǎng)格的概念也越來越火了。那我們本文就先從這些常見架構開始。

二、SOA架構解析

SOA 全稱是: Service Oriented Architecture,中文釋義為 “面向服務的架構”,它是一種設計理念,其中包含多個服務, 服務之間通過相互依賴最終提供一系列完整的功能。各個服務通常以獨立的形式部署運行,服務之間 通過網(wǎng)絡進行調(diào)用。架構圖如下:

一文網(wǎng)羅分布式架構原理和方法

 

 

跟 SOA 相提并論的還有一個 ESB(企業(yè)服務總線),簡單來說 ESB 就是一根管道,用來連接各個服務節(jié)點。ESB的存在是為了集成基于不同協(xié)議的不同服務,ESB 做了消息的轉化、解釋以及路由的工作,以此來讓不同的服務互聯(lián)互通; 隨著我們業(yè)務的越來越復雜,會發(fā)現(xiàn)服務越來越多,SOA架構下,它們的調(diào)用關系會變成如下形式:

一文網(wǎng)羅分布式架構原理和方法

 

很顯然,這樣不是我們所想要的,那這時候如果我們引入ESB的概念,項目調(diào)用就又會很清晰,如下:

一文網(wǎng)羅分布式架構原理和方法

 

SOA所要解決的核心問題

  • 系統(tǒng)間的集成 : 我們站在系統(tǒng)的角度來看,首先要解決各個系統(tǒng)間的通信問題,目的是將原先系統(tǒng)間散亂、無規(guī)劃的網(wǎng)狀結構,梳理成規(guī)整、可治理的星形結構,這步的實現(xiàn)往往需要引入一些概念和規(guī)范,比如 ESB、以及技術規(guī)范、服務管理規(guī)范; 這一步解決的核心問題是【有序】
  • 系統(tǒng)的服務化 : 我們站在功能的角度,需要把業(yè)務邏輯抽象成可復用、可組裝的服務,從而通過服務的編排實現(xiàn)業(yè)務的快速再生,目的是要把原先固有的業(yè)務功能抽象設計為通用的業(yè)務服務、實現(xiàn)業(yè)務邏輯的快速復用;這步要解決的核心問題是【復用】
  • 業(yè)務的服務化 : 我們站在企業(yè)的角度,要把企業(yè)職能抽象成可復用、可組裝的服務,就要把原先職能化的企業(yè)架構轉變?yōu)榉栈钠髽I(yè)架構,以便進一步提升企業(yè)的對外服務的能力。“前面兩步都是從技術層面來解決系統(tǒng)調(diào)用、系統(tǒng)功能復用的問題”。而本步驟,則是以業(yè)務驅(qū)動把一個業(yè)務單元封裝成一項服務。要解決的核心問題是【高效】

三、微服務(Microservices)架構解析

微服務架構和 SOA 架構非常類似,微服務只是的 SOA 升華,只不過微服務架構強調(diào)的是“業(yè)務需要徹底的組件化及服務化”,原單個業(yè)務系統(tǒng)會被拆分為多個可以獨立開發(fā)、設計、部署運行的小應用。這些小應用間通過服務化完成交互和集成。 組件表示的就是一個可以獨立更換和升級的單元,就像 PC 中的 CPU、內(nèi)存、顯卡、硬盤一樣,獨立且可以更換升級而不影響其他單元。若我們把 PC 中的各個組件以服務的方式構 建,那么這臺 PC 只需要維護主板(可以理解為ESB)和一些必要的外部設備就可以。CPU、內(nèi)存、硬盤等都是以組件方式提供服務,例如PC 需要調(diào)用 CPU 做計算處理,只需知道 CPU 這個組件的地址就可以了。

一文網(wǎng)羅分布式架構原理和方法

 

 

微服務的特征

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

四、SOA 和微服務架構的差別

微服務不再強調(diào)傳統(tǒng)SOA架構里面比較重的ESB企業(yè)服務總線,同時以 SOA 的思想進入到單個業(yè)務系統(tǒng)內(nèi)部實 現(xiàn)真正的組件化。

Docker 容器技術的出現(xiàn),為微服務提供了非常便利的條件,比如更小的部署單元,每個服務可以通過類似 Spring Boot 或者 Node 等技術獨立運行。

還有一個點大家應該可以分析出來,SOA 注重的是系統(tǒng)集成,而微服務關注的是完全分離。

五、服務網(wǎng)格(Service Mesh)架構解析

17 年年底,非侵入式的 Service Mesh 技術慢慢走向了成熟。Service Mesh ,中文釋義“服務網(wǎng)格”,作為服務間通信的基礎設施層在系統(tǒng)中存在。如果要用一句話來解釋什么叫 Service Mesh,我們可以將它比作是應用程序或者說微服務間的 TCP/IP,負責服務間的網(wǎng)絡調(diào)用、熔斷、限流和監(jiān)控。我們都知道在編寫應用程序時程序猿一般都無須關心 TCP/IP 這一層(比如提供 HTTP 協(xié)議的 Restful 應用),同樣如果使用服務網(wǎng)格我們也就不需要關系服務間的那些原來是由應用程序或者其他框架實現(xiàn)的事情(熔斷、限流、監(jiān)控等),現(xiàn)在只要交給 Service Mesh 就可以了。服務網(wǎng)格架構圖如下:

一文網(wǎng)羅分布式架構原理和方法

 

 

目前流行的 Service Mesh 開源軟件有 LinkerdEnvoy 和 Istio,而最近 Buoyant(開源 Linkerd 的公司)又發(fā)布了基于 Kubernetes 的 Service Mesh 開源項目 Conduit

關于微服務和服務網(wǎng)格的區(qū)別,我這樣理解:微服務更注重服務之間的生態(tài),專注于服務治理等方面,而服務網(wǎng)格更專注于服務之間的通信,以及和 DevOps 更好的結合等

服務網(wǎng)格的特征

  1. 應用程序間通訊的中間層
  2. 輕量級網(wǎng)絡代理
  3. 應用程序無感知
  4. 解耦應用程序的重試/超時、監(jiān)控、追蹤和服務發(fā)現(xiàn)

六、分布式架構的基本理論

在說 CAP、BASE 理論之前,我們先要了解下分布式一致性的問題。 實際上對于不同業(yè)務的服務,我們對數(shù)據(jù)一致性的要求是不一樣的,如 12306,它要求數(shù)據(jù)的嚴格一致性, 不能把票賣給用戶以后卻發(fā)現(xiàn)沒有座位了;再比如銀行轉賬, 我們通過銀行轉賬的時候,一般都會收到一個提示 : 轉賬申請將會在 24 小時內(nèi)到賬。實際上這個場景滿足的是最終錢只要轉賬成功了即可,同時如果錢沒匯出去還要保證資金不丟失。所以說,用戶在使用不同的服務的時候?qū)?shù)據(jù)一致性的要求是不一樣的。

關于分布式一致性問題

分布式系統(tǒng)中要解決的一個非常重要的問題就是數(shù)據(jù)的復制。 在我們的日常開發(fā)經(jīng)驗中,相信大多數(shù)開發(fā)人員都遇過這樣的問題 : 在做數(shù)據(jù)庫讀寫分離的場景中,假設客戶端 A 將系統(tǒng)中的一個值 V 由 V1 變更為 V2,但客戶端 B 無法立即讀取到 V 的最新值,而需要在一段時間之后才能讀取到。這再正常不過了,因為數(shù)據(jù)庫復制之間存是在延時的。

一文網(wǎng)羅分布式架構原理和方法

 

 

所謂分布式一致性的問題,就是指在分布式環(huán)境中引入數(shù)據(jù)復制機制后,不同數(shù)據(jù)節(jié)點之間可能會出現(xiàn)的、且無法依靠計算機應用程序自身解決的數(shù)據(jù)不一致的情況。簡單來說, 數(shù)據(jù)一致性就是指在對一個副本數(shù)據(jù)進行變更的時候,必須確保也能夠更新其它的副本,否則不同副本之間的數(shù)據(jù)將出現(xiàn)不一致。 那么如何去解決這個問題呢?按照正常的思路,我們可能會想到既然是網(wǎng)絡延遲導致的問題,那么我們就把同步動作進行阻塞,用戶 2 在查詢的時候必須要等數(shù)據(jù)同步完成以后再來做。但這個方案會非常影響性能。如果同步的數(shù)據(jù)比較多或比較頻繁,那么阻塞操作可能會導致整個新系統(tǒng)不可用。故我們沒有辦法找到一種既能夠滿足數(shù)據(jù)一致性、 又不影響系統(tǒng)性能的方案,所以就誕生了一個一致性的級別:

  1. 強一致性 : 這種一致性級別是最符合用戶直覺的,它要求系統(tǒng)寫入的是什么,讀出來的也要是什么,用戶體驗好,但實現(xiàn)起來往往對系統(tǒng)的性能影響較大。
  2. 弱一致性 : 這種一致性級別約束了系統(tǒng)在寫入成功后, 不保證立即可以讀到寫入的值,也不保證多久之后數(shù)據(jù) 能夠達到一致,但會盡可能地保證到某個時間級別(如秒級別)后,數(shù)據(jù)能夠達到一致狀態(tài)。
  3. 最終一致性 : 最終一致性其實是弱一致性的一個特例,系統(tǒng)會保證在一定時間內(nèi),能夠達到數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨提出來,是因為它是弱一致性中非常推崇的一種一致性模型,也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上用的比較多的一致性模型。

CAP 理論

它是一個經(jīng)典的分布式系統(tǒng)理論。CAP 理論告訴我們 : 一個分布式系統(tǒng)不可能同時滿足一致性(C:Consistency)、可用性(A:Availability)及分區(qū)容錯性(P:Partition tolerance) 這三個基本要求,最多只能同時滿足其中兩項。CAP 理論在互聯(lián)網(wǎng)界有著廣泛的知名度,也被稱為“帽子理論”,它是 由 Eric Brewer 教授在 2000 年舉行的 ACM 研討會提出的 一個著名猜想: 一致性(Consistency)、可用性(Availability)、分區(qū)容錯 (Partition-tolerance)三者無法在分布式系統(tǒng)中被同時滿足,并且最多只能滿足兩個!

  • 一致性 : 所有節(jié)點上的數(shù)據(jù)時刻保持同步
  • 可用性 : 每個請求都能接收一個響應,無論響應成功或失敗
  • 分區(qū)容錯 : 系統(tǒng)應該持續(xù)提供服務,即使系統(tǒng)內(nèi)部(某個節(jié)點分區(qū))有消息丟失。比如交換機失敗、網(wǎng)址網(wǎng)絡被分成幾個子網(wǎng),形成腦裂、服務器發(fā)生網(wǎng)絡延遲或死機,導致某些 server 與集群中的其他機器失去聯(lián)系。

分區(qū)是導致分布式系統(tǒng)可靠性問題的固有特性,從本質(zhì)上來看,CAP 理論的準確描述不應該是從 3 個特性中選取兩個,所以我們只能被迫適應,根本沒有選擇權。CAP 并不是一個普適性原理和指導思想,它僅適用于原子讀寫的 NoSql 場景中,并不適用于數(shù)據(jù)庫系統(tǒng)。

BASE 理論

從前面的分析中我們知道 : 在分布式(數(shù)據(jù)庫分片或分庫存在的多個實例上)前提下,CAP 理論并不適合數(shù)據(jù)庫事務(因為更新一些錯誤的數(shù)據(jù)而導致的失敗,無論使用什么高可用方案都是徒勞的,因為數(shù)據(jù)發(fā)生了無法修正的錯誤)。 此外 XA 事務雖然保證了數(shù)據(jù)庫在分布式系統(tǒng)下的 ACID (原子性、一致性、隔離性、持久性)特性,但同時也帶來了一 些性能方面的代價,對于并發(fā)和響應時間要求都比較高的電商平臺來說,是很難接受的。

eBay 嘗試了另外一條完全不同的路,放寬了數(shù)據(jù)庫事務的 ACID 要求,提出了一套名為 BASE 的新準則。BASE 全稱為 Basically Available,Soft-state,Eventually Consistent. 系統(tǒng)基本可用、軟狀態(tài)、數(shù)據(jù)最終一致性。相對于 CAP 來說,它大大降低了我們對系統(tǒng)的要求。

Basically Available(基本可用)

表示在分布式系統(tǒng)出現(xiàn)不可預 知的故障時,允許瞬時部分可用性

  1. 比如我們在淘寶上搜索商品,正常情況下是在 0.5s 內(nèi)返回查詢結果,但是由于后端的系統(tǒng)故障導致查詢響應時間變成了 2s
  2. 再比如數(shù)據(jù)庫采用分片模式,100W 個用戶數(shù)據(jù)分在 5 個數(shù)據(jù)庫實例上,如果破壞了一個實例,那么可用性還 有 80%,也就是 80%的用戶都可以登錄,系統(tǒng)仍然可用
  3. 電商大促時,為了應對訪問量激增,部分用戶可能會被 引導到降級頁面,服務層也可能只提供降級服務。這就 是損失部分可用性的體現(xiàn)

Soft-state(軟狀態(tài)).

表示系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài),并 且這個中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性,也就 是表示系統(tǒng)允許在不同節(jié)點的數(shù)據(jù)副本之間進行數(shù)據(jù)同步 過程中存在延時; 比如訂單狀態(tài),有一個待支付、支付中、 支付成功、支付失敗, 那么支付中就是一個中間狀態(tài),這 個中間狀態(tài)在支付成功以后,在支付表中的狀態(tài)同步給訂 單狀態(tài)之前,中間會存在一個時間內(nèi)的不一致。

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

表示的是所有 數(shù)據(jù)副本在一段時間的同步后最終都能達到一個一致的狀 態(tài),因此最終一致性的本質(zhì)是要保證數(shù)據(jù)最終達到一致, 而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致

BASE 理論的核心思想是 : 即使無法做到強一致性,但每個應用都可以根據(jù)自身業(yè)務特點,采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

七、分布式架構下的高可用設計

避免單點故障

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

應用的高可用性

  1. 故障監(jiān)控(系統(tǒng)監(jiān)控(cpu、內(nèi)存)/鏈路監(jiān)控/日志監(jiān) 控) 自動預警
  2. 應用的容錯設計、(服務降級、限流)自我保護能力
  3. 數(shù)據(jù)量(數(shù)據(jù)分片、讀寫分離)

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

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

加速靜態(tài)內(nèi)容訪問速度的 CDN

CDN 全稱是 Content Delivery Network,中文釋義是內(nèi)容分發(fā)網(wǎng)絡。CDN 的作用是把用戶需要的內(nèi)容分發(fā)到離用戶最近的地方進行響應,這樣用戶能夠快速獲取所需要的內(nèi)容。 CDN 本質(zhì)上就是一種網(wǎng)絡緩存技術,能夠把一些相對穩(wěn)定的資源放到距離最終用戶較近的地方,一方面可以節(jié)省整個廣域網(wǎng)的帶寬消耗,另外一方面也可以提升用戶的訪問速度、改善用戶體驗。現(xiàn)實系統(tǒng)中我們一般會把靜態(tài)的文件(圖片、腳本、靜態(tài)頁面等)放到 CDN 中。

一文網(wǎng)羅分布式架構原理和方法

 

 

  1. 當用戶訪問網(wǎng)站頁面上的內(nèi)容 URL,經(jīng)過本地 DNS 系統(tǒng)解析,DNS 系統(tǒng)最終會將域名的解析權交給 CNAME 指向的 CDN 專用 DNS 服務器。
  2. CDN 的 DNS 服務器將 CDN 的全局負載均衡設備 IP 地址返回用戶。
  3. 用戶向 CDN 的全局負載均衡設備發(fā)起內(nèi)容 URL 訪問請求。
  4. CDN全局負載均衡設備根據(jù)用戶IP地址,以及用戶請求的內(nèi)容URL, 選擇一臺用戶所屬區(qū)域的區(qū)域負載均衡設備,告訴用戶向這臺設備發(fā)起請求。
  5. 區(qū)域負載均衡設備會為用戶選擇一臺合適的緩存服務器提供服務。
  6. 選擇的依據(jù)包括 : 根據(jù)用戶 IP 地址,判斷哪一臺服務器距離用戶最近。根據(jù)用戶所請求的 URL 中攜帶的內(nèi)容名稱,判斷哪一臺服務器上有用戶所需內(nèi)容;查詢各個服務器當前的負載情況,判斷哪一臺服務器上有服務能力。基于以上條件的綜合分析之后,區(qū)域負載均衡設備會向全局負載均衡設備返回一臺緩存服務器的 IP 地址。
  7. 局負載均衡設備把服務器的 IP 地址返回給用戶。
  8. 用戶向緩存服務器發(fā)起請求,緩存服務器響應用戶請求,將用戶所需內(nèi)容返回到用戶終端。如果這臺緩存服務器上并沒有用戶想要的內(nèi)容,而區(qū)域均衡設備依然將它分配給了用戶,那么這臺服務器就要向它的上一級緩存服務器請求內(nèi)容,直到追溯到包含該內(nèi)容的源服務器并將內(nèi)容拉到本地。

什么情況下用 CDN?

最適合的是那些不會經(jīng)常變化的內(nèi)容,比如圖片,js 文件, css 文件,圖片文件包括程序模板中CSS 文件中用到的背景圖片,還有就是作為網(wǎng)站內(nèi)容組成部分的那些圖片等等。

灰度發(fā)布

我們的應用即使經(jīng)過了測試部門的測試,也仍然很難全面覆蓋用戶的使用場景,為了保證萬無一失,我們在進行發(fā)布的時候一般都會采用灰度發(fā)布,也就是會對新應用進行分批發(fā)布,逐步擴大新應用在整個及集群中的比例直到最后全部完成。灰度發(fā)布是說針對新應用在用戶體驗方面完全無感知。

灰度發(fā)布系統(tǒng)的作用在于,可以根據(jù)自己的配置,來將用 戶的流量導到新上線的系統(tǒng)上,來快速驗證新的功能, 而一旦出問題,也可以馬上的回滾發(fā)布,簡單的說,就是一套 A/BTest 系統(tǒng).

一文網(wǎng)羅分布式架構原理和方法

 

 

八、總結

通過本文,我們就對主流的SOA架構、微服務架構、服務網(wǎng)格架構做了解析,然后知道了分布式架構中的幾個基本理論,然后還分析了如何設計出高可用的分布式架構,有木有棒棒噠

原文:https://mp.weixin.qq.com/s/oc1ADp5dETDHYN4tdTv8Vw

分享到:
標簽:分布式 架構
用戶無頭像

網(wǎng)友整理

注冊時間:

網(wǎng)站:5 個   小程序:0 個  文章:12 篇

  • 51998

    網(wǎng)站

  • 12

    小程序

  • 1030137

    文章

  • 747

    會員

趕快注冊賬號,推廣您的網(wǎng)站吧!
最新入駐小程序

數(shù)獨大挑戰(zhàn)2018-06-03

數(shù)獨一種數(shù)學游戲,玩家需要根據(jù)9

答題星2018-06-03

您可以通過答題星輕松地創(chuàng)建試卷

全階人生考試2018-06-03

各種考試題,題庫,初中,高中,大學四六

運動步數(shù)有氧達人2018-06-03

記錄運動步數(shù),積累氧氣值。還可偷

每日養(yǎng)生app2018-06-03

每日養(yǎng)生,天天健康

體育訓練成績評定2018-06-03

通用課目體育訓練成績評定