很多時(shí)候，所謂的架構(gòu)演進(jìn)沒(méi)有太多的前瞻，大部分都是被逼出來(lái)的。

什么時(shí)候還技術(shù)債、變革或者跟上一些潮流趨勢(shì)，很多公司是根據(jù)業(yè)務(wù)來(lái)判斷的，而我們則是分三個(gè)階段：

• 冒煙
• 小火
• 大火

我們能夠做到的是盡可能在冒煙階段做一些技術(shù)的變革，如果出小火的時(shí)候再做技術(shù)的改革，那就有點(diǎn)晚了；到大火的話，相當(dāng)于被逼的沒(méi)有辦法了。

盡管是在同一個(gè)行業(yè)，不同的公司會(huì)有一些差別，我對(duì)美團(tuán)也略有了解，我們?cè)诩夹g(shù)上還是略微有一些差別。

我今天的分享分為以下四個(gè)部分：

• 挑戰(zhàn)（challenge）。有些技術(shù)是普適的、通用的，比如我們一直在用的 TiDB，再比如 Office 一類(lèi)的軟件，但我們并不是將解決方案（solution）賣(mài)給誰(shuí)。

有一些歐洲和美國(guó)的朋友找到我，說(shuō)我們?cè)谀沁?copy 一套是不是就能 work，這是不現(xiàn)實(shí)的。我們現(xiàn)在值錢(qián)的不是代碼，而是一批對(duì)業(yè)務(wù)了解的人，能把業(yè)務(wù)跑起來(lái)，所以我們與通用技術(shù)的差異是比較大的。

• 架構(gòu)（architecture）。architecture 里有一張圖是家家都有的，大同小異。但為什么我們到今天折騰成這樣一張圖，而不是在三年前？因?yàn)檫@里面有很多現(xiàn)實(shí)的困難。
• 拓?fù)浜蛿?shù)據(jù)（topology & data）。這里會(huì)有帶說(shuō)明的拓?fù)湟约耙恍?shù)據(jù)。數(shù)據(jù)其實(shí)有很多辛酸在里面，也出過(guò)很多宕機(jī)，線上業(yè)務(wù)最怕的就是宕機(jī)。
• 正在做的以及未來(lái)計(jì)劃（doing & planning）。這里是有點(diǎn)精神追求的，我們現(xiàn)在處于冒煙的階段。

餓了么的技術(shù)挑戰(zhàn)

如上圖，是下單量隨時(shí)間變化的曲線圖，這就是外賣(mài)行業(yè)的特色，綠色部分表示一些異常。前端流量會(huì)更大一些，因?yàn)閮烧哂幸粋€(gè)轉(zhuǎn)化。

電商在國(guó)內(nèi)有這樣的曲線，應(yīng)該只有外賣(mài)這個(gè)行業(yè)，我們二家（餓了么和美團(tuán)）都差不多。

在業(yè)務(wù)上要“削峰填谷”是很難的，因?yàn)槲覀冏瞿敲炊嗄甑呐Σ排囵B(yǎng)出來(lái)這樣的習(xí)慣，但是在技術(shù)上要想辦法。

看到這張圖大家會(huì)不會(huì)想，你們這家公司不搞云計(jì)算，就存在機(jī)器超級(jí)嚴(yán)重的浪費(fèi)。

我想告訴大家，就是非常嚴(yán)重的浪費(fèi)，但是沒(méi)有辦法，我現(xiàn)在做的容量規(guī)劃就是基于波峰來(lái)做。

我們也想給公司節(jié)省成本，IT 部門(mén)投入蠻大，公司也不會(huì)削減預(yù)算。我們現(xiàn)在很在意成本，因此在考慮怎么給公司減負(fù)。

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

作為程序員，我最喜歡的就是簡(jiǎn)單，能用錢(qián)砸的就不要安排一堆人去做。但是現(xiàn)在混合云越來(lái)越復(fù)雜，還要做很多調(diào)度器之間的適配。

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

