會(huì)議為：3月26日，北京，【思路匯】企業(yè)電商云應(yīng)用案例分享，易到用車(chē)首席架構(gòu)師—余慶發(fā)表了題為《易到用車(chē)構(gòu)架演進(jìn)及上云探索》的公開(kāi)演講。

以下為演講實(shí)錄：

首先非常容幸第一個(gè)上來(lái)跟大家分享，很高興和大家認(rèn)識(shí)做交流。然后我是在易到用車(chē)做架構(gòu)師，所以我這個(gè)演講可能技術(shù)性會(huì)更強(qiáng)一點(diǎn)。我個(gè)人先簡(jiǎn)單介紹一下，剛剛劉宸這邊也講了，就講了我的背景，可能在新浪，雅虎中國(guó)，淘寶阿里云都工作過(guò)，我個(gè)人比較喜歡開(kāi)源的，可以說(shuō)是典型的技術(shù)男吧。然后我自己寫(xiě)過(guò)開(kāi)源的分布式文件系統(tǒng)FastDSF，現(xiàn)在國(guó)內(nèi)用的蠻多的。參與過(guò)Apache Traffic Sever的核心代碼改造。

這個(gè)提綱三部分，可能在座的朋友對(duì)易到用車(chē)不是很了解，我就很簡(jiǎn)單過(guò)一下，重點(diǎn)是我們易到用車(chē)架構(gòu)的介紹。最后包括我們現(xiàn)在也在探討究竟要不要上云，可能有我們的一些思考跟大家分享一下。大家可能都知道，春節(jié)前滴滴和快滴合并了，在情人節(jié)那天牽手了，滴滴和快滴他們最早是做打車(chē)，易到用車(chē)一開(kāi)始定位就是做專(zhuān)車(chē)，后面滴滴快滴他們?nèi)ツ觊_(kāi)始做專(zhuān)車(chē)服務(wù)，易到用車(chē)從2010年對(duì)專(zhuān)車(chē)這個(gè)領(lǐng)域開(kāi)始做探索。在國(guó)內(nèi)易到用車(chē)是做這個(gè)領(lǐng)域的鼻祖，但目前從風(fēng)投上來(lái)看感覺(jué)滴滴更勝一些，其實(shí)滴滴在這塊營(yíng)銷(xiāo)很猛。

易到用車(chē)的生活主要是給大家出行提供便利。就是易到用車(chē)提倡的就是以我為本，按需而至。給人出行，包括領(lǐng)域，可能體現(xiàn)的是一種情懷，體現(xiàn)的是大家追求美好的生活，而不是現(xiàn)在在街頭上苦逼哈哈的在街上打車(chē)打不到的現(xiàn)狀。可能易到是一種美好的生活。大家對(duì)周航了解是非常有情懷非常有追求的一個(gè)人。然后我們易到用車(chē)剛剛講到2010年成立開(kāi)始做，我們推出專(zhuān)車(chē)隨叫隨到，按時(shí)計(jì)費(fèi)，檔次很高，屬于專(zhuān)業(yè)服務(wù)，讓用戶(hù)感覺(jué)這是我個(gè)人專(zhuān)車(chē)，就是我們用戶(hù)體驗(yàn)比較好。肯定傳統(tǒng)的出租車(chē)沒(méi)法比。然后看一下我們易到用車(chē)的用車(chē)情況，目前在國(guó)內(nèi)開(kāi)展75個(gè)城市，國(guó)外26家城市，其實(shí)一起到100家。簡(jiǎn)單跟大家介紹一下。

接下來(lái)是我比較重要的一部分，把易到用車(chē)技術(shù)的情況給大家匯報(bào)一下。其實(shí)易到用車(chē)技術(shù)上也不是有多先進(jìn)多牛逼，大家可以看到它主要是LAMP結(jié)構(gòu)，緩存我們用的是Redis，然后我們也會(huì)用MongoDB，在負(fù)載均衡方面我們會(huì)用到LVS，然后我們內(nèi)部負(fù)載均衡還會(huì)用到HAPROXY，然后也會(huì)用KEEPALIVED做雙機(jī)的熱備，剛剛我也說(shuō)我們沒(méi)有特殊的東西，也是典型的數(shù)據(jù)庫(kù)應(yīng)用。

我們看一下架構(gòu)圖吧，

