聲明：本文內(nèi)容來自于TOP100Summit旗下技術(shù)沙龍品牌into100沙龍第17期：高可用高并發(fā)解決之道，如需轉(zhuǎn)載請聯(lián)系主辦方進行授權(quán)。?
嘉賓：史海峰，當當架構(gòu)部總監(jiān)。2012年加入當當，負責總體架構(gòu)規(guī)劃、技術(shù)規(guī)范制定，善于把握復(fù)雜業(yè)務(wù)需求，提出創(chuàng)新性解決方案，參與重點項目方案設(shè)計，對系統(tǒng)架構(gòu)進行持續(xù)改造優(yōu)化，推動技術(shù)革新，組織內(nèi)外部技術(shù)交流。?

以下為分享整理正文：?

系統(tǒng)中的非功能性需求?
今天我們的主題是當當高可用架構(gòu)設(shè)計之道，高可用并不是功能性的需求，而是傳統(tǒng)的IT當中非功能性需求的一部分。大家可以看到我這里羅列了很多非功能性需求，但是這當中并沒有「高可用」這三個字。?

?

舉一個例子，比如說你買了一臺蘋果手機，無論是作為手機還是電腦，還是MP3，還是專門用來看視頻的，都是功能；那么非功能性呢，比如說大家很崇拜喬布斯，產(chǎn)品設(shè)計極致體驗，蘋果手機只有1個鍵，簡單好用，這就是一個非功能性需求。另外還有很多朋友買土豪金的手機，就是為了區(qū)分開，因為顏色不一樣。這個顏色也是非功能性需求。?

我們簡單介紹幾個非功能性需求。?

擴展性，有一些類似的可以抽象成統(tǒng)一模型的東西，如果說做好的話就可以支持擴展。用一個以前的例子，我以前是做電信行業(yè)的，比如說有一個需求要在全球通上開一個5塊錢的套餐，接著又要在動感地帶開一個10塊錢的套餐，那么我們就可以做成一個模型，做成一個套餐的產(chǎn)品，品牌是一個屬性，價格也是一個屬性。這樣的話，神州行再來一個50塊錢的套餐，我們就不需要改什么應(yīng)用，增加一些配置，定義一些產(chǎn)品屬性就可以了，這就是擴展性。?

高效率是說你對現(xiàn)有的資源使用是不是足夠高效。比如說有的人寫的代碼比較爛，一啟動就百分之幾十的CPU使用率，這就不太合理。?

可測試，很多開發(fā)的同學不當回事，覺得開發(fā)好功能邏輯就夠了。但是你做出來的東西是要保證質(zhì)量的。開個玩笑，如果說測試的妹子很漂亮，你愿意手把手的教她如何來測試功能，但要是妹子走了，來了一個糙爺們還需要你還手把手的教，你就不愿意了。因此必須要有一個測試的完整方法、功能說明、測試用例。?

這些非功能性的需求，是整個系統(tǒng)是不是正常穩(wěn)定、可靠運轉(zhuǎn)，以及被一個團隊長期沿用下去的一個前提。?

而可用性，涉及到很多方面。比如說伸縮性，是否能夠在業(yè)務(wù)量增長的前提之下，通過水平擴展可以很容易支撐更多的業(yè)務(wù)。比如說安全性、可靠性，數(shù)據(jù)會不會丟失？所以這里面很多的點，最終都是決定了可用性。?

那么可用性是什么呢？可用性就是這套系統(tǒng)最終是給用戶用的，是有這些功能的，但是其他方面如果不能保障好，不能N個用戶一直用，那你這個系統(tǒng)就無法體現(xiàn)它的價值。這是非常重要的，很多剛剛工作幾年的，或者是一直在做產(chǎn)品研發(fā)的同學，對這方面沒有切身的體會，沒有在大晚上被人打電話說出了什么問題你趕緊來處理一下，沒有這樣切身的痛苦的體會。?

「高可用」到底是什么?

?

