1 概述

整個軟件的發(fā)展歷程是一部軟件復(fù)雜性對抗史，軟件的復(fù)雜性分為技術(shù)復(fù)雜性和業(yè)務(wù)復(fù)雜性，業(yè)務(wù)復(fù)雜性主要是建模和抽象設(shè)計，技術(shù)復(fù)雜性主要是三高（高性能，高并發(fā)，高可用）的應(yīng)對，C端的業(yè)務(wù)一般以技術(shù)復(fù)雜性為主，業(yè)務(wù)復(fù)雜性為輔，而B端或者M端的業(yè)務(wù)通常以業(yè)務(wù)復(fù)雜性為主，技術(shù)復(fù)雜性為輔。本篇文章主要是從后端研發(fā)的視角結(jié)合自己多年的B C端系統(tǒng)建設(shè)實踐談下三高系統(tǒng)的建設(shè)方法論和實踐，希望和大家相互交流，共同進步，同時這是我參與創(chuàng)作者計劃的第1篇文章。

2 高性能篇

個人理解三高系統(tǒng)的核心在于高性能，系統(tǒng)的性能高，系統(tǒng)的處理速度快，吞吐量自然高，此時系統(tǒng)能夠應(yīng)對高并發(fā)的流量；系統(tǒng)的性能高，我們系統(tǒng)的對外承諾的TP99, TP999就比較低，超時等影響可用率的情況自然減少，系統(tǒng)的可用性也會提高，所以三高系統(tǒng)建設(shè)的出發(fā)點可以從系統(tǒng)的性能如何優(yōu)化進行建設(shè)，高性能篇從系統(tǒng)的讀寫兩個維度談下系統(tǒng)的性能優(yōu)化方法論及實踐；

2.1 方法論

首先我們要清楚知道影響系統(tǒng)性能的因素有那些，通常有以下三方面的因素：計算（computation），通信（communication），存儲（storage）。計算層面：系統(tǒng)本身的計算邏輯復(fù)雜，F(xiàn)ullgc；通信層面：依賴的下游耗時比較高；存儲層面：大庫大表，慢sql，ES集群的數(shù)據(jù)節(jié)點，索引，分片，分片大小設(shè)置的不合理；針對這些問題，我們可以從讀寫兩個維度針對性能問題進行優(yōu)化，下圖是我工作中解決性能問題的一些方法。

圖片

2.2 幾個實踐問題的探討

2.2.1 讀優(yōu)化：緩存和數(shù)據(jù)庫的結(jié)合藝術(shù)

一想到高性能，我們首先想到的是使用緩存，無論是本地緩存還是分布式的緩存，通過實踐我們發(fā)現(xiàn)緩存確實是提高我們系統(tǒng)性能最有效的手段，雖然緩存能夠暫存部分數(shù)據(jù)，提高系統(tǒng)的性能，但是我們一般不會使用緩存持久化數(shù)據(jù)，所以一般將緩存和數(shù)據(jù)庫結(jié)合使用，提高性能的同時也保證系統(tǒng)的可靠性；針對緩存和數(shù)據(jù)庫的結(jié)合使用，我們一般需要識別出系統(tǒng)是讀多寫少的系統(tǒng)，還是寫多讀少的系統(tǒng)；

2.2.1.1 讀多寫少的系統(tǒng)

針對讀多寫少的系統(tǒng)，我們一般采用同步更新數(shù)據(jù)庫，后刪除緩存；數(shù)據(jù)庫來應(yīng)對寫的流量，緩存來應(yīng)對讀的流量，提高讀的性能；此種方案我們是以數(shù)據(jù)庫數(shù)據(jù)為主，緩存數(shù)據(jù)為輔，這是前司大部分團隊采用的技術(shù)方案

圖片

2.2.1.2 寫多讀少的系統(tǒng)

針對寫多讀少的系統(tǒng)，我們一般采用同步更新緩存，異步更新數(shù)據(jù)庫，通過緩存來進行抗寫的流量，異步化更新數(shù)據(jù)庫，通過緩存和異步化提高系統(tǒng)的性能；此種技術(shù)方案以緩存數(shù)據(jù)為主，數(shù)據(jù)庫數(shù)據(jù)為輔，這是我了解到的京東物流這邊大部分團隊的技術(shù)方案，例如我們物流平臺-統(tǒng)一平臺小組的訂運關(guān)系單據(jù)的存儲采用的就是這種技術(shù)方案

