很多時候，所謂的架構演進沒有太多的前瞻，大部分都是被逼出來的。

什么時候還技術債、變革或者跟上一些潮流趨勢，很多公司是根據業務來判斷的，而我們則是分三個階段：

• 冒煙
• 小火
• 大火

我們能夠做到的是盡可能在冒煙階段做一些技術的變革，如果出小火的時候再做技術的改革，那就有點晚了；到大火的話，相當于被逼的沒有辦法了。

盡管是在同一個行業，不同的公司會有一些差別，我對美團也略有了解，我們在技術上還是略微有一些差別。

我今天的分享分為以下四個部分：

• 挑戰（challenge）。有些技術是普適的、通用的，比如我們一直在用的 TiDB，再比如 Office 一類的軟件，但我們并不是將解決方案（solution）賣給誰。

有一些歐洲和美國的朋友找到我，說我們在那邊 copy 一套是不是就能 work，這是不現實的。我們現在值錢的不是代碼，而是一批對業務了解的人，能把業務跑起來，所以我們與通用技術的差異是比較大的。

• 架構（architecture）。architecture 里有一張圖是家家都有的，大同小異。但為什么我們到今天折騰成這樣一張圖，而不是在三年前？因為這里面有很多現實的困難。
• 拓撲和數據（topology & data）。這里會有帶說明的拓撲以及一些數據。數據其實有很多辛酸在里面，也出過很多宕機，線上業務最怕的就是宕機。
• 正在做的以及未來計劃（doing & planning）。這里是有點精神追求的，我們現在處于冒煙的階段。

餓了么的技術挑戰

如上圖，是下單量隨時間變化的曲線圖，這就是外賣行業的特色，綠色部分表示一些異常。前端流量會更大一些，因為兩者有一個轉化。

電商在國內有這樣的曲線，應該只有外賣這個行業，我們二家（餓了么和美團）都差不多。

在業務上要“削峰填谷”是很難的，因為我們做那么多年的努力才培養出來這樣的習慣，但是在技術上要想辦法。

看到這張圖大家會不會想，你們這家公司不搞云計算，就存在機器超級嚴重的浪費。

我想告訴大家，就是非常嚴重的浪費，但是沒有辦法，我現在做的容量規劃就是基于波峰來做。

我們也想給公司節省成本，IT 部門投入蠻大，公司也不會削減預算。我們現在很在意成本，因此在考慮怎么給公司減負。

今天主要講云、后端的沖擊、在“削峰填谷”上面我們要做什么事情以及為什么要做混合云。

作為程序員，我最喜歡的就是簡單，能用錢砸的就不要安排一堆人去做。但是現在混合云越來越復雜，還要做很多調度器之間的適配。

比如 YARN 怎么跟 ZStack、Mesos 適配？我們是重度的 Mesos 用戶，做了大量的二次開發，適配是非常麻煩的。

對于高并發或者秒殺的沖擊還好，但是最大的是成本問題：怎么提升單位運營的效率？公司拼到最后，活下來就是拼效率，不是拼誰錢多。一切圍繞著效率來走，在這個出發點下我們做了一些架構的改造。

我們原來做災備，相對容易些，但后來災備也做不下去了。這不光是一個排除法，之前踩的坑對你做下一個選項是有價值的。

餓了么的架構演進

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。

今天講 IDC（Internet data center）+ Cloud，因為我們自己有 IDC，總不能報廢吧？

雖然機器三年折舊，但我們每年還會有一些增量補上去，而且我們還有一個很大的運維團隊。

這時，Cloud 又復雜了。我們基本上把國內四大云都用遍了，我們原來是騰訊云和百度云第一大用戶，阿里云不是第一估計也是前三，然后還有七牛云，總之我們把四大云都裹在里面。

最早我們想做災備，但災備有一個很大的麻煩，就是真到災難的時候不敢切換。

我們當時做的災備不順利，最大的開銷不在部署而是在測試，因為災備是沒有生產流量的，驗證起來很困難。

業務邏輯還好，比如多了個接口，少了個應用，從異步變為同步，但也很令人崩潰。

這一堆的事情最后讓我們暫停了項目，這個項目（災備）是我發起的，也是我叫停的。這是個賭局，包括 Google、TiDB 是不可能保證 100% 可靠的，總有一定的概率，無非是幾個 9的問題。

我們的（多活架構）coding & deploy & 測試加起來就三個月，前期準備了 9 個月。好多團隊異地多活很容易，三個月就可以搞定，其實不然。

首先，異地多活不是一個技術活，要想清楚業務需不需要。我們是被業務逼得沒辦法，因為災備沒有搞好，現在覺得災備也確實不好搞。 所以在偏業務的公司搞技術是一件很麻煩的事情。

這里講一下 global zone。我們有兩種 transaction，一個是下單，一個是配送。