接下來我們說一下什么是高可用。CAP理論是指在分布式數(shù)據(jù)的場景來形容三者不可兼得，就是一致性、可用性和分區(qū)容忍性。在整個系統(tǒng)層面也可以這么理解，因為多數(shù)系統(tǒng)的核心就是數(shù)據(jù)，數(shù)據(jù)本身受限于這三個特性只能滿足兩個，不能三個一起滿足，整個系統(tǒng)也是如此。?

在互聯(lián)網(wǎng)場景里，因為數(shù)據(jù)量大分區(qū)容忍性是必須要支持的。一致性可以稍微容忍一些，但是可用性是一定要保證的。所以最后多數(shù)的互聯(lián)網(wǎng)公司多數(shù)的業(yè)務(wù)系統(tǒng)就是犧牲一致性，保證可用性和分區(qū)容忍性。?

我們繼續(xù)往下看，什么可以影響可用性。?

?

其次是人禍，攜程公司去年也發(fā)生了「慘案」，系統(tǒng)宕機一下午，一直到晚上才恢復(fù)；還有阿里云，去年上了一個云盾的功能，用戶在執(zhí)行可執(zhí)行文件的時候，就把這個可執(zhí)行文件給刪了，回頭用戶再找這個可執(zhí)行文件的時候就找不到了。還有是BUG，在某一些特定場景下系統(tǒng)出問題，這是很正常的。?

設(shè)計缺陷是要重點說的，它比BUG更宏觀一些，是結(jié)構(gòu)上的問題，不是說你增加幾個判斷，改一下代碼就可以解決的。基本上是屬于一旦發(fā)現(xiàn)了，要么就是大改，要么就是重構(gòu)，調(diào)整原來的設(shè)計，很難馬上去解決。?

至于說性能瓶頸和資源不足，大家知道就是這么多的服務(wù)器，如果代碼性能寫得好，可能能扛住更多請求，如果寫得差，可能稍微增長一些就不行了。?

性能瓶頸就是短板，比如說負責某個模塊是一個沒有什么經(jīng)驗的小同學，代碼質(zhì)量不太高，他就可能成為了整個系統(tǒng)的短板，這個模塊出了問題，其他的代碼寫得再好，整個系統(tǒng)還是不能用。?

?

最后還有一些未知的情況。大家做技術(shù)做的時間長會遇到很多無法解釋的「未解之謎」，我們一般稱之為「靈異事件」，這個是指經(jīng)常發(fā)生的，你不知道問題在哪里，但是過段時間就來一次，就好象冥冥之中有人玩你一樣，但是總歸是可以找到原因解決的。?

至于說黑天鵝的事件，則是以前從來沒有出現(xiàn)過的情況，突然出現(xiàn)了，讓你不知道應(yīng)該怎么辦，而且可能是一兩年才出現(xiàn)一次，你會要考慮值不值得找它如何出現(xiàn)的。?

還有一些以后就再也不出現(xiàn)了，誰也不知道是怎么回事，你就不知道怎么辦了。最后一個是未知的，我們不知道會出現(xiàn)什么樣的事情，出現(xiàn)的情況我們也不知道如何應(yīng)對。科學告訴我們，已知的我們可以去努力解決，但是未知的，我們無法判斷。?

?

關(guān)于系統(tǒng)故障，有一個海因法則，意思是說出現(xiàn)一起嚴重的事故，都是由很多的隱患，很多的小問題，或者說一些問題沒有暴露出來，最終引發(fā)特別大的事故。負責運維的同學都知道，公司對系統(tǒng)的可用性是有指標的，是99.9%還是99.99%，還是99.999%，如果說公司沒有這個東西壓著你作為KPI，那就太幸運了，出了問題不至于讓你拿不到獎金。如果說你的公司有，我希望研發(fā)和架構(gòu)的同學都要清楚，而不是只有運維的同學知道，否則就是公司管理不到位，舉個例子如果可用性標準是99.99%，一年系統(tǒng)可以掛的時間是53分鐘，99.999%則是5分鐘，大家想想就知道，攜程掛了一下午，整個可用指標就完不成了，KPI就完成不了。?

?