圖片

2.2.2 寫優(yōu)化：秒殺場景下的異步化

針對于這種流量洪峰下的秒殺場景，對于接單接口的性能是很大的考驗，所以接單接口不會有很多同步交互的復(fù)雜邏輯。我們一般都是先異步將訂單接下來，返回給用戶成功，通過消息隊列來削峰處理訂單，緩存存儲相關(guān)sku的庫存，當(dāng)扣減庫存成功后，再短信通知用戶支付訂單。

圖片

3 高并發(fā)篇

提到高并發(fā)我們想到的是高吞吐，流量洪峰；如何提高高并發(fā)我們可以從單機的性能優(yōu)化，和集群的擴展來進行提高我們系統(tǒng)的并發(fā)能力，其實系統(tǒng)的高性能直接就提高了系統(tǒng)的高并發(fā)，上面的高性能篇主要是從單機的維度提高處理的速度來提高單機的并發(fā)處理能力，本章主要從集群的維度通過擴展：水平擴展，縱向擴展，垂直擴展三維立體來提高系統(tǒng)的并發(fā)能力。

3.1 方法論

圖片

3.1.1 X軸：水平擴展

水平擴展就是擴容，是我們采用最多的抗并發(fā)的措施：加機器，擴分片，每年618，雙11大促時，這是我們的常規(guī)操作，現(xiàn)有分組下的機器處理能力有限，我們通過擴容來應(yīng)對大促的流量，擴容我們分為應(yīng)用層和存儲層，應(yīng)用層都是無狀態(tài)的服務(wù)，我們可以通過公司部署平臺行云快速的擴容增加機器，存儲層的擴容相對比較麻煩，新增分片后，還涉及到數(shù)據(jù)的遷移以及分片規(guī)則的調(diào)整。

圖片

3.1.2 Y軸：縱向擴展

整個軟件應(yīng)用的架構(gòu)經(jīng)歷單體應(yīng)用，SOA，微服務(wù)，服務(wù)網(wǎng)格的演進。早期的架構(gòu)風(fēng)格所有的服務(wù)功能都融合在單體應(yīng)用中，通過單體服務(wù)來抗所有的流量，后來隨著業(yè)務(wù)的復(fù)雜性和用戶的增多以及我們基于對業(yè)務(wù)的深入理解采用DDD（領(lǐng)域驅(qū)動設(shè)計）來指導(dǎo)我們按照領(lǐng)域劃分服務(wù)，進行微服務(wù)建設(shè)，下圖是一個電商的單體應(yīng)用到按照DDD進行微服務(wù)劃分的一個演進過程。

圖片

3.1.3 Z軸：垂直擴展

當(dāng)我們在應(yīng)用層進行水平擴展時，每增加一臺機器都會增加數(shù)據(jù)庫的訪問鏈接，數(shù)據(jù)庫的連接數(shù)屬于寶貴資源，達到上限后，應(yīng)用層再擴容就會出現(xiàn)連接數(shù)耗盡的異常，此時存儲層成了整個系統(tǒng)高并發(fā)的瓶頸，針對數(shù)據(jù)庫我們一般采用分片（分而治之）的思想：分庫分表，通過增加庫實例來增加訪問的連接數(shù)，下圖是訂單進行分庫分表的架構(gòu)。

圖片

集群中數(shù)據(jù)庫的主從庫數(shù)量是有限制的的，達到最大限制后，一個機房的數(shù)據(jù)庫集群成了系統(tǒng)的瓶頸，解決方案是進行單元化建設(shè)，系統(tǒng)的流量和數(shù)據(jù)閉環(huán)在一個單元，這個單元分布在全國甚至全世界不同的地域，而不是集中在某個機房某個地域，北京的系統(tǒng)單元為北京用戶提供服務(wù)，上海的系統(tǒng)單元為上海用戶提供服務(wù)，就類似于京東物流的倉庫一樣，建在離用戶最近的地方，北京倉服務(wù)北京用戶，上海倉服務(wù)上海用戶。大家可以看到系統(tǒng)的建設(shè)和業(yè)務(wù)的發(fā)展底層的思想都是統(tǒng)一的，中國的頭部互聯(lián)網(wǎng)還都是業(yè)務(wù)驅(qū)動，所以技術(shù)要服務(wù)好業(yè)務(wù)?？傊覀兛梢钥吹酵ㄟ^分庫分表和單元化這種垂直擴展提高并發(fā)的同時也增強了系統(tǒng)的可用性，下圖是我們進行單元化建設(shè)的過程。

