当前位置:首页 > 程序人生

听云APMCon-浅谈App优化

发布时间:2019-10-12 09:30:04   编辑:it技术学习网   阅读次数:

  中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会,首次举办的APMCon以“驱动应用架构优化与创新”为主题,致力于推动APM在国内的成长与发展。

  饿了么移动技术负责人胡彪于移动性能优化专场发表了题为《浅谈App优化》的演讲,现场分享了饿了么在移动端性能优化方面的踩过的一些坑,以及采坑过程中一点心得。

  以下为演讲实录:

  胡彪:大家好,我是来自饿了么的胡彪,目前负责移动技术。大会组织委找到我的时候,其实我是拒绝的。因为饿了么既不是行业鼻祖也不是TOP级品牌,如果想讲APM这一块的东西,我是没有很多的自信的。饿了么还是一个创业公司,技术积累不像BAT如此深厚,但既然大会让我过来,我也就好好分享一下。

  一、一次惨痛的教训

  今天主要给大家讲述一个APP的瘦身过程,还有就是饿了么API Gateway跟大家分享一下,最后还会讲一下Network做的一些优化。先给大家看下图,在座各位有没有一眼看到这个图就觉察到一些异常的地方呢?这是整个中国互联网O2O行业或者任何第三方电商的异常曲线。同时熟悉外卖行业的也知道,这也是外卖曲线,只有在中午10点半到12点,下午4点到6点再到8点,大家可以看到是高峰。那是什么造成这个流量爆增呢?把这个图放大看一下,从这个点开始一直到这里,服务器出口带宽流量爆增高风两倍。这是什么原因造成的?在服务稳定的时候为什么出现这样的情况?

  原因是一个开发人员,我们在对APP做发布配制的时候没有做CDN,直接回到源站进行下载,没有通过CDN导致服务器流量增加了2倍。在40分钟的时间里大概浪费了60万人民币流量费。为什么说这样一个案例呢?随着现在无线网还有4G网络的普及,包括流量费不断降低,很多开发人员感觉没有必要去在乎多一兆或者多两兆。但是通过这个案例你会发现可能小小一兆两兆更多是为了你自己。如果你哪一天有一个发布,没有直接回源,放在CDN上面去,同样会面临同样的痛苦,通过这个惨痛的教训告诉我们,APP瘦身利人利己,百利而无一害。

  二、App Diet

\

  那么我们要怎么做呢?先来看看下图

  今天主要讲一下安卓的东西,我们首先开启需要minify、对资源做shrinkResources、不用这些资源全部删除掉。同时尽量避免使用大图片,尽可能使用png的图片,增加资源的复用率。饿了么有很多款APP,主要的工作是什么样子?类似于OA办公,地推人员商户做一些合作、帮商户开店、帮商户管理一些餐厅、还有管理整个业务模块。用户量不高,不到1万用户,我们内部地推人员在用,但是也是我们内部的一个核心。一旦这个出现问题了,我们跟商户基本上就失联了,今年3月份我接手这个APP之前安卓安装包18兆,iOS包也将近30兆。通过一步一步架构调整,我们现在已经把这个APP包大小减少到6兆,iOS包减少到低于10兆。接下来说一下我们在API gateway做的一些工作和经验。

  三、API Gateway

  首先放两张图,大家可以看到两张图以后感觉这有什么区别呢?其实是有的。正常情况下,我们开发客户端,通过TCP、通过HTTP、通过各种各样的API,不管是restful,还是其他风格的API所有端都是为了做一些hide access的东西,一些内部业务的逻辑一些保护,只能够去开发一些Service。包括做数据库的业务,都是在Service层面,通过网络层返回给用户而已。其实API这一层承担工作,本身非常非常的少。

  因为整个下层,饿了么自主研发一套SOA的框架。目前支持Python,Java语言,下面有很多MySQL Cluster,Redis Cluster,MQ Cluster一系列的Cluster,API Service不应该去做跟业务相关的任何东西。但是,我们往往遇到一个困境,就是不能没有一个专门的Team做API,这会造成了什么情况?最大的问题就是三方的沟通。首先,客户端人员跟API Team沟通,API Team的人和写Service的沟通。所以大家开发过程中遇到一个问题,客户端只需要开发一周,客户服务端需要两三周时间,没有办法联合调整,调了以后很难定位问题。在这种困境之下,我们开发了MUX,它是主要做什么工作呢?

  从此以后我们不再有API,通过config调用Service想要访问什么,需要什么数据,客户端需要什么数据,通过简单的config就能取到想要的数据。然后客户端开发人员不再需要跟API开发沟通,也不再有API team,把整个业务层降低了一层。