高可用同時是一個概率的問題。一個復(fù)雜的系統(tǒng)，比如說很多模塊或者子系統(tǒng)組成的系統(tǒng)，是可以通過一些方式大概去估算的。前些年云計算很火，很多人都說我們有一個云要自動運行，幾萬臺服務(wù)器必須要有自動恢復(fù)的系統(tǒng)，最好是分鐘級恢復(fù)，秒級恢復(fù)。這些都是一個概率，怎么去算呢？比如說我有兩個手機，最近一個月內(nèi)有3次差一點丟1臺手機，這是未遂事件，那么基本上我丟失的概率就確定了，比如說是1/30。我有兩個手機的話有什么好處，沒有手機用的概率就是1/900。但是丟手機的概率增加了，我就要做好心理準備，沒準哪天就會失去一個。?

多數(shù)系統(tǒng)是幾臺或者是幾十臺服務(wù)器組成一個小的集群，還有很多跟它平行和上下依賴的系統(tǒng)。這種系統(tǒng)都可以用這種方式去算，大概是什么樣的概率。?

這個還涉及到容量評估，要考慮系統(tǒng)負載是多少？比如說像我們以前做企業(yè)級系統(tǒng)用小型機，小型機的可靠性非常高，平時就是50%左右的負載，這個時候三四臺機器加在一起就夠用了，因為掛一臺基本上系統(tǒng)不會有太大影響。但是如果用不太可靠的PC服務(wù)器或者其他解決方式，因為擔心可能出現(xiàn)的狀況，所以現(xiàn)在很多互聯(lián)網(wǎng)公司采取的是常年運行10%的CPU或者是20%的CPU狀態(tài)。?

我們可以考慮一個系統(tǒng)，比如說一臺機器掛了，影響系統(tǒng)部分出現(xiàn)問題的概率有多高，多個系統(tǒng)總有一天會出問題，如果說系統(tǒng)足夠大，大家可以想像，無論是Facebook、谷歌，還是BAT基本上每天都會有各種各樣的小問題。所以越復(fù)雜的系統(tǒng)越是難以評估，我們要保證出現(xiàn)問題的時候可控。高可用并不是萬無一失，我們是用更多出問題的概率去降低整個系統(tǒng)出問題的概率。?

還有一個說法叫墨菲定律。基本上你想到的最壞的事情它總會發(fā)生的。上學的時候，數(shù)學老師會說，小概率事件基本上不會發(fā)生。但是在IT，在一個復(fù)雜環(huán)境當中，在上千臺上萬臺服務(wù)器的集群中，幾百人幾千人做的系統(tǒng)，一定會有一天出問題的。所以人算不如天算，你算出來概率很低，你保證我出問題的概率哪怕是幾十萬分之一，你覺得這輩子就趕不上了？不見得的。?

那么怎么辦？就是時刻準備著。這是我做了這么多年開發(fā)最大的體會。我們做的是一個7×24小時對外服務(wù)的系統(tǒng)，不能停。不能停的概念不是說像有的公司那樣，白天有人用，晚上沒人用，晚上出事了，我們來得及修補修補。但是像電商是7×24小時的，半夜三四點都有下單的。人家在熬夜開心下單的時候，你出了問題，阻止人家的下單，要不然就是打電話投訴，要不然是找地方吐槽。?

系統(tǒng)故障不僅是技術(shù)上的問題，最嚴重的是影響客戶體驗，前一段時間我們的評論系統(tǒng)出了點小問題：一個客戶買了一個面條機，反饋說并不是因為產(chǎn)品本身做不好面條要退貨，因為其他原因，這個因為產(chǎn)品已經(jīng)用過了所以按照規(guī)定是不能夠退貨的。結(jié)果用戶想評論的時候評論不了，用戶就覺得說當點擊評論按鈕時，系統(tǒng)告知接口錯誤，覺得這是在針對他，其實這只是系統(tǒng)故障，但是用戶并不會這么想。?

?