圖片

3.2 幾個實踐問題的探討

3.2.1 DDD在零售物流平臺的實踐

縱向的擴展，我們采用DDD進行領(lǐng)域的劃分進行微服務(wù)的建設(shè)，DDD的實踐必須基于對業(yè)務(wù)的深入理解，所以作為技術(shù)人員，如果想將DDD很好的落地，必須和業(yè)務(wù)專家，產(chǎn)品一起頭腦風(fēng)暴，技術(shù)前置去了解業(yè)務(wù)。研發(fā)可以從業(yè)務(wù)流程上去了解業(yè)務(wù)，然后基于業(yè)務(wù)流程進行領(lǐng)域劃分；

3.2.1.1 業(yè)務(wù)流程

正向流程：從B端商家視角來看，商家選擇服務(wù)商品比如卓配產(chǎn)品后，進行下單，服務(wù)商進行接單，分配快遞員，快遞員上門取件，對用戶郵寄的貨品進行稱重量方，詢價計費，然后商家支付運費，快遞員完成攬收，進入履約層面：貨品進行運輸，配送，直至C端用戶簽收完成妥投。

圖片

逆向流程：從C端用戶視角來看，用戶需要申請售后退貨，待商家審核通過后，選擇相應(yīng)的商品服務(wù)進行下單，后續(xù)的流程和正向流程類似。

圖片

3.2.1.2 應(yīng)用領(lǐng)域劃分

應(yīng)用領(lǐng)域的劃分主要根據(jù)我們的業(yè)務(wù)流程介紹提供了那些功能；目前我們系統(tǒng)支撐的業(yè)務(wù)來源包括：零售的商家后臺（京麥），訂單中臺，售后，傳美，快遞鳥，中鐵，統(tǒng)一發(fā)貨平臺等等；

從需求側(cè)來看，我們的上游包括了京東物流，京東零售，京東工業(yè)，外部的ISV等給物流平臺下單；

從供給側(cè)來看，我們的服務(wù)商包括：京東快遞，快運，中通，圓通，韻達等來提供履約的能力；

從領(lǐng)域劃分角度來看，將領(lǐng)域劃分為：商品服務(wù)域，訂單域，支付結(jié)算域，履約域，每個領(lǐng)域包括了提供的功能如下圖；至于為啥這樣劃分，我的思考是這樣的，相較于C端零售側(cè)的電商交易，我們是服務(wù)于商家的B端物流側(cè)的物流交易；C端零售針對于用戶提供的是實物的商品：手機，電腦；B端物流針對于商家提供的是虛擬的商品：一種履約物流服務(wù)，將貨品從商家交付到用戶；所以無論是我們的卓配產(chǎn)品還是電子面單產(chǎn)品，我們?yōu)樯虘籼峁┝诉@些虛擬商品，商家選擇這些虛擬商品后，就可以下單，取消，改單，支付，服務(wù)商進行履約；

圖片

3.2.2 熱key處理

垂直的擴展，在百億補貼，大促，秒殺場景下，相關(guān)sku會成為訪問的熱點，如果將相關(guān)sku存儲到某個單一的分片則可能出現(xiàn)流量訪問傾斜的問題，某個分片會承擔(dān)大部分的流量出現(xiàn)性能變差甚至分片被打垮的情況；針對熱key的問題我們可以采用如下兩種解決方案：

本地緩存：在應(yīng)用層增加本地緩存；先查本地緩存，本地緩存沒有查詢分布式緩存，分布式緩存沒有查詢數(shù)據(jù)庫；

隨機數(shù)法：針對某個key，我們可以在這個key后面增加一個隨機數(shù)，比如增加兩位的隨機，就可以將該key分散到100個分片上，避免熱點分片

總之無論是本地緩存還是key+隨機數(shù)，都是將熱key分散到不同的節(jié)點上來分散流量，提高并發(fā)的同時，也避免流量傾斜，將某個節(jié)點打垮；

4 高可用篇

