码迷,mamicode.com
首页 > 移动开发 > 详细

移动互联网的架构设计浅谈一

时间:2014-06-25 07:09:45      阅读:268      评论:0      收藏:0      [点我收藏+]

标签:style   http   使用   strong   文件   数据   

一,图片体验的优化。
       在手机上显示图片,速度是一个非常重要的体验点,试想,如果您打开一个网站,发现里面的图片一直显示失败或者是x,稍微做得好一点的,可能是一个不消失的loading或者是菊花等等,但不管如何, 没能快速的拉取和展示图片对用户体验是一个极大的挑战。那么,手机上的图片体验如何做呢?这里笔者有些小总结:
    1,减少图片的大小。在失真度和图片大小中做好折衷,尽量利用工具减少图片的size,也可以考虑利用不同的图片格式。
    2,减少图片的请求数。可以考虑把多个图片利用类似css sprite的方式进行合并,这样可以加载一次即可;
    3,考虑缓存。对图片在客户端进行一定的缓存,设置好缓存时长和更新机制;
    4,考虑使用cdn进行加载图片,做到就近接入访问;
    5,解决DSN劫持的问题。在手机业务上的经验告诉我们,很可能某些地区,某些运营商把我们的域名封掉或者劫持了,这样,图片的域名解释出来的IP却不是我们提供图片服务的IP,并且这种情况很难发现,  因为,如果运营商通过抽样随机劫持,就很难发现。解决办法可以:

 .去掉dns,改成直接访问IP的方式,但需要解决根据用户的ip获取最近图片服务的ip地址,实现上:这里cgi在吐出访问图片的地址的时候,获取用户的来源网关IP,调用IP地址库判断来源IP所属地和运营商,然后下发对应的图片部署接入IP, 客户端使用IP直连图片服务器,快速的访问资源。

  问题是,有实现成本,得业务自己去实现类似一个dns解释的逻辑,特别是图片放到cdn的话,这样改造就无法使用cdn带来的加速服务能力。

  

 .做好dns劫持的监控,实际上图片dns解释到的vip list肯定是在我们的一个白名单内,如果不是,则肯定属于dns劫持,客户端可以在某个时候拉取一下我们的vip list,作为监控和判断是否dns劫持的问题,如果dns的ip地址 不在白名单内,则替换使用白名单内的ip进行访问。
  

 .考虑备用域名的方式,即如果一个域名拉取不到,改用备用域名进行访问,当然如果备用域名也被劫持,那就不行了。


   6,不用图片,考虑文本替代方案。
   
