會議為：3月26日，北京，【思路匯】企業電商云應用案例分享，易到用車首席架構師—余慶發表了題為《易到用車構架演進及上云探索》的公開演講。

以下為演講實錄：

首先非常容幸第一個上來跟大家分享，很高興和大家認識做交流。然后我是在易到用車做架構師，所以我這個演講可能技術性會更強一點。我個人先簡單介紹一下，剛剛劉宸這邊也講了，就講了我的背景，可能在新浪，雅虎中國，淘寶阿里云都工作過，我個人比較喜歡開源的，可以說是典型的技術男吧。然后我自己寫過開源的分布式文件系統FastDSF，現在國內用的蠻多的。參與過Apache Traffic Sever的核心代碼改造。

這個提綱三部分，可能在座的朋友對易到用車不是很了解，我就很簡單過一下，重點是我們易到用車架構的介紹。最后包括我們現在也在探討究竟要不要上云，可能有我們的一些思考跟大家分享一下。大家可能都知道，春節前滴滴和快滴合并了，在情人節那天牽手了，滴滴和快滴他們最早是做打車，易到用車一開始定位就是做專車，后面滴滴快滴他們去年開始做專車服務，易到用車從2010年對專車這個領域開始做探索。在國內易到用車是做這個領域的鼻祖，但目前從風投上來看感覺滴滴更勝一些，其實滴滴在這塊營銷很猛。

易到用車的生活主要是給大家出行提供便利。就是易到用車提倡的就是以我為本，按需而至。給人出行，包括領域，可能體現的是一種情懷，體現的是大家追求美好的生活，而不是現在在街頭上苦逼哈哈的在街上打車打不到的現狀。可能易到是一種美好的生活。大家對周航了解是非常有情懷非常有追求的一個人。然后我們易到用車剛剛講到2010年成立開始做，我們推出專車隨叫隨到，按時計費，檔次很高，屬于專業服務，讓用戶感覺這是我個人專車，就是我們用戶體驗比較好。肯定傳統的出租車沒法比。然后看一下我們易到用車的用車情況，目前在國內開展75個城市，國外26家城市，其實一起到100家。簡單跟大家介紹一下。

接下來是我比較重要的一部分，把易到用車技術的情況給大家匯報一下。其實易到用車技術上也不是有多先進多牛逼，大家可以看到它主要是LAMP結構，緩存我們用的是Redis，然后我們也會用MongoDB，在負載均衡方面我們會用到LVS，然后我們內部負載均衡還會用到HAPROXY，然后也會用KEEPALIVED做雙機的熱備，剛剛我也說我們沒有特殊的東西，也是典型的數據庫應用。

我們看一下架構圖吧，

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

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

因為我們是用PHP的，怎么服務化，我們這邊有一個思路可以跟同仁們參考一下。我們的PHP服務化。大家理解PHP感覺還是腳本代碼，可能如果沒有別的方式，PHP性能不是特別好。然后我們可能提出新的方式，有這種方式之后，PHP的性能就不是問題了。因為我們主要是PHP語言，我們用C語言做PHP服務框架，用C來實現網絡通信層，這樣能支持大量的并發連接，我們的調用方和服務方就完全是走長連接了，因為走短連接的話開銷是比較大的，在服務化之前，我們原來的服務方是走http的，我們現在使用Apache，我們用的又是比較傳統的那種子進程的模式，注定了支持不了太多的并發連接，然后調用服務方都是用短連接，那就會產生短連接的建連開銷，積少成多，其實建連開銷還是很可觀的。然后我們建立長連接之后，就把這個建連開銷給省掉了，這是很大的特點。還有我們看傳統的PHP跑在Apache、nginx上面，都是傳統的web方式，其實是類似CGI的方式，這種方式開銷比較大，PHP生命周期以一個請求來做一個生命周期，這個請求開始，php的環境創建，到這個請求結束，相應的PHP資源就清除了，其實這個開銷比較大。然后我們就讓PHP以DAEMON方式來運行，以后臺守護方式來運行，這樣就把PHP運行在web SEVER下面這種性能的問題給解決掉了。

然后優化這塊，我們會通過C來寫框架，然后提供PHP擴展出來，以寫業務服務代碼直接用純PHP來寫，網絡通信什么的全都是走C的這套框架來實現，這樣能夠支持大并發連接，PHP不用關心網絡通信的事兒。其實就是和寫Apache的代碼一樣的，只要關心業務層就好了，說白了我們這個服務框架就類似于Web SEVER的一個容器。其實PHP框架和那個JAVA體系框架思路類似，只是我們是針對PHP語言來實現的服務框架。比如說淘寶內部是一個JAVA服務框架HSF，后面也開源了，HSF是java的服務框架，我們的是PHP的服務框架，其實它的基本思路都是類似的，只是我們針對PHP語言給他作出一套高性能的框架出來。其實這個框架最主要的就是兩大點，性能比較好，高效，并且相對比較簡潔。為什么說性能好，最主要的是PHP是以Daemon方式來運行的，省掉了好多資源。包括PHP，大家知道，它的OP Code，因為php他是解釋執行的，像傳統的web方式運行，它的代碼需要編譯成OP Code來執行，類似于JAVA的字節碼，編譯成OP code之后，然后需要緩存起來，為了提高效率，不然每次請求來了都需要建議解釋執行，然而以Daemon方式運行，就不存在這個問題了，因為他是后臺程序，一直在運行。像PHP寫的Class什么的，就和java一樣的，這個Class只要load一次，就Ok了，就一直在我的進程里面。所以我們的這種方式是改變PHP的傳統運行方式，這是很大的突破。

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