當你做了各種各樣的準備，覺得萬無一失了，難免有一天可能還是會翻船了。但是遇到這樣的事情也是好事，經(jīng)驗都是在這個時候積累起來的。那么什么是高可用？基本上就是三句話，降低故障出現(xiàn)的概率；縮小故障影響的范圍；出現(xiàn)故障快速恢復(fù)。不能因為是個小問題就覺得無所謂，反正我一堆的服務(wù)器，掛一個就掛一個吧，這種情況不好說會不會另外一個也掛了。因此有問題要盡快處理，最終的目的就是讓用戶可以正常的使用。?

如何設(shè)計高可用架構(gòu)?

?

高可用架構(gòu)設(shè)計常用的「姿勢」。大家看到這是一架飛機。我們有一個比喻說做運維這種系統(tǒng)，就是開著飛機修飛機。首先系統(tǒng)一直運行，其次運營、產(chǎn)品各種業(yè)務(wù)部門會不停提各種各樣需求，然后領(lǐng)導(dǎo)也許不懂技術(shù)，不懂什么叫分支、什么叫循環(huán)、什么叫面向?qū)ο?#xff1b;但是懂兩個詞，一個是敏捷，一個是迭代。?

所以做這件事情的時候難度是比較高的。我們不能讓這架飛機停下來歇幾天，把翅膀換了再飛上去；而是常年在天上飛的，飛上去的時候也許就是個阿帕奇直升機，特別是創(chuàng)業(yè)公司。回頭要拓展一個業(yè)務(wù)，增加一些功能，做著做著原來的業(yè)務(wù)不行了，新的業(yè)務(wù)變成了主營業(yè)務(wù)，結(jié)果變成了F15，從直升機變成了戰(zhàn)斗機，然后變成F16，變成F22。一旦技術(shù)團隊沒有做好，一頭栽下去，技術(shù)團隊的名聲就砸了。要么是沒做出來，要么是做出來之后一上線掛了，市場費用都白花了，這個責任要技術(shù)來承擔。?

我在四個領(lǐng)域里面分別提煉了幾條高可用相關(guān)的架構(gòu)方式。?

?

業(yè)務(wù)架構(gòu)就是指產(chǎn)品是什么功能，有什么要求。?

• 首先是領(lǐng)域切分，不要把雞蛋放在一個籃子里，比如說一些傳統(tǒng)網(wǎng)站，有非常多的二級域名。某一個二級域名掛了，都是不同的服務(wù)器，其他的還可以提供正常的服務(wù)。
• 系統(tǒng)分級，哪些系統(tǒng)對用戶來說比較重要，級別就會更高，我們就要花更多心思去保障，其他的相對差一些。
• 降低耦合，最近在架構(gòu)圈當中流行一個詞叫康威定律（編者注：Conway’s law: Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations），是指系統(tǒng)架構(gòu)是和公司組織架構(gòu)是有關(guān)系的。降低耦合也是如此，不要把系統(tǒng)搞得太復(fù)雜，你的組織和團隊不要和太多的部門打交道。優(yōu)化架構(gòu)，讓系統(tǒng)的關(guān)系盡可能的簡單、明確。這樣出現(xiàn)問題范圍可控。
• 有損服務(wù)是什么意思呢？可以犧牲一些用戶體驗來保證基本功能的可用。

系統(tǒng)架構(gòu)當中，分以下幾點。?

