Valentine 轉(zhuǎn)載請標(biāo)明出處。
主流架構(gòu)模型-SOA架構(gòu)和微服務(wù)架構(gòu)
SOA全稱（Service Oriented Architecture），中文意思為“面向服務(wù)的架構(gòu)”，它是一種設(shè)計方法，其中包含多個服務(wù)，服務(wù)之間通過相互依賴最終提供一系列的功能。一個服務(wù)通常以獨立的形式存在與操作系統(tǒng)進(jìn)程中，各個服務(wù)之間通過網(wǎng)絡(luò)調(diào)用。
還有一個ESB（企業(yè)服務(wù)總線），簡單來說ESB就是一根管道，用來連接各個服務(wù)節(jié)點。為了集成不同系統(tǒng)，不同協(xié)議的服務(wù)，ESB做了消息的轉(zhuǎn)化解釋和路由工作，讓不同的服務(wù)互聯(lián)互通。
SOA所解決的核心問題
1、系統(tǒng)繼承：站在系統(tǒng)的角度，解決企業(yè)系統(tǒng)間的通信問題，把原先散亂、五規(guī)劃的系統(tǒng)間的網(wǎng)狀結(jié)構(gòu)，梳理成規(guī)整、可治理的系統(tǒng)，這一步往往需要引入一些產(chǎn)品，比如ESB、技術(shù)規(guī)范、服務(wù)管理規(guī)范，這一步解決的核心問題是有序；
2、系統(tǒng)的服務(wù)化：站在功能的角度，把業(yè)務(wù)邏輯抽象成可復(fù)用、可組裝的服務(wù)，通過服務(wù)的編排實現(xiàn)業(yè)務(wù)的快速再生，目的：把原先固有的業(yè)務(wù)功能轉(zhuǎn)變?yōu)橥ㄓ玫臉I(yè)務(wù)服務(wù)，實現(xiàn)業(yè)務(wù)邏輯的快速復(fù)用，這一步解決的核心問題是復(fù)用；
3、業(yè)務(wù)的服務(wù)化：站在企業(yè)的角度，把企業(yè)職能抽象成可復(fù)用、可組裝的服務(wù)，把原先職能化的企業(yè)架構(gòu)轉(zhuǎn)變?yōu)榉?wù)化的企業(yè)架構(gòu)，進(jìn)一步提升企業(yè)的對外服務(wù)能力，前面兩步都是從技術(shù)層面來解決系統(tǒng)調(diào)用、系統(tǒng)功能復(fù)用的問題，第三步則是以業(yè)務(wù)驅(qū)動把一個業(yè)務(wù)單元封裝成一項服務(wù)，這一步解決的核心問題是高效。
微服務(wù)架構(gòu)
微服務(wù)架構(gòu)其實和SOA架構(gòu)類似，微服務(wù)是在SOA上做的升華，微服務(wù)架構(gòu)強(qiáng)調(diào)的一個重點是“業(yè)務(wù)需要徹底地組件化和服務(wù)化”，原有的單個業(yè)務(wù)系統(tǒng)會拆分為多個可以獨立開發(fā)、設(shè)計、運行的小應(yīng)用，這些小應(yīng)用之間通過服務(wù)完成交互和集成。
組件表示一個可以獨立更換和升級的單元，就像PC中的CPU、內(nèi)存、顯卡、硬盤一樣，獨立且可以更換升級而不影響其他單元。如果把PC作為組件以服務(wù)的方式構(gòu)建，那么這臺PC只需要維護(hù)主板和一些必要的外部設(shè)備。CPU、內(nèi)存、硬盤都是以組件方式提供服務(wù)，PC需要調(diào)用CPU做計算處理，只需要知道CPU這個組件的地址即可。
微服務(wù)的特征
1、通過服務(wù)實現(xiàn)組件化
2、按業(yè)務(wù)能力來劃分服務(wù)和開發(fā)團(tuán)隊
3、去中心化
4、基礎(chǔ)設(shè)施自動化（devops、自動化部署）
SOA和微服務(wù)架構(gòu)的差別
1、微服務(wù)不在強(qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線，同時SOA的思想進(jìn)入到單個業(yè)務(wù)系統(tǒng)內(nèi)部實現(xiàn)真正的組件化；
2、Docker容器技術(shù)的出現(xiàn)，為服務(wù)提供了更便利的條件，比如更小的部署單元，每個服務(wù)可以通過類似Node或者Spring Boot等技術(shù)跑在自己的進(jìn)程中；
3、SOA注重的是系統(tǒng)集成方面，而微服務(wù)關(guān)注的是完全分離。
領(lǐng)域驅(qū)動設(shè)計及業(yè)務(wù)驅(qū)動劃分
領(lǐng)域驅(qū)動設(shè)計的概念
領(lǐng)域驅(qū)動設(shè)計（DDD，Domain-Driven Design），軟件開發(fā)不是一蹴而就的事情，我們不可能在不了解產(chǎn)品（或行業(yè)領(lǐng)域）的前提下進(jìn)行軟件開發(fā)，在開發(fā)前，通常需要進(jìn)行大量的業(yè)務(wù)只是梳理，然后才到軟件設(shè)計的層面，最后才是開發(fā)，而在業(yè)務(wù)只是梳理的過程中，我們必然會形成某個領(lǐng)域只是，根據(jù)領(lǐng)域只是來一步步驅(qū)動軟件設(shè)計，就是領(lǐng)域驅(qū)動設(shè)計的基本概念。
為什么需要DDD
業(yè)務(wù)初期工，功能大都非常簡單，普通的CRUD就能滿足，此時系統(tǒng)是清晰的，隨著產(chǎn)品不斷迭代和演化，業(yè)務(wù)邏輯變得越來越復(fù)雜，我們的系統(tǒng)也越來越冗雜，各個模塊之間彼此關(guān)聯(lián)，甚至到后期連作者都很難說清模塊的具體功能意圖是啥，導(dǎo)致在修改一個功能時，要追溯到這個功能需要的修改點就要很長時間，更別提修改帶來的不可預(yù)知的影響面。
比如說訂單服務(wù)接口中提供查詢、創(chuàng)建訂單相關(guān)的接口，也提供了訂單評價、支付的接口。同時訂單表是個大表，包含了非常多字段，在我們維護(hù)代碼的時候，將會導(dǎo)致牽一發(fā)動全身，很可能只是想改下評價相關(guān)的功能，卻影響到創(chuàng)建訂單的核心路徑，雖然我們可以通過測試來保證功能完備性，但當(dāng)我們在訂單領(lǐng)域有大量需求同時并行開發(fā)，改動重疊，惡性循環(huán)，疲于奔命修改各種問題。
絕大部分公司都是這樣一個狀態(tài)，然后一般的解決方案就是不斷地重構(gòu)系統(tǒng)，讓系統(tǒng)的設(shè)計隨著業(yè)務(wù)成長也進(jìn)行不斷的演進(jìn)。通過重構(gòu)出一些獨立的類來存放某些通用的邏輯解決混亂問題，但是我們很難給它一個業(yè)務(wù)上的含義，只能以技術(shù)維度進(jìn)行描述，這個帶來的問題就是其他人接手這塊代碼的時候不知道這個的含義或者可以通過修改這塊通用邏輯來達(dá)到某些需求。
領(lǐng)域模型追本溯源
領(lǐng)域模型本身就不是一個陌生的單詞，說直白點，在早期領(lǐng)域模型就是數(shù)據(jù)庫設(shè)計，我們做傳統(tǒng)項目的流程或者說包括現(xiàn)在我們做項目的流程，都是先討論需求，然后是數(shù)據(jù)庫建模，在需求逐步確定的過程不斷地去更新數(shù)據(jù)庫設(shè)計，接著我們在項目開發(fā)階段，發(fā)現(xiàn)有些關(guān)系沒有建、有些字段少了、有些結(jié)構(gòu)設(shè)計不合理，又在不斷地去調(diào)整設(shè)計，最后上線。在傳統(tǒng)項目中，數(shù)據(jù)庫是整個項目的根本，數(shù)據(jù)模型出來以后后續(xù)的開發(fā)都是圍繞著數(shù)據(jù)展開，然后形成這樣的一個架構(gòu)view、controllers、service、dao(pojo)。
1、service很重，所有邏輯處理基本都放在service層；
2、POJO作為service層的非常重要的一個實體，會因為不同場景的需求做不同的變化和組合，就會造成POJO的幾種不同模型（失血、貧血、充血），用來形容領(lǐng)域模型太胖或者太瘦；
隨著業(yè)務(wù)變得復(fù)雜以后，包括數(shù)據(jù)結(jié)構(gòu)的變化，那么各個模塊就需要進(jìn)行修改，原本清晰的系統(tǒng)經(jīng)過不斷的演化變得復(fù)雜、冗余、耦合度高，后果非常嚴(yán)重。
我們是想一下如果一個軟件產(chǎn)品不依賴數(shù)據(jù)庫存儲設(shè)備，那我么怎么去設(shè)計這個軟件呢？如果沒有了數(shù)據(jù)存儲，那么我們的領(lǐng)域模型就得基于程序本身來設(shè)計，那這個就是DDD需要去考慮的問題。
以抽獎設(shè)計為例
DDD理解起來有點抽象，這個有點像設(shè)計模式，感覺很有用，但是不知道怎么應(yīng)用到自己寫的代碼里面，或者生搬硬套起來又很別扭，那么接下來以一個簡單的轉(zhuǎn)盤抽獎案例來分析一下DDD的應(yīng)用。
針對功能層面劃分邊界
這個系統(tǒng)可以劃分為運營管理平臺和用戶使用層，運營平臺對于抽獎的配置比較復(fù)雜但是操作頻率會比較低，而用戶對抽獎活動頁面的使用是高頻率的但是對于配置規(guī)則來說是無感知的。根據(jù)這樣的特點，我們把抽獎平臺劃分針對C端抽獎和M端抽獎兩個子域，在確認(rèn)了M端領(lǐng)域和C端的界限上下文后，我們再對各自上下文內(nèi)容進(jìn)行界限上下文的劃分，接下來以C端用戶為例來劃分界限上下文。
確認(rèn)基本需求
首先我們要來了解該產(chǎn)品的基本需求
1、抽獎資格（什么情況下會有抽獎機(jī)會、抽獎次數(shù)、抽獎的活動起始時間）
2、抽獎的獎品（實物、優(yōu)惠券、理財金、購物卡...）
3、獎品自身的配置，概率、庫存、某些獎品在有限的概率下還只能被限制抽到多少次等
4、風(fēng)控對接，防止惡意薅羊毛
針對產(chǎn)品功能劃分邊界
抽獎上下文是整個領(lǐng)域的核心，負(fù)責(zé)處理用戶抽獎的核心業(yè)務(wù)。
1、對于活動的限制，我們定義了活動資格的通用語言，將活動開始/結(jié)束時間，活動可參與次數(shù)等限制條件都收攏到活動資格子域中。
2、由于C端存在一些刷單行為，我們根據(jù)產(chǎn)品需求定義了風(fēng)控上下文，用戶對活動進(jìn)行風(fēng)控。
3、由于抽獎和發(fā)獎品其實可以認(rèn)為是兩個領(lǐng)域，一個負(fù)責(zé)根據(jù)概率去抽獎、另一個負(fù)責(zé)將選中的獎品發(fā)放出去，所以對于這一塊也獨立出來一個領(lǐng)域。
細(xì)化上下文
通過上下文劃分以后，我們還需要進(jìn)一步梳理上下文之間的關(guān)系，梳理的好處在于：
1、任務(wù)更好拆分（一個開發(fā)人員可以全身心投入到相關(guān)子域的上下文中）；
2、方便溝通，明確自身上下文和其他上下文之間的依賴關(guān)系，可以實現(xiàn)更好的對接，然后是基于上下文的更進(jìn)一步細(xì)化建模，在DDD中存在一些名字定義；
實體
當(dāng)一個對象由其標(biāo)識（而不是屬性）區(qū)分時，這種對象稱為實體（Entity）。
值對象
當(dāng)一個對象用于對事物進(jìn)行描述而沒有唯一標(biāo)識時，它被稱作為值對象。
聚合根
聚合根屬于實體對象，它是領(lǐng)域?qū)ο笾幸粋€高度內(nèi)聚的核心對象。（聚合根具有全局的唯一標(biāo)識，而實體只有在聚合內(nèi)部有唯一的本地標(biāo)識，值對象沒有唯一標(biāo)識，不存在這個值對象或者那個值對象的說法）。
領(lǐng)域服務(wù)
一些重要的領(lǐng)域行為或操作，可以歸類為領(lǐng)域服務(wù)。它實現(xiàn)了全部業(yè)務(wù)邏輯并且通過各種校驗手段保證業(yè)務(wù)的正確性。
資源庫
資源封裝了基礎(chǔ)設(shè)施來提供查詢和持久化聚合操作，這樣能夠讓我們始終關(guān)注在模型層面，把對象的存儲和訪問都委托給資源庫來完成。它不是數(shù)據(jù)庫的封裝，而是領(lǐng)域?qū)优c基礎(chǔ)設(shè)施之間的橋梁，DDD關(guān)心的是領(lǐng)域內(nèi)的模型，而不是數(shù)據(jù)庫的操作。
代碼設(shè)計
在實際開發(fā)中，我們一般會采用模塊來表示一個領(lǐng)域的界限上下文，比如
com.gupaoedu.michael.bussiness.lottery.;//抽獎上下文
com.gupaoedu.michael.bussiness.riskcontrol.;// 風(fēng)控上下文
com.gupaoedu.michael.bussiness.prize.;//獎品上下文
com.gupaoedu.michael.bussiness.qualification.;// 活動資格上下文
com.gupaoedu.michael.bussiness.stock.;//庫存上下文
對于模塊內(nèi)的組織結(jié)構(gòu)，一般情況下我們是按照領(lǐng)域?qū)ο?、領(lǐng)域服務(wù)、領(lǐng)域資源庫等組織方式定義的。
com.gupaoedu.michael.bussiness.lottery.domain.valobj.;//領(lǐng)域?qū)ο?值對象
com.gupaoedu.michael.bussiness.lottery.domain.entity.;//領(lǐng)域?qū)ο?實體
com.gupaoedu.michael.bussiness.lottery.domain.aggregate.;//領(lǐng)域?qū)ο?聚合根
com.gupaoedu.michael.bussiness.lottery.service.;//領(lǐng)域服務(wù)
com.gupaoedu.michael.bussiness.lottery.repo.;//領(lǐng)域資源庫
領(lǐng)域驅(qū)動的好處
用DDD可以很好地解決領(lǐng)域模型到設(shè)計模型的同步、演進(jìn)最后映射到實際的代碼邏輯。
總的來說，DDD有幾個好處
1、DDD能夠讓我們知道如何抽象出界限上下文以及如何去分而治之，
分而治之：把復(fù)雜的大規(guī)模軟件拆分成若干個子模塊，每一個模塊都能獨立運行和解決相關(guān)問題，并且分割后各個部分可以組裝成一個整體。
抽象：使用抽象能夠精簡問題空間，而且問題越小越容易理解，比如說我們要對接支付，我們抽象的維度應(yīng)該是支付，而不是具體的微信支付還是支付寶支付。
2、DDD的界限上下文可以完美匹配微服務(wù)的要求，在系統(tǒng)復(fù)雜之后，我們都需要用分治來拆解問題，一般有兩種方式，技術(shù)維度和業(yè)務(wù)維度，技術(shù)維度是類似MVC這樣，業(yè)務(wù)維度則是按業(yè)務(wù)領(lǐng)域來劃分系統(tǒng)，微服務(wù)架構(gòu)更強(qiáng)調(diào)從業(yè)務(wù)維度去做分治來應(yīng)對系統(tǒng)復(fù)雜度，而DDD也是同樣的著重業(yè)務(wù)視角。
總結(jié)
領(lǐng)域驅(qū)動設(shè)計其實可以簡單認(rèn)為是一種指導(dǎo)思想，是一種軟件開發(fā)方法，通過DDD可以將系統(tǒng)設(shè)計更加合理，最終滿足高內(nèi)聚低耦合的本質(zhì)。有點類似數(shù)據(jù)庫的三范式，我們開始在學(xué)的時候并不太理解，當(dāng)有足夠的設(shè)計經(jīng)驗以后慢慢發(fā)現(xiàn)三范式帶來的好處，同時我們也并不一定需要嚴(yán)格按照這三范式去進(jìn)行實踐，有些情況下是可以靈活調(diào)整的。
分布式架構(gòu)的基本理論CAP、BASE以及應(yīng)用
說CAP、BASE理論之前，先要了解一下分布式一致性的這個問題，實際上，對于不同業(yè)務(wù)產(chǎn)品，我們對數(shù)據(jù)一致性的要求是不一樣的，比如12306，他們要求的是數(shù)據(jù)的嚴(yán)格一致性，不能說把票賣給用戶以后發(fā)現(xiàn)沒有座位了，比如銀行轉(zhuǎn)賬，通過銀行轉(zhuǎn)賬的時候，一般會收到一個提示，轉(zhuǎn)賬申請將會在24小時之內(nèi)到賬，實際上這個場景滿足的是最終錢只要匯出去即可，同時以及如果錢沒匯出去要保證資金不丟失就行，所以說，用戶在使用不同的產(chǎn)品的時候，對數(shù)據(jù)一致性的要求是不一樣的。
關(guān)于分布式一致性的問題
在分布式系統(tǒng)中要解決的一個仲要問題就是數(shù)據(jù)的復(fù)制。在我們的日常開發(fā)經(jīng)驗中，相信很多開發(fā)人員都遇到過這樣的問題：在做數(shù)據(jù)庫讀寫分離的場景中，假設(shè)客戶端C1將系統(tǒng)中的一個值K由V1更新為V2，但是客戶端C2無法立刻讀取到K的最新值，需要在一段時間之后才能讀取到，這很正常，因為數(shù)據(jù)庫復(fù)制之間存在延時。
所謂分布式一致性問題，是指在分布式環(huán)境中引入數(shù)據(jù)復(fù)制之后，不同數(shù)據(jù)節(jié)點之間可能出現(xiàn)的，并無法依靠計算機(jī)應(yīng)用程序自身解決的數(shù)據(jù)不一致的情況。簡單講，數(shù)據(jù)一致性就是指在對一個副本數(shù)據(jù)進(jìn)行更新的時候，必須確保也能夠更新其他的副本，否則不同副本之間的數(shù)據(jù)將不一致。
那么如何去解決這個問題？按照正常的思路，我們可能會想，既然是因為網(wǎng)絡(luò)延遲導(dǎo)致的問題，那么我們就可以把同步動作阻塞，用戶2在查詢的時候必須要等到數(shù)據(jù)同步完成以后再來做，但是這個方案帶來的問題是性能會受到非常大的影響，如果同步的數(shù)據(jù)比較多或者比較頻繁，那么因為阻塞操作可能將導(dǎo)致整個系統(tǒng)不可用。
總結(jié)：所以我們沒有辦法找到一種能夠滿足數(shù)據(jù)一致性、又不影響系統(tǒng)運行的方案，所以這就誕生了一個一致性的級別：
1、強(qiáng)一致性：這種一致性級別是最符合用戶直覺的，它要求系統(tǒng)寫入什么，讀出來的也會是什么，用戶體驗好，但是實現(xiàn)起來往往對系統(tǒng)的性能影響大；
2、弱一致性：這種級別約束了系統(tǒng)在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數(shù)據(jù)能夠達(dá)到一致，但盡可能保障某個時間級別（比如秒級別）后，數(shù)據(jù)能夠達(dá)到一致狀態(tài)；
3、最終一致性，最終一致性是若一致性的一個特例，系統(tǒng)會保證在一定時間內(nèi)，能夠達(dá)到一個數(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ù)時刻保持同步；
可用性：每個請求都能接收一個響應(yīng)，無論響應(yīng)成功或失??；
分區(qū)容錯：系統(tǒng)應(yīng)該持續(xù)提供服務(wù)，即時系統(tǒng)內(nèi)部（某個節(jié)點分區(qū)）有消息丟失。比如交換機(jī)失敗、網(wǎng)址網(wǎng)絡(luò)被分成幾個子網(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 個特性中選取兩個，只能是CP或者AP，根本沒有選擇權(quán)；
總結(jié)一下：CAP 并不是一個普適性原理和指導(dǎo)思想，它僅適用于原子讀寫的NoSql 場景中，并不適用于數(shù)據(jù)庫系統(tǒng)。
BASE理論
從前面的分析中知道，在分布式（數(shù)據(jù)庫分片或分開存在的多個實例上）系統(tǒng)下，CAP理論并不適合數(shù)據(jù)庫事務(wù)（因為跟新一些錯誤的數(shù)據(jù)而導(dǎo)致的失敗，無論使用什么樣的高可用方案都是徒勞，因為數(shù)據(jù)發(fā)生了無法修正的錯誤）。此外XA事務(wù)雖然保證了數(shù)據(jù)庫在分布式系統(tǒng)下的ACID（原子性、一致性、隔離性、持久性）特性，但也帶來了一些性能方面的代價，對于并發(fā)和響應(yīng)時間要求比較高的電商平臺來說，是很難接受的。
eBay嘗試了另外一條完全不同的路，放寬了數(shù)據(jù)庫事務(wù)的ACID要求，提出了一套名為BASE的新準(zhǔn)則，全稱是Basically available, soft-state, Eventually Consistent.系統(tǒng)基本可用、軟狀態(tài)、數(shù)據(jù)最終一致性。相對于CAP來說，它大大降低了我們對系統(tǒng)的要求。
Basically available（基本可用），在分布式系統(tǒng)出現(xiàn)不可預(yù)知的故障時，允許瞬時部分可用性。
- 比如我們在淘寶上搜索商品，正常情況下是在0.5s 內(nèi)返回查詢結(jié)果，但是由于后端的系統(tǒng)故障導(dǎo)致查詢響應(yīng)時間變成了2s；
- 再比如數(shù)據(jù)庫采用分片模式，100W 個用戶數(shù)據(jù)分在5個數(shù)據(jù)庫實例上，如果破壞了一個實例，那么可用性還有80%，也就是80%的用戶都可以登錄，系統(tǒng)仍然可用；
- 電商大促時，為了應(yīng)對訪問量激增，部分用戶可能會被引導(dǎo)到降級頁面，服務(wù)層也可能只提供降級服務(wù)。這就是損失部分可用性的體現(xiàn)；
soft-state（軟狀態(tài)） 表示系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并且這個中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，也就是表示系統(tǒng)允許在不同節(jié)點的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步過程中存在延時； 比如訂單狀態(tài)，有一個待支付、支付中、支付成功、支付失敗， 那么支付中就是一個中間狀態(tài)，這個中間狀態(tài)在支付成功以后，在支付表中的狀態(tài)同步給訂單狀態(tài)之前，中間會存在一個時間內(nèi)的不一致。
Eventually consistent（數(shù)據(jù)的最終一致性），表示的是所有數(shù)據(jù)副本在一段時間的同步后最終都能達(dá)到一個一直的狀態(tài)，因此最終一致性的本質(zhì)是要保證數(shù)據(jù)最終達(dá)到一直，而不需要實時保證系統(tǒng)數(shù)據(jù)的強(qiáng)一致。
BASE 理論的核心思想是：即使無法做到強(qiáng)一致性，但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性。
什么是分布式架構(gòu)下的高可用設(shè)計
1、避免單點故障
a）負(fù)載均衡技術(shù)（failover/選址/硬件負(fù)載/軟件負(fù)載/去中心化的軟件負(fù)載（gossip（redis-cluster）））
b）熱備（linux HA）
c）多機(jī)房（同城災(zāi)備、異地災(zāi)備）
2、應(yīng)用的高可用性
a）故障監(jiān)控（系統(tǒng)監(jiān)控（cpu、內(nèi)存）/鏈路監(jiān)控/日志監(jiān)控）自動預(yù)警
b）應(yīng)用的容錯設(shè)計、（服務(wù)降級、限流）自我保護(hù)能力
c）數(shù)據(jù)量（數(shù)據(jù)分片、讀寫分離）
分布式架構(gòu)下的可伸縮設(shè)計
垂直伸縮 提升硬件能力
水平伸縮 增加服務(wù)器
加速靜態(tài)內(nèi)容訪問速度的CDN
CDN是Content Deliver Network的縮寫，表示的是內(nèi)容分發(fā)網(wǎng)絡(luò)。CDN的作用是把用戶需要的內(nèi)容分發(fā)到離用戶最近的地方，這樣可以讓用戶快速獲取所需內(nèi)容。CDN其實是一種網(wǎng)絡(luò)緩存技術(shù)，能夠把一些相對穩(wěn)定的資源放到距離用戶較近的地方，一方面可以節(jié)省整個廣域網(wǎng)的消耗，另一方面可以提升用戶的訪問速度，改進(jìn)用戶體驗。一般會把靜態(tài)的文件（圖片、腳本、靜態(tài)頁面）放到CDN中。
1、當(dāng)用戶點擊網(wǎng)站頁面上的內(nèi)容URL，經(jīng)過本地DNS系統(tǒng)解析，DNS系統(tǒng)會將域名解析權(quán)交給CNAME指向的CDN專用DNS服務(wù)器；
2、CDN的DNS服務(wù)器將CDN的全局負(fù)載均衡設(shè)備IP地址返回給用戶；
3、用戶向CDN的全局負(fù)載均衡設(shè)備發(fā)起內(nèi)容URL訪問請求；
4、CDN全局負(fù)載均衡設(shè)備根據(jù)用戶IP地址，以及用戶請求的內(nèi)容URL，選擇一臺用戶所屬區(qū)域的區(qū)域負(fù)載均衡設(shè)備，告訴用戶向這臺設(shè)備發(fā)起請求；
5、區(qū)域負(fù)載均衡設(shè)備會為用戶選擇一臺合適的CDN緩存服務(wù)器提供服務(wù)，選擇的依據(jù)包括：根據(jù)用戶IP地址，判斷哪一臺服務(wù)器距離用戶最近，根據(jù)用戶所請求的URL中攜帶的內(nèi)容名稱，判斷哪一臺服務(wù)器上有用戶所需內(nèi)容，查詢各個服務(wù)器當(dāng)前的負(fù)載情況，判斷哪一臺服務(wù)器尚有服務(wù)能力。基于以上這些條件的綜合分析之后，區(qū)域負(fù)載均衡設(shè)備會向全局負(fù)載均衡設(shè)備返回一臺緩存服務(wù)器的IP地址；
6、全局負(fù)載均衡設(shè)備把服務(wù)器的IP地址返回給用戶，用戶向緩存服務(wù)器發(fā)起請求，緩存服務(wù)器響應(yīng)用戶請求，將用戶所需內(nèi)容傳送到用戶終端。如果這臺緩存服務(wù)器上并沒有用戶想要的內(nèi)容，而區(qū)域均衡設(shè)備依然將它分配給了用戶，那么這臺服務(wù)器就要向它的上一級緩存服務(wù)器請求內(nèi)容，直至追溯到網(wǎng)站的源服務(wù)器將內(nèi)容拉到本地。
什么情況下使用CDN
最適合的是那些不會經(jīng)常變化的內(nèi)容，比如圖片，JS文件，CSS文件，圖片文件包括程序模板中單，CSS文件中用到的背景圖片，還有就是作為網(wǎng)站內(nèi)容組成部分的那些圖片，都可以。
灰度發(fā)布
我們的應(yīng)用雖然經(jīng)過了測試部門的測試，但是仍然很難全面覆蓋用戶的使用場景，為了保證萬無一失，我們在進(jìn)行發(fā)布的時候一般會采用灰度發(fā)布，也就是會對新應(yīng)用進(jìn)行分批發(fā)布，逐步擴(kuò)大新應(yīng)用在整個集群的比例，直到最后全部完成。
灰度發(fā)布系統(tǒng)的作用在于，可以根據(jù)自己的配置，來將用戶的流量都到新上線的系統(tǒng)上，來快速驗證新的功能修改，而一旦出問題，也可以馬上恢復(fù)，簡單來說，是一套A/BTest系統(tǒng)。
學(xué)習(xí)來源https://www.gupaoedu.com/