對(duì)于高并發(fā)或者秒殺的沖擊還好，但是最大的是成本問(wèn)題：怎么提升單位運(yùn)營(yíng)的效率？公司拼到最后，活下來(lái)就是拼效率，不是拼誰(shuí)錢(qián)多。一切圍繞著效率來(lái)走，在這個(gè)出發(fā)點(diǎn)下我們做了一些架構(gòu)的改造。

我們?cè)瓉?lái)做災(zāi)備，相對(duì)容易些，但后來(lái)災(zāi)備也做不下去了。這不光是一個(gè)排除法，之前踩的坑對(duì)你做下一個(gè)選項(xiàng)是有價(jià)值的。

餓了么的架構(gòu)演進(jìn)

5 年前我們沒(méi)有這張圖，還處于人肉運(yùn)維階段，那時(shí)才叫 DevOps（a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops)）。

為什么呢？因?yàn)槲覀兊墓こ處熅褪?Ops，沒(méi)有專(zhuān)門(mén)的 Ops 團(tuán)隊(duì)。三年前我進(jìn)去后發(fā)現(xiàn)很夸張，團(tuán)隊(duì)就一個(gè)專(zhuān)職 DBA（Database administration）和一個(gè)  Ops。

后來(lái)我發(fā)現(xiàn)不行，要招人，我招人完全超出你的想象，是招一堆人寫(xiě)業(yè)務(wù)邏輯。業(yè)務(wù)邏輯沒(méi)有辦法智能，也沒(méi)有辦法像劉奇他們招三個(gè)中國(guó)最頂尖的程序員就可以搞定。

對(duì)業(yè)務(wù)邏輯是這樣的，我們已經(jīng)抽象了，但是還是不行，業(yè)務(wù)邏輯 AI 解決不了，后來(lái)發(fā)現(xiàn)招人不行，做的項(xiàng)目亂七八糟的，系統(tǒng)也老掛。

我也不是吐槽  Pyhton，我們最近也做了大計(jì)劃，大概會(huì)省幾億的人民幣，就是 Python 轉(zhuǎn) Go，因?yàn)榇蟛糠至髁靠?Python 扛的，集群壓力也是蠻大的。用 Go 的話（成本）大概除以 5。

今天講 IDC（Internet data center）+ Cloud，因?yàn)槲覀冏约河?IDC，總不能報(bào)廢吧？

雖然機(jī)器三年折舊，但我們每年還會(huì)有一些增量補(bǔ)上去，而且我們還有一個(gè)很大的運(yùn)維團(tuán)隊(duì)。

這時(shí)，Cloud 又復(fù)雜了。我們基本上把國(guó)內(nèi)四大云都用遍了，我們?cè)瓉?lái)是騰訊云和百度云第一大用戶，阿里云不是第一估計(jì)也是前三，然后還有七牛云，總之我們把四大云都裹在里面。

最早我們想做災(zāi)備，但災(zāi)備有一個(gè)很大的麻煩，就是真到災(zāi)難的時(shí)候不敢切換。

我們當(dāng)時(shí)做的災(zāi)備不順利，最大的開(kāi)銷(xiāo)不在部署而是在測(cè)試，因?yàn)闉?zāi)備是沒(méi)有生產(chǎn)流量的，驗(yàn)證起來(lái)很困難。

業(yè)務(wù)邏輯還好，比如多了個(gè)接口，少了個(gè)應(yīng)用，從異步變?yōu)橥?，但也很令人崩潰?/p>

這一堆的事情最后讓我們暫停了項(xiàng)目，這個(gè)項(xiàng)目（災(zāi)備）是我發(fā)起的，也是我叫停的。這是個(gè)賭局，包括 Google、TiDB 是不可能保證 100% 可靠的，總有一定的概率，無(wú)非是幾個(gè) 9的問(wèn)題。

