餓了么混合云架構探索

本文根據 餓了么 CTO  張雪峰在 2017年 ECUG 十周年盛會上演講的整理

壓力還是蠻大的，因為技術會議越來越多，商業味越來越重。但是不寫公司名字或者介紹一下業務的特點，其實很難去講。像我們這種每天"送盒飯"的，有什么技術含量？大家拋開公司名字，看這個行業，業務特點比較重的，或者偏線下的，很多時候所謂的架構或者演進大部分時候都是被逼出來的，也沒有太多的前瞻。技術什么時候還債、變革或者跟上一些潮流趨勢，我們是根據業務來判斷的，分三個階段：第一是 冒煙 ；第二是 小火 ；第三是 大火。 我們能夠做到的是盡可能在冒煙階段做一些技術的變革。如果出小火的時候再做技術的改革，那就有點晚了。到大火的話，相當于被逼的沒有辦法了。 我 原來也是想純粹搞技術，寫一 點 好玩的 東西。 后來 進到一個專注具體業務的 公司 ，發現先要活下來 。 不同的公司會有一些差別， 我對美團 也略有了解 ， 我們 在技術上 還是 略微有一些差別， 盡管是在同一個行業 。

我今天的演講分為四個部分：

• 挑戰（challenge）。有些技術是普適的，通用的，比如我們一直在用的TiDB，再比如office一類的軟件，但我們的并不是將解決方案（solution）賣給誰。有一些歐洲和美國的朋友找到我，說我們在那邊copy一套是不是就能work，這是不現實的。我們現在值錢的不是代碼，而是一批對業務了解的人，能把業務跑起來。所以我們與通用技術的差異是比較大的。

• 架構（architecture）。architecture里有一張圖是家家都有的，大同小異。但為什么我們到今天折騰成這樣一張圖，而不是在三年前？因為這里面有很多現實的困難。

• 拓撲和數據（topology & data）。這里會有帶說明的拓撲以及一些數據。數據其實有很多辛酸在里面，也出很過很多宕機，線上業務最怕的就是宕機。

• 正在做的以及未來計劃（doing & planning）。這里是有點精神追求的，我們現在處于冒煙的階段。

 

Challenge 1

圖1 下單量隨時間的變化

大家看一下，這就是行業的特色，綠色不要管，是一些異常。這是下單量，其實前端流量更大，兩者有一個轉化。電商在國內有這樣的曲線，應該只有外賣這個行業，我們二家（餓了么和美團）都差不多。 業務上 要“削峰填谷”是很難的， 我們做那么多年的努力才培養出來這樣的習慣。 但是 技術上要想辦法 。看到這張圖大家會不會想，你們這家公司 不搞云計算，機器浪費超級嚴重 。 我告訴大家，就是非常嚴重， 但是沒有辦法，我 現在做的 容量 規劃就是基于 波峰來 做 。我們也 想給公司節省成本， IT 部門投入蠻大，公司也不會削減預算。我們現在很在意成本 ， 因此在考慮 怎么 給公司減負。

 

Challenge 2

圖2 challenge 2

今天主要講云、后端的沖擊、在“削峰填谷”上面我們要做什么事情以及為什么要做混合云。我作為程序員，最喜歡的就是簡單，能用錢砸的就不要安排一堆人去做。但是現在混合云越來越復雜，還要做很多調度器之間的適配。比如 YARN 怎么跟 ZStack、Mesos 適配。我們是重度的 Mesos 用戶，做了大量的二次開發，適配是非常麻煩的。 高并發或者秒殺的沖擊還好 ，最大的問題是 成本： 怎么提升單位運營的效率 。 公司拼到最后，活下來就是拼效率，不是拼誰錢多。一切圍繞著效率來走，在這個出發點下我們做了一些架構的改造。 我們原來做災備，相對容易 些 ，但后來災備也做不下去了。這 不光是一個排除法， 之前踩的 坑對你做下一個選項是有價值的 。

 

Architecture 1

圖3 architecture 1