架構(gòu)大家都是這么干的，最底層是存儲(chǔ)層，我們有Mysql、MongoDB，有Redis，我們的緩存用Redis，然后我們的隊(duì)列會(huì)用MQ，服務(wù)層有用戶(hù)，有司機(jī)，有定單，有支付，還有消息推送之類(lèi)的。然后我們對(duì)APP這塊，或者第三方合作伙伴我們用OPEN API，這里會(huì)涉及到安全的問(wèn)題，所以需要認(rèn)證，我們現(xiàn)在用比較主流的認(rèn)證方式，就是OAuth方式。我們現(xiàn)在是個(gè)典型的O2O的應(yīng)用，我們的用戶(hù)主要是用APP，我們的定單量主要是APP貢獻(xiàn)的，網(wǎng)站量占的比例是比較小的。大概是這樣。

再往下看，這是我們面臨的技術(shù)挑戰(zhàn)。技術(shù)挑戰(zhàn)我簡(jiǎn)單寫(xiě)了幾條，對(duì)成長(zhǎng)比較快的互聯(lián)網(wǎng)公司都會(huì)碰到這個(gè)問(wèn)題，比如說(shuō)我們變化比較快，及時(shí)應(yīng)付業(yè)務(wù)的需求，可能技術(shù)上搞的經(jīng)常加班加點(diǎn)的事情比較常見(jiàn)。另外就是可能前面我們可能也是跟著業(yè)務(wù)跑，做的比較快。像模塊劃分其實(shí)也分了，但是可能我們具體在做的時(shí)候界限沒(méi)有分的那么清楚，所以就存在耦合的情況，然后性能也存在性能的問(wèn)題。還有開(kāi)源軟件，互聯(lián)網(wǎng)大量會(huì)用到開(kāi)源軟件，在平常情況下只用到開(kāi)源軟件滿(mǎn)足不了需求，需要自己定制開(kāi)發(fā)，或者是自主開(kāi)發(fā)。比如我們的消息推送平臺(tái)就是一個(gè)例子，我們最早就是基于一個(gè)開(kāi)源平臺(tái)ejabberd做的，他是基于XMPP協(xié)議做的，采用輪訓(xùn)算法，效果特別差，負(fù)載率高，送達(dá)率也不是特別高，然后我們自主開(kāi)發(fā)了平臺(tái)，送達(dá)率比原來(lái)推送率提高了大概5%吧。以前推送率大概93%，我們改進(jìn)之后大概能夠到99%，應(yīng)該是提高了6%個(gè)點(diǎn)。包括性能的問(wèn)題也消失掉了。然后像我們今年，可以說(shuō)今年的工作重點(diǎn)，就是我們會(huì)做服務(wù)化，還有就是中心化。這個(gè)其實(shí)很多公司就是服務(wù)化和中心化走過(guò)來(lái)的，這塊我們?cè)谧?#xff0c;還沒(méi)有做完，反正今年全部搞定，否則就是剛剛講的模塊耦合會(huì)影響性能和擴(kuò)展性能出問(wèn)題，另外就是開(kāi)發(fā)效率和什么效率都會(huì)受到影響。另外我們也會(huì)再看多機(jī)房的問(wèn)題，我們目前是一個(gè)機(jī)房，也在考慮多個(gè)機(jī)房，做互備的方式。

