会议为：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，目前我们主要是做专车这一个大的应用，然后其实我们也相应是一个电子商务类型的互联网企业，也是偏电子商务。我们的特点，比如说你的定单，你的用户，你的支付什么的，这个系统我们要求就在一个私有云里面，就在一个云里面做，一个是考虑安全问题，如果跨机房调用，连接的稳定性和延时不可控肯定是不能被接受的。所以我们前面论证过上云是不是先上一部分还是上一个模块，我们论证之后都觉得不可取。我们考虑的主要两点，一个是链路问题，一个是稳定性问题，所以我们答案要么就全上，要么就不上，很干脆，没有说我们自己又托管，又上云，我们数据再怎么调用，这个基本上我们不考虑了。然后我们现在要不要上云也没定，也还在考虑。然后我就讲这么多吧，谢谢大家！