第一個是數(shù)據(jù)獨立，不允許跨系統(tǒng)訪問數(shù)據(jù)庫這個常識大家都懂，但是很多公司做不好，因為沒有強有力的措施去控制。這種事情做起來不太容易，需要管理或者說大家認可才行，但是實際上是非常關(guān)鍵的，因為數(shù)據(jù)如果不切分，系統(tǒng)很難切分，耦合就非常嚴重。時間長了出了問題，你連誰寫的，誰改的這個數(shù)據(jù)都不知道，那怎么辦？?
第二點是集群分布，這個就不提了。?
第三個是冗余部署。比如說電商業(yè)務(wù)是有波動的，每天的上午11點或者是下午4、5點訂單量都會增長，上班族都要休息一下，給自己的辛苦找一些心理安慰，這個時候開始購物。但不能說就這點增長就彈性部署一次。所以一定要有冗余，一般來講是3-5倍，保證哪怕突然來了一波流量你也可以扛得住。?
尤其是電商公司，可能會搞一些促銷，可能有的業(yè)務(wù)部門搞促銷的時候，沒有知會技術(shù)部門，覺得這個促銷沒什么，可能一兩天就搞定了，然后流量預(yù)估也就上來200%。但是萬一趕上這是網(wǎng)絡(luò)紅人、明星或者是小鮮肉出了書、發(fā)了唱片或者穿了什么衣服，一下子成了爆款，系統(tǒng)沒扛住，然后運營回頭就得抱怨白折騰了。?
第四個讀寫分離這個不用說了。?
技術(shù)架構(gòu)方面，仔細說一下。要是小公司出了什么問題，幾個人碰個頭，達成共識就可以了；但是一個上規(guī)模的公司，技術(shù)團隊幾百人甚至是上千人的團隊，如果技術(shù)層面控制不了的話，就會有非常嚴重的隱患。?

• 首先是選擇使用的技術(shù)平臺，有的公司java也有、PHP也有、Python、Go等等的什么都有。
• 其次是人員職能，有的公司說我們的工程師都要做全棧工程師，我們的工程師什么都會。創(chuàng)業(yè)團隊可以，但是一般成熟的公司都是專業(yè)分工，專業(yè)分工就來了一個問題，大家畢竟要對接，而且很多東西需要有人持續(xù)運維，因此就有必要統(tǒng)一技術(shù)標準。
• 第三點就是規(guī)范標準，比如說代碼、發(fā)布的規(guī)范都要有。如果說可以沉淀的話，以上說的規(guī)范是可以做成一個統(tǒng)一的框架，現(xiàn)在當當也在做一個框架。
• 還有就是合理的選型，一方面不同特性的技術(shù)需要用到合適的場景當中。另一方面不合適的技術(shù)選型一定要盡量堵住。因為現(xiàn)在很多同學都有非常高漲的學習熱情，新技術(shù)層出不窮。這樣的話很多人會犯一個「錘子心理」的錯誤。
• 比如說我最近在當當上買了一本書，花了兩個月看完，然后趕上做一個項目，我就覺得自己很懂了，英雄有了用武之地。錘子心理是什么意思呢？他有了一個錘子，看誰都是釘子，就想敲敲。這種情況是要控制的。
• 也許這個技術(shù)不是不能用，但是不是增加系統(tǒng)的負擔，公司能不能持續(xù)運營。比如招來一個牛人，這個牛人自己寫了一個框架，用了什么算法。用起來確實很好，但是過后牛人走了怎么辦？出了問題怎么辦？誰管？這種問題都是要考慮的。
• 還有就是持續(xù)集成。我們要從技術(shù)層面去保證多數(shù)測試都可以覆蓋到，不能說換一個測試或者是換一個開發(fā)就經(jīng)常犯一些重復(fù)的低級錯誤。

基礎(chǔ)架構(gòu)?

• 在一個完整的系統(tǒng)當中有一些和業(yè)務(wù)沒有關(guān)系的系統(tǒng)，比如運維平臺的存在，是為了降低運維的風險，同時也是為了提高效率，保證質(zhì)量。
• 比如統(tǒng)一監(jiān)控，那么大一個系統(tǒng)誰知道哪里有問題，哪里不正常，所以必須要統(tǒng)一監(jiān)控。
• 還有是壓測工具，比如雙十一，你有沒有信心？誰敢說？我們要進行測試，壓測之后我們說5倍沒問題，10倍沒問題。但是不壓測誰敢說？
• 還有就是流量控制。常見是分流和限流，如果說有一個頁面訪問量太大，可以分到類似的頁面去，更大的時候我們只能限流。

電商系統(tǒng)架構(gòu)?

?

