網(wǎng)站在剛開始的時候大概只是一個想法：一個產(chǎn)業(yè)的模型，快速地將它產(chǎn)生出來。“快”是第一位的，不需要花太多精力在架構(gòu)設(shè)計上。
網(wǎng)站進(jìn)入擴(kuò)張期才需要對架構(gòu)投入更多的精力來承載網(wǎng)站在爆發(fā)時的流量。餓了么成立已經(jīng) 8 年，現(xiàn)在日訂單量突破 900 萬。我們也有了較為完善的網(wǎng)站架構(gòu)。
網(wǎng)站基礎(chǔ)架
構(gòu)初期，我們使用了能夠更容易拓展 SOA 的框架。我們用 SOA 的框架，解決兩件事情：
1. 分工協(xié)作
網(wǎng)站初期，程序員可能就 1~5 個，那時候大家忙同一個事情上就可以了。彼此之間的工作都互相了解，往往是通過“吼”的方式就把問題解決了。
但是隨著人員的增加，這種方式顯然是不行的，不可能一個人更新了代碼再把其他人的所有代碼重新上線一遍吧？于是就要考慮分工協(xié)作的問題。
2. 快速擴(kuò)展
以前訂單量可能從 1k 到 1w，雖然增長了 10 倍，但是總量并不是很高，對于一個網(wǎng)站的壓力來說，也不是那么大。真的訂單量從 10w 到 100w，從 100w 到 200w 的時候，可能也只是擴(kuò)大了 10 倍，但是對整個網(wǎng)站的架構(gòu)上來說是一個巨大的挑戰(zhàn)。
我們的背景就是 2014 年的 100 萬突破現(xiàn)在 900 萬，技術(shù)團(tuán)隊(duì)由剛開始的30多個人，到現(xiàn)在已經(jīng)是超過 900 人的團(tuán)隊(duì)。這時候分工協(xié)作就是個巨大的挑戰(zhàn)。服務(wù)的分分合合，團(tuán)隊(duì)的分分合合，這都需要一套框架體系來支撐，這也是 SOA 框架的一個作用。
看一下我們的現(xiàn)狀，中間是我們整個架構(gòu)的體系，右側(cè)是和服務(wù)化相關(guān)的一些基礎(chǔ)，包括基礎(chǔ)的組件或者服務(wù)。
先說語言，我們原來的網(wǎng)站是在 PHP 上的，然后慢慢轉(zhuǎn)型。
創(chuàng)始人都是大學(xué)生創(chuàng)業(yè)，那么理所當(dāng)然 Python 是一個很好的首選。到現(xiàn)在 Python 也是很好的選擇，但是我們?yōu)槭裁匆獢U(kuò)展到 Java 和 Go 呢？
Python 很多人都會寫，但是真正能把他做的很好的人并不多。隨著業(yè)務(wù)的發(fā)展，需要更多的開發(fā)人員?？紤]到 Java 成熟的生態(tài)環(huán)境，以及新興的 Go 生態(tài)，我們最終選擇了 Python、Java、Go 多語言共存的一個生態(tài)。
WebAPI 主要做一些 HTTPS 卸載、限流，還有安全校驗(yàn)等一些通用的和業(yè)務(wù)邏輯無關(guān)的操作。
Service Orchestrator 是服務(wù)編排層，通過配置的方式實(shí)現(xiàn)內(nèi)外網(wǎng)的協(xié)議轉(zhuǎn)換、服務(wù)的聚合裁剪。
架構(gòu)圖右邊是一些圍繞這些服務(wù)化框架的輔助系統(tǒng)，比如說用于定期執(zhí)行一個任務(wù)的 Job 系統(tǒng)。我們有將近快 1000 個服務(wù)，這些系統(tǒng)怎么監(jiān)控？所以必須有一套監(jiān)控系統(tǒng)。剛開始只有 30 多個人的時候，我們更擅長的是跑到機(jī)器上去搜一下 Log，那么 900 多人的時候，你不可能都到機(jī)器上去搜一遍 Log，就需要有個集中式的日志系統(tǒng)。其他的系統(tǒng)就不一一贅述了。
羅馬不是一天建成的，基礎(chǔ)架構(gòu)是個演進(jìn)的過程。我們精力有限，那先做什么呢？
服務(wù)拆分
當(dāng)網(wǎng)站變大了，原來的架構(gòu)跟不上發(fā)展的節(jié)奏了。我們要做的第一件事情就是：把大 Repo 拆成一個小 Repo，把大服務(wù)拆成小服務(wù)，把我們的集中基礎(chǔ)服務(wù)，拆分到不同的物理機(jī)器上去。
光是服務(wù)拆分用了一年多的時間才做完，這是一個比較漫長的過程。
這個過程中，首先要對 API 做一個很好的定義。因?yàn)橐坏┠愕?API 上線之后，再做一些修改的成本是相當(dāng)大的。會有很多人依賴于你的 API，很多時候你也并不知道有誰依賴于你的 API，這是一個很大的問題。
然后再把一些基礎(chǔ)服務(wù)抽象出來。很多原來的服務(wù)其實(shí)是耦合在原來的業(yè)務(wù)代碼里面的。比如說支付業(yè)務(wù)，業(yè)務(wù)很單一的時候，緊耦合的代碼沒有關(guān)系，但是擴(kuò)展出越來越多業(yè)務(wù)都需要支付服務(wù)的時候，你每一個業(yè)務(wù)（比如說支付的功能）都要去做一個嗎？所以我們要把這些基礎(chǔ)服務(wù)抽離出來。比如說支付服務(wù)、短信服務(wù)、推送服務(wù)等。
拆服務(wù)看似很簡單、沒什么價值，但這恰恰是我們剛開始就要做的事情。其實(shí)在這個時期，前面所有的那些架構(gòu)都可以往后拖，因?yàn)椴蛔黾軜?gòu)調(diào)整其實(shí)不會死人，但是拆服務(wù)你不做的話，真的會死人的。
服務(wù)拆分必定是一個漫長的過程，這實(shí)際上是一個很痛苦的過程，也是需要很多配套系統(tǒng)的系統(tǒng)工程。
發(fā)布系統(tǒng)
發(fā)布是最大的不穩(wěn)定因素。很多公司對發(fā)布的時間窗口有嚴(yán)格的限定，比如說
每周只有兩天可以發(fā)布；
周末是絕對不可以發(fā)布的；
業(yè)務(wù)的高峰期絕對不允許發(fā)布；
等等……
我們發(fā)現(xiàn)，發(fā)布的最大問題在于發(fā)布上去之后沒有簡單可執(zhí)行的回退操作?；赝瞬僮鞯降资钦l來執(zhí)行，是發(fā)布人員就可以執(zhí)行，還是需要專人來執(zhí)行？如果是發(fā)布人員的話，發(fā)布人員并非 24 小時在線工作，出了問題找不到人怎么辦？如果是有專人來執(zhí)行回退，而又沒有簡單、統(tǒng)一的回退操作，那這個人需要熟悉發(fā)布人員的代碼，這基本上不可行。
所以我們就需要有發(fā)布系統(tǒng)，發(fā)布系統(tǒng)定義了統(tǒng)一的回退操作，所有服務(wù)必須遵循發(fā)布系統(tǒng)的定義回退操作。
在餓了么對接發(fā)布系統(tǒng)是對所有人的強(qiáng)制要求，所有的系統(tǒng)必須全部接入發(fā)布系統(tǒng)。發(fā)布系統(tǒng)的框架很重要，這個東西其實(shí)對于公司是很重要的一件事情，需要放到第一優(yōu)先級的隊(duì)列里面去考慮的。
服務(wù)框架
緊接著就是餓了么的服務(wù)框架，把一個大的 Repo 拆分成一個小的 Repo，把一個大的服務(wù)拆成一個小的服務(wù)，讓我們的服務(wù)盡量獨(dú)立出去，這需要一套分布式服務(wù)框架來支撐。
分布式服務(wù)框架包含的服務(wù)注冊、發(fā)現(xiàn)、負(fù)載均衡、路由、流控、熔斷、降級等功能，這里就不一一展開了。前面已經(jīng)提及，餓了么是多語言的生態(tài)，有 Python 的，也有 Java 的，我們的服務(wù)化框架對應(yīng)也是多語言的。這對我們后來一些中間件的選型是有影響的，比如說 DAL 層。
DAL 數(shù)據(jù)訪問層
當(dāng)業(yè)務(wù)量越來越大的時候，數(shù)據(jù)庫會變成一個瓶頸。
前期可以通過提升硬件的方式來提升數(shù)據(jù)庫的性能。比如：
升級到一個有更多 CPU 的機(jī)器
把硬盤改成 SSD 的或者更高級一點(diǎn)的
但硬件提升終歸是有一個容量的限制的。而且很多做業(yè)務(wù)的小伙伴，寫代碼的時候都直接操作數(shù)據(jù)庫，發(fā)生過很多次服務(wù)一上線數(shù)據(jù)庫就被打爆的情形。數(shù)據(jù)庫被打爆掉了之后，除非等待數(shù)據(jù)庫恢復(fù)，沒有任何其他機(jī)會可以恢復(fù)業(yè)務(wù)。
如果數(shù)據(jù)庫里面數(shù)據(jù)是正常的，業(yè)務(wù)其實(shí)都可以補(bǔ)償出來的。所以我們做 DAL 服務(wù)層的時候，第一件事情是限流，其他的東西還可以放一放。然后做連接復(fù)用，我們 Python 框架用的多進(jìn)程單線程加協(xié)程的模型。
多進(jìn)程之間其實(shí)是不可以共享一個連接的。比如：一臺機(jī)器上部署了 10 個 Python 進(jìn)程，每個進(jìn)程 10 個數(shù)據(jù)庫連接。再擴(kuò)展到 10 臺機(jī)器上，就有 1000 個數(shù)據(jù)庫連接。對數(shù)據(jù)庫來說，連接是一個很昂貴的東西，我們 DAL 層要做一個連接復(fù)用。
這個連接復(fù)用講的不是服務(wù)本身的連接復(fù)用，而是說 DAL 層上的連接復(fù)用，就是服務(wù)有 1000 個連接到 DAL 層，經(jīng)過連接復(fù)用后對數(shù)據(jù)庫可能只是保持著十幾個連接。一旦發(fā)現(xiàn)某個數(shù)據(jù)庫請求是一個事務(wù)的話，那么 DAL 就幫你保留這個連接的對應(yīng)關(guān)系。當(dāng)這個事務(wù)結(jié)束之后，就把數(shù)據(jù)庫的連接，放回到共用池里面去，供其他人使用。
然后做冒煙和熔斷。數(shù)據(jù)庫也可以熔斷的。當(dāng)數(shù)據(jù)庫發(fā)生冒煙時，我們會殺掉一些數(shù)據(jù)庫的請求，保證數(shù)據(jù)庫不至于崩潰。
服務(wù)治理
服務(wù)框架之后，涉及服務(wù)治理的問題。服務(wù)治理其實(shí)是一個很大的概念。首先是埋點(diǎn)，你要埋很多很多的監(jiān)控點(diǎn)。
比如有一個請求，請求成功了或者失敗了，請求的響應(yīng)時間是多少，把所有的監(jiān)控指標(biāo)放到監(jiān)控系統(tǒng)上面去。我們有一個很大的監(jiān)控屏幕，上面有很多的監(jiān)控指標(biāo)。我們有專門小組72小時去盯著這個屏幕，如果有任何曲線波動了，就找人去解決。另外是報警系統(tǒng)，一個監(jiān)控屏幕展示的東西總是有限的，只能放那些很重要的關(guān)鍵指標(biāo)。這個時候就需要有報警系統(tǒng)。
羅馬不是一天建成的，基礎(chǔ)架構(gòu)更是一個演進(jìn)的過程。
我們的資源和時間總是有限的，作為架構(gòu)師和 CTO 來說，如何在這種有限的資源下，產(chǎn)出更重要的東西？
我們做了很多系統(tǒng)，覺得自己做的很棒了，但其實(shí)不是，我感覺我們又回到了石器時代，因?yàn)閱栴}越來越多，需求也越來越多，總感覺你的系統(tǒng)里還缺點(diǎn)什么東西，想做的功能也一大堆。
比如對于流控系統(tǒng)，現(xiàn)在我們還是需要用戶去配一個并發(fā)數(shù)，那么這個并發(fā)數(shù)，是不是根本不需要用戶去配？是不是可以基于我們服務(wù)本身的一個狀態(tài)自動去控制并發(fā)數(shù)？
然后是升級方式，SDK 升級是個很痛苦的事情。比如說我們服務(wù)框架 2.0 發(fā)布的時候是去年 12 月份，到現(xiàn)在還有人用的是 1.0.是不是可以做到 SDK 的無損感升級，我們自己來控制升級的時間和節(jié)奏。
還有我們現(xiàn)在的監(jiān)控只支持同一個服務(wù)上的匯聚，是不分集群、不分機(jī)器的，那么是不是以后的指標(biāo)可以分集群的，分機(jī)器的？舉一個最簡單的例子，比如一個服務(wù)上有 10 臺機(jī)器，那么可能只是某一個機(jī)器上出了問題。但是它所有的指標(biāo)都會平均分?jǐn)偟狡渌?9 臺機(jī)器上去。你只是看到了整個服務(wù)延時增加了，但有可能只是某一臺機(jī)器拖慢了整個服務(wù)集群。但是我們現(xiàn)在還做不到更多維度的監(jiān)控。
還有智能化的報警，這個報警，就是快、全、準(zhǔn)，我們現(xiàn)在做到更快了，做到更全了，怎么才能做到更準(zhǔn)？每天的報警量高峰時間一分鐘一千多個報警發(fā)出去。所有的一千報警都是有用的嗎？報警多了之后，就相當(dāng)于沒有報警。大家都疲勞了，就不去看了。我怎么能夠把這個報警更準(zhǔn)確地區(qū)分出來？還有更智能化的鏈路分析？以后是不是我們的監(jiān)控不要放監(jiān)控指標(biāo)，而是放鏈路分析，這樣就能夠很清晰的知道，這個問題對應(yīng)的是哪一個結(jié)點(diǎn)上出了問題。
這些問題涉及我們做事的一個原則：東西夠用就好，但是要能夠未雨綢繆，做一定的超前規(guī)劃。
閱讀排行榜