因?yàn)槲覀兪怯肞HP的，怎么服務(wù)化，我們這邊有一個(gè)思路可以跟同仁們參考一下。我們的PHP服務(wù)化。大家理解PHP感覺(jué)還是腳本代碼，可能如果沒(méi)有別的方式，PHP性能不是特別好。然后我們可能提出新的方式，有這種方式之后，PHP的性能就不是問(wèn)題了。因?yàn)槲覀冎饕荘HP語(yǔ)言，我們用C語(yǔ)言做PHP服務(wù)框架，用C來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)通信層，這樣能支持大量的并發(fā)連接，我們的調(diào)用方和服務(wù)方就完全是走長(zhǎng)連接了，因?yàn)樽叨踢B接的話(huà)開(kāi)銷(xiāo)是比較大的，在服務(wù)化之前，我們?cè)瓉?lái)的服務(wù)方是走h(yuǎn)ttp的，我們現(xiàn)在使用Apache，我們用的又是比較傳統(tǒng)的那種子進(jìn)程的模式，注定了支持不了太多的并發(fā)連接，然后調(diào)用服務(wù)方都是用短連接，那就會(huì)產(chǎn)生短連接的建連開(kāi)銷(xiāo)，積少成多，其實(shí)建連開(kāi)銷(xiāo)還是很可觀的。然后我們建立長(zhǎng)連接之后，就把這個(gè)建連開(kāi)銷(xiāo)給省掉了，這是很大的特點(diǎn)。還有我們看傳統(tǒng)的PHP跑在Apache、nginx上面，都是傳統(tǒng)的web方式，其實(shí)是類(lèi)似CGI的方式，這種方式開(kāi)銷(xiāo)比較大，PHP生命周期以一個(gè)請(qǐng)求來(lái)做一個(gè)生命周期，這個(gè)請(qǐng)求開(kāi)始，php的環(huán)境創(chuàng)建，到這個(gè)請(qǐng)求結(jié)束，相應(yīng)的PHP資源就清除了，其實(shí)這個(gè)開(kāi)銷(xiāo)比較大。然后我們就讓PHP以DAEMON方式來(lái)運(yùn)行，以后臺(tái)守護(hù)方式來(lái)運(yùn)行，這樣就把PHP運(yùn)行在web SEVER下面這種性能的問(wèn)題給解決掉了。

然后優(yōu)化這塊，我們會(huì)通過(guò)C來(lái)寫(xiě)框架，然后提供PHP擴(kuò)展出來(lái)，以寫(xiě)業(yè)務(wù)服務(wù)代碼直接用純PHP來(lái)寫(xiě)，網(wǎng)絡(luò)通信什么的全都是走C的這套框架來(lái)實(shí)現(xiàn)，這樣能夠支持大并發(fā)連接，PHP不用關(guān)心網(wǎng)絡(luò)通信的事兒。其實(shí)就是和寫(xiě)Apache的代碼一樣的，只要關(guān)心業(yè)務(wù)層就好了，說(shuō)白了我們這個(gè)服務(wù)框架就類(lèi)似于Web SEVER的一個(gè)容器。其實(shí)PHP框架和那個(gè)JAVA體系框架思路類(lèi)似，只是我們是針對(duì)PHP語(yǔ)言來(lái)實(shí)現(xiàn)的服務(wù)框架。比如說(shuō)淘寶內(nèi)部是一個(gè)JAVA服務(wù)框架HSF，后面也開(kāi)源了，HSF是java的服務(wù)框架，我們的是PHP的服務(wù)框架，其實(shí)它的基本思路都是類(lèi)似的，只是我們針對(duì)PHP語(yǔ)言給他作出一套高性能的框架出來(lái)。其實(shí)這個(gè)框架最主要的就是兩大點(diǎn)，性能比較好，高效，并且相對(duì)比較簡(jiǎn)潔。為什么說(shuō)性能好，最主要的是PHP是以Daemon方式來(lái)運(yùn)行的，省掉了好多資源。包括PHP，大家知道，它的OP Code，因?yàn)閜hp他是解釋執(zhí)行的，像傳統(tǒng)的web方式運(yùn)行，它的代碼需要編譯成OP Code來(lái)執(zhí)行，類(lèi)似于JAVA的字節(jié)碼，編譯成OP code之后，然后需要緩存起來(lái)，為了提高效率，不然每次請(qǐng)求來(lái)了都需要建議解釋執(zhí)行，然而以Daemon方式運(yùn)行，就不存在這個(gè)問(wèn)題了，因?yàn)樗呛笈_(tái)程序，一直在運(yùn)行。像PHP寫(xiě)的Class什么的，就和java一樣的，這個(gè)Class只要load一次，就Ok了，就一直在我的進(jìn)程里面。所以我們的這種方式是改變PHP的傳統(tǒng)運(yùn)行方式，這是很大的突破。