保證系統(tǒng)的可用性是系統(tǒng)建設(shè)中的重中之重，如果沒有可用性，高性能和高并發(fā)也無從談起，高可用的建設(shè)通常是通過保護系統(tǒng)和冗余的方法來進行容錯保證系統(tǒng)的可用性。本篇主要從三個維度：應(yīng)用層，存儲層，部署層談下可用性的建設(shè)。應(yīng)用層的內(nèi)容來自我的另一篇文章：http://sd.jd.com/article/33612?shareId=224276&isHideShareButtnotallow=1

4.1 方法論

圖片

4.1.1 應(yīng)用層

4.1.1.1 限流

限流一般是從服務(wù)提供者provider的視角提供的針對自我保護的能力，對于流量負載超過我們系統(tǒng)的處理能力，限流策略可以防止我們的系統(tǒng)被激增的流量打垮。京東內(nèi)部無論是同步交互的JSF, 還是異步交互的JMQ都提供了限流的能力，大家可以根據(jù)自己系統(tǒng)的情況進行設(shè)置；我們知道常見的限流算法包括：計數(shù)器算法，滑動時間窗口算法，漏斗算法，令牌桶算法，具體算法可以網(wǎng)上google下，下面是這些算法的優(yōu)缺點對比。

4.1.1.2 熔斷降級

熔斷和降級是兩件事情，但是他們一般是結(jié)合在一起使用的。熔斷是防止我們的系統(tǒng)被下游系統(tǒng)拖垮，比如下游系統(tǒng)接口性能嚴重變差，甚至下游系統(tǒng)掛了；這個時候會導(dǎo)致大量的線程堆積，不能釋放占用的CPU，內(nèi)存等資源，這種情況下不僅影響該接口的性能，還會影響其他接口的性能，嚴重的情況會將我們的系統(tǒng)拖垮，造成雪崩效應(yīng)，通過打開熔斷器，流量不再請求到有問題的系統(tǒng)，可以保護我們的系統(tǒng)不被拖垮。降級是一種有損操作，我們作為服務(wù)提供者，需要將這種損失盡可能降到最低，無論是返回友好的提示，還是返回可接受的降級數(shù)據(jù)。降級細分的話又分為人工降級，自動降級。

人工降級：人工降級一般采用降級開關(guān)來控制，公司內(nèi)部一般采用配置中心Ducc來做開關(guān)降級，開關(guān)的修改也是線上操作，這塊也需要做好監(jiān)控

自動降級：自動降級是采用自動化的中間件例如Hystrix，公司的小盾龍等；如果采用自動降級的話；我們必須要對降級的條件非常的明確，比如失敗的調(diào)用次數(shù)等；

4.1.1.3 超時設(shè)置

分布式系統(tǒng)中的難點之一：不可靠的網(wǎng)絡(luò)，京東物流現(xiàn)有的微服務(wù)架構(gòu)下，服務(wù)之間都是通過JSF網(wǎng)絡(luò)交互進行同步通信，我們探測下游依賴服務(wù)是否可用的最快捷的方式是設(shè)置超時時間。超時的設(shè)置可以讓系統(tǒng)快速失敗，進行自我保護，避免無限等待下游依賴系統(tǒng)，將系統(tǒng)的線程耗盡，系統(tǒng)拖垮；

超時時間如何設(shè)置也是一門學(xué)問，如何設(shè)置一個合理的超時時間也是一個逐步迭代的過程，比如下游新開發(fā)的接口，一般會基于壓測提供一個TP99的耗時，我們會基于此配置超時時間；老接口的話，會基于線上的TP99耗時來配置超時時間。

超時時間在設(shè)置的時候需要遵循漏斗原則，從上游系統(tǒng)到下游系統(tǒng)設(shè)置的超時時間要逐漸減少，如下圖所示。為什么要滿足漏斗原則，假設(shè)不滿足漏斗原則，比如服務(wù)A調(diào)取服務(wù)B的超時時間設(shè)置成500ms，而服務(wù)B調(diào)取服務(wù)C的超時時間設(shè)置成800ms，這個時候回導(dǎo)致服務(wù)A調(diào)取服務(wù)B大量的超時從而導(dǎo)致可用率降低，而此時服務(wù)B從自身角度看是可用的；

圖片

4.1.1.4 重試