我們的（多活架構(gòu)）coding & deploy & 測(cè)試加起來(lái)就三個(gè)月，前期準(zhǔn)備了 9 個(gè)月。好多團(tuán)隊(duì)異地多活很容易，三個(gè)月就可以搞定，其實(shí)不然。

首先，異地多活不是一個(gè)技術(shù)活，要想清楚業(yè)務(wù)需不需要。我們是被業(yè)務(wù)逼得沒(méi)辦法，因?yàn)闉?zāi)備沒(méi)有搞好，現(xiàn)在覺(jué)得災(zāi)備也確實(shí)不好搞。 所以在偏業(yè)務(wù)的公司搞技術(shù)是一件很麻煩的事情。

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

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

百度也做了多活，叫“同城多活”，嚴(yán)格意義上那不是多活，“同城”就類(lèi)似于 global zone。

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

因?yàn)槲覀兪?IDC 不是云，云你是無(wú)所謂在哪里的。我們的異地多活是被迫的，我很喜歡百度的“同城偽多活”。

百度外賣(mài)用的百度云，在廣州有兩個(gè)機(jī)房，延遲大概 2ms。只有一個(gè)地方有 master ，流量是均分的。如果流量跟 master 的 DB 不在一起，就會(huì)通過(guò)專(zhuān)線同城穿一下，這就相當(dāng)于我們的 global zone。

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

如上圖，我們有 4 個(gè)調(diào)度器，非常的頭疼。我們講一下 ZStack，在 Docker 沒(méi)推之前，基本都是在 ZStack 上，也就是虛擬機(jī)，物理機(jī)沒(méi)有特別的調(diào)度。

我們大概有 20% 的節(jié)點(diǎn)部署了 Docker，有多公司已經(jīng) 100% 使用 Docker，但我們現(xiàn)在做不到，有一些現(xiàn)實(shí)的困難。

Docker 化也有一點(diǎn)麻煩，有些集群是沒(méi)法遷 Docker 的，比如 ElasticSearch 這種有狀態(tài)的服務(wù)。我們現(xiàn)在也開(kāi)始自研分布式存儲(chǔ)系統(tǒng)，從 EMC 挖人來(lái)做，但還處于冒煙階段。

再來(lái)說(shuō)說(shuō)大數(shù)據(jù)的 TP（Transaction Processing）和 AP（Analytical Processing）。

我們的 AP 原來(lái)基本上都在 YARN 上面。大家可能會(huì)詫異，我們現(xiàn)在這樣的一個(gè)情況，為什么不是 Kubernetes？

這也是被逼的，開(kāi)始就沒(méi)有打算用 Kubernetes，而是用 Mesos。很多時(shí)候跟你的團(tuán)隊(duì)有關(guān)，團(tuán)隊(duì)在 Mesos 上面已經(jīng)很長(zhǎng)時(shí)間了，業(yè)務(wù)也比較穩(wěn)定，而Kubernetes 太復(fù)雜，上手也比較重。

現(xiàn)在上 Kubernetes 是因?yàn)橐?Google 的產(chǎn)品，我們現(xiàn)在有一個(gè)機(jī)器學(xué)習(xí)平臺(tái)，除了 Spark，也有機(jī)器學(xué)習(xí)。但還有一些同學(xué)，特別是用慣 Python 的，用慣 Tenserflow 的，我們現(xiàn)在都走 elearn（自研AI over Kubernetes）。

大家會(huì)感覺(jué)很詫異，我們居然不是在 TP 上部署  Kubernetes，我們 TP 上現(xiàn)在主要是 Mesos 和 ZStack。

這時(shí)，Cloud 更麻煩了，現(xiàn)在餓了么這邊主要還是阿里云，百度外賣(mài)那邊主要是百度云。

百度云也有很頭疼的問(wèn)題，前兩天跟他們聊，也是很痛苦的。我們的團(tuán)隊(duì)堅(jiān)持要用物理機(jī)的，原來(lái)在騰訊云上面的時(shí)候，我們就有自己有物理機(jī)，并且挪到了騰訊云的機(jī)房。