然后另外就是剛剛講到調(diào)用方和服務(wù)方，它是長(zhǎng)連接，包括你寫(xiě)這個(gè)服務(wù)的時(shí)候到后端的資源，到Mysql、到Redis、到MongoDB，它的調(diào)用方是長(zhǎng)連接，你的服務(wù)方本身到后端的連接也是長(zhǎng)連接，其實(shí)就把連接的這個(gè)開(kāi)銷(xiāo)給省掉了，這個(gè)也是我們的顯著提升。其實(shí)我們做服務(wù)化之后和java版的服務(wù)化是一樣的，它天然就是負(fù)載均衡化的，它不像我們走h(yuǎn)ttp方式的，你在最外層還得加一層LB負(fù)載層，比如你的負(fù)載層是用nginx來(lái)做也好，haproxy來(lái)做也好，還是使用lvs來(lái)做也好，也是有一層負(fù)載負(fù)載均衡層的。但是我們天然做服務(wù)框架方式的話(huà)，就把負(fù)載均衡層完全給拿掉了，就是完全扁平化的。然后我們的通信協(xié)議，是用的我們自己的私有協(xié)議，叫二進(jìn)制協(xié)議，比起http協(xié)議，也是簡(jiǎn)潔高效。像http協(xié)議的header，一個(gè)請(qǐng)求，一個(gè)response，如果省一點(diǎn)的話(huà)，什么server啊，什么host什么的，亂七八糟加起來(lái)，我估計(jì)一個(gè)請(qǐng)求一個(gè)響應(yīng)，這一來(lái)一回，它的header部分的字節(jié)數(shù)加起來(lái)就接近1K了，對(duì)于內(nèi)部的服務(wù)調(diào)用來(lái)講就是完全不必要的消耗。

然后我們的特點(diǎn)就是要實(shí)現(xiàn)簡(jiǎn)潔高效。這是第一個(gè)特點(diǎn)。

第二個(gè)特點(diǎn)就是副產(chǎn)品，不是主要產(chǎn)品，但是也是很有用的。通過(guò)服務(wù)化之后，他的訂單中心就自成體系，只要我的中心管好，調(diào)用方其實(shí)它只要知道中心，因?yàn)槲覀冇蟹?wù)管理的中心，對(duì)調(diào)用方他只要知道管理中心的地址，他就可以找到很多服務(wù)，比如說(shuō)我有訂單服務(wù)，用戶(hù)服務(wù)，支付服務(wù)，結(jié)算服務(wù)之類(lèi)的，他不需要知道每一個(gè)服務(wù)的地址，他只要知道管理中心的地址，這些服務(wù)的位置和地址他都可以拿到。這個(gè)對(duì)服務(wù)中心有一個(gè)好處，就是降低調(diào)用方的配置門(mén)檻和難度。我主要就總結(jié)了這兩點(diǎn)。

然后可能我們架構(gòu)上的一些探索和我們要做的工作大概介紹的差不多了。然后就是我們易到用車(chē)這邊要不要上云，可能這塊我們探索了肯定有大半年了，包括可能后面也講了，包括我們和國(guó)內(nèi)的一些知名服務(wù)廠(chǎng)商都交流過(guò)。國(guó)際知名的我們也都交流過(guò)。另外易到用車(chē)目前還沒(méi)有上云，還是自己托管的方式，很傳統(tǒng)的方式。我們?cè)谔接懸灰显埔泊蟾乓荒陼r(shí)間了，前面我們也試用過(guò)一個(gè)國(guó)際知名服務(wù)商的服務(wù)，他們?cè)趪?guó)內(nèi)體驗(yàn)不是很好。后面如果我們要上云也不會(huì)選他們了，OK，這是大概的情況。

然后云服務(wù)優(yōu)勢(shì)，這可能是我個(gè)人的一點(diǎn)見(jiàn)解，不全面，就是我個(gè)人的想法。其實(shí)云服務(wù)我覺(jué)得最大的優(yōu)勢(shì)就是彈性，按需分配。云服務(wù)是比較典型的行業(yè)，比如說(shuō)游戲行業(yè)，游戲行業(yè)大家知道要上一個(gè)游戲的話(huà)，一般這個(gè)游戲剛推出來(lái)可能比較火爆，爆增。然后過(guò)了幾個(gè)月之后，可能慢慢地很迅速的這個(gè)用戶(hù)就會(huì)下來(lái)。像比較典型的游戲行業(yè)可能適合云服務(wù)，尤其是對(duì)這個(gè)彈性要求高。這是云服務(wù)最大的優(yōu)勢(shì)就是它的彈性，就是我的資源按需分配，我今天比如說(shuō)20臺(tái)機(jī)器，明天用戶(hù)量上升，100臺(tái)機(jī)器也可以。因?yàn)槟阕约和泄懿豢赡?#xff0c;你提前一百臺(tái)機(jī)器預(yù)備好，根據(jù)評(píng)估只要100臺(tái)機(jī)器扛得住，然后你把機(jī)器放在那里備著。我認(rèn)為這是云服務(wù)最大的優(yōu)勢(shì)。然后就是云服務(wù)有很大的安全性，在安全方面做了很多的功課，比如會(huì)提供防DDOS攻擊的，還有包括CC攻擊等等的服務(wù)和手段都在里面。這是互聯(lián)網(wǎng)企業(yè)比較看重的一個(gè)地方，就是安全性。還有一個(gè)可能我認(rèn)為云服務(wù)提供好的服務(wù)就是提供增值服務(wù)，就是如數(shù)據(jù)統(tǒng)計(jì)和分析平臺(tái)。大家可能知道現(xiàn)在數(shù)據(jù)越來(lái)越重要，講究怎么從數(shù)據(jù)里面分析、挖掘找到有價(jià)值的東西，這些東西都是需要計(jì)算資源的，如果這個(gè)平臺(tái)有這個(gè)資源輸入出來(lái)的話(huà)，肯定很多企業(yè)會(huì)很關(guān)心這點(diǎn)。我主要介紹就這三點(diǎn)，等會(huì)兒大家看如果有不足的地方大家可以交流。