分布式系統(tǒng)中性能的影響主要是通信，無論是在分布式系統(tǒng)中還是垮團隊溝通，communication是最昂貴的；比如我們研發(fā)都知道需求的交付有一半以上甚至更多的時間花在跨團隊的溝通上，真正寫代碼的時間是很少的；分布式系統(tǒng)中我們查看調(diào)用鏈路，其實我們系統(tǒng)本身計算的耗時是很少的，主要來自于外部系統(tǒng)的網(wǎng)絡(luò)交互，無論是下游的業(yè)務(wù)系統(tǒng)，還是中間件：Mysql, redis, es等等；所以在和外部系統(tǒng)的一次請求交互中，我們系統(tǒng)是希望盡最大努力得到想要的結(jié)果，但往往事與愿違，由于不可靠網(wǎng)絡(luò)的原因，我們在和下游系統(tǒng)交互時，都會配置超時重試次數(shù)，希望在可接受的SLA范圍內(nèi)一次請求拿到結(jié)果，但重試不是無限的重試，我們一般都是配置重試次數(shù)的限制，偶爾抖動的重試可以提高我們系統(tǒng)的可用率，如果下游服務(wù)故障掛掉，重試反而會增加下游系統(tǒng)的負載，從而增加故障的嚴重程度。在一次請求調(diào)用中，我們要知道對外提供的API，后面是有多少個service在提供服務(wù)，如果調(diào)用鏈路比較長，服務(wù)之間rpc交互都設(shè)置了重試次數(shù)，這個時候我們需要警惕重試風(fēng)暴。如下圖service D 出現(xiàn)問題，重試風(fēng)暴會加重service D的故障嚴重程度。對于API的重試，我們還要區(qū)分該接口是讀接口還是寫接口，如果是讀接口重試一般沒什么影響，寫接口重試一定要做好接口的冪等性。

圖片

4.1.1.5 隔離

隔離是將故障爆炸半徑最小化的有效手段，我們通過不同層面的隔離來控制影響范圍，保證系統(tǒng)的高可用：

4.1.1.5.1 系統(tǒng)建設(shè)層面隔離

我們知道系統(tǒng)的分類可以分為：在線的系統(tǒng)，離線系統(tǒng)（批處理系統(tǒng)），近實時系統(tǒng)（流處理系統(tǒng)），如下是這些系統(tǒng)的定義：

在線系統(tǒng)：服務(wù)端等待請求的到達，接收到請求后，服務(wù)盡可能快的處理，然后返回給客戶端一個響應(yīng)，響應(yīng)時間通常是在線服務(wù)性能的主要衡量指標。我們生活中在手機使用的APP大部分都是在線系統(tǒng)；

離線系統(tǒng)：或稱批處理系統(tǒng)，接收大量的輸入數(shù)據(jù)，運行一個作業(yè)來處理數(shù)據(jù)，并產(chǎn)出輸出數(shù)據(jù)，作業(yè)往往需要定時，定期運行一段時間，比如從幾分鐘到幾天，所以用戶通常不會等待作業(yè)完成，吞吐量是離線系統(tǒng)的主要衡量指標。例如我們看到的報表數(shù)據(jù)：日訂單量，月訂單量，日活躍用戶數(shù)，月活躍用戶數(shù)都是批處理系統(tǒng)運算一段時間得到的；

近實時系統(tǒng)：或者稱流處理系統(tǒng)，其介于在線系統(tǒng)和離線系統(tǒng)之間，流處理系統(tǒng)一般會有觸發(fā)源：用戶的行為操作，數(shù)據(jù)庫的寫操作，傳感器等，觸發(fā)源作為消息會通過消息代理中間件：JMQ, KAFKA等進行傳遞，消費者消費到消息后再做其他的操作，例如構(gòu)建緩存，索引，通知用戶等；

以上三種系統(tǒng)是需要進行隔離建設(shè)的，因為他們的衡量指標及對資源的使用情況完全不一樣的，比如我們小組會將在線系統(tǒng)作為一個服務(wù)單獨部署：jdl-uep-main, 離線系統(tǒng)和近實時系統(tǒng)作為一個服務(wù)單獨部署：jdl-uep-worker；

4.1.1.5.2 環(huán)境的隔離