但現(xiàn)在阿里云不能讓我們把自己的機(jī)器給挪進(jìn)去的。怎么辦呢？在今年云棲上已經(jīng)提到了，我們算是第一批用的。我們要堅(jiān)持用物理機(jī)，否則 IO 密集的任務(wù)根本跑不起來(lái)。

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

當(dāng)然還有重要的原因，那就是 RDS 太貴了。我們也會(huì)在 Cloud 上部署二次開(kāi)發(fā)的 Mesos。

餓了么架構(gòu)拓?fù)浜痛髷?shù)據(jù)

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

在我們上海新機(jī)房沒(méi)有啟用之前，大數(shù)據(jù)的 AP 和 TP 是混合部署的，但這個(gè)混部是隔開(kāi)的，并不是真正意義上在一個(gè) node 混部。

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

原來(lái)兩個(gè)支付是不走專(zhuān)線的，后來(lái)發(fā)現(xiàn)走公網(wǎng)很難忍受，峰值的時(shí)候稍有抖動(dòng)就受不了，一秒鐘可能 1 萬(wàn)個(gè)訂單就沒(méi)了。

在支付這個(gè)環(huán)節(jié)丟掉客人是最傷的，如果 APP 一開(kāi)始打不開(kāi)就認(rèn)了，但是什么流程都走完了，最后支付不成功，就很麻煩。

我們專(zhuān)線非常多，每條線都是一個(gè)環(huán)路?，F(xiàn)在廣州百度那邊，百度云不是一個(gè)大的 IDC 架構(gòu)，那邊是完整的體系，到上海兩個(gè)機(jī)房要做兩條專(zhuān)線，每一條都是環(huán)路，也很復(fù)雜。

我們內(nèi)部最頭疼的不是 IDC，而是各種專(zhuān)線，因?yàn)榉浅?fù)雜。還有到我們的 Office，還要有 POP 點(diǎn)。

我也不想搞的那么復(fù)雜，可能大家會(huì)說(shuō)把北京的 IDC 廢棄不就結(jié)了，但是沒(méi)這么簡(jiǎn)單。因?yàn)榍疤崾且愣嗷?，不管是異地還是同城。

我們現(xiàn)在北京和上海兩個(gè)團(tuán)隊(duì)加在一起大概 25k 個(gè)節(jié)點(diǎn)。Docker 率只有不到 20%，我們的目標(biāo)是 50%~60%，因?yàn)橛泻芏嗍亲霾涣说?，尤其是中間件，用 Docker 不劃算。

大數(shù)據(jù)這塊當(dāng)時(shí)狠了下心，把 TP 的應(yīng)用全部“干掉”，但現(xiàn)在發(fā)現(xiàn)，雖然機(jī)房是以大數(shù)據(jù)為主了，但是 AP 和 TP 同城能不能合在一起，好不容易分開(kāi)現(xiàn)在又要合在一起。

現(xiàn)在大數(shù)據(jù)的機(jī)房壓力也比較大了，我們業(yè)務(wù)的增加是 120TB，除了大數(shù)據(jù)還有我們自己的系統(tǒng)日志、trace 差不多 400TB。每天要處理 3PB，總的存量是 12PB，數(shù)據(jù)量特別大。

我們現(xiàn)在的系統(tǒng)不能出問(wèn)題，也不能停，尤其是通用軟件的供應(yīng)商。

不管這個(gè)客戶是秒殺類(lèi)的還是常規(guī)類(lèi)的業(yè)務(wù)，肯定會(huì)受不了。我們還只是為自己的業(yè)務(wù)提供服務(wù)，損失要稍微小一些。

但是做公共設(shè)施，比如七牛云、TiDB，一旦停頓，所有的用戶都找你麻煩，所以我們相對(duì)來(lái)說(shuō)壓力還算小。

