Valentine 轉(zhuǎn)載請標明出處割坠。
主流架構(gòu)模型-SOA架構(gòu)和微服務(wù)架構(gòu)
SOA全稱（Service Oriented Architecture）功茴，中文意思為“面向服務(wù)的架構(gòu)”，它是一種設(shè)計方法高氮，其中包含多個服務(wù)沿盅，服務(wù)之間通過相互依賴最終提供一系列的功能。一個服務(wù)通常以獨立的形式存在與操作系統(tǒng)進程中纫溃，各個服務(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ù)邏輯抽象成可復用每庆、可組裝的服務(wù)，通過服務(wù)的編排實現(xiàn)業(yè)務(wù)的快速再生今穿，目的：把原先固有的業(yè)務(wù)功能轉(zhuǎn)變?yōu)橥ㄓ玫臉I(yè)務(wù)服務(wù)缤灵，實現(xiàn)業(yè)務(wù)邏輯的快速復用，這一步解決的核心問題是復用荣赶；
3凤价、業(yè)務(wù)的服務(wù)化：站在企業(yè)的角度鸽斟，把企業(yè)職能抽象成可復用拔创、可組裝的服務(wù)，把原先職能化的企業(yè)架構(gòu)轉(zhuǎn)變?yōu)榉?wù)化的企業(yè)架構(gòu)富蓄，進一步提升企業(yè)的對外服務(wù)能力剩燥，前面兩步都是從技術(shù)層面來解決系統(tǒng)調(diào)用、系統(tǒng)功能復用的問題立倍，第三步則是以業(yè)務(wù)驅(qū)動把一個業(yè)務(wù)單元封裝成一項服務(wù)灭红，這一步解決的核心問題是高效。
微服務(wù)架構(gòu)
微服務(wù)架構(gòu)其實和SOA架構(gòu)類似口注，微服務(wù)是在SOA上做的升華变擒，微服務(wù)架構(gòu)強調(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只需要維護主板和一些必要的外部設(shè)備。CPU棵磷、內(nèi)存账阻、硬盤都是以組件方式提供服務(wù)，PC需要調(diào)用CPU做計算處理泽本，只需要知道CPU這個組件的地址即可淘太。
微服務(wù)的特征
1、通過服務(wù)實現(xiàn)組件化
2、按業(yè)務(wù)能力來劃分服務(wù)和開發(fā)團隊
3蒲牧、去中心化
4撇贺、基礎(chǔ)設(shè)施自動化（devops、自動化部署）
SOA和微服務(wù)架構(gòu)的差別
1冰抢、微服務(wù)不在強調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線松嘶，同時SOA的思想進入到單個業(yè)務(wù)系統(tǒng)內(nèi)部實現(xiàn)真正的組件化；
2挎扰、Docker容器技術(shù)的出現(xiàn)翠订，為服務(wù)提供了更便利的條件，比如更小的部署單元遵倦，每個服務(wù)可以通過類似Node或者Spring Boot等技術(shù)跑在自己的進程中尽超；
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)域）的前提下進行軟件開發(fā)，在開發(fā)前续搀，通常需要進行大量的業(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ù)邏輯變得越來越復雜曙强，我們的系統(tǒng)也越來越冗雜，各個模塊之間彼此關(guān)聯(lián)途茫，甚至到后期連作者都很難說清模塊的具體功能意圖是啥碟嘴，導致在修改一個功能時，要追溯到這個功能需要的修改點就要很長時間囊卜，更別提修改帶來的不可預知的影響面娜扇。
比如說訂單服務(wù)接口中提供查詢错沃、創(chuàng)建訂單相關(guān)的接口，也提供了訂單評價雀瓢、支付的接口枢析。同時訂單表是個大表，包含了非常多字段刃麸，在我們維護代碼的時候醒叁，將會導致牽一發(fā)動全身，很可能只是想改下評價相關(guān)的功能泊业，卻影響到創(chuàng)建訂單的核心路徑把沼，雖然我們可以通過測試來保證功能完備性，但當我們在訂單領(lǐng)域有大量需求同時并行開發(fā)吁伺，改動重疊饮睬，惡性循環(huán)，疲于奔命修改各種問題箱蝠。
絕大部分公司都是這樣一個狀態(tài)续捂，然后一般的解決方案就是不斷地重構(gòu)系統(tǒng)垦垂，讓系統(tǒng)的設(shè)計隨著業(yè)務(wù)成長也進行不斷的演進宦搬。通過重構(gòu)出一些獨立的類來存放某些通用的邏輯解決混亂問題，但是我們很難給它一個業(yè)務(wù)上的含義劫拗，只能以技術(shù)維度進行描述间校，這個帶來的問題就是其他人接手這塊代碼的時候不知道這個的含義或者可以通過修改這塊通用邏輯來達到某些需求。
領(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ù)變得復雜以后，包括數(shù)據(jù)結(jié)構(gòu)的變化亲铡，那么各個模塊就需要進行修改才写，原本清晰的系統(tǒng)經(jīng)過不斷的演化變得復雜、冗余奖蔓、耦合度高赞草，后果非常嚴重。
我們是想一下如果一個軟件產(chǎn)品不依賴數(shù)據(jù)庫存儲設(shè)備吆鹤，那我么怎么去設(shè)計這個軟件呢厨疙？如果沒有了數(shù)據(jù)存儲，那么我們的領(lǐng)域模型就得基于程序本身來設(shè)計疑务，那這個就是DDD需要去考慮的問題沾凄。
以抽獎設(shè)計為例
DDD理解起來有點抽象，這個有點像設(shè)計模式知允，感覺很有用撒蟀，但是不知道怎么應(yīng)用到自己寫的代碼里面，或者生搬硬套起來又很別扭温鸽，那么接下來以一個簡單的轉(zhuǎn)盤抽獎案例來分析一下DDD的應(yīng)用保屯。
針對功能層面劃分邊界
這個系統(tǒng)可以劃分為運營管理平臺和用戶使用層，運營平臺對于抽獎的配置比較復雜但是操作頻率會比較低嗤朴，而用戶對抽獎活動頁面的使用是高頻率的但是對于配置規(guī)則來說是無感知的配椭。根據(jù)這樣的特點，我們把抽獎平臺劃分針對C端抽獎和M端抽獎兩個子域雹姊，在確認了M端領(lǐng)域和C端的界限上下文后股缸，我們再對各自上下文內(nèi)容進行界限上下文的劃分，接下來以C端用戶為例來劃分界限上下文吱雏。
確認基本需求
首先我們要來了解該產(chǎn)品的基本需求
1敦姻、抽獎資格（什么情況下會有抽獎機會瘾境、抽獎次數(shù)、抽獎的活動起始時間）
2镰惦、抽獎的獎品（實物迷守、優(yōu)惠券、理財金旺入、購物卡...）
3兑凿、獎品自身的配置，概率茵瘾、庫存礼华、某些獎品在有限的概率下還只能被限制抽到多少次等
4、風控對接拗秘，防止惡意薅羊毛
針對產(chǎn)品功能劃分邊界
抽獎上下文是整個領(lǐng)域的核心圣絮，負責處理用戶抽獎的核心業(yè)務(wù)。
1雕旨、對于活動的限制扮匠，我們定義了活動資格的通用語言，將活動開始/結(jié)束時間凡涩，活動可參與次數(shù)等限制條件都收攏到活動資格子域中棒搜。
2、由于C端存在一些刷單行為突照，我們根據(jù)產(chǎn)品需求定義了風控上下文帮非，用戶對活動進行風控氧吐。
3讹蘑、由于抽獎和發(fā)獎品其實可以認為是兩個領(lǐng)域，一個負責根據(jù)概率去抽獎筑舅、另一個負責將選中的獎品發(fā)放出去座慰，所以對于這一塊也獨立出來一個領(lǐng)域。
細化上下文
通過上下文劃分以后翠拣，我們還需要進一步梳理上下文之間的關(guān)系版仔，梳理的好處在于：
1、任務(wù)更好拆分（一個開發(fā)人員可以全身心投入到相關(guān)子域的上下文中）误墓；
2蛮粮、方便溝通，明確自身上下文和其他上下文之間的依賴關(guān)系谜慌，可以實現(xiàn)更好的對接然想，然后是基于上下文的更進一步細化建模，在DDD中存在一些名字定義欣范；
實體
當一個對象由其標識（而不是屬性）區(qū)分時变泄，這種對象稱為實體（Entity）令哟。
值對象
當一個對象用于對事物進行描述而沒有唯一標識時，它被稱作為值對象妨蛹。
聚合根
聚合根屬于實體對象屏富，它是領(lǐng)域?qū)ο笾幸粋€高度內(nèi)聚的核心對象。（聚合根具有全局的唯一標識蛙卤，而實體只有在聚合內(nèi)部有唯一的本地標識狠半，值對象沒有唯一標識，不存在這個值對象或者那個值對象的說法）颤难。
領(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.;// 風控上下文
com.gupaoedu.michael.bussiness.prize.;//獎品上下文
com.gupaoedu.michael.bussiness.qualification.;// 活動資格上下文
com.gupaoedu.michael.bussiness.stock.;//庫存上下文
對于模塊內(nèi)的組織結(jié)構(gòu)逆济，一般情況下我們是按照領(lǐng)域?qū)ο蟆㈩I(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è)計模型的同步、演進最后映射到實際的代碼邏輯松靡。
總的來說简僧，DDD有幾個好處
1、DDD能夠讓我們知道如何抽象出界限上下文以及如何去分而治之雕欺，
分而治之：把復雜的大規(guī)模軟件拆分成若干個子模塊岛马，每一個模塊都能獨立運行和解決相關(guān)問題，并且分割后各個部分可以組裝成一個整體屠列。
抽象：使用抽象能夠精簡問題空間啦逆，而且問題越小越容易理解，比如說我們要對接支付笛洛，我們抽象的維度應(yīng)該是支付夏志，而不是具體的微信支付還是支付寶支付。
2撞蜂、DDD的界限上下文可以完美匹配微服務(wù)的要求盲镶，在系統(tǒng)復雜之后侥袜，我們都需要用分治來拆解問題，一般有兩種方式溉贿，技術(shù)維度和業(yè)務(wù)維度枫吧，技術(shù)維度是類似MVC這樣，業(yè)務(wù)維度則是按業(yè)務(wù)領(lǐng)域來劃分系統(tǒng)宇色，微服務(wù)架構(gòu)更強調(diào)從業(yè)務(wù)維度去做分治來應(yīng)對系統(tǒng)復雜度九杂，而DDD也是同樣的著重業(yè)務(wù)視角。
總結(jié)
領(lǐng)域驅(qū)動設(shè)計其實可以簡單認為是一種指導思想宣蠕，是一種軟件開發(fā)方法例隆，通過DDD可以將系統(tǒng)設(shè)計更加合理，最終滿足高內(nèi)聚低耦合的本質(zhì)抢蚀。有點類似數(shù)據(jù)庫的三范式镀层，我們開始在學的時候并不太理解，當有足夠的設(shè)計經(jīng)驗以后慢慢發(fā)現(xiàn)三范式帶來的好處皿曲，同時我們也并不一定需要嚴格按照這三范式去進行實踐唱逢，有些情況下是可以靈活調(diào)整的。
分布式架構(gòu)的基本理論CAP屋休、BASE以及應(yīng)用
說CAP坞古、BASE理論之前，先要了解一下分布式一致性的這個問題劫樟，實際上痪枫，對于不同業(yè)務(wù)產(chǎn)品，我們對數(shù)據(jù)一致性的要求是不一樣的叠艳，比如12306奶陈，他們要求的是數(shù)據(jù)的嚴格一致性，不能說把票賣給用戶以后發(fā)現(xiàn)沒有座位了虑绵，比如銀行轉(zhuǎn)賬尿瞭，通過銀行轉(zhuǎn)賬的時候，一般會收到一個提示翅睛，轉(zhuǎn)賬申請將會在24小時之內(nèi)到賬，實際上這個場景滿足的是最終錢只要匯出去即可黑竞，同時以及如果錢沒匯出去要保證資金不丟失就行捕发，所以說，用戶在使用不同的產(chǎn)品的時候很魂，對數(shù)據(jù)一致性的要求是不一樣的扎酷。
關(guān)于分布式一致性的問題
在分布式系統(tǒng)中要解決的一個仲要問題就是數(shù)據(jù)的復制。在我們的日常開發(fā)經(jīng)驗中遏匆，相信很多開發(fā)人員都遇到過這樣的問題：在做數(shù)據(jù)庫讀寫分離的場景中法挨，假設(shè)客戶端C1將系統(tǒng)中的一個值K由V1更新為V2谁榜，但是客戶端C2無法立刻讀取到K的最新值，需要在一段時間之后才能讀取到凡纳，這很正常窃植，因為數(shù)據(jù)庫復制之間存在延時。
所謂分布式一致性問題荐糜，是指在分布式環(huán)境中引入數(shù)據(jù)復制之后巷怜，不同數(shù)據(jù)節(jié)點之間可能出現(xiàn)的，并無法依靠計算機應(yīng)用程序自身解決的數(shù)據(jù)不一致的情況暴氏。簡單講延塑，數(shù)據(jù)一致性就是指在對一個副本數(shù)據(jù)進行更新的時候，必須確保也能夠更新其他的副本答渔，否則不同副本之間的數(shù)據(jù)將不一致关带。
那么如何去解決這個問題？按照正常的思路沼撕，我們可能會想豫缨，既然是因為網(wǎng)絡(luò)延遲導致的問題，那么我們就可以把同步動作阻塞端朵，用戶2在查詢的時候必須要等到數(shù)據(jù)同步完成以后再來做好芭，但是這個方案帶來的問題是性能會受到非常大的影響，如果同步的數(shù)據(jù)比較多或者比較頻繁冲呢，那么因為阻塞操作可能將導致整個系統(tǒng)不可用舍败。
總結(jié)：所以我們沒有辦法找到一種能夠滿足數(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ù)時刻保持同步铝量；
可用性：每個請求都能接收一個響應(yīng)倘屹，無論響應(yīng)成功或失敗慢叨；
分區(qū)容錯：系統(tǒng)應(yīng)該持續(xù)提供服務(wù)纽匙，即時系統(tǒng)內(nèi)部（某個節(jié)點分區(qū)）有消息丟失。比如交換機失敗拍谐、網(wǎng)址網(wǎng)絡(luò)被分成幾個子網(wǎng)烛缔，形成腦裂；服務(wù)器發(fā)生網(wǎng)絡(luò)延遲或死機轩拨，導致某些server 與集群中的其他機器失去聯(lián)系践瓷；
分區(qū)是導致分布式系統(tǒng)可靠性問題的固有特性，從本質(zhì)上來看亡蓉，CAP 理論的準確描述不應(yīng)該是從3 個特性中選取兩個晕翠，只能是CP或者AP，根本沒有選擇權(quán)砍濒；
總結(jié)一下：CAP 并不是一個普適性原理和指導思想淋肾，它僅適用于原子讀寫的NoSql 場景中，并不適用于數(shù)據(jù)庫系統(tǒng)梯影。
BASE理論
從前面的分析中知道巫员，在分布式（數(shù)據(jù)庫分片或分開存在的多個實例上）系統(tǒng)下，CAP理論并不適合數(shù)據(jù)庫事務(wù)（因為跟新一些錯誤的數(shù)據(jù)而導致的失敗甲棍，無論使用什么樣的高可用方案都是徒勞，因為數(shù)據(jù)發(fā)生了無法修正的錯誤）。此外XA事務(wù)雖然保證了數(shù)據(jù)庫在分布式系統(tǒng)下的ACID（原子性感猛、一致性七扰、隔離性、持久性）特性陪白，但也帶來了一些性能方面的代價颈走，對于并發(fā)和響應(yīng)時間要求比較高的電商平臺來說，是很難接受的咱士。
eBay嘗試了另外一條完全不同的路立由，放寬了數(shù)據(jù)庫事務(wù)的ACID要求，提出了一套名為BASE的新準則序厉，全稱是Basically available, soft-state, Eventually Consistent.系統(tǒng)基本可用锐膜、軟狀態(tài)、數(shù)據(jù)最終一致性弛房。相對于CAP來說道盏，它大大降低了我們對系統(tǒng)的要求。
Basically available（基本可用）文捶，在分布式系統(tǒng)出現(xiàn)不可預知的故障時荷逞，允許瞬時部分可用性。
- 比如我們在淘寶上搜索商品粹排，正常情況下是在0.5s 內(nèi)返回查詢結(jié)果种远，但是由于后端的系統(tǒng)故障導致查詢響應(yīng)時間變成了2s；
- 再比如數(shù)據(jù)庫采用分片模式顽耳，100W 個用戶數(shù)據(jù)分在5個數(shù)據(jù)庫實例上坠敷，如果破壞了一個實例，那么可用性還有80%斧抱，也就是80%的用戶都可以登錄常拓，系統(tǒng)仍然可用；
- 電商大促時辉浦，為了應(yīng)對訪問量激增弄抬，部分用戶可能會被引導到降級頁面，服務(wù)層也可能只提供降級服務(wù)宪郊。這就是損失部分可用性的體現(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 理論的核心思想是：即使無法做到強一致性，但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點帅韧，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性里初。
什么是分布式架構(gòu)下的高可用設(shè)計
1、避免單點故障
a）負載均衡技術(shù)（failover/選址/硬件負載/軟件負載/去中心化的軟件負載（gossip（redis-cluster）））
b）熱備（linux HA）
c）多機房（同城災(zāi)備弱匪、異地災(zāi)備）
2青瀑、應(yīng)用的高可用性
a）故障監(jiān)控（系統(tǒng)監(jiān)控（cpu、內(nèi)存）/鏈路監(jiān)控/日志監(jiān)控）自動預警
b）應(yīng)用的容錯設(shè)計萧诫、（服務(wù)降級斥难、限流）自我保護能力
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)的消耗缴饭，另一方面可以提升用戶的訪問速度暑劝，改進用戶體驗。一般會把靜態(tài)的文件（圖片颗搂、腳本担猛、靜態(tài)頁面）放到CDN中。
1丢氢、當用戶點擊網(wǎng)站頁面上的內(nèi)容URL傅联，經(jīng)過本地DNS系統(tǒng)解析，DNS系統(tǒng)會將域名解析權(quán)交給CNAME指向的CDN專用DNS服務(wù)器疚察；
2蒸走、CDN的DNS服務(wù)器將CDN的全局負載均衡設(shè)備IP地址返回給用戶；
3貌嫡、用戶向CDN的全局負載均衡設(shè)備發(fā)起內(nèi)容URL訪問請求该溯；
4、CDN全局負載均衡設(shè)備根據(jù)用戶IP地址嫁艇，以及用戶請求的內(nèi)容URL朗伶，選擇一臺用戶所屬區(qū)域的區(qū)域負載均衡設(shè)備弦撩，告訴用戶向這臺設(shè)備發(fā)起請求步咪；
5、區(qū)域負載均衡設(shè)備會為用戶選擇一臺合適的CDN緩存服務(wù)器提供服務(wù)益楼，選擇的依據(jù)包括：根據(jù)用戶IP地址猾漫，判斷哪一臺服務(wù)器距離用戶最近，根據(jù)用戶所請求的URL中攜帶的內(nèi)容名稱感凤，判斷哪一臺服務(wù)器上有用戶所需內(nèi)容悯周，查詢各個服務(wù)器當前的負載情況，判斷哪一臺服務(wù)器尚有服務(wù)能力陪竿∏菀恚基于以上這些條件的綜合分析之后，區(qū)域負載均衡設(shè)備會向全局負載均衡設(shè)備返回一臺緩存服務(wù)器的IP地址族跛；
6闰挡、全局負載均衡設(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)過了測試部門的測試腥刹，但是仍然很難全面覆蓋用戶的使用場景马胧，為了保證萬無一失，我們在進行發(fā)布的時候一般會采用灰度發(fā)布衔峰，也就是會對新應(yīng)用進行分批發(fā)布佩脊，逐步擴大新應(yīng)用在整個集群的比例蛙粘，直到最后全部完成。
灰度發(fā)布系統(tǒng)的作用在于威彰，可以根據(jù)自己的配置出牧，來將用戶的流量都到新上線的系統(tǒng)上，來快速驗證新的功能修改歇盼，而一旦出問題舔痕，也可以馬上恢復，簡單來說豹缀，是一套A/BTest系統(tǒng)伯复。