這個圖是一個比較簡單的電商系統(tǒng)架構(gòu)，主要說說系統(tǒng)分層。最上面的點是展示，包括首頁、搜索、列表、活動專題頁這些東西，這個展示其實都是用戶查詢的，沒有操作，只要用戶可以看就可以了，這些數(shù)據(jù)是可以緩存，可以靜態(tài)化的，可以通過這樣的方式保證用戶訪問，可以把數(shù)據(jù)都緩存起來。比如說當當?shù)氖醉?#xff0c;是不依賴任何系統(tǒng)的，其他系統(tǒng)都掛了，首頁打開是沒有問題的，畢竟主站是最大的流量入口。?

還有第二點就是交易系統(tǒng)。和訂單系統(tǒng)是上下游的關(guān)系，交易系統(tǒng)是生成訂單的，訂單系統(tǒng)是處理訂單的。交易系統(tǒng)的訂單數(shù)據(jù)是存在自己的數(shù)據(jù)庫當中。為什么呢？因為好不容易用戶來了，終于下單了，一定要留住。訂單系統(tǒng)也很復(fù)雜，不能說因為訂單系統(tǒng)掛了，導(dǎo)致訂單無法生成了。所以生成訂單這件事情是在交易系統(tǒng)完成的。訂單系統(tǒng)可以異步去處理訂單，訂單系統(tǒng)出了問題，用戶該買還是可以買的，這是電商當中非常重要的。?

第三個是商品數(shù)據(jù)中心，就是為了應(yīng)對前面的這一堆面向用戶的訪問，我們的數(shù)據(jù)是單獨有一份只讀的對外提供，和后面的PIM系統(tǒng)是分開的。PIM是寫，這邊是讀。如果PIM掛了，沒有問題。后臺系統(tǒng)不會對前臺造成太大的影響。?

?

交易系統(tǒng)是最核心的，最大的使命是生成訂單。除了基本的生成訂單的功能，還可以做什么呢？第一就是要快！比如說促銷，這里沒有寫價格和庫存，價格和庫存都是敏感數(shù)據(jù)，要求盡可能準確的，我們都是實時的。但是促銷是可以緩存的，因為現(xiàn)在還不是系統(tǒng)智能去調(diào)整促銷策略的，都是靠人工設(shè)置的，節(jié)奏和頻率都是比較低的，緩存下來之后，基本上是OK的。避免促銷服務(wù)不穩(wěn)定對交易產(chǎn)生影響，如果用戶點半天沒有反應(yīng)，用戶就會走的，要降低依賴。?

還有一個交易單緩存，就是訂單生成之前的臨時數(shù)據(jù)，要選擇支付方式、要寫地址、要選擇是不是用紅包、抵用券、優(yōu)惠卡這些東西，選得差不多了，萬一客戶端瀏覽器崩潰了、網(wǎng)斷了或者是閃斷、交易系統(tǒng)應(yīng)用服務(wù)器某一個節(jié)點掛了，怎么辦？這是最重要的時刻，都已經(jīng)臨門一腳了，我們是有緩存的，數(shù)據(jù)量也不是很大，只要他在比較短的時間內(nèi)打開，填的東西還在，還可以順暢的往下走。這個也是非常重要的。我記得以前有的網(wǎng)站出了問題，要重新選一遍，那個時候覺得非常郁悶，除非這個東西非常需要，否則那就算了。?

電商數(shù)據(jù)模型?

?

這是電商最常見的數(shù)據(jù)模型，商家來發(fā)布商品、設(shè)置促銷、價格、庫存這些東西。用戶來瀏覽、收藏、加入購物車，最后下單。對于平臺電商來說，就會出現(xiàn)多個商家，商品要按照商家來分，訂單也要按照商家來分。但是對用戶來說，收藏、加購物車的商品還有訂單對應(yīng)的是多個商家。?

這個時候有一個非常明確的問題，比如查詢收藏列表，或者是商家管理他的商品的時候，怎么樣可以很快的處理？商品可能有幾千萬上億，肯定不會放在一個數(shù)據(jù)庫里，多個數(shù)據(jù)庫，按什么分？后邊按商家分，前邊按用戶分，中間兩套數(shù)據(jù)庫。?

說起來邏輯其實挺簡單，但是很多創(chuàng)業(yè)公司沒有琢磨過這個事，中間就是一個庫，上面設(shè)一個索引，數(shù)據(jù)量小還沒有問題，一旦大了怎么辦？覺得這是解決不了的問題。?