大部分 transaction 都可以在一個機房完成，但還有一些東西是繞不過去的，需要用到 global zong。

百度也做了多活，叫“同城多活”，嚴格意義上那不是多活，“同城”就類似于 global zone。

要是僅僅安于北京和上海，其實 BGP 放哪里都無所謂，但如果要打兩百個城市，在一些三四線城市，你根本沒有辦法。

因為我們是 IDC 不是云，云你是無所謂在哪里的。我們的異地多活是被迫的，我很喜歡百度的“同城偽多活”。

百度外賣用的百度云，在廣州有兩個機房，延遲大概 2ms。只有一個地方有 master ，流量是均分的。如果流量跟 master 的 DB 不在一起，就會通過專線同城穿一下，這就相當于我們的 global zone。

如上圖，這是典型的南北線，但也不是南北的線，是根據流量切分的。

如上圖，我們有 4 個調度器，非常的頭疼。我們講一下 ZStack，在 Docker 沒推之前，基本都是在 ZStack 上，也就是虛擬機，物理機沒有特別的調度。

我們大概有 20% 的節點部署了 Docker，有多公司已經 100% 使用 Docker，但我們現在做不到，有一些現實的困難。

Docker 化也有一點麻煩，有些集群是沒法遷 Docker 的，比如 ElasticSearch 這種有狀態的服務。我們現在也開始自研分布式存儲系統，從 EMC 挖人來做，但還處于冒煙階段。

再來說說大數據的 TP（Transaction Processing）和 AP（Analytical Processing）。

我們的 AP 原來基本上都在 YARN 上面。大家可能會詫異，我們現在這樣的一個情況，為什么不是 Kubernetes？

這也是被逼的，開始就沒有打算用 Kubernetes，而是用 Mesos。很多時候跟你的團隊有關，團隊在 Mesos 上面已經很長時間了，業務也比較穩定，而Kubernetes 太復雜，上手也比較重。

現在上 Kubernetes 是因為要用 Google 的產品，我們現在有一個機器學習平臺，除了 Spark，也有機器學習。但還有一些同學，特別是用慣 Python 的，用慣 Tenserflow 的，我們現在都走 elearn（自研AI over Kubernetes）。

大家會感覺很詫異，我們居然不是在 TP 上部署  Kubernetes，我們 TP 上現在主要是 Mesos 和 ZStack。

這時，Cloud 更麻煩了，現在餓了么這邊主要還是阿里云，百度外賣那邊主要是百度云。

百度云也有很頭疼的問題，前兩天跟他們聊，也是很痛苦的。我們的團隊堅持要用物理機的，原來在騰訊云上面的時候，我們就有自己有物理機，并且挪到了騰訊云的機房。

但現在阿里云不能讓我們把自己的機器給挪進去的。怎么辦呢？在今年云棲上已經提到了，我們算是第一批用的。我們要堅持用物理機，否則 IO 密集的任務根本跑不起來。

RDS（Relational Database Service）我們也試過，但只是用在測試。我們所有的程序員和 QA（Quality Assurance）用的環境都是在阿里云上面，是用 RDS。

當然還有重要的原因，那就是 RDS 太貴了。我們也會在 Cloud 上部署二次開發的 Mesos。

餓了么架構拓撲和大數據

如上圖所示，黃框基本上都是機房，包括 IDC 和 Cloud。最麻煩的就是北京和上海。

在我們上海新機房沒有啟用之前，大數據的 AP 和 TP 是混合部署的，但這個混部是隔開的，并不是真正意義上在一個 node 混部。

這邊是阿里云華東和阿里云華北，騰訊云快下完了。另外還有一些專線，也就是兩個支付（微信和支付寶）。

原來兩個支付是不走專線的，后來發現走公網很難忍受，峰值的時候稍有抖動就受不了，一秒鐘可能 1 萬個訂單就沒了。

在支付這個環節丟掉客人是最傷的，如果 APP 一開始打不開就認了，但是什么流程都走完了，最后支付不成功，就很麻煩。

我們專線非常多，每條線都是一個環路。現在廣州百度那邊，百度云不是一個大的 IDC 架構，那邊是完整的體系，到上海兩個機房要做兩條專線，每一條都是環路，也很復雜。

我們內部最頭疼的不是 IDC，而是各種專線，因為非常復雜。還有到我們的 Office，還要有 POP 點。

我也不想搞的那么復雜，可能大家會說把北京的 IDC 廢棄不就結了，但是沒這么簡單。因為前提是要搞多活，不管是異地還是同城。

我們現在北京和上海兩個團隊加在一起大概 25k 個節點。Docker 率只有不到 20%，我們的目標是 50%~60%，因為有很多是做不了的，尤其是中間件，用 Docker 不劃算。

大數據這塊當時狠了下心，把 TP 的應用全部“干掉”，但現在發現，雖然機房是以大數據為主了，但是 AP 和 TP 同城能不能合在一起，好不容易分開現在又要合在一起。