二,优化后台的架构
     后台返回越快,前端的体验就越好,因此,也需要对后台服务的调用链进行梳理,避免循环调用,快慢混杂等问题,基本的原则比较简单,都是一些设计方面的原则
   1,轻重分离。服务中把访问量大,需要速度快的服务和访问量小,但业务逻辑复杂的流程从代码实现和物理部署上进行彻底分离,如用的接入cgi(甚至不同的域名),不同的后台server,不同的集群进行隔离。
      如果放在一起,慢的会拖住快的,这就像木桶原理一样,最终的速度是由最慢的决定的,如果处理不好,可能导致整个服务堵塞不可用。
 
   2,评估好业务的访问流程和路径设计,区分关键路径和非关键路径,设计上尽量考虑把关键路径转换为非关键路径,关键路径需要有多级容灾的考虑,非关键异常需要有监控。
   
   3,考虑异步化。异步化相比同步的实现来说稍微复杂一些,或者说需要做的工作可能多些,但异步化的好处也会非常明显,特别是需要高性能的业务流程。常见的异步化实现策略是借助mq作为各个系统的缓冲, 生产者进程或者子系统把消息写入mq即可立即返回,而消费者进程或者子系统则定时从mq读取消息继续处理,并且把处理的结果通过回调通知或者写入返回mq给到生产者查询。当然,如果生产者是不关注结果的,那 就更加简单了,丢到mq后即可,这里的问题是整个mq是整个业务流程的关键,需要确保服务的高度可用和性能。
 
   4,一些配置的动态加载,本地化存储,加上基于版本的更新机制。笔者也发现过有些业务cgi之所以在较少请求量的时候就出现了较高的负载,最终不得不用更多的机器来承担相应的请求量,定位最终原因是cgi在启动的时候需要加载 很多配置的东西,甚至很多配置并不是该cgi需要的,优化思路是:是按需加载,只加载该cgi需要的;提前加载配置到共享内存,同时增加版本号,维护好cgi自身进程的私有版本和共享内存的版本,cgi启动的时候比较版本号,发现不同,则 真正进行文件的重新Load到内存。还有一种模式是采用配置中心进行推送的模式,实现集中管理。
 
   5,做好外部依赖的管理。一个业务流程可能往往要调用到外部的系统,并且这些系统可能不是你们团队维护的,如果该系统是非关键路径还好,如果是关键路径,那么做好对外部依赖的管理就显得更加重要了,那么如何做好外部依赖的管理呢?
      这里有几个小的tips:

 . 对外部调用的服务单独进行封装,如设计单独的proxy去调用外部的服务,这样的好处是方便集中监控和容灾逻辑等处理,在设计上把外部因素进行物理隔离的第一步,后续如果外部系统的协议或者ip地址得发生变化,则可以只修改该模块即可 快速修复;


 . 严重建议对外部接口进行错误和超时的监控,一旦出问题,提前预警并快速解决,这里是有血的教训的,某业务和某平台提供者双方在纠结是谁的问题上吵得不可开交,不知道是谁的问题,业务说自己没问题,平台方说自己的服务也很快,如果 你能够拿出你的监控数据,接口超时设置是 1s, 超时的记录有n条,时间是ns,错误的记录有m条,主要错误类型是xxx,那对快速定位是非常有帮助的。


 . 考虑是否可以弱化为非关键路径?有些调用可能是否无法弱化为非关键路径的,如登录态校验,失败了只能是业务流程终止,给用户返回失败(当然可能存在部分业务缓存session id作为异常的时候的备用,但这个不是很建议,原因很简单,可能导致入口 不唯一,甚至造成安全漏洞,这里需要具体案例具体分析)。有些路径是可以设计为非关键路径的,如数据上报,


 . 关键路径的多级灰度模式。如果知道某个服务是关键路径,比如在支付前的请求billno_server获取唯一的订单号,从业务流程看,这个肯定是一个关键路径,没有订单号就无法下单,业务流程执行不下去,但如果每次下单都调用一次billno_server生成 一个订单号,偶尔的网络超时或者失败都是可能的,而对用户来说,就是此次下单提示大家都非常熟悉得不能熟悉的一句话:“系统繁忙,请稍后再试”,那么是否能够做得更好呢?或者至少减少这种概率呢? 一种思路是每次请求一批billno缓存到本地进程空间, 然后使用的时候先从本地缓存中取,没有了再去请求;一种是请求失败的时候,是否可以考虑用本地随机生成一个,在极端情况下弱化对该关键路径的依赖?


 . 若关键路径的数据唯一来源是本业务,则可以考虑自建部分热点数据,一点出现问题,则切换到自建的部分热点数据,继续提供服务。

   6,考虑到手机客户端的计算能力比较弱,在设计上是否把计算成本更多的往服务端移动,利用强大的服务器端计算能力提升用户体验,这一点也是微信架构设计给笔者的一个感受。
   
 三,优化链接
     如何管理链接是一个老生常谈的话题了,这里主要长连接和短连接的问题。当然还有一些什么连接池等策略。  
     弱网络环境下,建立链接的时间非常长,网络质量测试数据显示,建立链接占用耗时接近1/3,走短链接又导致链接频繁,所以考虑将短链接改成长链接,在碎片时间内重复利用,减少建链耗时,此外,还有以下几个优点: 

     1,C/S的持续链接使得后端能够主动push关键数据到客户端,例如实时的通知,新数字提醒等等,能很好的改善体验,在短链接的情况下,只能依靠客户端进行定时轮询,不可避免的使新数据有所延迟。

 

     2,进一步节省短链接过程中的包大小,短链接情况下,每次来回请求,都不可避免需要带上一些公共数据。长链接只用在建链接成功后的第一个包中上行这些数据,后续包则可以省掉这些字段,进一步减少流量; 


     3,长链接还能有效的减少流量限制类手机软件导致服务不可用的问题,有些流量限制类软件会接管用户的所有网络请求,以达到流量计算和断流的目的,这种本质上就是一种劫持,使用长链接+私有加密协议, 可以使得对方无法准确分析包情况,减少劫持到来的服务不可用情况。


     4,长链接还可以减少在高并发下对临时端口的依赖,有些使用短链接的服务,在高并发下,发现临时端口不可用的问题也可以通过长链接得到缓急。 
 
     注意:使用长链接的时候,必然有长链接过期不可用的情况,因此,业务实现需要埋入重连机制。
 
 四,基于网络质量的多级服务设计
     手机的网络环境比较多样,如wifi, 3G, 4G 还有2G等,不同的网络环境的体验是不同的,对非常好的网络环境我们就不说了,关键讨论一下在2G等比较恶劣的情况下的一些思考。

1,不同的网络环境是否具备多级的服务能力?如针对2g网络的用户,显示的内容更少? 图片变成文字?一些功能入口不可用?


2,减少网络协议包的大小。在网速很慢的情况下,包的大小至关重要,直接影响成功率,可以考虑更加紧凑的协议(包括不必要的字段不发送)+压缩算法。这里有个tips,大家知道cookie的内容都是每次跟在http请求一起发送给到服务器的, 对图片,js,ccs等建议部署其他域名进行cookie隔离,这样也可以减少一定的包大小。

 
 

移动互联网的架构设计浅谈一,布布扣,bubuko.com

移动互联网的架构设计浅谈一

标签:style   http   使用   strong   文件   数据   

原文地址:http://blog.csdn.net/tenfyguo/article/details/34107629

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!