然后易到用車(chē)和云的匹配情況，易到用車(chē)我們做的比較典型的O2O應(yīng)用，我們彈性并不是那么高。因?yàn)椴豢赡芤幌伦咏裉?0臺(tái)機(jī)器，一個(gè)月就到100臺(tái)機(jī)器，我們看不到有這么迅猛的增長(zhǎng)，所以我們對(duì)彈性要求性能不是太高。安全性能我們挺重視的，一方面是傳統(tǒng)的攻擊性，另外一方面我們對(duì)數(shù)據(jù)這方面也很重視。數(shù)據(jù)安全你數(shù)據(jù)被競(jìng)爭(zhēng)對(duì)手拿去了這就是很大的問(wèn)題。然后提供的增值服務(wù)，目前易到用車(chē)對(duì)服務(wù)的要求不是特別高。

我們易到用車(chē)選擇云的關(guān)注點(diǎn)其實(shí)主要這幾點(diǎn)，一點(diǎn)就是可用性，就是你的服務(wù)是不是靠譜的，比如打客服多長(zhǎng)時(shí)間響應(yīng)及故障處理速度。這是我們特別關(guān)注的。另外就是安全性，其實(shí)安全性更主要的就是剛剛我講的數(shù)據(jù)安全，我的數(shù)據(jù)不管什么原因被人拿走了這肯定是不能接受的。成本這塊肯定也會(huì)考慮。另外增值服務(wù)也是我們比較關(guān)注的，我們?cè)破脚_(tái)如果提供計(jì)算分析的能力，有這樣的一些服務(wù)提供出來(lái)的話(huà)，如果我們上云，我們肯定會(huì)用的。

最后我們也是在探討會(huì)不會(huì)上云呢？其實(shí)我們易到用車(chē)有個(gè)特點(diǎn)，我們現(xiàn)在是個(gè)大的APP，目前我們主要是做專(zhuān)車(chē)這一個(gè)大的應(yīng)用，然后其實(shí)我們也相應(yīng)是一個(gè)電子商務(wù)類(lèi)型的互聯(lián)網(wǎng)企業(yè)，也是偏電子商務(wù)。我們的特點(diǎn)，比如說(shuō)你的定單，你的用戶(hù)，你的支付什么的，這個(gè)系統(tǒng)我們要求就在一個(gè)私有云里面，就在一個(gè)云里面做，一個(gè)是考慮安全問(wèn)題，如果跨機(jī)房調(diào)用，連接的穩(wěn)定性和延時(shí)不可控肯定是不能被接受的。所以我們前面論證過(guò)上云是不是先上一部分還是上一個(gè)模塊，我們論證之后都覺(jué)得不可取。我們考慮的主要兩點(diǎn)，一個(gè)是鏈路問(wèn)題，一個(gè)是穩(wěn)定性問(wèn)題，所以我們答案要么就全上，要么就不上，很干脆，沒(méi)有說(shuō)我們自己又托管，又上云，我們數(shù)據(jù)再怎么調(diào)用，這個(gè)基本上我們不考慮了。然后我們現(xiàn)在要不要上云也沒(méi)定，也還在考慮。然后我就講這么多吧，謝謝大家！

總結(jié)

以上是生活随笔為你收集整理的易到用车构架演进及上云探索的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。