進一步來說，這只是一個場景，還有一些更具體的場景。比如說我們剛剛提到購物車或者是收藏夾，如果在購物車或者是收藏夾，商品數(shù)據(jù)不按照用戶來分，也不按照商家分，就按照商品ID來分，均勻的分布在我們的數(shù)據(jù)層是不是可行？?

這個邏輯在平時也許沒有問題，但是電商有一個說法叫爆品，大家可以想像一下，平時是沒有問題的，正常下單正常瀏覽，一旦出現(xiàn)爆品，就會出現(xiàn)熱點數(shù)據(jù)。爆品所在的數(shù)據(jù)分片會被用戶集中瀏覽，熱點問題沒有辦法解決就是設(shè)計缺陷。再怎么分，那一個商品就在一個庫當中，你也不能把它一劈兩半。就是我剛剛說的，可能突然爆發(fā)一下，時間也不長，但是你扛不住，扛不住怎么辦？我們一會兒再說。?

?

資源隔離重點保障，這也是很重要的。比如商品數(shù)據(jù)中心給前臺提供商品數(shù)據(jù)，是分成三個集群的。那邊的是網(wǎng)站，這邊是App，這邊是購物車和交易，各自都有自己的緩存和數(shù)據(jù)庫，數(shù)據(jù)完全一樣的。為什么要分開？和剛剛說的一樣，首先交易下單是最關(guān)鍵的而且性能要保證，不能受到其他場景的影響。其次移動端也非常重要，大家都是在手機上操作，其實對速度是非常關(guān)注的，不能因為網(wǎng)站流量大了，導(dǎo)致手機瀏覽緩慢，甚至可以掛掉一個集群，其他的還正常，其實就是不要把雞蛋放到一個籃子里。用空間換時間，用時間換空間。?

通過框架來樹立開發(fā)規(guī)范?

?

我們做的一個框架叫ddframe，這是我們技術(shù)層面想做的事情。很多的互聯(lián)網(wǎng)公司開發(fā)平均工作經(jīng)驗有3年就不錯了。因為這幾年各種創(chuàng)業(yè)公司比較多，膨脹的也很厲害，要找一些有經(jīng)驗的工程師很難。很多開發(fā)同學沒有經(jīng)歷過各種慘痛教訓，開發(fā)都是比較隨意的，因此我們需要做一個開發(fā)的框架去給他們做一些規(guī)范的事，能夠有效的去幫助他們，盡量不去做一些出格的事情，因此我們做了ddframe。?

框架有幾個模塊：包括最核心的部分、包括和監(jiān)控的對接、SOA的部分DubboX、還有作業(yè)框架elastic-job、以及分布式數(shù)據(jù)庫中間件sharding-JDBC。?

Dubbox是我們在Dubbo的層面做了二次開發(fā)，現(xiàn)在有不少公司在用，這個部分把一般的服務(wù)注冊、軟負載、路由都搞定了。?

elastic-job是分布式作業(yè)調(diào)度框架。采用分布式作業(yè)調(diào)度框架前有什么問題呢？第一個是怎么實現(xiàn)避免單點，很多人是這樣做的，兩臺機器都部署，其中一臺crontab注釋一下，一臺機器出問題了，就去另外那臺機器上把注釋去掉，這是非常低效的，而且是完全靠人的。機器多了怎么辦？因此我們需要分布式的作業(yè)調(diào)度。這是我們?nèi)ツ觊_發(fā)的，最近唯品會在我們的早期版本基礎(chǔ)上，自己做了一個內(nèi)部的作業(yè)調(diào)度平臺，當然也歡迎大家使用。我們?yōu)槭裁醋约鹤?#xff0c;為什么不用TBSchedule，是因為我們發(fā)現(xiàn)沒有特別合適的，所以自己做。?