5年前我們沒有這張圖，是人肉運維，那時才叫 DevOps（ a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops) ）。為什么呢？因為我們的工程師就是 Ops，沒有專門的 Ops 團隊。三年前我進去發現很夸張，就一個專職 DBA（Database administration）和一個 Ops。后來發現不行，要招人，完全超出你的想象，招一堆人寫業務邏輯。業務邏輯沒有辦法智能，也沒有辦法像劉奇他們招三個中國最頂尖的程序員就可以搞定。對業務邏輯是這樣的，我們已經抽象了還是不行，業務邏輯 AI 解決不了。后來發現招人不行，做的亂七八糟的，系統也老掛，我也不是吐槽 Pyhton。我們最近也做了大計劃，大概會省幾億的人民幣，就是 Python 轉 Go，因為大部分流量靠 Python 扛的，集群壓力也是蠻大的。用 Go 的話（成本）大概除以5。但這個寫 Python 的同學很牛，除了 DBA 沒干基本上啥都干了。后來拆分出了亂七八糟這些東西，現在看起來蠻漂亮的，花了我們很長時間。

今天講 IDC（Internet data center）+ Cloud，因為我們自己有 IDC，總不能報廢吧？雖然機器三年折舊，但我們每年還會有一些增量補上去，而且我們還有一個很大的運維團隊。Cloud 又復雜了。我們基本上把國內四大云都用遍了，騰訊云我們原來是第一大用戶，百度云也是第一大用戶，阿里云不是第一估計也是前三的，然后還有七牛云，總之四大云把我們都裹在里面。

 

Architecture 2

圖4 architecture 2

最早我們想做災備，但災備有一個有個很大的麻煩，就是真到災難的時候不敢切換。我們當時做的災備不順利，最大的開銷不在部署而在測試，因為災備是沒有生產流量的，驗證起來很困難。業務邏輯還好，比如多了個接口，少了個應用，從異步變為同步，但也很令人崩潰。這一堆的事情最后讓我們暫停了項目，這個項目（災備）是我發起的，也是我叫停的。這其實是個賭局，包括google、TiDB是不可能保證100%可靠的，總有一定的概率，無非是幾個9。

我們的（多活架構）coding & deploy & 測試加起來就三個月，前期準備了9個月。好多團隊異地多活很容易，三個月就可以搞定，其實不然。首先，異地多活不是一個技術活，要想清楚業務需不需要。我們是被業務逼得沒辦法，因為災備沒有搞好，現在覺得災備也確實不好搞。 所以在偏業務的公司搞技術是一件很麻煩的事情。

講一下 global zone。我們有兩種 transaction，一個是下單，一個是配送。大部分 transaction 都可以在一個機房完成，但還有一些東西是繞不過去的，需要用到 global zong。百度也做了多活，叫“同城多活”，嚴格意義上那不是多活，“同城”就類似于 global zone。要是僅僅安于北京和上海，其實BGP放哪里都無所謂，但如果要打兩百個城市，在一些三四線城市，你根本沒有辦法。因為我們是 IDC 不是云，云你是無所謂在哪里的。我們的異地多活是被迫的，我很喜歡百度的“同城偽多活”。百度外賣用的百度云在廣州有兩個機房，延遲大概2ms。只有一個地方有 master ，流量是均分的。如果流量跟 master 的 DB 不在一起，就會通過專線同城穿一下，這就相當于我們的 global zone。

 

Architecture 3

圖5 architecture 3

這是典型的南北線，但其實也不是南北的線，是根據流量切分的。

 

Architecture 4

圖6 architecture 4

我們有4個調度器，非常的頭疼。我們講一下 ZStack，在 Docker 沒推之前，基本都是在 ZStack 上，也就是虛擬機，物理機沒有特別的調度。我們大概有20%的節點部署了 Docker，有多公司已經100% Docker，但我們現在做不到，有一些現實的困難。Docker 也有一點麻煩，有些集群是沒法遷 Docker 的，比如 ElasticSearch 這種有狀態的服務。我們現在也開始自研分布式存儲系統，從 EMC 挖人來做，但還處于冒煙階段。

再來說說大數據的 TP（ Transaction Processing ）和 AP（ Analytical Processing ）。我們的AP原來基本上都在 YARN 上面。大家可能會詫異，我們現在這樣的一個情況，為什么不是 Kubernetse。也是被逼的，開始就沒有打算用 Kubernetse，而是用Mesos。很多時候跟你的團隊有關，團隊在上面已經很長時間了，業務也比較穩定。Kubernetse 太復雜，上手也比較重。現在上 Kubernetse 也是被逼的，因為要用 Google 的東西，我們現在有一個機器學習平臺，除了spark，spark也有機器學習。但還有一些同學，特別是用慣 python 的，用慣 tenserflow 的，我們現在都走 elearn（自研AI over Kubernetse）。大家會感覺很詫異，我們居然不是在TP上部署 Kubernetse。我們TP上現在主要是 Mesos 和 ZStack。

