【圖：餓了麼資深架構師朱琳騏】

12月10日，餓了麼資深架構師朱琳騏在2021雲上架構與運維峰會上，分享了餓了麼雲上基礎架構的演進歷程。以下是他的演講實錄：

經過10多年的運營，餓了麼的業務不僅從起步時的個位數的訂單成長到了現在的千萬級別，同時還完成了從外賣業務到“愛什麼來什麼”綜合業務形態的演進。我會以業務的需求和變化為主線，聊一聊這10多年我們的技術是如何演進的。

一、架構的演進歷程

2014年前餓了麼和傳統的技術性公司並沒有特別大的區別，主要是以傳統的獨立應用方式來進行部署。隨著移動網際網路的興起，外賣業務迅猛發展，傳統模式的架構只能支撐百萬單量。為了支撐業務的靈活多變和不斷提升的單量，餓了麼進行兩次非常大的技術升級。

2014年到2017年，餓了麼完成了從單體應用到微服務體系的技術改造。2017年完成了多活架構的演進，2018年到2021年9月，完成了從用雲到IaaS全面上雲和PaaS上雲三個重要的里程碑，目前餓了麼也在構建基於雲原生新的架構體系。

二、雲端計算—基礎架構升級1.0

一切技術的演進都是為了滿足業務的訴求，業務狂奔促成了餓了麼，也促使其完成了從單體到多活架構的演進。

01 傳統架構

傳統單體架構有著耦合度高、交付慢、運維效率低下等諸多缺陷。隨著業務架構的調整，單體服務也逐步按照領域進行了微服務體系的升級。

為了提升運維效率、交付效率和穩定性，我們構建出了elss、appos、ice 3三位一體的自動化釋出平臺

02 異地多活和用雲

2017年，上海機房出現瓶頸，傳統的同城雙活已經沒有辦法滿足我們的需求，而異地多活對於任何一個技術團隊來說都是非常大的挑戰。後續經過各方共同努力，耗時3個月，多活成功上線。接下來簡單介紹一下多活相關的元件。

DRC主要是做資料同步，dal在切流的時候做一些資料禁寫工作， APIrouter會在Gzs的排程下進行機房之間的流量切換。

多活上線後，除了解決業務的容量問題，也為餓了麼的穩定性提供了堅實的後盾。

上圖深色部分是在雲上構建的。多活上線以後我們急需資源，按照傳統的預算採購再進行部署沒有辦法跟上我們的節奏，所以必須藉助於雲上的彈效能力來構建alpha和alt2兩套完整的測試環境，這樣我們就可以隨時根據業務的需求進行容量調整。

網際網路的大促是每年的傳統，自建的機房早在年初就規劃好了，如果我們每年都按照大促的規模進行部署，將有大量的資源被浪費掉。因此我們不只把閘道器搬到雲上，其中一個機房也在雲上重新進行了構建。此後，我們只需要在大促前做好雲上的擴容就可以了。活動結束後，一鍵操作縮容即可，節省了大量的成本和時間。

除了大促，薅羊毛也是網際網路特有的。為了避免黑產薅羊毛，閘道器在雲上構建的同時，也直接使用了阿里雲的tfe來進行流量清洗，安全效能得到了大的提升，而這個對餓了麼來說只是付費然後開箱即得的簡單操作。

截至2018年，餓了麼完成了基於雲端計算的基礎架構1.0升級，多活體系和Sam中間特殊的中介軟體，在滿足業務的同時，也為二次上雲的演進埋下了一個伏筆。

三、雲原生—基礎架構升級2.0

01 業務痛點

隨著2018年餓了麼被阿里收購，餓了麼從單一的外賣體系演進到了承接本地生活的綜合體系，“愛什麼來什麼”的業務對我們提出了更高的要求。後續餓了麼上雲，也是與業務痛點息息相關的。

當時我們面臨了以下幾大問題：

⚫ WG機房過保穩定性變差。

⚫ 為了降低使用者的支出，我們需要降低單均成本。

⚫ 從單獨的外賣業務到本地生活，我們需要快速試錯，必須藉助彈效能力才能靈活多變。

