編者按：這是一篇來自鲲鵬會的文章，其内容是畢玄在TGO 鲲鵬會杭州分會活動現場分享的《雲時代的軟體架構》的整理。特别轉載到雲栖社群，讓更多開發者深入了解阿裡架構的變遷和對雲技術的一些新的想法。
2018 年 12 月 15 日，TGO 鲲鵬會杭州分會拉開了 TGO 特有的技術人年會「E 家宴」的帷幕，60+CTO/ 技術 VP 相聚在杭州殊勝龍井酒店。其中，阿裡巴巴系統軟體、中間件、研發效能負責人畢玄，連尚網絡副總裁 &WiFi 萬能鑰匙萬能接入業務群 CEO、TGO 鲲鵬會上海會員萬玉權， 同盾科技聯合創始人 & 技術 VP、TGO 鲲鵬會杭州會長張新波，及 TGO 鲲鵬會杭州會員、大搜車技術 VP 沈淦、尚尚簽 CTO 陶真，和浪潮集團 AI 首席架構師 張清等重磅嘉賓應邀出席，與參會者一起探讨雲時代的軟體架構、技術紅利、團隊轉型 / 演進 / 發展等話題。
畢玄，阿裡巴巴系統軟體、中間件、研發效能負責人。
2018 級電子與資訊領域工程博士研究所學生。2007 加入阿裡，經曆阿裡電商 10 多年來的技術架構演進，打造了阿裡重要的中間件 HSF 服務架構，設計并帶領多團隊實作了阿裡電商異地多活架構。2011 年開始打造了阿裡自研的容器及對資源使用率提升巨大的統一排程系統。先後任職淘寶網平台架構部架構師、集團核心系統研發部資深技術專家、阿裡中間件負責人。
奠定阿裡五年業務快速發展基礎的架構改造
阿裡經曆了幾次較大的軟體架構疊代，首先是分布式時代的阿裡電商架構。淘寶從 2007 年開始做新一輪架構改造，淘寶從 2007 年開始碰到的最大的問題，即通路量增長太快，導緻出現了一個問題：不能加機器了，即伸縮性的問題。淘寶在業務發展過程中，2008 年以前所有的解決方案就是簡單加機器就能解決，但是到 2007 年突然出現加不了，那時候淘寶資料庫用的是中國最好的 IBM 的小型機。以前資料庫連接配接我們用 Oracle，Oracle 資料庫最大的問題是每個連結消耗的記憶體特别大。因為記憶體始終有瓶頸，是以當我們記憶體、資料庫連接配接不夠的時候，我們的解決辦法是多插記憶體條，後來記憶體條插滿了，就沒有辦法了。是以 2007 年淘寶判斷必須做新一輪的架構改造，讓我們具備水準伸縮能力。
大家現在都知道一個思路，既然一個系統加不了機器，資料庫抗不住，那就把一個資料庫拆成兩個資料庫，把通路資料庫的業務盡可能集中。以交易為例，以前是所有的 web 應用都要通路的，如果你把交易邏輯抽象出來，把通路資料庫操作的地方抽象成一個系統，而這個系統其實不需要很多機器，連接配接數就可以大幅度下降，這是當時的思路。
那時候淘寶面臨主要問題是能否再次水準伸縮，但是還有第二個問題，那就是被技術團隊投訴研發進度太慢。我加入淘寶時有 100 多個工程師，開發了同一個系統，每個人都可以改裡面所有的代碼。這個時候問題就來了，比如我接了一個業務，我要改這個類這一行代碼，然後另外一個業務也要改同一類同一行的代碼。等這兩個人一送出，同一天釋出，合并代碼就合不了，因為邏輯太複雜了。是以淘寶當時創新性提倡了一種方法：排期。我們在每個月第一天會開淘寶曆史上研發團隊最激烈以及大家鬥志最昂揚的會議，就是用來排這個月的釋出。如果兩個研發團隊發生了沖突，那就 PK 一下誰的需求牛逼。當演進成新的架構的時候，這個問題就被解掉了。
當阿裡巴巴整個架構演進成一套服務式架構的時候，一是随伸縮上的能力和價值被認可；第二，2008 年研發團隊從 100 人增加到 200 人，2009 年增加到近 600 人以上，一年是幾倍地增長。如果當時沒有做服務化，整個淘寶業務發展會受到非常大的影響。是以我們湊巧在最應該做架構改造的時候做完了，這一輪是淘寶曆史上比較重要的一輪，在這一輪架構中打造出三個最重要的中間件：服務框、消息中間件、TDDL 雲上服務。這一輪架構為阿裡巴巴 2008-2013 年五年業務的快速發展奠定了堅實的基礎。那五年，大部分的團隊不用關注技術問題，而是可以非常快地做業務，這對淘寶而言非常重要。
到後來架構圖就畫得相對标準一點，現在大部分的公司都是這個架構，沒有什麼差別，基本上都分成三層。這個架構從 2008-2009 年初，花一年的時間完成架構改造，代号五彩石，五彩石項目把淘寶和淘寶商城技術架構合并，合并成新的架構，這個項目對整個阿裡的意義絕對重大。這個項目做完以後，架構差不多完成了。
架構完成以後，我們一緻認為我們做了非常完美的架構，但上線以後，我們發現這個架構碰到的最大問題是穩定性問題。2009 年淘寶穩定性是整個淘寶曆史上最差的一年，我們在那一年穩定性小于 3 個 9。後來這個架構在發展過程中不斷演進，我們重點做穩定性。除了穩定性，也存在其他小的挑戰，比如秒殺，那個架構對秒殺沒有什麼特殊支援的，是以我們後來對秒殺做了針對性地改造，當然整個結構沒有變過，這個架構支撐了淘寶非常多年，直到 2013 年。
到了 2013 年，我們碰到了新的挑戰。因為規模增長的問題，導緻我們在 2013 年雙 11 的時候突然間發現了一個問題，我們在雙 11 備戰的前一個月也要加機器。資料庫團隊告訴我們不能加太多，因為那時候已經不是買 Oracle，是 MySQL，MySQL 的連接配接确實比 Oracle 更小很多，但是我們前面的機器也是很多，是以最後的連結池又成為了問題。當然除了資料庫以外，我們發現中間件和其他的東西也存在一些問題，雖然我們整個是分布式系統，但是一個分布式系統裡面一定有某些點是集中的，某些點一定是全部都要接的，那些點随着規模的上升就會成為很大的瓶頸點。是以到了 2013 年，我們就再次面臨了這個挑戰，那時候已經是雙 11 前一個月，我們已經改變不了什麼。那年我們臨時用了别的方案頂過了那一年的雙 11，但在那年雙 11 以後我們明白，阿裡迎來了新一輪架構更新的機會。
新一輪的架構改造：異地多活
2013 年，我們決定開始做阿裡巴巴新一輪的架構改造，我們把這一輪架構改造在内部稱為單元化，版本的代号是 3.0 到 4.0。這一輪解決的第一個問題是水準伸縮，怎麼樣在不加機器下扛大的規模；二是我們決定必須做另外一件事情，讓整個阿裡可以随便在哪裡部署，并且是多個地點。
很多人記得 2013 年杭州特别熱，40 度高溫持續了十幾天，結果是阿裡巴巴接到了通知，我們的其中機房必須限電。那一年吓壞我們了，因為那個機房是資料庫機房，如果斷了，整個淘寶全挂了，那一次事件給了我們無比大的教訓。
這個項目跟我們做分布式有一個很大的不同，2008 年做的時候我們其實有參考對象。2013 年我們做異地多活的時候沒有參考對象，而且大家都認為這件事情風險非常高，如果能不做盡可能不要做。從全球來看，谷歌很早做了，Facebook 做了一點點但沒有做得太徹底，亞馬遜和 eBay 都是不做的。後來我們參考各家方案，發現谷歌的方案在電商行業根本不可用，谷歌不在乎響應時間，但是交易非常在乎。比如你下單慢一點，在雙 11 這樣的場景下肯定會導緻我們崩盤，因為響應時間往上拉高，我們沒有辦法支援。Facebook 和騰訊都做了，騰訊主要是微信做，但微信其實是一個消息 IM 系統，IM 其實是比較容易做的，因為大家本來就是異步互動，但是交易是特别強調同步并且對資料一緻性要求特别高的場景，是以我們在做整個方案的時候完全隻能自己想到底該怎麼辦。我們最後做的方案是這邊的方案——異地多活。
我自己帶着團隊做這個方案的時候，最關心的隻有一個問題：異地多活最大的風險是什麼？因為它是活的，異地這個點不是冷備的點，意味着異地的點也在寫資料，它最大的風險就在于每個點都在寫資料，如果資料一旦寫錯了就廢了。阿裡是一家做信任的公司，隻要資料一錯，我們這個公司的聲譽就毀了。是以當時做這個方案，我們跟架構師團隊講最重要的是：不要出現資料錯亂，其他我們都可以接受。其實這個項目在整個架構設計上是非常充分展現了當時最活的講 CAP 隻能選兩個地方，因為我們選擇了資料一緻性，是以一定程度上犧牲了可用性，對可用性會有一些影響。
這個項目在 2016 年基本上全部做完，從 2016 年以後整個阿裡部署架構一直都是這樣的，我們現在一直都是三地部署，我們有三個點，任何一個點挂了對我們都沒有任何影響，我們切換流量大概隻需要在 30 秒内就可以全部完成。因為我們上了以後才發現單地風險很容易出現風險，尤其是單個機房，比如說路由器、交換機出現問題，你就不知道怎麼辦，但是多地就沒有問題。
這個架構對阿裡來講最大的價值：第一，再次具備水準伸縮的能力，我們現在支援雙 11，隻需要不斷擴容單元或者說重新建立不同的單元，就可以完成整個過程；第二，可以讓地域級的容災能力提升，因為我們都是活的，是以就可以随便切來切去。淘寶在雙 11 前面一個月密集備戰的過程，我們就會不斷切流量，每天白天都在切流量，但我相信很多使用者是從來沒有感受過我們在切流量。是以我認為這次架構改造之後，應該還能撐個很多年。
資源彈性時代的阿裡電商架構
近幾年主要圍繞另外一件事情做。你們都會發現我們在做前面兩個版本改造最大的差別是：前兩個版本都在解決水準伸縮的問題，其實水準伸縮是業務對技術團隊的基本要求，你肯定要做到可以加機器解掉業務高峰的問題，是以這時候技術團隊對業務團隊的價值是有限的。但随着我們在水準伸縮上解決得更好，包括雙 11 穩定性的確定上做得越來越好，技術團隊可以做更多。其實雙 11 後來面臨的問題和挑戰是成本，穩定性方面随着全鍊路壓測之後，我們就發現很多東西越來越穩了，但是雙 11 的成本是我們很大的壓力，因為雙 11 的峰值跟日常的峰值差距越來越拉大，意味着為了雙 11 前面那一段時間，我們要付出的代價是非常巨大的。是以現在這個問題就成為了我們最頭痛的問題。
我講阿裡的技術架構演進時，很多人會問我一個問題：雙 11 後，你們的機器都拿去幹嘛了？這句話，每次都問得我非常尴尬，我也不知道怎麼回答，我也隻能随便扯，通常的扯法告訴你下一年日常峰值會接近雙 11 的峰值，那就沒怎麼浪費，但很多人都懂其實是不大可能的，是以很難回答。但是阿裡還好，出現了兩個變數。我們後來出現了兩個東西，來讓我們更好解決這個問題：第一，阿裡雲。從 2014 年開始阿裡雲發展起來了，阿裡雲的發展對我們來講有一個巨大的好處，因為我可以借阿裡雲的資源臨時頂一下雙 11，借完了再還給阿裡雲，阿裡雲再售賣，這隻是一個周期的問題。是以阿裡雲的起來，至少對雙 11 的幫助是非常巨大的。我們也用了很多年的時間做這件事情，因為阿裡的技術和阿裡雲的技術确實有差别，是以為了讓我們的東西能跑在阿裡雲上，并且對業務研發團隊沒有感覺，其實也要做很多的東西，比如說運維系統怎麼對接兩套不一樣的東西，又讓業務沒有安全，資源的使用方式不一樣，阿裡雲上是 ECS，我們内部都是容器，是以這兩者也要做對接。是以我們當時做了很多這方面的工作。
可以給大家一個資料。我們在 2014 年用阿裡雲資源扛雙 11 10% 的流量，2015 年用阿裡雲的資源扛 60% 的流量，2015 年扛 60％流量的那一年做雙 11 的成本，每萬筆下降了 50%，後來幾年我們一直延用這個方案，不斷增加雲的資源。
但是去年開始發現其實我們還有别的路可以走，除了雲以外，因為用雲其實還是要錢的。比如，我們要用很長一段時間，因為我們買的機器實在太多了，阿裡雲賣掉也需要一些時間。後來我們在想有沒有不用錢的方案？其實作在大部分内部有兩個最大的叢集，一個用來部署線上業務，一個用來部署離線業務。通常來講，你有兩個叢集，但是這兩個叢集沒有太大的關系。
是以我們認為在雙 11 的時候可以用大資料計算的叢集扛短時的高峰。我們開始做這個方案，但是這個方案有個非常複雜的問題，雖然我們的離線沒有那麼重要，但也不能全部停掉，因為如果全部停掉對雙 11 也會産生影響，大家知道我們有實時推薦，我們需要大資料進行計算。如果不能全停，就有一個問題：怎麼保證線上業務放上去跑的時候，離線不會把你的資源全部搶光？是以有一個互相幹擾的問題。我們在過去幾年，在作業系統的部分、排程系統部分做很多的工作，來避免這個問題。今年，我們大概用離線機器扛了 16 萬筆的交易，相當于 16 萬筆交易不用花錢，完全免費，對業務團隊來講，今年雙 11 每萬筆交易成本相比去年又下降了 17%。我們總共有 49.1 萬筆，是以帶來的成本節省是非常壯觀的。
雲時代的軟體架構走向何方？
雲時代的軟體架構走向何方？這是我們一直在思考的部分，我們在想未來怎麼跟雲結合。我前面所講的資源彈性跟雲就有很大的關系。是以我們認為雲時代軟體架構，在價值層面看到的：對很多使用方來說，第一點是彈性，我可以有高峰就用、沒有高峰就退。阿裡還有另外一家特别典型的公司：餓了麼。餓了麼是典型有非常明顯高峰效應的公司，但是它過了高峰就沒有什麼量了，這種公司，如果你為高峰準備錢，投入是非常大的，是以它跟雲更好結合，在彈性上一定可以享受非常大的價值；第二點，我們認為雲的整體演進會帶來另外一點改變是整個業務研發團隊會越來越不關注下面是什麼，越來越脫離下面這一層，這是我們認為的一個風向，因為阿裡巴巴在今年雙 11 裡面已經小面積使用了這個技術。比如說大家看到的手淘首頁，首頁下面有很多推薦，如果按以前的開發方式，門檻是很高的，你要懂阿裡巴巴背後非常多的技術。但今年我們把它改成了很類似的方式，前端的人可以簡單寫幾個函數，把頁面組裝起來，後面有非常複雜的服務調用、擴容體系，把很多工作都隐藏到了背後的一套平台，前端的人在整體業務效率上非常高。是以我們認為如果我們的軟體架構真的演進到跟雲深度整合，有一個好處是你的研發效率會提高，門檻會降低，至少在阿裡幾個場景裡我們看到了這個現象。
我們在内部讨論一個問題：我們認為阿裡走到今天面臨的一個很大問題是每進到一個阿裡做業務研發的員工，如果你想做好一個業務研發，你都要了解阿裡背後非常複雜的技術體系。而你要了解這個技術體系，門檻不低，你要學習很多的東西。但是我相信做過業務研發的人知道，做業務研發的代碼邏輯不應該關心這些東西，他應該關心怎麼把業務邏輯抽象成一個比較簡單的東西，這是業務最核心的問題，現在就導緻很多業務人需要花更多時間學技術，而不是研究業務，我們認為這個事會被改變。
是以在雲的時代，我們希望設計一個右邊的架構，希望在下面有一個非常厚的平台，所有的業務團隊更加關注寫一些很小的代碼片段或者相對來講更為複雜一點的簡單服務，通過下面的東西幫你組裝，你也不用關心所有的架構。這是我們希望雲演進的方向，也是我們現在探索阿裡巴巴整個軟體架構怎麼演進成這個樣子。大家看阿裡的架構演進，就可以發現我們前面解了伸縮性問題，成本問題基本接近解決，當然還需要進一步努力。我們現在關注的下一個問題是效率問題，怎麼讓我們的效率進一步提升起來，比如說我們希望阿裡巴巴整個業務研發的門檻能夠降低到像 2007 年一樣，這樣的話業務研發的效率就會非常高，但這背後必須有很複雜的方案。是以我們認為這一代架構最關鍵的是怎麼降低研發門檻，怎麼大幅拉高研發效率，這就是阿裡現在正在探索的。
本文來自
TGO鲲鵬會。點選看原文。