現在大數據的機房壓力也比較大了，我們業務的增加是 120TB，除了大數據還有我們自己的系統日志、trace 差不多 400TB。每天要處理 3PB，總的存量是 12PB，數據量特別大。

我們現在的系統不能出問題，也不能停，尤其是通用軟件的供應商。

不管這個客戶是秒殺類的還是常規類的業務，肯定會受不了。我們還只是為自己的業務提供服務，損失要稍微小一些。

但是做公共設施，比如七牛云、TiDB，一旦停頓，所有的用戶都找你麻煩，所以我們相對來說壓力還算小。

我們業務沒有辦法，逼著我們每天發布 350 次，現在可能不止了，因為現在有很多新業務，每天發布好幾次。

我們大數據非常的燒錢，最貴的 3 個集群：MySQL、Hadoop+Spark 還有 Redis。

Redis 還有很大的省錢空間，從經濟/效率的角度來看，這個東西放在那兒很浪費。

還有大數據的備份，大數據是我們的命脈。如果網站宕一天，我們道歉一下就行了，第二天該來的用戶還得來。

但大數據一旦出問題，一是數據是隱私，二是數據丟掉或者錯亂，會更加麻煩。

我們每天做了很多的備份，但后來發現這些備份太冷了，到底劃不劃算，你不能去賭它，但是成本放那兒太痛苦了。混合云架構是被逼出來的，不是我想搞這些東西的。

餓了么正在做的以及未來計劃

混合云架構

多活的難點主要在異地多活，同城偽多活是比較容易的，也就是 global zone 這種方式，但同城做真正的多活也跟異地差不多，主要是 latency 的問題。

你要自己做 DRC（Data Replication Center），包括 MySQL 層面，Zookeeper 層面和 Reids 層面。

我們用一個服務，就希望它是跨 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 的人感覺沒有什么變化。

我們繼續超賣，一核當三核用，我們按峰值來算的，發現平時的峰值利用率也不是那么高。

混部嘗試

不管我們要不要做 auto scaling，不管我們業務上要不要削峰填谷，都要做混部。

混部這塊，百度走的早一些，他們前幾年做了一個系統，目的不是要混部，但是要產生一個好的副作用來實現這樣的功能。

回到業務本身，混部其實很難的，我跟他們聊的時候，說搜索這種業務是可以采用類似于網格計算的，每個格子自己算，然后匯聚。

他們有大量的 swap（數據交換），但你讓 Spark 來做這些功能，比如 Machine Learning 和 swap，即使是萬兆網卡，也會突然把帶寬占滿。

現在機器學習跟搜索或者爬蟲可以分而治之的技術不一樣，我們叫分布式，有大量的 swap。我們也在嘗試，把能夠在每一個節點單獨計算，不需要大量 swap 的任務放上去。

混部是為了解決什么問題呢？我們業務的峰值非常高，到波谷的時候這些機器就閑置著，那是不是可以來跑一些 job。

這個 job 不是指 TP。TP 也有一些 job，但都耗不了多少 CPU。這是不劃算的，不能純粹玩技術，為了玩而玩，我們要解決的是大量的場景。

我們能想到的是 Hadoop、Spark，尤其是現在 Machine Learning 壓力比較大。但是聊下來比較難，第一不能異地，第二同城也很難。

還有很頭疼的挑戰：我們大數據團隊用的機型是定制的，他們已經習慣了這種機型模板。

我們 TP 的模板非常多，已經從上百種壓縮到十幾種，但還是量很大的，有 API 的，有業務邏輯的，有 Redis 的。如何把大數據或者 Machine Learning 的任務適配到雜七雜八的機型是個問題。

我們這個行業經常有促銷活動?；顒拥臅r候即使有云，也還是要花錢的。所以活動期間可以把大數據任務凍結，釋放機器資源用于大促。

大部分任務拖延三四個小時都是可以接受的。兩邊互相的部，首先解決資源隔離的問題，還有調度器。YARN 是很難調度 TP 的，Mesos 或者 Kubernetes 調度 AP 也是有麻煩的。

我們在研究的問題是 YARN、Mesos 和 ZStack 怎么適配，現在仍然沒有搞定。

混部的問題早就存在，但是財務上面給我的壓力沒有到冒煙，如果餓了么哪天提供了餓了么云，大家不要驚訝。

我們不會去做公有云，但是曾經考慮介于 PaaS（Platform-as-a-Service）和 SaaS（Software-as-a-Service）之間的物流云。

我們現在有很多的配送并不來自于餓了么，也幫雙 11 配送?，F在也有叫閃送，可以在很短的時間送到，一個人送一個件，但是收費比較高。

我看到閃送的人直接騎摩托車送的，一般是電動車。很多時候業務發展起來了，正好也幫我們解決了這樣的一些問題。