近日Velocity China 2016在京舉行，會(huì)上阿里中間件技術(shù)部資深技術(shù)專家丁宇（花名叔同）發(fā)表了題為《零點(diǎn)之戰(zhàn)–阿里雙11高可用架構(gòu)演進(jìn)之路》的演講。丁宇從2009年開始，參加了每年的阿里雙11技術(shù)保障工作， 最近兩年他分別以共享平臺(tái)事業(yè)部雙11項(xiàng)目負(fù)責(zé)人，和集團(tuán)雙11項(xiàng)目穩(wěn)定性總負(fù)責(zé)人的身份參與其中。
阿里巴巴平臺(tái)的業(yè)務(wù)規(guī)模在過去的8年呈指數(shù)級(jí)增長(zhǎng)，給雙11所帶來的技術(shù)挑戰(zhàn)是世界性的，特別是如何在零點(diǎn)峰值到來時(shí)確保系統(tǒng)的穩(wěn)定性。零點(diǎn)技術(shù)挑戰(zhàn)的本質(zhì)是用有限的成本去實(shí)現(xiàn)最大化的集群整體吞吐能力和最佳的用戶體驗(yàn)，并取得二者之間的平衡。阿里在解決這些問題的時(shí)候沒有參考和借鑒的對(duì)象，只能自我創(chuàng)新。阿里技術(shù)團(tuán)隊(duì)在 8年雙11歷練中沉淀了很多技術(shù)產(chǎn)品，其中高可用方面的中間件技術(shù)，經(jīng)歷了幾代架構(gòu)的演進(jìn)和優(yōu)化越來越成熟，且在阿里雙11技術(shù)保障中起到的作用越來越大。丁宇從擴(kuò)展性、線上的容量規(guī)劃、成本增速過快、精細(xì)化運(yùn)行控制和線上穩(wěn)定性治理等方面進(jìn)行了闡述。
對(duì)于未來的挑戰(zhàn)，丁宇則認(rèn)為還有很多可以優(yōu)化的地方，他歸納為精細(xì)化、數(shù)據(jù)化及智能化三方面，及從容量確定性到資源的確定性；更加精細(xì)化的分析和預(yù)測(cè)流量模型及業(yè)務(wù)模型；技術(shù)變量的采集、分析、預(yù)測(cè)，通過數(shù)據(jù)分析驅(qū)動(dòng)，自主決策處理等，最終在用戶體驗(yàn)、成本控制和最大系統(tǒng)吞吐能力之間找到新的平衡點(diǎn)。
丁宇：大家好！我今天演講的主題是《零點(diǎn)之戰(zhàn)–阿里雙11高可用架構(gòu)演進(jìn)之路》。大家知道，規(guī)模和場(chǎng)景是驅(qū)動(dòng)技術(shù)發(fā)展的關(guān)鍵要素。阿里做了8年雙11，業(yè)務(wù)規(guī)模有上百倍的增長(zhǎng)，系統(tǒng)的復(fù)雜度和大促支撐難度更是以指數(shù)級(jí)攀升。隨著規(guī)模的增加，技術(shù)挑戰(zhàn)也非常不一樣，后面會(huì)展開講。這是一個(gè)世界級(jí)的場(chǎng)景，雙11最難的就是保障零點(diǎn)峰值的穩(wěn)定性，我們把它當(dāng)做一場(chǎng)戰(zhàn)爭(zhēng)來打，是一場(chǎng)不能輸?shù)膽?zhàn)爭(zhēng)。面對(duì)世界級(jí)的難題，在業(yè)界沒有什么可以參考和借鑒的對(duì)象，所以我們都是自主創(chuàng)新，沉淀了很多技術(shù)產(chǎn)品，高可用性的產(chǎn)品，經(jīng)歷了幾代的架構(gòu)演進(jìn)，今天我會(huì)選取一部分跟大家做個(gè)交流。下面是我的個(gè)人介紹，和聯(lián)系方式。
我們看一下整個(gè)雙11的技術(shù)挑戰(zhàn)是什么，大家知道做雙11非常難,但是究竟難在什么地方？阿里內(nèi)部有一句話:雙11是業(yè)務(wù)的狂歡、技術(shù)的盛宴。阿里做了8年雙11，這8年見證了電商業(yè)務(wù)的飛速發(fā)展，我們看一下業(yè)務(wù)指標(biāo)變化。雙11交易額從2009年的5.9億到2016年，半個(gè)月以前的雙11交易額達(dá)到1207億，實(shí)現(xiàn)了200倍的增長(zhǎng)。交易峰值從2009年的400筆每秒，到2016年17.5萬筆每秒，增長(zhǎng)了400多倍。系統(tǒng)規(guī)模也有幾十倍、上百倍的增長(zhǎng)。
在這一塊面臨著什么問題？首先面臨的是系統(tǒng)擴(kuò)展性的問題，規(guī)模增長(zhǎng)了數(shù)百倍，系統(tǒng)是不是能水平擴(kuò)展以支撐數(shù)百倍的增長(zhǎng)？這是我們面臨的首要難題。
雙11零點(diǎn)技術(shù)挑戰(zhàn)的本質(zhì)是什么？是用較低的成本去實(shí)現(xiàn)最大化的吞吐量和最佳的用戶體驗(yàn)，三者取得一個(gè)平衡，用合理的代價(jià)來解決零點(diǎn)峰值,支持好業(yè)務(wù)的狂歡，保證業(yè)務(wù)系統(tǒng)平穩(wěn)運(yùn)行。如果不限成本做這件事，難度會(huì)降低非常多。我們用有限成本來做這件事就會(huì)面臨一個(gè)問題，集群規(guī)模、機(jī)器數(shù)、機(jī)房資源都是固定的，怎么能把資源最合理的分配下去？假設(shè)有500個(gè)系統(tǒng)，要一起來支持雙11，要做一個(gè)非常極致的容量規(guī)劃，把硬件資源能夠非常均勻地分配給每一個(gè)應(yīng)用，讓整個(gè)集群整個(gè)技術(shù)鏈條上沒有瓶頸，這就是容量領(lǐng)域最大的挑戰(zhàn)。因?yàn)槿绻幸粋€(gè)地方存在短板，整個(gè)系統(tǒng)就沒法做到最大化吞吐量，所以要求有一個(gè)極致的容量規(guī)劃。
雙11的不確定性來自于什么呢？還是來自于所有技術(shù)變量的疊加，如果業(yè)務(wù)不變，系統(tǒng)架構(gòu)不變，技術(shù)也不升級(jí)，那難度會(huì)越來越小。但是所有事情都在變，好多變量，比如說用戶的流量會(huì)發(fā)生很大的變化，有很大的增量，峰值流量的構(gòu)成、還有系統(tǒng)架構(gòu)的變化會(huì)帶來很多不確定。流量的組成部分有哪些用戶來源，哪些業(yè)務(wù)模型會(huì)讓峰值的流量和壓力不同。包括CPU利用率，這些會(huì)影響到整體，因?yàn)檎麄€(gè)系統(tǒng)是在非常高的水位情況下運(yùn)行的，又要運(yùn)行平穩(wěn)、整體全鏈條沒有短板，所以對(duì)線上要實(shí)現(xiàn)非常精細(xì)化的運(yùn)行控制，還要有很強(qiáng)大的穩(wěn)定性治理能力，這又是一個(gè)挑戰(zhàn)。
零點(diǎn)峰值對(duì)我們來說有什么意義？這個(gè)意義非常巨大。它可以讓技術(shù)實(shí)現(xiàn)能力有個(gè)推動(dòng)力，推動(dòng)架構(gòu)優(yōu)化，加速技術(shù)演進(jìn)和沉淀，催生技術(shù)創(chuàng)新，所以雙11也是技術(shù)的盛宴。
針對(duì)這幾個(gè)挑戰(zhàn)，我今天分成幾個(gè)部分：如何解決業(yè)務(wù)增長(zhǎng)情況下擴(kuò)展性的問題、如何解決線上容量規(guī)劃的問題、如何解決成本增速很快的問題、如何做精細(xì)化的運(yùn)行控制、如何治理線上穩(wěn)定性。
先講一下淘寶架構(gòu)的發(fā)展背景，2007—2008年這兩年，是從集中式架構(gòu)快速演變?yōu)榉植际降募軜?gòu)。大家已經(jīng)非常熟悉這套架構(gòu)，現(xiàn)在一般的互聯(lián)網(wǎng)應(yīng)用，互聯(lián)網(wǎng)系統(tǒng)都會(huì)采用這樣的分層架構(gòu)，業(yè)務(wù)上分層，通過分布式中間件進(jìn)行遠(yuǎn)程消息傳遞、遠(yuǎn)程服務(wù)調(diào)用，中間提供一層共享中心，把公共業(yè)務(wù)邏輯抽象成平臺(tái)，抽象成服務(wù)中心，不直接對(duì)用戶暴露接口，提供一種服務(wù)能力，中間會(huì)有緩存，底層有存儲(chǔ)集群，這是非常常見的架構(gòu)，在2008年整個(gè)架構(gòu)演變到這個(gè)程度，到現(xiàn)在為止架構(gòu)也沒有發(fā)生太大變化。
隨著場(chǎng)景的遞增、體量的激增帶來了很多別的問題，是這套架構(gòu)不能解決的，后面會(huì)逐步展開。在這個(gè)演變的過程中，我們沉淀了大量的中間件技術(shù)產(chǎn)品，這里就像一個(gè)大廈，系統(tǒng)之間的交互，分布式環(huán)境下的交互，包括一致性協(xié)調(diào)、負(fù)載均衡工作都是由中間件完成的，中間件就相當(dāng)于大廈的框架結(jié)構(gòu)和管道，中間件的沉淀對(duì)后面的架構(gòu)演進(jìn)打了非常好的基礎(chǔ)。
在這個(gè)架構(gòu)改造完成后，早期雙11的規(guī)模增長(zhǎng)問題還沒有那么明顯，我們面臨著很多其他問題，其中就包括系統(tǒng)可用性。因?yàn)槲覀冇?0個(gè)系統(tǒng)快速拆成100個(gè)系統(tǒng)，然后分層，水平拆分、垂直切分，面臨著治理的問題。以前出現(xiàn)問題知道是一個(gè)系統(tǒng)導(dǎo)致的，可以快速回滾變更恢復(fù)，現(xiàn)在是100個(gè)系統(tǒng)，很難定位問題根源在哪里。好多系統(tǒng)發(fā)布、變更了，也沒辦法快速恢復(fù)，失去了先恢復(fù)后定位的能力，這是我們面臨的挑戰(zhàn)。當(dāng)時(shí)存儲(chǔ)層還有很多IOE技術(shù)組件，從2009年開始去IOE，存儲(chǔ)這一層也把它升級(jí)成可以水平擴(kuò)展的架構(gòu)。
那個(gè)時(shí)候整個(gè)機(jī)房會(huì)遇到很多不穩(wěn)定的情況，不知道有多少人當(dāng)年也在做同樣的事情，網(wǎng)絡(luò)、電力都有不穩(wěn)定的情況，很普遍，我們做 了同城容災(zāi)和異地冷備的架構(gòu)迭代。同城兩個(gè)機(jī)房，各承擔(dān)50%的流量，數(shù)據(jù)庫(kù)也放在兩邊一主一備。一個(gè)機(jī)房出問題的時(shí)候可以進(jìn)行數(shù)據(jù)庫(kù)、流量的切換，這是同城容災(zāi)的方案。
這套架構(gòu)逐漸在雙11碰到了很多問題，當(dāng)規(guī)模增長(zhǎng)的時(shí)候，對(duì)機(jī)房體量要求越來越大，要有很大的規(guī)模。分布式架構(gòu)下，比如說A集群要對(duì)B集群有服務(wù)依賴調(diào)用，規(guī)模都是5千臺(tái)，大家知道負(fù)載均衡的機(jī)制，需要建立連接。五千對(duì)五千，連接數(shù)在超級(jí)機(jī)房下是一個(gè)很大的挑戰(zhàn)。數(shù)據(jù)庫(kù)也一樣，你規(guī)模達(dá)到了一萬臺(tái)，每臺(tái)都要建立連接。單機(jī)房無法承載業(yè)務(wù)系統(tǒng)規(guī)模的增量，擴(kuò)展性是在中間件這一層受到限制。
IDC的資源也存在限制，一個(gè)城市沒有辦法支撐我們的體量，這是物理限制。包括本地容災(zāi)問題，臺(tái)風(fēng)、電力導(dǎo)致問題，告訴你2小時(shí)后就拉閘限電，技術(shù)沒準(zhǔn)備好切換，業(yè)務(wù)就會(huì)受損。還有國(guó)際化部署的問題，需要把業(yè)務(wù)集群部署出去。這些挑戰(zhàn)要求我們由同城走到異地。
我們?nèi)ビ^察整個(gè)阿里電商的業(yè)務(wù)，它的數(shù)據(jù)模型，有這樣一個(gè)方案。建設(shè)異地單元機(jī)房，在地域上可以相互容災(zāi)，異地大量調(diào)用的時(shí)延問題是一個(gè)巨大挑戰(zhàn)。大家可以算一下，北京到上海調(diào)用一個(gè)RTT需要多少毫秒，一次調(diào)用可以接受，如果每個(gè)請(qǐng)求調(diào)用500次是絕對(duì)不能接受的。所以單元內(nèi)要做調(diào)用封閉，必須在單元內(nèi)完成所有的業(yè)務(wù)請(qǐng)求交互。同時(shí)要按用戶的維度去切分單元流量，這樣就可以實(shí)現(xiàn)水平擴(kuò)展，什么規(guī)則的用戶在哪個(gè)單元來處理他的業(yè)務(wù)請(qǐng)求。
我們分析整個(gè)阿里業(yè)務(wù)模型，分為買家數(shù)據(jù)、賣家數(shù)據(jù)，發(fā)現(xiàn)賣家數(shù)據(jù)體量適中，而且更新不那么頻繁。買家數(shù)據(jù)會(huì)創(chuàng)建很多交易訂單，數(shù)據(jù)規(guī)模和訪問量很大，比賣家要大一個(gè)數(shù)量級(jí)。要保持每個(gè)單元的封閉，需要去切分買家集合，賣家數(shù)據(jù)集合小可以同步到各個(gè)單元，選擇這樣一個(gè)方案。在數(shù)據(jù)層實(shí)現(xiàn)數(shù)據(jù)同步，達(dá)到一致性，保證業(yè)務(wù)在單元內(nèi)的封閉調(diào)用。
做完就是現(xiàn)在這么一個(gè)架構(gòu)?？梢园从脩羧我饩S度進(jìn)行路由，運(yùn)用不同規(guī)則路由到不同的單元機(jī)房，在單元內(nèi)實(shí)現(xiàn)業(yè)務(wù)的閉環(huán), 解決了請(qǐng)求時(shí)延的問題。后續(xù)擴(kuò)展性就很好做了，容量不夠再建一個(gè)單元，因?yàn)閱卧獌?nèi)閉環(huán)，所以可以建到更遠(yuǎn)的地方去，體量就不再是限制了。
每一層，每個(gè)單元都有完整的部署，當(dāng)然也會(huì)有跨單元請(qǐng)求的情況存在，有一些服務(wù)調(diào)用、消息同步，包括底層的數(shù)據(jù)同步一直都在做，而且量很大，要保證每個(gè)單元的數(shù)據(jù)合法、一致，完成業(yè)務(wù)全鏈條的封閉。
這套架構(gòu)對(duì)我們有什么幫助？首先它消除了IDC資源單點(diǎn)和容量單點(diǎn)的問題，容量瓶頸解決了，不會(huì)受地域的限制。也解決了異地容災(zāi)的問題，可以快速建一個(gè)單元，快速把流量切走。當(dāng)一個(gè)地域性問題出現(xiàn)的時(shí)候，可以快速把流量切走，這個(gè)問題就恢復(fù)了，等地域性問題恢復(fù)，流量再切回來，日常可用性的保障就有了很好的提升。容量規(guī)劃這件事也因此簡(jiǎn)化了,一個(gè)單元有固定的處理能力。然后可以快速?gòu)?fù)制一個(gè)單元，可以小體量驗(yàn)證，逐個(gè)單元批量復(fù)制，整體容量和擴(kuò)展性就變得簡(jiǎn)單了。同時(shí)提升了可運(yùn)維性，單元可以快速拉起、下線、遷移。這個(gè)問題的解決為后續(xù)的架構(gòu)演進(jìn)，打下了很好的基礎(chǔ)。
看一下容量規(guī)劃是怎么做的，這也經(jīng)歷了幾個(gè)階段的演進(jìn)。一般來講，要做容量一定要先掌握應(yīng)用性能基線，比方說500個(gè)系統(tǒng)，每一個(gè)系統(tǒng)的性能基線都要掌握。最開始的時(shí)候，在線下開始做，使用很多常見的壓測(cè)工具。當(dāng)然受限于環(huán)境因素，線下環(huán)境很難打造一個(gè)完備的、跟線上非常相似的環(huán)境。我們通過壓側(cè)得到這個(gè)應(yīng)用的性能基線，然后準(zhǔn)備一個(gè)容量模型，通過基線吞吐量去計(jì)算將來有多大流量，在保持一定水位的前提下，可以知道在雙11的時(shí)候應(yīng)用怎么做容量規(guī)劃。
這個(gè)計(jì)算模型好幾年都沒有變過，一直在變的一個(gè)事情是，如何測(cè)試這個(gè)應(yīng)用的基線吞吐量能力。經(jīng)歷了幾個(gè)階段，線下是一個(gè)階段，我們發(fā)現(xiàn)線下非常不準(zhǔn)，然后又走到線上。如何使用線上環(huán)境不影響用戶？得到一個(gè)高水位下的吞吐能力表現(xiàn)。采用線上引流的方式，無論存儲(chǔ)層、服務(wù)層還是Web應(yīng)用這一層，都是用線上引流，依賴于中間件，自研的中間件負(fù)載均衡，還有反向代理都有流量代理的能力。如果有一百臺(tái)服務(wù)器，把其中80臺(tái)的流量一點(diǎn)一點(diǎn)引到某10臺(tái)上去，看在不同的流量壓力下，系統(tǒng)負(fù)載的增加，用戶響應(yīng)時(shí)間的變化，三者之間的關(guān)系，把這張圖畫出來，這就比線下做這件事情精準(zhǔn)度高很多，也逼近想要的結(jié)果，這就是我們線上壓測(cè)的架構(gòu)。我們?cè)u(píng)估出來基線能力然后做容量規(guī)劃，這是一個(gè)階段。
這個(gè)階段很快就遇到了挑戰(zhàn)，大家知道，早年在雙11買東西時(shí)會(huì)遇到有一些大的、小的問題，跟容量規(guī)劃不準(zhǔn)有很大的關(guān)系。容量規(guī)劃的目的是評(píng)估用戶登陸、添加購(gòu)物車、購(gòu)買整個(gè)鏈條如何合理分配資源。剛才說一個(gè)應(yīng)用雙11加多少機(jī)器，根據(jù)對(duì)雙11業(yè)務(wù)的理解來分配，這樣做規(guī)劃。這種流量規(guī)劃是不是合理的？我們發(fā)現(xiàn)差距還是蠻大的，真正雙11零點(diǎn)峰值的實(shí)際流量，與我們的規(guī)劃差距比較大。
500多個(gè)核心系統(tǒng)，技術(shù)鏈條長(zhǎng)、業(yè)務(wù)入口多、邏輯復(fù)雜，如果人來梳理難免會(huì)有各種各樣的偏差。整個(gè)鏈條上瓶頸點(diǎn)比較多，因?yàn)闆]有驗(yàn)證過，問題會(huì)比較多。無法提前發(fā)現(xiàn)問題，雙11峰值真正來的時(shí)候發(fā)現(xiàn)已經(jīng)晚了，需要應(yīng)急措施來處理這些問題。這個(gè)規(guī)劃方法是堆積木的方法，拼出來整個(gè)集群配比，人的判斷在里面起了很大的作用，往往都是不靠譜的。我們發(fā)現(xiàn)做容量規(guī)劃不應(yīng)該是一個(gè)一個(gè)應(yīng)用系統(tǒng)去看，應(yīng)該是一個(gè)業(yè)務(wù)鏈條整體去看。
如圖所示，整個(gè)線上關(guān)系比這個(gè)復(fù)雜得多，這只是一個(gè)樣例，上游調(diào)用方有十幾二十個(gè)，下游依賴方有十幾二十個(gè)，每個(gè)調(diào)用方輕微的差異變化就會(huì)對(duì)這個(gè)集群產(chǎn)生疊加效應(yīng)，變化會(huì)放大，所以這個(gè)非常不準(zhǔn)。我們?nèi)狈︱?yàn)證整個(gè)鏈條實(shí)際承載能力的手段，這是遇到的很大的挑戰(zhàn)。
我們提出需要一個(gè)驗(yàn)證方案，雙11是屬于有限場(chǎng)景，真正流量的沖擊只在幾個(gè)流量入口，可能是20個(gè)流量入口，整個(gè)洪峰流量關(guān)系是可以梳理出來的，每個(gè)鏈條一起來驗(yàn)證它的容量是不是符合預(yù)期，有這樣一個(gè)方案設(shè)計(jì)。我們希望在線上來做，用大規(guī)模的流量去壓測(cè)，從IDC到網(wǎng)絡(luò)、中間件、應(yīng)用、緩存、數(shù)據(jù)庫(kù)，所有基礎(chǔ)設(shè)施能夠用同樣的流量模型來驗(yàn)證，這也要求在線上做，而且要做海量請(qǐng)求，跟雙11同樣的流量驗(yàn)證整個(gè)集群的實(shí)際能力。
要自定義一個(gè)工具，業(yè)界所有的流量工具都滿足不了規(guī)模的需求，所以要自己創(chuàng)造。同時(shí)業(yè)務(wù)模型和流量模型要非常精準(zhǔn)，跟雙11非常像，基于線上數(shù)據(jù)、測(cè)試數(shù)據(jù)結(jié)合構(gòu)造一套特殊模型，大體量、大規(guī)模、非常逼真。如果字段是空的、假的，執(zhí)行過程中對(duì)字段計(jì)算的消耗就是受限的、是不真實(shí)的，所以要達(dá)到非常嚴(yán)苛的擬真度。還要求在線上做讀、寫、創(chuàng)建、支付操作，同時(shí)絕對(duì)不能影響用戶，壓測(cè)數(shù)據(jù)、正常數(shù)據(jù)不能混在一起，用戶要做到無感知。要把系統(tǒng)所有瓶頸暴露出來，我們?cè)O(shè)計(jì)了這樣一個(gè)方案。
這里大量利用了之前沉淀的中間件體系。我們構(gòu)造了一個(gè)分布式流量引擎，把它部署在全國(guó)阿里的CDN上，阿里CDN規(guī)模非常大，這滿足了發(fā)出大流量的要求，可以反壓阿里機(jī)房，產(chǎn)生巨大的壓力，一秒達(dá)到上千萬的QPS。在數(shù)據(jù)模型的構(gòu)造上花了很大心思，每年會(huì)不斷迭代，讓它更加逼近真實(shí)。同時(shí)對(duì)用戶的流量進(jìn)行了很好的數(shù)據(jù)化分析，真正模擬雙11當(dāng)時(shí)的用戶流量，結(jié)合這份數(shù)據(jù)推送到壓測(cè)引擎里，然后從遠(yuǎn)端發(fā)起壓力。
整個(gè)鏈條覆蓋很長(zhǎng)，和客戶端一樣建立鏈接，整個(gè)覆蓋鏈條跟用戶訪問基本上是一樣的。做的是線程級(jí)隔離，每個(gè)線程處理的可能是測(cè)試請(qǐng)求，也可能是正常用戶請(qǐng)求，請(qǐng)求間互相無感知，數(shù)據(jù)不會(huì)共享。同時(shí)對(duì)數(shù)據(jù)存儲(chǔ)層進(jìn)行了隔離，也不會(huì)做全網(wǎng)的業(yè)務(wù)，只覆蓋雙11最重要的業(yè)務(wù)場(chǎng)景，這樣風(fēng)險(xiǎn)比較可控，暴露問題也更加精準(zhǔn)有針對(duì)性。
全鏈路壓測(cè)是一個(gè)劃時(shí)代的容量規(guī)劃技術(shù)，壓測(cè)演練過程中發(fā)現(xiàn)很多瓶頸，無論是容量調(diào)配問題、性能問題還是隱藏bug。并發(fā)的問題只有在大流量下才會(huì)暴露，小流量的線下測(cè)試，受限場(chǎng)景下是驗(yàn)不出來的，所以用這套方案，容量也可以調(diào)整，問題也可以暴露，我們每年用這個(gè)壓測(cè)方案可以發(fā)現(xiàn)上千個(gè)問題，很多問題是非常致命的，如果雙11的時(shí)候爆發(fā)都是不能承受的。
這個(gè)方案有什么意義，它打破了對(duì)于不可預(yù)知技術(shù)風(fēng)險(xiǎn)的控制能力，加速技術(shù)的進(jìn)化。怎么理解？我們?cè)诙虝r(shí)間內(nèi)可以大膽創(chuàng)新，大膽上新技術(shù)，更加激進(jìn)。因?yàn)橛幸惶妆５追桨?，無論做多少創(chuàng)新，可以做到幾個(gè)月升級(jí)一次架構(gòu)，新技術(shù)幾個(gè)月推到全網(wǎng)。因?yàn)殡p11要的是容量確定性,比如說要準(zhǔn)備17.5萬的能力，什么技術(shù)都可以嘗試，最后通過線上演練，大流量全鏈路壓測(cè)，看能不能達(dá)到17.5萬。能達(dá)到技術(shù)是過關(guān)的，整體能力也是過關(guān)的，所以加速了技術(shù)的進(jìn)化。
它能做到主動(dòng)發(fā)現(xiàn)問題而不是被動(dòng)等待，如果零點(diǎn)發(fā)現(xiàn)了再應(yīng)急處理，應(yīng)急處理往往是很被動(dòng)的，而且容易忙中出錯(cuò)。應(yīng)急出現(xiàn)的問題往往是預(yù)期不到，沒有很好的手段去解決。比如說出現(xiàn)了數(shù)據(jù)問題， 寫個(gè)腳本對(duì)數(shù)據(jù)做后臺(tái)更新，這可能會(huì)產(chǎn)生更悲劇的事情，所以要減少應(yīng)急的情況，盡量做到全都是確定的，有什么大招都是測(cè)試驗(yàn)證過的，這也是我們的經(jīng)驗(yàn)。這種壓測(cè)演練方式為我們穩(wěn)定性的確定性打下了堅(jiān)實(shí)的基礎(chǔ)。
看一下成本優(yōu)化，這是個(gè)很大的話題，我們可以做性能優(yōu)化降低成本，但雙11這個(gè)體量來講，做單一系統(tǒng)優(yōu)化對(duì)全局有多大幫助要打個(gè)問號(hào)，不是說它沒有用。性能優(yōu)化的關(guān)鍵還是在于找到瓶頸，對(duì)瓶頸進(jìn)行優(yōu)化，這個(gè)效果是最好的。胡子眉毛一把抓，500個(gè)系統(tǒng)都優(yōu)化20%，最后不一定是整體水平提升20%，性能優(yōu)化和降低成本也有一定的關(guān)系,然后可以進(jìn)行架構(gòu)整合，從架構(gòu)層面做優(yōu)化。通過分析，我們發(fā)現(xiàn)還有更好的方式。
上面的紅線是日常處理能力，這是截取的某一段時(shí)間，幾個(gè)月內(nèi)的峰值情況。大家會(huì)發(fā)現(xiàn)，日常情況下很多小活動(dòng)，日常能力是能夠處理的，大活動(dòng)日常能力是不能處理的。為了一個(gè)活動(dòng)增加了一批機(jī)器資源，活動(dòng)過后很長(zhǎng)時(shí)間機(jī)器是沒法利用起來的，要長(zhǎng)期分?jǐn)傔@個(gè)成本，對(duì)雙11來講就是這樣。為了雙11這一天增加了大量成本，過后一年都會(huì)有資源利用率不高的情況，很可怕的浪費(fèi)，因?yàn)轶w量比較大，低效運(yùn)行對(duì)成本影響很大。需要找到一個(gè)能夠幫助解決短時(shí)間內(nèi)要很多資源，長(zhǎng)時(shí)間又都不需要的問題，阿里云的彈性能力就是最好的方案，所以我們選擇阿里云的基礎(chǔ)設(shè)施，做混合云彈性架構(gòu)。它可以降低資源保有時(shí)間，大促就一天，剩下時(shí)間就把資源歸還給云，這個(gè)方案大幅降低了大促成本。我們做的混合云架構(gòu)支撐雙11，規(guī)模是全球最大的。使用云的效率高不高，資源保有時(shí)間長(zhǎng)短很大程度上取決于運(yùn)維能力，包括怎么跟業(yè)務(wù)集成，也做了很多運(yùn)維能力的升級(jí)。包括8小時(shí)在云機(jī)房拉起一個(gè)站點(diǎn)，就是前面講的8小時(shí)建一個(gè)單元，成本節(jié)約。以前是20天，現(xiàn)在提升到1天，對(duì)成本優(yōu)化的效果是非常明顯的。
買了一批資源建起一個(gè)站點(diǎn)，還需要把資源調(diào)勻，通過全鏈壓測(cè)，3小時(shí)可以把整個(gè)機(jī)房甚至全部機(jī)房資源調(diào)勻，提升效率也是降低成本的手段。同時(shí)實(shí)施了全面Docker化，拉平異構(gòu)平臺(tái)的運(yùn)維成本，用一年的時(shí)間把核心系統(tǒng)全部Docker化來支撐雙11。做這種技術(shù)升級(jí)，是需要全鏈壓測(cè)驗(yàn)證的，不然也不會(huì)這么快完成，現(xiàn)在阿里有幾十萬的Docker容器跑在線上。
接下來看一下運(yùn)行控制，系統(tǒng)容量已經(jīng)調(diào)勻，有了最大吞吐能力，但是用戶熱情很夸張，超出想象。超出整個(gè)集群處理能力的流量，需要把它擋在外面，如果放進(jìn)來的話，整個(gè)集群就一起宕掉了，一個(gè)請(qǐng)求都處理不了，整體癱瘓，這時(shí)必須做限流保護(hù)和有損服務(wù)，放進(jìn)來的流量好好處理，沒有放進(jìn)來的，等一會(huì)兒刷一下也會(huì)進(jìn)來，這是通用做法。
我們通過訪問請(qǐng)求數(shù)做限制，也可以通過應(yīng)用負(fù)載做限制，也可以通過線程并發(fā)數(shù)。調(diào)用下游，當(dāng)下游產(chǎn)生問題負(fù)載變高時(shí)，線程數(shù)會(huì)增加，這時(shí)就要對(duì)下游進(jìn)行降級(jí)，要識(shí)別哪些系統(tǒng)可以被降級(jí)，系統(tǒng)自身可以自動(dòng)完成降級(jí)，不會(huì)對(duì)核心業(yè)務(wù)產(chǎn)生大的影響，這是要事先識(shí)別的。通過識(shí)別哪些業(yè)務(wù)可以被降級(jí)，通過限流框架降掉這些場(chǎng)景。當(dāng)發(fā)現(xiàn)流量大到無法處理時(shí)，就限制一些擋在外面，每一層都有限制，包括web接入層、應(yīng)用層、服務(wù)層。整體原則是處理不了就別放進(jìn)來，放進(jìn)來的就是處理得了的，外面入口收緊一點(diǎn)，里面處理放松一點(diǎn)，有很多自我保護(hù)手段。
再看一下流量調(diào)度，整個(gè)系統(tǒng)在高水位運(yùn)行的情況下很容易產(chǎn)生波動(dòng)，有一個(gè)集群。平均來看整體水位70%，但是有幾臺(tái)可能瀕臨崩潰了，這很常見。比如說有一個(gè)比較大的計(jì)算，路由到某臺(tái)機(jī)器，是經(jīng)常碰到的。會(huì)發(fā)現(xiàn)很多流量也會(huì)同時(shí)路由到這臺(tái)服務(wù)器，這些流量都會(huì)受到影響。根據(jù)實(shí)時(shí)探測(cè)，通過現(xiàn)有的一些基礎(chǔ)能力、負(fù)載均衡進(jìn)行流量調(diào)度，把有問題的機(jī)器歸并在一起降權(quán)，有問題的計(jì)算就被隔離了，路由的流量就到了正常機(jī)器，分布式系統(tǒng)可以實(shí)現(xiàn)自我隔離和恢復(fù)，實(shí)現(xiàn)了流量的調(diào)度。關(guān)注局部用戶體驗(yàn)，只要流量放進(jìn)來，都要給一個(gè)比較好的處理和響應(yīng)，提升整體的可用性和體驗(yàn)。
這是開關(guān)和預(yù)案，對(duì)雙11來說非常重要。開關(guān)是系統(tǒng)后門，提供一套標(biāo)準(zhǔn)化的系統(tǒng)后門，可以讓應(yīng)用不改代碼，通過配置改變行為,雙11我們準(zhǔn)備了非常多的開關(guān)。光有開關(guān)還不夠，有些業(yè)務(wù)鏈條需要降級(jí)，可能一個(gè)鏈條上20個(gè)系統(tǒng)都要操作一些開關(guān)，才能把一個(gè)業(yè)務(wù)完整降級(jí)，在復(fù)雜系統(tǒng)上經(jīng)常會(huì)遇到這樣的場(chǎng)景。我們實(shí)現(xiàn)了一套預(yù)案體系，保證一系列的開關(guān)能有序、完整的被執(zhí)行，而且每一臺(tái)服務(wù)器都要執(zhí)行到位，保證一致性、完整性。
一個(gè)經(jīng)驗(yàn)教訓(xùn)就是雙11的時(shí)候千萬別執(zhí)行沒有測(cè)試過的開關(guān)，往往會(huì)出問題。雙11今天體量很大，有數(shù)以千計(jì)的預(yù)案，還是對(duì)每一個(gè)預(yù)案進(jìn)行測(cè)試，保證每一個(gè)開關(guān)、預(yù)案執(zhí)行下去都是滿足期望的。
下面說一下穩(wěn)定性治理。當(dāng)系統(tǒng)復(fù)雜到一定程度，沒有一個(gè)人能掌握整個(gè)系統(tǒng)架構(gòu)，只能用中間件能力來識(shí)別架構(gòu)復(fù)雜度，理清關(guān)系。通過中間件的通道能力跟蹤整個(gè)調(diào)用鏈條，推動(dòng)架構(gòu)梳理，整理出依賴關(guān)系，對(duì)海量調(diào)用進(jìn)行統(tǒng)計(jì)，得到各個(gè)系統(tǒng)的穩(wěn)定性指標(biāo)，這都是從數(shù)據(jù)中挖掘的。比如說調(diào)用層次、響應(yīng)時(shí)間，哪里阻斷了會(huì)影響業(yè)務(wù)，哪里阻斷了不會(huì)影響業(yè)務(wù)，都是被挖掘出來的。同時(shí)會(huì)結(jié)合業(yè)務(wù)測(cè)試用例看哪些鏈條可以被降級(jí)，哪些不可以降級(jí)，有些降下來主業(yè)務(wù)就不顯示了。技術(shù)同學(xué)會(huì)對(duì)弱依賴做業(yè)務(wù)容錯(cuò)，強(qiáng)依賴要保證系統(tǒng)不能掛，穩(wěn)定性治理非常關(guān)鍵。
做了這么多年雙11，未來會(huì)有哪些挑戰(zhàn)？我們希望能做到精細(xì)化、數(shù)據(jù)化、智能化的雙11，從容量確定性到資源確定性，哪些應(yīng)用放在一起，什么樣的配置放在一起會(huì)讓整體集群達(dá)到最佳狀態(tài)，后續(xù)希望做到每一臺(tái)物理機(jī)的內(nèi)核怎么分配，仍然知道如何匹配達(dá)到最佳狀態(tài)，進(jìn)入到微觀的層面，目的還是一樣，讓整體集群全局沒有瓶頸，做到非常精細(xì)化。技術(shù)有很多變量，疊加會(huì)產(chǎn)生風(fēng)險(xiǎn)，所以要精細(xì)分析、預(yù)測(cè)，得出逼近真實(shí)的流量數(shù)據(jù)模型。我們希望做到智能化的雙11，還是對(duì)這些變量，要通過數(shù)據(jù)分析去自我決策。根據(jù)多年的積累，系統(tǒng)對(duì)一些變量的變化區(qū)間是有容忍度的。一種是可以自我決策，降級(jí)是一種決策，一種是可以容忍變化。做到這樣系統(tǒng)已經(jīng)非常智能了，雙11的時(shí)候不用做太多工作，大家可以看到曲線飆升，系統(tǒng)平穩(wěn)運(yùn)行，這是非常理想的。
同時(shí)隨著體量繼續(xù)增長(zhǎng)，今天又迎來了一次技術(shù)升級(jí)的契機(jī)，所以希望在成本、體驗(yàn)和吞吐能力上繼續(xù)探索，找到一個(gè)新的平衡點(diǎn)，能奉獻(xiàn)給大家更完美的雙11。謝謝大家！
Q1：您上面提到的單元是怎么劃分的？
丁宇：剛才講到買家業(yè)務(wù)和賣家業(yè)務(wù)，會(huì)把完整的買家業(yè)務(wù)部署在每一個(gè)單元，買家系統(tǒng)有多少我們很清楚。賣家系統(tǒng)不需要部署，因?yàn)榱髁坎粫?huì)過來，只要梳理這些業(yè)務(wù)就可以了。但是阿里業(yè)務(wù)很復(fù)雜，林林總總，要看哪些系統(tǒng)屬于這個(gè)域，我們有個(gè)標(biāo)識(shí)，配置驅(qū)動(dòng)，標(biāo)識(shí)是單元應(yīng)用，就知道新建站點(diǎn)的時(shí)候某些應(yīng)用要跟著單元走，同時(shí)部署還有個(gè)順序，跟著單元的建設(shè)一起走就可以。
Q2：一個(gè)完整的買家包括所有的服務(wù)做一個(gè)單元？
丁宇：對(duì)。
Q3：?jiǎn)卧獣?huì)有不同切換的情況在，那買家數(shù)據(jù)是怎么保持同步的？
丁宇：?jiǎn)卧姆桨笇?duì)用戶流量來說比較簡(jiǎn)單，我們數(shù)據(jù)層做了非常多的工作，實(shí)時(shí)的把買家在這個(gè)單元產(chǎn)生的數(shù)據(jù)同步到中心，賣家數(shù)據(jù)要同步到單元，都要實(shí)時(shí)做。比如說發(fā)現(xiàn)1秒的延時(shí)，要等數(shù)據(jù)同步完成才能切換過來，數(shù)據(jù)同步效率非常關(guān)鍵。
Q4：如果再極端一點(diǎn)，是某個(gè)壞掉的單元變成完全不可訪問的情況，這種產(chǎn)品怎么切換？
丁宇：這個(gè)數(shù)據(jù)是同步不出來的，這一塊要做一個(gè)權(quán)衡，就是流量必須切走，這會(huì)產(chǎn)生數(shù)據(jù)不一致，可以事后補(bǔ)償，要不然會(huì)產(chǎn)生更大的業(yè)務(wù)問題。
聯(lián)系客服