我們業(yè)務(wù)沒(méi)有辦法，逼著我們每天發(fā)布 350 次，現(xiàn)在可能不止了，因?yàn)楝F(xiàn)在有很多新業(yè)務(wù)，每天發(fā)布好幾次。

我們大數(shù)據(jù)非常的燒錢(qián)，最貴的 3 個(gè)集群：MySQL、Hadoop+Spark 還有 Redis。

Redis 還有很大的省錢(qián)空間，從經(jīng)濟(jì)/效率的角度來(lái)看，這個(gè)東西放在那兒很浪費(fèi)。

還有大數(shù)據(jù)的備份，大數(shù)據(jù)是我們的命脈。如果網(wǎng)站宕一天，我們道歉一下就行了，第二天該來(lái)的用戶還得來(lái)。

但大數(shù)據(jù)一旦出問(wèn)題，一是數(shù)據(jù)是隱私，二是數(shù)據(jù)丟掉或者錯(cuò)亂，會(huì)更加麻煩。

我們每天做了很多的備份，但后來(lái)發(fā)現(xiàn)這些備份太冷了，到底劃不劃算，你不能去賭它，但是成本放那兒太痛苦了?；旌显萍軜?gòu)是被逼出來(lái)的，不是我想搞這些東西的。

餓了么正在做的以及未來(lái)計(jì)劃

混合云架構(gòu)

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

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

我們用一個(gè)服務(wù)，就希望它是跨 IDC 的，主要就是 latency 和一致性，這兩個(gè)問(wèn)題很難協(xié)調(diào)。

還有 Cloud Native，是大勢(shì)所趨，就像 Go 語(yǔ)言。冒煙時(shí)開(kāi)始做，太超前了也不行，畢竟要先把業(yè)務(wù)做起來(lái)。

但是到小火就比較危險(xiǎn)了，我們也曾到小火的時(shí)候再去還債，還債還算容易，到小火的時(shí)候真的靠人肉上去砸就比較麻煩了。

Cloud 肯定會(huì)考慮的，混合云雖然聽(tīng)上去很時(shí)尚，但是我們的步調(diào)比較謹(jǐn)慎。對(duì)運(yùn)維團(tuán)隊(duì)也是個(gè)挑戰(zhàn)，比如 RDS。

我們內(nèi)部數(shù)據(jù)庫(kù)也千奇百怪，有 MySQL、MongoDB。你讓習(xí)慣了敲命令行，寫(xiě)腳本的運(yùn)維變成程序員，我們內(nèi)部反過(guò)來(lái)叫 OpsDev，這個(gè)難度要遠(yuǎn)超過(guò) DevOps。我們希望公司所有人都是程序員，但是這個(gè)挑戰(zhàn)蠻大的。

我們 Serverless 是在線上做了一個(gè)系統(tǒng)，但是比較簡(jiǎn)單。接下來(lái)可能會(huì)考慮短信推送，移動(dòng)推送，因?yàn)檫@個(gè)只要搭個(gè) Redis，開(kāi)啟就可以直接發(fā)送了。

對(duì)我們來(lái)說(shuō)，Serverless 對(duì)復(fù)雜業(yè)務(wù)是走不通的，除非我們?nèi)坑?Cloud infrastructure。

Auto scaling 是我們?cè)谟?jì)劃做的，因?yàn)槎嗷钭隽酥蟛拍芟鄬?duì)寬松一些，流量想切多少切多少。

95% 的 transaction 都在同一個(gè) zone 里做完的。不做這件事情就沒(méi)有辦法做阿里云的拓展。阿里云現(xiàn)在可以做 Auto scaling，但是成本很高。

一般來(lái)說(shuō)，云的成本會(huì)比 IDC 要高一些，那是不是做 4 小時(shí)的拉起再拉出（值應(yīng)對(duì)峰值流量）是劃算的？