從研發(fā)到上線階段我們會使用不同的環(huán)境，比如業(yè)界常見的環(huán)境分為：開發(fā)，測試，預(yù)發(fā)和線上環(huán)境；研發(fā)人員在開發(fā)環(huán)境進行開發(fā)和聯(lián)調(diào)，測試人員在測試環(huán)境進行測試，運營和產(chǎn)品在預(yù)發(fā)環(huán)境進行UAT，最終交付的產(chǎn)品部署到線上環(huán)境提供給用戶使用。在研發(fā)流程中，我們部署時要遵循從應(yīng)用層到中間件層再到存儲層，都要在一個環(huán)境，嚴禁垮環(huán)境的調(diào)用，比如測試環(huán)境調(diào)用線上，預(yù)發(fā)環(huán)境調(diào)用線上等。

圖片

4.1.1.5.3 數(shù)據(jù)隔離

隨著業(yè)務(wù)的發(fā)展，我們對外提供的服務(wù)往往會支撐多業(yè)務(wù)，多租戶，所以這個時候我們會按照業(yè)務(wù)進行數(shù)據(jù)隔離；比如我們組產(chǎn)生的物流訂單數(shù)據(jù)業(yè)務(wù)方就包含京東零售，其他電商平臺，ISV等，為了避免彼此的影響我們需要在存儲層對數(shù)據(jù)進行隔離，數(shù)據(jù)的隔離可以按照不同粒度，第一種是通過租戶id字段進行區(qū)分，所有的數(shù)據(jù)存儲在一張表中，另外一個是庫粒度的區(qū)分，不同的租戶單獨分配對應(yīng)的數(shù)據(jù)庫。

圖片

圖片

數(shù)據(jù)的隔離除了按照業(yè)務(wù)進行隔離外，還有按照環(huán)境進行隔離的，比如我們的數(shù)據(jù)庫分為測試庫，預(yù)發(fā)庫，線上庫，全鏈路壓測時，我們?yōu)榱四M線上的環(huán)境，同時避免污染線上的數(shù)據(jù)，往往會創(chuàng)建影子庫，影子表等。根據(jù)數(shù)據(jù)的訪問頻次進行隔離，我們將經(jīng)常訪問的數(shù)據(jù)稱為熱數(shù)據(jù)，不經(jīng)常訪問的數(shù)據(jù)稱為冷數(shù)據(jù)；將經(jīng)常訪問的數(shù)據(jù)緩存到緩存，提高系統(tǒng)的性能。不經(jīng)常訪問的數(shù)據(jù)持久化到數(shù)據(jù)庫或者將不使用的數(shù)據(jù)結(jié)轉(zhuǎn)歸檔到OSS，避免大庫大表。

4.1.1.5.4 核心/非核心流程隔離

我們知道應(yīng)用是分級的，京東內(nèi)部針對應(yīng)用的重要程度會將應(yīng)用分為0，1，2，3級應(yīng)用。業(yè)務(wù)的流程也分為黃金流程和非黃金流程。在業(yè)務(wù)流程中，針對不同級別的應(yīng)用交互，需要將核心和非核心的流程進行隔離。例如在交易業(yè)務(wù)過程中，會涉及到訂單系統(tǒng)，支付系統(tǒng)，通知系統(tǒng)，那這個過程中核心系統(tǒng)是訂單系統(tǒng)和支付系統(tǒng)，而通知相對來說重要性不是那么高，所以我們會投入更多的資源到訂單系統(tǒng)和支付系統(tǒng)，優(yōu)先保證這兩個系統(tǒng)的穩(wěn)定性，通知系統(tǒng)可以采用異步的方式與其他兩個系統(tǒng)解耦隔離，避免對其他另外兩個系統(tǒng)的影響。

圖片

4.1.1.5.5 讀寫隔離

應(yīng)用層面，領(lǐng)域驅(qū)動設(shè)計（DDD）中最著名的CQRS（Command Query Responsibility Segregation）將寫服務(wù)和讀服務(wù)進行隔離。寫服務(wù)主要處理來自客戶端的command寫命令，而讀服務(wù)處理來自客戶端的query讀請求，這樣從應(yīng)用層面進行讀寫隔離，不僅可以提高系統(tǒng)的可擴展性，同時也會提高系統(tǒng)的可維護性，應(yīng)用層面我們都采用微服務(wù)架構(gòu)，應(yīng)用層都是無狀態(tài)服務(wù)，可以擴容加機器隨意擴展，存儲層需要持久化，擴展就比較費勁。除了應(yīng)用層面的CQRS，在存儲層面，我們也會進行讀寫隔離，例如數(shù)據(jù)庫都會采用一主多從的架構(gòu)，讀請求可以路由到從庫從而分擔(dān)主庫的壓力，提高系統(tǒng)的性能和吞吐量。所以應(yīng)用層面通過讀寫隔離主要解決可擴展問題，存儲層面主要解決性能和吞吐量的問題。