Cloud 更麻煩了，現在餓了么這邊主要還是阿里云，百度外賣那邊主要是百度云。百度云等會講，也有很頭疼的，前兩天跟他們聊，也是很痛苦的。我們的團隊堅持要用物理機的，原來在騰訊云上面的時候，我們就有自己有物理機，并且挪到了騰訊云的機房。但現在阿里云不能讓我們把自己的機器給挪進去的。怎么辦呢，其實在今年云棲上已經提到了，我們算是第一批用的。我們要堅持要用物理機，否則 IO 密集的任務根本跑不起來。RDS（Relational Database Service）我們也試過，但只是用在測試。我們所有的程序員和 QA（Quality Assurance）用的環境都是在阿里云上面，是用 RDS。當然還有重要的原因，那就是 RDS 太貴了。我們也會在Cloud上部署二次開發的 Mesos。

 

Topology & Data 1

圖7 topology & data 1

大家可以看一下，黃框基本上都是機房，包括 IDC 和 Cloud。最麻煩的就是北京一個，上海一個。在我們上海新機房沒有開之前，大數據的 AP 和 TP 是混合部署的，但這個混部其實是隔開的，并不是真正意義上在一個 node 混部。這邊是阿里云華東和阿里云華北，騰訊云其實快下完了。另外還有一些專線，也就是兩個支付（微信和支付寶）。原來兩個支付是不走專線的，后來發現走公網很難忍受的，峰值的時候稍有抖動就受不了，一秒鐘可能1萬個訂單就沒了。在支付這個環節丟掉客人是最傷的，一開始APP打不開就認了，最后什么都走完了，最后支付不成功，就很麻煩。我們專線非常多，每條線都是一個環路。現在廣州百度那邊，百度云不是一個大的 IDC 架構，那邊是完整的體系，到上海兩個機房要做兩條專線，每一條都是環路，也很很復雜。我們內部最頭疼的不是 IDC，是各種專線，非常復雜。還有到我們的 office，還要有 POP 點。我也不想搞的那么復雜，把北京的 IDC 廢棄不就結了，但是沒這么簡單。前提是要搞多活，不管是異地還是同城。

 

Topology & Data 1

圖8 topology & data 2

我們現在北京上海兩個團隊加在一起大概25k個節點。Docker 率只有不到20%，我們的目標是50%~60%，因為有很多是做不了的，尤其是中間件，用 Docker 不劃算。大數據這塊當時狠了下心，把 TP 的應用全部“干掉”，但現在發現，雖然機房是以大數據為主了，但是AP和TP同城能不能合在一起，好不容易分開現在又要合在一起。現在大數據的機房壓力也比較大了，我們業務的增加是 120TB，除了大數據還有我們自己的系統日志、trace 差不多 400TB。每天要處理 3PB，總的存量是 12PB，數據量特別大。

我們現在的系統不能讓它出問題，也不能停。昨天也聽劉奇講到，尤其是通用軟件的供應商，停一秒鐘意味著什么？不管這個客戶是秒殺類的還是常規類的業務，肯定受不了。我們還只是為自己的業務提供服務，損失要稍微小一些。但是做公共設施，比如七牛云、TiDB，一旦停頓，所有的用戶都找你麻煩，所以我們相對來說壓力還算小。我們業務沒有辦法，逼著我們每天350次發布，現在可能不止了，現在有很多新業務，每天發布好幾次。我們大數據非常的燒錢，我們最貴的3個集群：MySQL、Hadoop+Spark 還有 Redis。Redis 還有很大的省錢空間。從經濟/效率的角度來看，這個東西放在那兒很浪費。還有大數據的備份，大數據是我們的命脈。網站宕一天我們道歉一下就行了，第二天該來的用戶還得來，但大數據一旦出問題，一是數據是隱私，二是數據丟掉或者錯亂，會更加麻煩。我們每天做了很多的備份，但后來發現這些備份太冷了，到底劃不劃算，你不能去賭它，但是成本放那兒太痛苦了。混合云架構是被逼出來的，不是我想搞這些東西的。

 

