2016阿里技術論壇於4月15日在清華大學舉辦，主旨是闡述阿里對世界創新做出的貢獻。阿里巴巴集團技術委員會主席王堅，阿里巴巴集團首席技術官（CTO）張建鋒（花名：行癲），阿里巴巴集團首席風險官（CRO）劉振飛（花名：振飛），螞蟻金服首席技術官（CTO）程立（花名：魯肅）以及來自阿里巴巴集團各部門多位技術大咖齊聚一堂，與莘莘學子分享阿里的技術夢想。
在下午的《電商技術：零到三萬億，從未停止的技術創新》分論壇上，阿里巴巴研究員蔣江偉（花名：小邪）發表了題爲《零點之戰，雙十一背後的分佈式技術》的演講。
以下爲演講實錄：
我的分享有兩個部分，一是阿里技術部的發展過程，二是跟“雙十一”技術相關的情況。
2008年，當時淘寶跟淘寶商城的體系是分開的，包括商品、交易、營銷以及店鋪等。那時候我們在維護一個龐大的系統，代碼以及各種各樣的問題嚴重製約了整個技術的發展。在這個背景情況下，我們做了分佈式化的改造。
這對於技術有非常明顯的幫助。舉個例子，我們數據庫，小到做變更，大到數據庫重新選型，都可以做到比較透明。如果沒有抽離出共享服務層，那這個事情的變更是難以想象的，現在我們在基礎技術上去做大量的創新工作，但是上層的業務系統根本不需要去修改任何的代碼。所以一個是技術上面的創新，一個是業務上面效率帶來了非常正向的變化。
整個架構就變化了。原來是一個應用，它從應用到數據做完之後就變成這樣了（如圖），這個只是0.1版本，是用來教學用的。但是到現在已經沒有辦法學了，已經超過幾千個系統，已經畫不下的這麼一個場景。
那麼做一個比較大的分佈式的架構需要哪些技術？第一個阿里巴巴，還要下APS，還要下篩選，還有服務框架，還有做數據的治理，另外還有我們的應用軟件，還有我們的開發框架，最下面可能就是一個存儲，非常重要的就是存儲，很多的數據都是加入到了緩和裏面。比如現在訪問淘寶，經常被訪問的會員的數據和商品的數據都是放在緩存的。還有文件系統，這些圖片存在在系統裏面，這個規模也是非常大，在全國也是非常大的一個文件系統。還有阿里的關係數據庫，我們通過TDDL對數據做了分庫分表，還有我們利用消息中間件解決異步流程，解決數據最終一致性的問題。通過這7箇中間件的產品，構成了整個阿里技術體系的分佈式架構。使得我們的工程師在開發我們系統的時候，開發一個單機版的程序一樣簡單。
剛纔講到的是分佈式技術上的呈現，其實使用了分佈式技術之後，直接帶來的影響就是讓我們整個擴展性得到了非常大的提升，同時，從原來的商用的體系裏面變成了分佈式體系之後，成本下降也非常明顯。
哪些技術在“雙十一”誕生的？“雙十一”它是一個對於工程師來說，就像是面臨高考，在座的可能就考過一次高考，我們工程師每年都要做高考，考砸了跟各位是一樣的，都是非常嚴重。
總共7年的“雙十一”下來，沒有出過大的問題。差不多2年的時間整個技術體系有一些沉澱。2009年—2010年，還是懵懵懂懂的過程，基本沒有出現什麼問題，工程師都沒有特別的感知。
但是也有一些小問題，我瞭解到當時最大的問題就是圖片，圖片由於CDN的容量到了，我們做了一件事情就是把淘寶上部分商品的最後一些圖片不做顯示。第二個事情，因爲剛纔前面講到2008年中後期做了改造之後，整個系統全部分佈式之後，系統的規模速度增加，一個是系統的數量增加，導致了整個系統的邏輯，或者說整個依賴關係已經沒法用工程師的視角歸置和梳理出來， 做了一個工具用來治理系統之間依賴的關係，流量，強弱。
2011年、2012年的時候192億、370幾億，這個時候對整個交易系統的挑戰非常大了。所以主要是做了整個擴容，整個容量擴大的非常快。在這之前，我們講“雙十一”最大的挑戰有兩個。第一個是怎麼評估容量，系統能支撐多少容量，這個容量的評估那時候開始做了。第二個，一代治理，容量規劃，就是說做了這些事情，其實表現得並不好，在2011年、2012年的時候前面30分鐘還是出現了不少問題，突然間購物車商品被刪除掉了，或者說下單的時候紅包沒有用，各種各樣的問題。出現這些問題之後，引進了下一代技術，比如說我們做了自動化數據訂正系統。
2013年、2014年有了一個先進的技術，剛纔我們在視頻有提到，在“雙十一”之前都是在做這個事情，它是一個容量規劃的新的高度。原來我們在之前做容量評估的時候，我們評估每個系統的容量怎麼評估呢？通過引流，當前用戶，我們把用戶的流量集中在一個上面，看一下應用，當你流量不斷上漲的時候你的表現情況是什麼樣的，我們的CPU，還有我們的內存等等。當它出現拐點的時候，我們把這些值給記錄下來，這樣的話就知道系統的容量。這種辦法非常準確，但是有一個問題，因爲你係統的量非常大，即使參與整個“雙十一”的系統，我預估，因爲我搞不清楚到底有多少，預估有幾百個系統，直接參與“雙十一”交易，就是航天飛機的零件，如果一個零件發生問題，整個就會毀掉。
在“雙十一”之前我們做了這麼一個事情，它是按照正完全真實的場景，全部動用現在的服務器，然後去模擬“雙十一”當天可能會產生的用戶行爲，系統、服務器，還有真實的邏輯去做壓測。與原來的壓測方式相比它有幾個比較好的地方，第一個原來的方式是真實的流量，但是實際情況是促銷的時候，“雙十一”大促的時候，它的流量跟平時的模型是不一樣的，平時的路徑我們是通過搜索或者翻頁，“雙十一”肯定不是這樣的，“雙十一”肯定就是所有的東西都加到購物車裏面了，這個時候我很少再去做搜索或者再去下單，甚至有一些藉助瀏覽器工具怎麼樣更快的搶到一些東西，模型是不一樣的，但是我們需要模擬出當時的場景。總結一下我們需要這樣一個技術：第一是做了一些根據業務場景做模擬的能力，第二個它能夠產生巨大的流量，這個巨大的流量能夠把我們整個集羣，超過幾十萬臺的流量全部壓滿，然後我們給那個服務器加上新的服務器，然後我們再來做，把所有服務器的流量拉平。
還有一個事情我們做了BCP防資損對賬，這個產品做完之，如果出現問題會被秒級發現。剛開始做BCP的時候，我自己覺得意義不是非常大，因爲我覺得如果是所有的代碼是工程師寫的，我認爲只要經過測試上線的系統，邏輯肯定是不會出問題。感覺意義不是非常大，但是沒有拒絕做這件事情。 後來做出來之後發現這個事情還是非常有意義，原因是什麼？我們系統出現異常的流程會導致我們的數據出現異常。比如說我講“雙十一”的時候，突然因爲我的優惠券沒有使用，這時候就會發現，所以在2013年2014年的時候，整個交易額到了570幾億，但是整個表現已經非常好了，就是這個表現跟我們行業內的其他公司不一樣，無論從數據上，體驗流暢上面都要遠遠超於同行。
2015年的時候，我們達到了912億的交易額，整個體驗也是非常不錯，但是我們遇到了新的挑戰，爲了支撐這912億之後我們大量的計算，但是過了這一天之後，本來非常繁忙的變成非常空閒，這個成本浪費是非常大的。不過不用擔心，因爲利用阿里雲計算，所以可以非常好的解決彈性的問題。
後面介紹一個整個阿里的文化。我們是開源項目最多的，比如說2015年開源了65個項目，還有高含量的項目18個，還有一些在國內都是非常知名的一些開源項目，這些項目都是由阿里巴巴的工程師，可能是在工作中的一些沉澱，或者說業餘的時間來貢獻力量。在阿里直接參與開源操作有300多人，這是開源的文化。
本文轉載自雲棲社區：https://yq.aliyun.com