圖片

4.1.1.5.6 線程池隔離

線程是昂貴的資源，為了提高線程的使用效率，復(fù)用線程，避免創(chuàng)建和銷毀的消耗，我們采用了池化技術(shù)，線程池，但是在使用線程的過程中，我們也做好線程池的隔離，避免多個API接口復(fù)用同一個線程。

圖片

4.1.1.6 兼容

我們在對老系統(tǒng)，老功能進行重構(gòu)迭代的時候，一定要做好兼容，否則上線后會出現(xiàn)重大的線上問題，公司內(nèi)外有大量因為沒有做好兼容性，而導(dǎo)致資損的情況。兼容分為：向前兼容性和向后兼容性，需要好好的區(qū)分他們，如下是他們的定義:

向前兼容性：向前兼容性指的是舊版本的軟件或硬件能夠與將來推出的新版本兼容的特性，簡而言之舊版本軟件或系統(tǒng)兼容新的數(shù)據(jù)和流量。

向后兼容性：向后兼容性則是指新版本的軟件或硬件能夠與之前版本的系統(tǒng)或組件兼容的特性，簡而言之新版本軟件或系統(tǒng)兼容老的數(shù)據(jù)和流量。

根據(jù)新老系統(tǒng)和新老數(shù)據(jù)我們可以將系統(tǒng)劃分為四個象限：第一象限：新系統(tǒng)和新數(shù)據(jù)是我們系統(tǒng)改造上線后的狀態(tài)，第三象限：老系統(tǒng)和老數(shù)據(jù)是我們系統(tǒng)改造上線前的狀態(tài)，第一象限和第三象限的問題我們在研發(fā)和測試階段一般都能發(fā)現(xiàn)排除掉，線上故障的高發(fā)期往往出現(xiàn)在第二和第四象限，第二象限是因為沒有做好向前兼容性，例如上線過程中，發(fā)現(xiàn)問題進行了代碼回滾，但是在上線過程中產(chǎn)生了新數(shù)據(jù)，回滾后的老系統(tǒng)不能處理上線過程中新產(chǎn)生的數(shù)據(jù)，導(dǎo)致線上故障。第四象限是因為沒有做好向后兼容性，上線后新系統(tǒng)影響了老流程。針對第二象限的問題，我們可以構(gòu)造新的數(shù)據(jù)去驗證老的系統(tǒng)，針對第四象限的問題，我們可以通過流量的錄制回放解決，錄制線上的老流量，對新功能進行驗證。

圖片

4.1.2 存儲層

存儲層主要通過復(fù)制和分片來保證存儲層的高可用，復(fù)制主要是通過副本（主從節(jié)點，主從副本）來保證高可用，分片是將數(shù)據(jù)分散到不同的節(jié)點上來保證高可用（雞蛋不要放在同一個籃子中）。復(fù)制和分片在保證高可用的情況下，其實也提高了系統(tǒng)的高性能和高并發(fā)，復(fù)制和分片的思想在Mysql，Redis，ElasticSearch, kafka中都進行了采用。

4.1.2.1 復(fù)制

復(fù)制技術(shù)是一份數(shù)據(jù)的完整的拷貝，思想是通過冗余保證高可用。復(fù)制又可以分為：主從復(fù)制，多主復(fù)制，無主復(fù)制。

主從復(fù)制：客戶端將所有寫入操作發(fā)送到單個節(jié)點（主庫），該節(jié)點將數(shù)據(jù)更改事件流發(fā)送到其他副本（從庫）。讀取可以在任何副本上執(zhí)行，但從庫的讀取結(jié)果可能是陳舊的。

多主復(fù)制：客戶端將每個寫入發(fā)送到幾個主庫節(jié)點之一，其中任何一個主庫都可以接受寫入。主庫將數(shù)據(jù)更改事件流發(fā)送給彼此以及任何從庫節(jié)點。

無主復(fù)制：客戶端將每個寫入發(fā)送到幾個節(jié)點，并從多個節(jié)點并行讀取，以檢測和糾正具有陳舊數(shù)據(jù)的節(jié)點。

4.1.2.2 分區(qū)