Doing & Future（混合云架構）

圖9 混合云架構

多活的難點主要在異地多活，同城偽多活是比較容易的，也就是 global zone 這種方式，但同城做真正的多活也跟異地差不多，主要是 latency 的問題，你要自己做 DRC（Data Replication Center），包括 MySQL 層面，Zookeeper 層面和 Reids 層面。我們跟 PingCAP 也合作蠻久了，我也問過東旭， 你是不是可以異地機房跨 IDC。這還是一年前，東旭跟我說還沒有考慮這個問題，因為沒有這樣的用戶。昨天聊的時候說好像可以支持跨 IDC，而且是北京上海這種35ms的延遲跨度。我們用一個服務，就希望它是跨 IDC 的，主要就是 latency 和一致性，這兩個問題很難協調。

還有 Cloud Native，是大勢所趨，就像Go語言。冒煙時開始做，太超前了也不行，畢竟要先把業務做起來。但是到小火就比較危險了，我們也曾到小火的時候再去還債，還債還算容易，到小火的時候真的靠人肉上去砸就比較麻煩了。Cloud 肯定會考慮的，混合云雖然聽上去很時尚，但是我們步調比較謹慎的。對運維團隊也是個挑戰，比如 RDS。我們內部數據庫也千奇百怪，有 MySQL、MongoDB。你讓習慣了敲命令行寫腳本的運維變成程序員，我們內部反過來叫 OpsDev，這個難度要遠超過 DevOps。我們希望公司所有人都是程序員，但是這個挑戰蠻大的。

我們 Serverless 是在線上做了一個系統，但是比較簡單。接下來可能會考慮短信推送，移動推送，因為這個只要搭個 Redis，開啟就可以直接發送了。對我們來說，Serverless 對復雜業務是走不通的，除非我們全部用 Cloud infrastructure。

Auto scaling 是我們在計劃做的，因為多活做了之后才能相對寬松一些，流量想切多少切多少。95%的 transaction 都在同一個 zone 里做完的。不做這件事情就沒有辦法做阿里云的拓展。阿里云現在可以做 auto scaling，但是成本很高。一般來說云的成本會比 IDC 要高一些，那是不是說做4小時的拉起再拉出（值應對峰值流量）是劃算的？我們算了一筆賬，發現不一定是這樣。如果削峰填谷做的比較有成效的話，就會沖淡 auto scaling 節省的成本。我們和新浪微博不一樣，它是不可預知突發事件的，所以只能做 on demand（按需）。雖然我們有很大的波谷差異，但是可以預知的。前兩天團隊給我一個“炸彈”：我們現在機器利用率很低，我們不是上 Docker 嘛，我們做一件事情——超賣。什么叫超賣？我們原來是一核對一核，現在一核當兩核，后來發現還不錯，用 Docker 的人感覺沒有什么變化。我們繼續超賣，一核當三核用，我們按峰值來算的，發現平時的峰值利用率也不是那么高。

 

Doing & Future（混部嘗試）

圖10 混部嘗試

不管我們要不要做 auto scaling，不管我們業務上要不要削峰填谷，都要做 混部 。混部百度走的早一些，他們前幾年做了一個系統，目的不是要混部，但是要產生一個好的副作用來實現這樣的東西。回到業務本身，混部其實很難的，我跟他們聊的時候，說搜索這種業務是可以采用類似于網格計算的，每個格子自己算，然后匯聚。他們有大量的 swap（數據交換），但你讓 spark 來做這些東西，比如 machine learning 和 swap，即使是萬兆網卡，也會突然把帶寬占滿。現在機器學習跟搜索或者爬蟲可以分而治之的技術不一樣，我們叫分布式，有大量的 swap。我們也在嘗試，把能夠在每一個節點單獨計算，不需要大量 swap 的任務放上去。