我們算了一筆賬，發(fā)現(xiàn)不一定是這樣。如果削峰填谷做的比較有成效的話，就會(huì)沖淡 Auto scaling 節(jié)省的成本。

我們和新浪微博不一樣，它是不可預(yù)知突發(fā)事件的，所以只能做 on demand（按需）。雖然我們有很大的波谷差異，但是可以預(yù)知的。

前兩天團(tuán)隊(duì)給我一個(gè)“炸彈”：我們現(xiàn)在機(jī)器利用率很低，我們不是上了 Docker 嘛，我們做一件事情——超賣(mài)。

什么叫超賣(mài)？我們?cè)瓉?lái)是一核對(duì)一核，現(xiàn)在一核當(dāng)兩核，后來(lái)發(fā)現(xiàn)還不錯(cuò)，用 Docker 的人感覺(jué)沒(méi)有什么變化。

我們繼續(xù)超賣(mài)，一核當(dāng)三核用，我們按峰值來(lái)算的，發(fā)現(xiàn)平時(shí)的峰值利用率也不是那么高。

混部嘗試

不管我們要不要做 auto scaling，不管我們業(yè)務(wù)上要不要削峰填谷，都要做混部。

混部這塊，百度走的早一些，他們前幾年做了一個(gè)系統(tǒng)，目的不是要混部，但是要產(chǎn)生一個(gè)好的副作用來(lái)實(shí)現(xiàn)這樣的功能。

回到業(yè)務(wù)本身，混部其實(shí)很難的，我跟他們聊的時(shí)候，說(shuō)搜索這種業(yè)務(wù)是可以采用類(lèi)似于網(wǎng)格計(jì)算的，每個(gè)格子自己算，然后匯聚。

他們有大量的 swap（數(shù)據(jù)交換），但你讓 Spark 來(lái)做這些功能，比如 Machine Learning 和 swap，即使是萬(wàn)兆網(wǎng)卡，也會(huì)突然把帶寬占滿。

現(xiàn)在機(jī)器學(xué)習(xí)跟搜索或者爬蟲(chóng)可以分而治之的技術(shù)不一樣，我們叫分布式，有大量的 swap。我們也在嘗試，把能夠在每一個(gè)節(jié)點(diǎn)單獨(dú)計(jì)算，不需要大量 swap 的任務(wù)放上去。

混部是為了解決什么問(wèn)題呢？我們業(yè)務(wù)的峰值非常高，到波谷的時(shí)候這些機(jī)器就閑置著，那是不是可以來(lái)跑一些 job。

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

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

還有很頭疼的挑戰(zhàn)：我們大數(shù)據(jù)團(tuán)隊(duì)用的機(jī)型是定制的，他們已經(jīng)習(xí)慣了這種機(jī)型模板。

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

我們這個(gè)行業(yè)經(jīng)常有促銷(xiāo)活動(dòng)?；顒?dòng)的時(shí)候即使有云，也還是要花錢(qián)的。所以活動(dòng)期間可以把大數(shù)據(jù)任務(wù)凍結(jié)，釋放機(jī)器資源用于大促。

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

我們?cè)谘芯康膯?wèn)題是 YARN、Mesos 和 ZStack 怎么適配，現(xiàn)在仍然沒(méi)有搞定。

混部的問(wèn)題早就存在，但是財(cái)務(wù)上面給我的壓力沒(méi)有到冒煙，如果餓了么哪天提供了餓了么云，大家不要驚訝。

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

我們現(xiàn)在有很多的配送并不來(lái)自于餓了么，也幫雙 11 配送。現(xiàn)在也有叫閃送，可以在很短的時(shí)間送到，一個(gè)人送一個(gè)件，但是收費(fèi)比較高。

我看到閃送的人直接騎摩托車(chē)送的，一般是電動(dòng)車(chē)。很多時(shí)候業(yè)務(wù)發(fā)展起來(lái)了，正好也幫我們解決了這樣的一些問(wèn)題。