建站
咨詢
售后
建站咨詢
新聞中心
一、前言
成都創(chuàng)新互聯(lián)公司專注于麻城網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供麻城營(yíng)銷型網(wǎng)站建設(shè)，麻城網(wǎng)站制作、麻城網(wǎng)頁設(shè)計(jì)、麻城網(wǎng)站官網(wǎng)定制、成都小程序開發(fā)服務(wù)，打造麻城網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供麻城網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。
本文我們來聊一聊目前主流的分布式架構(gòu)和分布式架構(gòu)中常見理論以及如何才能設(shè)計(jì)出高可用的分布式架構(gòu)好了。分布式架構(gòu)中，SOA和微服務(wù)架構(gòu)是最常見兩種分布式架構(gòu)，而且目前服務(wù)網(wǎng)格的概念也越來越火了。那我們本文就先從這些常見架構(gòu)開始。
二、SOA架構(gòu)解析
SOA 全稱是: Service Oriented Architecture，中文釋義為 “面向服務(wù)的架構(gòu)”，它是一種設(shè)計(jì)理念，其中包含多個(gè)服務(wù)， 服務(wù)之間通過相互依賴最終提供一系列完整的功能。各個(gè)服務(wù)通常以獨(dú)立的形式部署運(yùn)行，服務(wù)之間 通過網(wǎng)絡(luò)進(jìn)行調(diào)用。架構(gòu)圖如下：
跟 SOA 相提并論的還有一個(gè) ESB(企業(yè)服務(wù)總線)，簡(jiǎn)單來說 ESB 就是一根管道，用來連接各個(gè)服務(wù)節(jié)點(diǎn)。ESB的存在是為了集成基于不同協(xié)議的不同服務(wù)，ESB 做了消息的轉(zhuǎn)化、解釋以及路由的工作，以此來讓不同的服務(wù)互聯(lián)互通; 隨著我們業(yè)務(wù)的越來越復(fù)雜，會(huì)發(fā)現(xiàn)服務(wù)越來越多，SOA架構(gòu)下，它們的調(diào)用關(guān)系會(huì)變成如下形式：
很顯然，這樣不是我們所想要的，那這時(shí)候如果我們引入ESB的概念，項(xiàng)目調(diào)用就又會(huì)很清晰，如下：
SOA所要解決的核心問題
- 系統(tǒng)間的集成 : 我們站在系統(tǒng)的角度來看，首先要解決各個(gè)系統(tǒng)間的通信問題，目的是將原先系統(tǒng)間散亂、無規(guī)劃的網(wǎng)狀結(jié)構(gòu)，梳理成規(guī)整、可治理的星形結(jié)構(gòu)，這步的實(shí)現(xiàn)往往需要引入一些概念和規(guī)范，比如 ESB、以及技術(shù)規(guī)范、服務(wù)管理規(guī)范; 這一步解決的核心問題是【有序】。
- 系統(tǒng)的服務(wù)化 : 我們站在功能的角度，需要把業(yè)務(wù)邏輯抽象成可復(fù)用、可組裝的服務(wù)，從而通過服務(wù)的編排實(shí)現(xiàn)業(yè)務(wù)的快速再生，目的是要把原先固有的業(yè)務(wù)功能抽象設(shè)計(jì)為通用的業(yè)務(wù)服務(wù)、實(shí)現(xiàn)業(yè)務(wù)邏輯的快速?gòu)?fù)用;這步要解決的核心問題是【復(fù)用】。
- 業(yè)務(wù)的服務(wù)化 : 我們站在企業(yè)的角度，要把企業(yè)職能抽象成可復(fù)用、可組裝的服務(wù)，就要把原先職能化的企業(yè)架構(gòu)轉(zhuǎn)變?yōu)榉?wù)化的企業(yè)架構(gòu)，以便進(jìn)一步提升企業(yè)的對(duì)外服務(wù)的能力?！扒懊鎯刹蕉际菑募夹g(shù)層面來解決系統(tǒng)調(diào)用、系統(tǒng)功能復(fù)用的問題”。而本步驟，則是以業(yè)務(wù)驅(qū)動(dòng)把一個(gè)業(yè)務(wù)單元封裝成一項(xiàng)服務(wù)。要解決的核心問題是 【高效】。
三、微服務(wù)（Microservices）架構(gòu)解析
微服務(wù)架構(gòu)和 SOA 架構(gòu)非常類似,微服務(wù)只是 SOA 的升華，只不過微服務(wù)架構(gòu)強(qiáng)調(diào)的是“業(yè)務(wù)需要徹底的組件化及服務(wù)化”，原單個(gè)業(yè)務(wù)系統(tǒng)會(huì)被拆分為多個(gè)可以獨(dú)立開發(fā)、設(shè)計(jì)、部署運(yùn)行的小應(yīng)用。這些小應(yīng)用間通過服務(wù)化完成交互和集成。 組件表示的就是一個(gè)可以獨(dú)立更換和升級(jí)的單元，就像 PC 中的 CPU、內(nèi)存、顯卡、硬盤一樣，獨(dú)立且可以更換升級(jí)而不影響其他單元。若我們把 PC 中的各個(gè)組件以服務(wù)的方式構(gòu) 建，那么這臺(tái) PC 只需要維護(hù)主板（可以理解為ESB）和一些必要的外部設(shè)備就可以。CPU、內(nèi)存、硬盤等都是以組件方式提供服務(wù)，例如PC 需要調(diào)用 CPU 做計(jì)算處理，只需知道 CPU 這個(gè)組件的地址就可以了。
微服務(wù)的特征
- 通過服務(wù)實(shí)現(xiàn)組件化
- 按業(yè)務(wù)能力來劃分服務(wù)和開發(fā)團(tuán)隊(duì)
- 去中心化
- 基礎(chǔ)設(shè)施自動(dòng)化(devops、自動(dòng)化部署)
四、SOA 和微服務(wù)架構(gòu)的差別
微服務(wù)不再?gòu)?qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線，同時(shí)以 SOA 的思想進(jìn)入到單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部實(shí) 現(xiàn)真正的組件化。
Docker 容器技術(shù)的出現(xiàn)，為微服務(wù)提供了非常便利的條件，比如更小的部署單元，每個(gè)服務(wù)可以通過類似 Spring Boot 或者 Node 等技術(shù)獨(dú)立運(yùn)行。
還有一個(gè)點(diǎn)大家應(yīng)該可以分析出來，SOA 注重的是系統(tǒng)集成，而微服務(wù)關(guān)注的是完全分離。
五、服務(wù)網(wǎng)格（Service Mesh）架構(gòu)解析
17 年年底，非侵入式的 Service Mesh 技術(shù)慢慢走向了成熟。Service Mesh ，中文釋義“服務(wù)網(wǎng)格”，作為服務(wù)間通信的基礎(chǔ)設(shè)施層在系統(tǒng)中存在。如果要用一句話來解釋什么叫 Service Mesh，我們可以將它比作是應(yīng)用程序或者說微服務(wù)間的 TCP/IP層，負(fù)責(zé)服務(wù)間的網(wǎng)絡(luò)調(diào)用、熔斷、限流和監(jiān)控。我們都知道在編寫應(yīng)用程序時(shí)程序猿一般都無須關(guān)心 TCP/IP 這一層（比如提供 HTTP 協(xié)議的 Restful 應(yīng)用），同樣如果使用服務(wù)網(wǎng)格我們也就不需要關(guān)系服務(wù)間的那些原來是由應(yīng)用程序或者其他框架實(shí)現(xiàn)的事情(熔斷、限流、監(jiān)控等)，現(xiàn)在只要交給 Service Mesh 就可以了。服務(wù)網(wǎng)格架構(gòu)圖如下：
目前流行的 Service Mesh 開源軟件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（開源 Linkerd 的公司）又發(fā)布了基于 Kubernetes 的 Service Mesh 開源項(xiàng)目 Conduit。
關(guān)于微服務(wù)和服務(wù)網(wǎng)格的區(qū)別，我這樣理解：微服務(wù)更注重服務(wù)之間的生態(tài)，專注于服務(wù)治理等方面，而服務(wù)網(wǎng)格更專注于服務(wù)之間的通信，以及和 DevOps 更好的結(jié)合等。
服務(wù)網(wǎng)格的特征
- 應(yīng)用程序間通訊的中間層
- 輕量級(jí)網(wǎng)絡(luò)代理
- 應(yīng)用程序無感知
- 解耦應(yīng)用程序的重試/超時(shí)、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)
六、分布式架構(gòu)的基本理論
在說 CAP、BASE 理論之前，我們先要了解下分布式一致性的問題。 實(shí)際上對(duì)于不同業(yè)務(wù)的服務(wù)，我們對(duì)數(shù)據(jù)一致性的要求是不一樣的，如 12306，它要求數(shù)據(jù)的嚴(yán)格一致性， 不能把票賣給用戶以后卻發(fā)現(xiàn)沒有座位了;再比如銀行轉(zhuǎn)賬， 我們通過銀行轉(zhuǎn)賬的時(shí)候，一般都會(huì)收到一個(gè)提示 : 轉(zhuǎn)賬申請(qǐng)將會(huì)在 24 小時(shí)內(nèi)到賬。實(shí)際上這個(gè)場(chǎng)景滿足的是最終錢只要轉(zhuǎn)賬成功了即可，同時(shí)如果錢沒匯出去還要保證資金不丟失。所以說，用戶在使用不同的服務(wù)的時(shí)候?qū)?shù)據(jù)一致性的要求是不一樣的。
關(guān)于分布式一致性問題
分布式系統(tǒng)中要解決的一個(gè)非常重要的問題就是數(shù)據(jù)的復(fù)制。 在我們的日常開發(fā)經(jīng)驗(yàn)中，相信大多數(shù)開發(fā)人員都遇過這樣的問題 : 在做數(shù)據(jù)庫(kù)讀寫分離的場(chǎng)景中，假設(shè)客戶端 A 將系統(tǒng)中的一個(gè)值 V 由 V1 變更為 V2，但客戶端 B 無法立即讀取到 V 的最新值，e而需要在一段時(shí)間之后才能讀取到。這再正常不過了，因?yàn)閿?shù)據(jù)庫(kù)復(fù)制之間存是在延時(shí)的。
所謂分布式一致性的問題，就是指在分布式環(huán)境中引入數(shù)據(jù)復(fù)制機(jī)制后，不同數(shù)據(jù)節(jié)點(diǎn)之間可能會(huì)出現(xiàn)的、且無法依靠計(jì)算機(jī)應(yīng)用程序自身解決的數(shù)據(jù)不一致的情況。簡(jiǎn)單來說， 數(shù)據(jù)一致性就是指在對(duì)一個(gè)副本數(shù)據(jù)進(jìn)行變更的時(shí)候，必須確保也能夠更新其它的副本，否則不同副本之間的數(shù)據(jù)將出現(xiàn)不一致。 那么如何去解決這個(gè)問題呢？按照正常的思路，我們可能會(huì)想到既然是網(wǎng)絡(luò)延遲導(dǎo)致的問題，那么我們就把同步動(dòng)作進(jìn)行阻塞，用戶 2 在查詢的時(shí)候必須要等數(shù)據(jù)同步完成以后再來做。但這個(gè)方案會(huì)非常影響性能。如果同步的數(shù)據(jù)比較多或比較頻繁，那么阻塞操作可能會(huì)導(dǎo)致整個(gè)新系統(tǒng)不可用。故我們沒有辦法找到一種既能夠滿足數(shù)據(jù)一致性、 又不影響系統(tǒng)性能的方案，所以就誕生了一個(gè)一致性的級(jí)別:
- 強(qiáng)一致性 : 這種一致性級(jí)別是最符合用戶直覺的，它要求系統(tǒng)寫入的是什么，讀出來的也要是什么，用戶體驗(yàn)好，但實(shí)現(xiàn)起來往往對(duì)系統(tǒng)的性能影響較大。
- 弱一致性 : 這種一致性級(jí)別約束了系統(tǒng)在寫入成功后， 不保證立即可以讀到寫入的值，也不保證多久之后數(shù)據(jù) 能夠達(dá)到一致，但會(huì)盡可能地保證到某個(gè)時(shí)間級(jí)別(如秒級(jí)別)后，數(shù)據(jù)能夠達(dá)到一致狀態(tài)。
- 最終一致性 : 最終一致性其實(shí)是弱一致性的一個(gè)特例，系統(tǒng)會(huì)保證在一定時(shí)間內(nèi)，能夠達(dá)到數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨(dú)提出來，是因?yàn)樗侨跻恢滦灾蟹浅Ｍ瞥绲囊环N一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上用的比較多的一致性模型。
CAP 理論
它是一個(gè)經(jīng)典的分布式系統(tǒng)理論。CAP 理論告訴我們 : 一個(gè)分布式系統(tǒng)不可能同時(shí)滿足一致性(C:Consistency)、可用性(A:Availability)及分區(qū)容錯(cuò)性(P:Partition tolerance) 這三個(gè)基本要求，最多只能同時(shí)滿足其中兩項(xiàng)。CAP 理論在互聯(lián)網(wǎng)界有著廣泛的知名度，也被稱為“帽子理論”，它是 由 Eric Brewer 教授在 2000 年舉行的 ACM 研討會(huì)提出的 一個(gè)著名猜想: 一致性(Consistency)、可用性(Availability)、分區(qū)容錯(cuò) (Partition-tolerance)三者無法在分布式系統(tǒng)中被同時(shí)滿足，并且最多只能滿足兩個(gè)!
- 一致性 : 所有節(jié)點(diǎn)上的數(shù)據(jù)時(shí)刻保持同步
- 可用性 : 每個(gè)請(qǐng)求都能接收一個(gè)響應(yīng)，無論響應(yīng)成功或失敗
- 分區(qū)容錯(cuò) : 系統(tǒng)應(yīng)該持續(xù)提供服務(wù)，即使系統(tǒng)內(nèi)部(某個(gè)節(jié)點(diǎn)分區(qū))有消息丟失。比如交換機(jī)失敗、網(wǎng)址網(wǎng)絡(luò)被分成幾個(gè)子網(wǎng)，形成腦裂、服務(wù)器發(fā)生網(wǎng)絡(luò)延遲或死機(jī)，導(dǎo)致某些 server 與集群中的其他機(jī)器失去聯(lián)系。
分區(qū)是導(dǎo)致分布式系統(tǒng)可靠性問題的固有特性，從本質(zhì)上來看，CAP 理論的準(zhǔn)確描述不應(yīng)該是從 3 個(gè)特性中選取兩個(gè)，所以我們只能被迫適應(yīng)，根本沒有選擇權(quán)。CAP 并不是一個(gè)普適性原理和指導(dǎo)思想，它僅適用于原子讀寫的 NOSQL 場(chǎng)景中，并不適用于數(shù)據(jù)庫(kù)系統(tǒng)。
BASE 理論
從前面的分析中我們知道 : 在分布式(數(shù)據(jù)庫(kù)分片或分庫(kù)存在的多個(gè)實(shí)例上)前提下，CAP 理論并不適合數(shù)據(jù)庫(kù)事務(wù)(因?yàn)楦乱恍╁e(cuò)誤的數(shù)據(jù)而導(dǎo)致的失敗，無論使用什么高可用方案都是徒勞的，因?yàn)閿?shù)據(jù)發(fā)生了無法修正的錯(cuò)誤)。 此外 XA 事務(wù)雖然保證了數(shù)據(jù)庫(kù)在分布式系統(tǒng)下的 ACID (原子性、一致性、隔離性、持久性)特性，但同時(shí)也帶來了一 些性能方面的代價(jià)，對(duì)于并發(fā)和響應(yīng)時(shí)間要求都比較高的電商平臺(tái)來說，是很難接受的。
eBay 嘗試了另外一條完全不同的路，放寬了數(shù)據(jù)庫(kù)事務(wù)的 ACID 要求，提出了一套名為 BASE 的新準(zhǔn)則。BASE 全稱為 Basically Available,Soft-state,Eventually Consistent. 系統(tǒng)基本可用、軟狀態(tài)、數(shù)據(jù)最終一致性。相對(duì)于 CAP 來說，它大大降低了我們對(duì)系統(tǒng)的要求。
Basically Available(基本可用)
表示在分布式系統(tǒng)出現(xiàn)不可預(yù) 知的故障時(shí)，允許瞬時(shí)部分可用性
- 比如我們?cè)谔詫毶纤阉魃唐?，正常情況下是在 0.5s 內(nèi)返回查詢結(jié)果，但是由于后端的系統(tǒng)故障導(dǎo)致查詢響應(yīng)時(shí)間變成了 2s
- 再比如數(shù)據(jù)庫(kù)采用分片模式，100W 個(gè)用戶數(shù)據(jù)分在 5 個(gè)數(shù)據(jù)庫(kù)實(shí)例上，如果破壞了一個(gè)實(shí)例，那么可用性還 有 80%，也就是 80%的用戶都可以登錄，系統(tǒng)仍然可用
- 電商大促時(shí)，為了應(yīng)對(duì)訪問量激增，部分用戶可能會(huì)被 引導(dǎo)到降級(jí)頁面，服務(wù)層也可能只提供降級(jí)服務(wù)。這就 是損失部分可用性的體現(xiàn)
Soft-state(軟狀態(tài)).
表示系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并 且這個(gè)中間狀態(tài)的存在不會(huì)影響系統(tǒng)的整體可用性，也就 是表示系統(tǒng)允許在不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步 過程中存在延時(shí); 比如訂單狀態(tài)，有一個(gè)待支付、支付中、 支付成功、支付失敗， 那么支付中就是一個(gè)中間狀態(tài)，這 個(gè)中間狀態(tài)在支付成功以后，在支付表中的狀態(tài)同步給訂 單狀態(tài)之前，中間會(huì)存在一個(gè)時(shí)間內(nèi)的不一致。
Eventually consistent(數(shù)據(jù)的最終一致性)
表示的是所有 數(shù)據(jù)副本在一段時(shí)間的同步后最終都能達(dá)到一個(gè)一致的狀 態(tài)，因此最終一致性的本質(zhì)是要保證數(shù)據(jù)最終達(dá)到一致， 而不需要實(shí)時(shí)保證系統(tǒng)數(shù)據(jù)的強(qiáng)一致
BASE 理論的核心思想是 : 即使無法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性。
七、分布式架構(gòu)下的高可用設(shè)計(jì)
避免單點(diǎn)故障
- 負(fù)載均衡技術(shù)(failover/選址/硬件負(fù)載/ 軟件負(fù)載/去中心化的軟件負(fù)載(gossip(redis- cluster)))
- 熱備(linux HA)
- 多機(jī)房(同城災(zāi)備、異地災(zāi)備)
應(yīng)用的高可用性
- 故障監(jiān)控(系統(tǒng)監(jiān)控(cpu、內(nèi)存)/鏈路監(jiān)控/日志監(jiān) 控) 自動(dòng)預(yù)警
- 應(yīng)用的容錯(cuò)設(shè)計(jì)、(服務(wù)降級(jí)、限流)自我保護(hù)能力
- 數(shù)據(jù)量(數(shù)據(jù)分片、讀寫分離)
分布式架構(gòu)下的可伸縮設(shè)計(jì)
- 垂直伸縮
- 提升硬件能力
- 水平伸縮
- 增加服務(wù)器
加速靜態(tài)內(nèi)容訪問速度的 cdn
CDN 全稱是 Content Delivery Network，中文釋義是內(nèi)容分發(fā)網(wǎng)絡(luò)。CDN 的作用是把用戶需要的內(nèi)容分發(fā)到離用戶最近的地方進(jìn)行響應(yīng)，這樣用戶能夠快速獲取所需要的內(nèi)容。 CDN 本質(zhì)上就是一種網(wǎng)絡(luò)緩存技術(shù)，能夠把一些相對(duì)穩(wěn)定的資源放到距離最終用戶較近的地方，一方面可以節(jié)省整個(gè)廣域網(wǎng)的帶寬消耗，另外一方面也可以提升用戶的訪問速度、改善用戶體驗(yàn)?，F(xiàn)實(shí)系統(tǒng)中我們一般會(huì)把靜態(tài)的文件(圖片、腳本、靜態(tài)頁面等)放到 CDN 中。
- 當(dāng)用戶訪問網(wǎng)站頁面上的內(nèi)容 URL，經(jīng)過本地 DNS 系統(tǒng)解析，DNS 系統(tǒng)最終會(huì)將域名的解析權(quán)交給 CNAME 指向的 CDN 專用 DNS 服務(wù)器。
- CDN 的 DNS 服務(wù)器將 CDN 的全局負(fù)載均衡設(shè)備 IP 地址返回用戶。
- 用戶向 CDN 的全局負(fù)載均衡設(shè)備發(fā)起內(nèi)容 URL 訪問請(qǐng)求。
- CDN全局負(fù)載均衡設(shè)備根據(jù)用戶IP地址，以及用戶請(qǐng)求的內(nèi)容URL， 選擇一臺(tái)用戶所屬區(qū)域的區(qū)域負(fù)載均衡設(shè)備，告訴用戶向這臺(tái)設(shè)備發(fā)起請(qǐng)求。
- 區(qū)域負(fù)載均衡設(shè)備會(huì)為用戶選擇一臺(tái)合適的緩存服務(wù)器提供服務(wù)。
- 選擇的依據(jù)包括 : 根據(jù)用戶 IP 地址，判斷哪一臺(tái)服務(wù)器距離用戶最近。根據(jù)用戶所請(qǐng)求的 URL 中攜帶的內(nèi)容名稱，判斷哪一臺(tái)服務(wù)器上有用戶所需內(nèi)容;查詢各個(gè)服務(wù)器當(dāng)前的負(fù)載情況，判斷哪一臺(tái)服務(wù)器上有服務(wù)能力?；谝陨蠗l件的綜合分析之后，區(qū)域負(fù)載均衡設(shè)備會(huì)向全局負(fù)載均衡設(shè)備返回一臺(tái)緩存服務(wù)器的 IP 地址。
- 局負(fù)載均衡設(shè)備把服務(wù)器的 IP 地址返回給用戶。
- 用戶向緩存服務(wù)器發(fā)起請(qǐng)求，緩存服務(wù)器響應(yīng)用戶請(qǐng)求，將用戶所需內(nèi)容返回到用戶終端。如果這臺(tái)緩存服務(wù)器上并沒有用戶想要的內(nèi)容，而區(qū)域均衡設(shè)備依然將它分配給了用戶，那么這臺(tái)服務(wù)器就要向它的上一級(jí)緩存服務(wù)器請(qǐng)求內(nèi)容，直到追溯到包含該內(nèi)容的源服務(wù)器并將內(nèi)容拉到本地。
什么情況下用 CDN？
最適合的是那些不會(huì)經(jīng)常變化的內(nèi)容，比如圖片，js 文件， CSS 文件，圖片文件包括程序模板中CSS 文件中用到的背景圖片，還有就是作為網(wǎng)站內(nèi)容組成部分的那些圖片等等。
灰度發(fā)布
我們的應(yīng)用即使經(jīng)過了測(cè)試部門的測(cè)試，也仍然很難全面覆蓋用戶的使用場(chǎng)景，為了保證萬無一失，我們?cè)谶M(jìn)行發(fā)布的時(shí)候一般都會(huì)采用灰度發(fā)布，也就是會(huì)對(duì)新應(yīng)用進(jìn)行分批發(fā)布，逐步擴(kuò)大新應(yīng)用在整個(gè)及集群中的比例直到最后全部完成?；叶劝l(fā)布是說針對(duì)新應(yīng)用在用戶體驗(yàn)方面完全無感知。
灰度發(fā)布系統(tǒng)的作用在于，可以根據(jù)自己的配置，來將用 戶的流量導(dǎo)到新上線的系統(tǒng)上，來快速驗(yàn)證新的功能， 而一旦出問題，也可以馬上的回滾發(fā)布，簡(jiǎn)單的說，就是一套 A/BTest 系統(tǒng).
八、總結(jié)
通過本文，我們就對(duì)主流的SOA架構(gòu)、微服務(wù)架構(gòu)、服務(wù)網(wǎng)格架構(gòu)做了解析，然后知道了分布式架構(gòu)中的幾個(gè)基本理論，然后還分析了如何設(shè)計(jì)出高可用的分布式架構(gòu)，有木有棒棒噠！
福利：在此我向大家推薦一個(gè)Java架構(gòu)群 ：725633148 里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：（有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化、分布式架構(gòu)）等這些成為架構(gòu)師必備的知識(shí)體系 進(jìn)群馬上免費(fèi)領(lǐng)取，目前受益良多！
網(wǎng)頁名稱：主流分布式架構(gòu)的風(fēng)流韻事
標(biāo)題鏈接：http://www.dlmjj.cn/article/piiojs.html