混部是為了解決什么問題呢？我們業務的峰值非常高，到波谷的時候這些機器就閑置著，那是不是可以來跑一些 job。這個 job 不是指 TP。TP 也有一些 job，但都耗不了多少 CPU。這是不劃算的，不能純粹玩技術，為了玩而玩，我們要解決的是大量的場景。我們能想到的是 Hadoop、Spark，尤其是現在 machine learning 壓力比較大。但是聊下來比較難，第一不能異地，第二同城也很難。還有很頭疼的挑戰：我們大數據團隊用的機型是定制的，他們已經習慣了這種機型模板。我們 TP 的模板非常多，已經從上百種壓縮到十幾種，但還是量很大的，有 API 的，有業務邏輯的，有 Redis 的。如何把大數據或者 machine learning 的任務適配到到雜七雜八的機型是個問題。

我們這個行業經常有促銷活動。活動的時候即使有云，也還是要花錢的。所以活動期間可以把大數據任務凍結，釋放機器資源用于大促。大部分任務拖延三四個小時都是可以接收的。兩邊互相的部，首先解決資源隔離的問題，還有調度器。YARN 是很難調度TP的，Mesos 或者 Kubernetse 調度 AP 也是有麻煩的。

我們在研究的問題是 YARN、Mesos 和 ZStack 怎么適配，現在沒有搞定。混部的問題早就存在，但是財務上面給我的壓力沒有到冒煙，所以放最后一頁講。如果餓了么哪天提供了餓了么云，大家不要驚訝，我們不會去做公有云，但是曾經考慮介于 PaaS（Platform-as-a-Service）和 SaaS（Software-as-a-Service）之間的物流云。我們現在有很多的配送并不來自于餓了么，也幫雙11配送。現在也有叫閃送，可以在很短的時間送到，一個人送一個件，但是收費比較高。我看到閃送的人直接騎摩托車送的，一般是電動車。很多時候業務發展起來了，正好也幫我們解決了這樣的一些問題。

 

Q&A

提問一： 剛才我聽到有一個遷移Docker的打算，我不知道出發點訴求是什么？剛才說成本比較高，這個成本是指人力成本還是時間成本？

張雪峰： 是說利用率。我們這種業務如果說要擴容，雖然有冷備的機器在，但還是比較慢，Docker現在很快。我們這種業務擴容很正常的，壓測不可能壓到所有的細節，我們分公共和業務研發團隊，公共團隊主持這個工作，但是業務不可能了解那么細。業務保證大盤不出問題，現在公司業務小問題盡量小，以前可能就是一個新浪微博，現在就是小問題，機器勻出來做一些其他的問題。成本為什么比較高是嗎？不是人力成本，是我們的機器比較差，你先活下來，一開始用錢，其實創業很多時候先用錢換時間，你上公有云，為什么呢？因為錢可能貴一些，但是時間換回來了，我們早年也是這樣，錢換時間，因為這個時間過了就倒閉了，倒閉還談什么。

提問二： 剛才聽到，您對一些有狀態的服務遷到 Docker 里面有一些擔心，但是我看到現在 Docker 容器，其實存儲的時候有一些插件，不把服務器切到容器上面，細節上面還有什么問題？   

張雪峰： 不是因為插件，是因為存儲，如果我們自己可以搞定，一旦有狀態的話存儲就搞不定。原來最土的一種辦法，我們用所謂的企業存儲方案，后來發現不行，量太大，圖片還容易解決，我們內部的圖片小文件還可以，但不是塊存儲，我們現在也是用錢換能力，我們有單機的，來做這個還可以的，一旦進入容器里面挑戰比較大。不是不能玩，說直白一點，不能讓這一塊有任何的波動。

提問三： 我之前在IBM做過存儲和虛擬化適配。你研究的塊存儲這一塊給數據庫這樣定嗎？

張雪峰： 對，它不是對象存儲，我們的對象最主要就是圖片。以前沒有踩過的坑里面能夠看懂，排障能力，雖然我們不敢用。我只是請某一個EMC的同學幫我們支持這個工作，我不是用EMC，因為互聯網公司很少去買軟件，我們會買一些我們搞不定的東西。

提問： 沒有考慮過直接買EMC？

張雪峰： 不會。我們這種一秒出來，我給你5分鐘先看懂故障在哪兒，如果我們是一個平緩的業務無所謂，大部分都是高峰期出的問題，80%的故障出在高峰期，不是說EMC的產品不是好產品，是我們hold不住。

 

來自：http://mp.weixin.qq.com/s/4oEWnE03KkOEZtsUXl99KA