第二個模塊就是RDB，就是分布式數(shù)據(jù)庫問題，和高可用關(guān)系不太大，不詳細介紹。總體而言，我們是想通過統(tǒng)一的框架、技術(shù)組件降低開發(fā)人員實現(xiàn)的復(fù)雜度，減少風險，不給他們找麻煩。?

有了框架就有了工具，有了工具就有了共同的語言。大家可以回想一下歷史課，秦始皇統(tǒng)一六國之后做了什么，統(tǒng)一度量衡、錢幣、文字。有了這些統(tǒng)一的東西，大家互相之間比較容易交流、積累經(jīng)驗，如果說某個團隊比較閑了，也可以支持別的團隊，有人在某個團隊膩了，可以去其他的團隊。?

運維與監(jiān)控?

?

原來我們有一個運維平臺，但是去年技術(shù)圈出現(xiàn)了那么多的各種事件，運維經(jīng)理說運維太重要也太危險了，因此我們做了一個強制的生產(chǎn)環(huán)境灰度發(fā)布，不允許你一鍵發(fā)布，給大家一個緩沖。自動備份也是非常重要的，如果說你發(fā)現(xiàn)灰度發(fā)布第一個節(jié)點就報錯了，你要做的事情就是回滾。?

?

接下來是監(jiān)控。監(jiān)控是一個很大的系統(tǒng)，非常的重要。一個好的監(jiān)控系統(tǒng)可能更牛，因為就算是24小時都有運維的同學，但是運維同學也有打盹的時候，或者是沒注意。經(jīng)常我們會在電影當中看到，某一個大盜進入到某一個大廈當中，保安就在那里喝個茶什么的，保安沒看到。這種事情是經(jīng)常會有的。?

而且有了監(jiān)控就有了數(shù)據(jù)，監(jiān)控不一定觸發(fā)報警，但是你有了數(shù)據(jù)之后可以看趨勢。比如說最重要的一點–預(yù)算。我們今年要采購多少臺服務(wù)器，多數(shù)是拍腦袋拍出來的，業(yè)務(wù)說我們今年業(yè)務(wù)量增加30%，我們多采購30%的服務(wù)器，就是這么拍腦袋拍出來的，其實這個是不準確的。?

如果系統(tǒng)在某些場景下有嚴重的性能衰竭，需要去評估，或者要去看，不同的業(yè)務(wù)模式會對系統(tǒng)造成不同的壓力。比如有的系統(tǒng)今年負載反而下降了，就往下減服務(wù)器。有的可能增加200%，原來10%的負載，現(xiàn)在變成了30%了，那么這種，哪怕你的業(yè)務(wù)增長30%，這個壓力還是增長200%。這是什么概念？之前是10%到30%，現(xiàn)在就是30%到90%了。你只有有了這些數(shù)據(jù)，才可以合理的去估算。?

大促或者出現(xiàn)爆品時怎么辦?
相信在上海的同學也都遇到過這樣的情況。在地鐵站，高峰時限流，用欄桿把人擋住。限流基本上是電商標配，以前沒有，所以動不動就掛了。現(xiàn)在成熟了，如果出現(xiàn)了爆品，出現(xiàn)了熱點數(shù)據(jù)怎么辦？?

你不能說流量一來你就掛了，這個時候限流就非常重要了。舉例來說可以扛得住8000，8000以外的就攔住，不讓進來。比如淘寶去年雙十一零點之后的幾分鐘，有人手機淘寶進不去，或者是支付寶支付不了，就在朋友圈里發(fā)截圖說淘寶又掛了，但是沒有多少人回應(yīng)，因為多數(shù)人是可以使用的，他剛好倒霉，是被限流了。有了限流今天來10倍就10倍，來20倍沒有辦法，但是系統(tǒng)扛得住，把其他的流量扔了，保證了基本的收入。?

那么最后我們該做的事情都做了，還能怎么辦呢？就只能求佛祖保佑了。這種時候有信仰也許會對你的系統(tǒng)可用性指標有點幫助。不管有沒有用，我們可以努力一下，在自己的代碼注釋當中放上一個佛祖保佑一下。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/5340650.html

總結(jié)

以上是生活随笔為你收集整理的当当网高可用架构之道--转的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。