分區(qū)也稱為分片，對于非常大的數(shù)據(jù)集在單節(jié)點進行存儲時，一方面可用性比較低（雞蛋放在同一個籃子中），另一方面也會遇到存儲和性能的瓶頸，我們需要將大的數(shù)據(jù)集通過負載均衡分片到不同的節(jié)點上，每條數(shù)據(jù)（每條記錄，每行或每個文檔）屬于且僅屬于一個分區(qū)，每個分區(qū)都是自己的小型數(shù)據(jù)庫。分區(qū)我們分為鍵范圍分區(qū)，散列分區(qū)。

鍵范圍分區(qū)：其中鍵是有序的，并且分區(qū)擁有從某個最小值到某個最大值的所有鍵。排序的優(yōu)勢在于可以進行有效的范圍查詢，但是如果應(yīng)用程序經(jīng)常訪問相鄰的鍵，則存在熱點的風(fēng)險。在這種方法中，當(dāng)分區(qū)變得太大時，通常將分區(qū)分成兩個子分區(qū)來動態(tài)地重新平衡分區(qū)。

散列分區(qū)：散列函數(shù)應(yīng)用于每個鍵，分區(qū)擁有一定范圍的散列。這種方法破壞了鍵的排序，使得范圍查詢效率低下，但可以更均勻地分配負載。通過散列進行分區(qū)時，通常先提前創(chuàng)建固定數(shù)量的分區(qū)，為每個節(jié)點分配多個分區(qū)，并在添加或刪除節(jié)點時將整個分區(qū)從一個節(jié)點移動到另一個節(jié)點。也可以使用動態(tài)分區(qū)。

4.1.2.3 Redis 的復(fù)制和分片

redis cluster集群中，我們會劃分16384個槽，key 通過散列哈希算法會映射到相應(yīng)的槽中，這些槽分配到不同的分片上，每個分片有主節(jié)點和從節(jié)點，主節(jié)點對外提供讀寫服務(wù)，從節(jié)點對外提供讀服務(wù)。當(dāng)某個分片的主節(jié)點掛掉，其他分片的主節(jié)點會從掛掉分片的從節(jié)點選擇一個作為主節(jié)點繼續(xù)對外提供服務(wù)。整體的架構(gòu)如下圖所示

圖片

4.1.2.4 ES索引的復(fù)制和分片

我們在創(chuàng)建ES索引時，會指定分片的數(shù)量和副本的數(shù)量，分片的數(shù)量確定后是不允許修改的，副本的數(shù)量允許修改，分片的數(shù)量一般和數(shù)據(jù)節(jié)點的數(shù)量保持一致，這樣能將索引的數(shù)據(jù)分配到每個數(shù)據(jù)節(jié)點上，每個數(shù)據(jù)節(jié)點都存儲索引的部分數(shù)據(jù)，Primary分片可以對外提供讀寫服務(wù)，Replica分片對外提供讀服務(wù)的同時作為備份節(jié)點保證可用性，ES索引的不同分片在不同數(shù)據(jù)節(jié)點的分布如下圖所示。

圖片

4.1.2.5 Kafka topic的復(fù)制和分區(qū)

kafka的topic為了提高可用性及高吞吐，引入了topic的分區(qū)，每個分區(qū)為了提高可用性，分區(qū)分為Leaderpartition和Followerpartition，Leader partition對外提供讀寫服務(wù)，F(xiàn)ollowerpartition作為災(zāi)備提高可用性，整體的架構(gòu)如下圖；

圖片

4.1.3 部署層

4.1.3.1 業(yè)界部署架構(gòu)的演進

部署層是通過不斷突破單機器，單機房，單地域，做到機器級別，機房級別，地域級別的容災(zāi)來保證系統(tǒng)的高可用。核心思想是通過冗余以及負載均衡進行容災(zāi)保證高可用。

圖片

4.1.3.2 我們部署架構(gòu)現(xiàn)狀

目前我們的應(yīng)用都是采用多機房多分組Docker容器化部署，會根據(jù)業(yè)務(wù)方的重要程度及流量大小設(shè)置不同的別名，隔離到不同的分組中對外提供服務(wù)。

?應(yīng)用容器機房為：中云信，有孚，廊坊，宿遷等；

?數(shù)據(jù)庫Mysql雙機房部署：中云信，有孚；

?緩存Redis雙機房部署：中云信，有孚；

?ES單機房部署：有孚；

圖片