\

  并且,在一个请求里面可以完成多个不同的业务。比如说一些比较复杂的业务,首页需要请求非常多的一些业务,为了做到这些业务的原子化,可能就会发生很多的请求。一些公司可能在首页做一些wrap把很多的业务数据,banner,item等等一系列的数据融合在很大很大的json或者xml里面。但是这个接口原子性,因为banner更新频度跟item不一样,缓存策略也不一样,在做trouble shooting时候就是非常非常难处理这样的问题。

  所以,大家看起来这两个图一模一样的,但实际上我们做了这么多的事情。API team我们以前有10个人,现在解散了。解散是为了把他们的能力发挥到更好的岗位上面去,人力成本就降低了,10个人一年也是几百万研发成本。同时所有东西都是configurable的,是可以自动化配制定义的,所以可能不再需要一些专门的人,只需要一个半熟练工,详细阅读user guide细理解每一个配制意义就可以了。flexiablility也是一个核心的痛点,我们减少了业务复杂度,我们Service更flexiability。Loose coupling刚也是说了,我们这一层API不做任何遍历直到解码,这代表着API不会出错。发现了一些错误时候,第一时间就是找客户端人员,一层一层定位,你肯定找不到DBA这个接口为什么不对,随着我们用config减少了API这一层trouble shooting操作,我们配对了在这一层肯定不会出错,接下来就可以找Service和SOA层面的东西,还有其他的一些DB storage的东西。

  最后一点在这里说一下,trouble shooting也是有很多自动化运营的东西,有很多业务曲线在里面。我们可以把这些曲线弄出来以后,很容易找到相应的问题,因为我们的业务业杂度降低了。

  四、Network Optimization

  今天和昨天讲了很多APM、性能可视化的东西,还有我们这个专场刚刚网易还有上午刘刚老师讲了很多的东西,我想到一点,我们要去hook网络数据,我们要切面获取网络请求、首包时间、DNS一系列的、业务详细时间等。这些数据最终要落到哪里去?最终还是落到服务器上面去,我们做storage的数据流量要远远超过我们的API business logic访问。一个比较大APP开发完以后,有100个接口左右,并且用户在每一个页面停留时间,用户每一个页面操作的频度都很高。我们的DAU跟很多大公司没有办法跟他比。但是我们的DAU都是真的,用户饿了有需求了才打开我们APP,转化率非常高,大概三分之一都转化成真正的订单。

  所以,在我们APP里面停留的时间,基本上就是打开,找到想吃的餐厅,下单,支付,整个生命周期就是3分钟5分钟,很难有一个人在APP上面选20分钟完全不知道自己吃什么。但是,我说这个问题是想说,定餐访问10个不到的接口,所有的API数据可能产生10倍,并且这些数据量远远大于API量。这些数据包含首包时间,DNS时间,还有SSH时间等等一系列的时间,还可能做一些HTTP、DNS等,还有页面一些跳转,页面耗电,这些数据都可以归到APM层面,但是我今天要说的并不是APM,听云包括在座的都比我们好,有很多欠缺的地方。

  我们退而求其次,如何在网络层做一些优化?上图是我先抛出一个结果,对接下来的演讲有个更直观明了的东西。我传文本大部分数据都是非实时的,PB之后没有什么变化,淡在我做了压缩以后,PB加GZIP的情况下20条数据可以达到88.8%的压缩比,PB加7Z可以达到91.2%,可以看到我发出去的数据就是2K多非常的小。同样把数据放到100条,很多数据也都是非实时的,如果是100条,我们看一下压缩比,PB加GZIP压缩比为91.2%,pb加7Z能达到93.6%。

  我们来看看上面一张图,我把整个请求的数据作为一个json,然后变成一个string,同时把string作为PB的一个字段扔回PB里面去,不可能压缩很多。所以,我加了一些头一些版本一些扩展,导致我的PB的文件会比我的纯文本文件还要大。如果我不用json,我直接把数据全PB化,大家猜一猜,最高压缩比达到多少呢?全部用PB的时候,在100条的时候,我最高加到了99.4%。就是说100兆的东西压完以后就是剩下600K。这个压缩比非常非常的惊人。但是为什么我没有用纯PB的方式做呢?因为PB的扩展性非常的差。我现在可能感觉用PB,把数据格式定义非常好,但是以后扩展怎么办?随着不断地扩展,有很多的字段废弃掉,我依然把这些字段放在PB里面去,可能暂时看起来这个数据的确比用纯PB要大一些。

  所以,这就是为什么大家可以看到刚刚那个图为什么PB比json大,其实PB本身比json小,一个数据可以压到45%到60%左右,同时要看数据重复性,APM和UBT的数据有很多大的重复性,包括页面一些东西都是重复的,压缩也要高一些。

  我们刚刚说的都是如何压缩body,但是大家用HTTP 1.0和1.1都是知道有很多Header组。可以看一下上面的图Header有很大的,我想压缩Header怎么办?要么使用HTTP/2。我们用HTTP/2,不仅可以做到batch-request,还可以做到Header压缩。我用HTTP/2做过试验,没有贴图我大概可以370bytes可以压到大41到45的样子,这个压缩比大概是在90%。

  所以我们会用到HTTP/2,同时去尝试更多压缩的算法。什么是压缩算法?我们考虑到了数据量庞大,APM的数据特别是crash一些数据,还有crash整个用户一些log数据可能会非常大。我们可能考虑更好的一些,因为压缩算法大家都是知道的,你是多耗用资源还是少耗用资源多耗用内存?因为手机端特别是安卓,首先碎片化非常非常的严重,在国内各种各样的rom、手机配制也是不一样的,如果我们对于CPU对于内存耗用比较多也是有很多的问题。所以,我们在选取压缩算法的时候,主要考虑更多的是性能问题,而不是纯粹压缩比。如果压到99.9%,对于手机的消耗性能高,造成页面卡顿,手机发烫,发热,耗电非常高,这个也是不可取的。

  同时,也是积极地考虑把一部分的业务用上APM,因为APM的东西有一些实时性比较高,包括HTTP的数据也是要求相对比较高一些。用过饿了么的朋友可以感觉到,一个订单一个操作会影响到首页排名,每一次操作都可以影响到一些排名,这个时候用到实时UBT的一些数据,包括实时APM的数据。这样的数据我想做batch request已经不可能了,二次调的压缩数据最高就是达到91.2%。

  在这个时候因为本身没有办法做batch-request,其实不管用不用HTTP/2都是没有意义的,这个时候就是考虑用TCP去替换HTTP。

\

本文链接:听云APMCon-浅谈App优化

友情链接: 心经结缘 大悲咒 大悲咒功德
网站地图
it技术学习网版权所有   苏ICP备18043316号