⚫ 經過淘系業務錘鍊的中介軟體，比我們有更高的穩定性和產品能力。

⚫ 要進行rpc框架統一，這不僅能滿足業務和集團互聯互通的訴求，還能節省大量重複建設的成本。

經過對用雲紅利和業務痛點的分析，最終我們選擇了全面上雲，在雲上對本地生活的基礎設施進行全面升級。

02 上雲策略

上雲規劃分為3步。

首先從IaaS層開始，將資源網路儲存等設施基於雲原生進行打造。完成IaaS層上雲之後，再進行PaaS上雲，採用雲上中介軟體為產研提供服務，還將我們特有的多活相關的中介軟體基於CloudHosting進行重構，以此完成基於雲原生的2.0架構升級。

截至2020年5月30號，本地生活IaaS全面上雲，這個過程充分體現了阿里雲的技術實力。

03 收益

接下來分享一下上雲的收益。

首先基礎設施雲化之後，合池收益每月494萬，年化近6000萬。另外借助彈效能力，我們做了ECS水位治理，日均成本下降了9萬，年均的收益達到3400萬。此外，基礎運維的人力節省了5個。

第二點是整個釋出系統打通，測試環境和集團共用之後，大概降低了30%容量要求。此外，釋出系統人力也節省了5個。

從去年6月份到今年9月份，我們完成了PaaS上雲。這個過程我們借用了多活能力，對各種方案進行兜底。另外，前面提到的Sam也在這裡起到了非常大的作用，它能夠在產研無感的同時完美做到同構中介軟體的切流。

目前為止，微服務體系從Huskar、Pylon遷移到了集團的Pandora、DNS、Sentinel，未來還會再往雲上的EDAS進行升級。訊息層的kafka已經全部上雲，在AMqp開服之後，MAXQ也將會進行升級。代理層已經從SoapProxy升級到HsfProxy，最近餓了麼也在和阿里雲正在共建中介軟體4.0，之後就能解決中心化的Proxy問題。儲存層的ES已經有70%在雲上了，MySQL到RDS的遷移還在專案啟動階段。快取層的Redis和Ekv已經完全上雲了，用了雲上的redis和 lindorm。

微服務體系打通之後，Proxy只需要保留多單元的定址能力，使得節點數目縮減50%，節省了大概1萬核。同時，替換了DNCS以後，微服務體系的穩定性和能力都有了大幅的增強，包括原來我們沒有的灰度能力。人力成本上節省了近10人。

第二個大收益點在於中介軟體上雲。首先產品的效能穩定性得到提升，其次大促資源預留成本也明顯降低。之前每年都會為了大促額外保留30%的buffer，而現在不需要了。還有基礎設施方面的人力成本減少50人。

04 未來規劃

餓了麼上雲專案的結束並不代表技術演進到此停止，業務還在發展，新的技術痛點依然會存在。根據當前的業務痛點，我們進行了新一輪的規劃，主要分為三個方面：

⚫ 完成通用自研中介軟體到雲上中介軟體的過渡；同時對自研中介軟體，進行基於雲原生環境的改造，進一步增強產品的穩定性和資源的利用率。

⚫ 構建IaaS層資源平臺，雲上雲下的資源統一收口，提升產業的工作效率；同時也要加強資源利用率的感知和成本治理的平臺化；最終藉助雲上H/VPA能力排程能力，結合業務特性來提升整體的資源利用率。

⚫ 構建Paas層平臺，藉助雲原生sidecar的部署能力完成從Sam到Envoy升級；增強中介軟體使用能力，快速定位線上問題；提升中介軟體能力，如redis資料壓縮和分片場景；最後還要保留原來的一些能力，比如資源切換。中介軟體升級的時候，怎麼樣保證產研無感以及系統的快速恢復能力，這些都是我們重點要規劃的事情。

最後，我想強調，對於餓了麼來說，雲原生不是技術的終點，而是新的生態下的全新起點。

點選大會官網，檢視朱琳騏在峰會上的精彩演講視訊。