然后我們的特點就是要實現簡潔高效。這是第一個特點。

第二個特點就是副產品，不是主要產品，但是也是很有用的。通過服務化之后，他的訂單中心就自成體系，只要我的中心管好，調用方其實它只要知道中心，因為我們有服務管理的中心，對調用方他只要知道管理中心的地址，他就可以找到很多服務，比如說我有訂單服務，用戶服務，支付服務，結算服務之類的，他不需要知道每一個服務的地址，他只要知道管理中心的地址，這些服務的位置和地址他都可以拿到。這個對服務中心有一個好處，就是降低調用方的配置門檻和難度。我主要就總結了這兩點。

然后可能我們架構上的一些探索和我們要做的工作大概介紹的差不多了。然后就是我們易到用車這邊要不要上云，可能這塊我們探索了肯定有大半年了，包括可能后面也講了，包括我們和國內的一些知名服務廠商都交流過。國際知名的我們也都交流過。另外易到用車目前還沒有上云，還是自己托管的方式，很傳統的方式。我們在探討要不要上云也大概一年時間了，前面我們也試用過一個國際知名服務商的服務，他們在國內體驗不是很好。后面如果我們要上云也不會選他們了，OK，這是大概的情況。

然后云服務優勢，這可能是我個人的一點見解，不全面，就是我個人的想法。其實云服務我覺得最大的優勢就是彈性，按需分配。云服務是比較典型的行業，比如說游戲行業，游戲行業大家知道要上一個游戲的話，一般這個游戲剛推出來可能比較火爆，爆增。然后過了幾個月之后，可能慢慢地很迅速的這個用戶就會下來。像比較典型的游戲行業可能適合云服務，尤其是對這個彈性要求高。這是云服務最大的優勢就是它的彈性，就是我的資源按需分配，我今天比如說20臺機器，明天用戶量上升，100臺機器也可以。因為你自己托管不可能，你提前一百臺機器預備好，根據評估只要100臺機器扛得住，然后你把機器放在那里備著。我認為這是云服務最大的優勢。然后就是云服務有很大的安全性，在安全方面做了很多的功課，比如會提供防DDOS攻擊的，還有包括CC攻擊等等的服務和手段都在里面。這是互聯網企業比較看重的一個地方，就是安全性。還有一個可能我認為云服務提供好的服務就是提供增值服務，就是如數據統計和分析平臺。大家可能知道現在數據越來越重要，講究怎么從數據里面分析、挖掘找到有價值的東西，這些東西都是需要計算資源的，如果這個平臺有這個資源輸入出來的話，肯定很多企業會很關心這點。我主要介紹就這三點，等會兒大家看如果有不足的地方大家可以交流。

然后易到用車和云的匹配情況，易到用車我們做的比較典型的O2O應用，我們彈性并不是那么高。因為不可能一下子今天20臺機器，一個月就到100臺機器，我們看不到有這么迅猛的增長，所以我們對彈性要求性能不是太高。安全性能我們挺重視的，一方面是傳統的攻擊性，另外一方面我們對數據這方面也很重視。數據安全你數據被競爭對手拿去了這就是很大的問題。然后提供的增值服務，目前易到用車對服務的要求不是特別高。

我們易到用車選擇云的關注點其實主要這幾點，一點就是可用性，就是你的服務是不是靠譜的，比如打客服多長時間響應及故障處理速度。這是我們特別關注的。另外就是安全性，其實安全性更主要的就是剛剛我講的數據安全，我的數據不管什么原因被人拿走了這肯定是不能接受的。成本這塊肯定也會考慮。另外增值服務也是我們比較關注的，我們云平臺如果提供計算分析的能力，有這樣的一些服務提供出來的話，如果我們上云，我們肯定會用的。

最后我們也是在探討會不會上云呢？其實我們易到用車有個特點，我們現在是個大的APP，目前我們主要是做專車這一個大的應用，然后其實我們也相應是一個電子商務類型的互聯網企業，也是偏電子商務。我們的特點，比如說你的定單，你的用戶，你的支付什么的，這個系統我們要求就在一個私有云里面，就在一個云里面做，一個是考慮安全問題，如果跨機房調用，連接的穩定性和延時不可控肯定是不能被接受的。所以我們前面論證過上云是不是先上一部分還是上一個模塊，我們論證之后都覺得不可取。我們考慮的主要兩點，一個是鏈路問題，一個是穩定性問題，所以我們答案要么就全上，要么就不上，很干脆，沒有說我們自己又托管，又上云，我們數據再怎么調用，這個基本上我們不考慮了。然后我們現在要不要上云也沒定，也還在考慮。然后我就講這么多吧，謝謝大家！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。