“网易云阅读”-移动架构

       过年回家,手机中有两个应用是爱不释手的,一个是微信,一个就是网易云阅读了。这里不谈论微信了,说说网易云阅读。刚刚接触网易云阅读,是偶然的,具体咋知道的已经忘了。这个APP且不谈交互体验好不好(在交互细节上面只能说还凑活,能够满足需求,但是没有超出期望),但确实解决了我的问题,零碎时间的阅读问题。之前网页端阅读36氪文档以及其他网站的文章,下了个虎嗅的客户端看文章,觉得有点分散,后来这个app有了之后,直接订阅了,减少了看文章来回切换的麻烦了,至此之后,爱不释手呵呵。 

        正好最近Infoq上面有篇关于移动架构的文章,大体看了一下PPT,觉得写得挺实在,例子就是网易云阅读,所以正好算是简介翻译一下这篇文章,结合我这个菜鸟的理解,也算是学习一下优秀的架构。

         网易云阅读的下载地址:http://yuedu.163.com/ 

         移动应用架构策略(infoq地址):http://www.infoq.com/cn/presentations/mobile-application-architecture-strategy (作者和我是一个工种呵呵,IT中的服务端开发)

         1、平台类的应用

        第一次使用这个app,就发现他是平台级的应用产品,自己不生产内容,聚合第三方的信息,为用户提供阅读服务,作为用户不需要到处查看文章内容,内容提供者不需要考虑推广等事情,可以专注于自己的内容。

        2、移动产品存在的问题

        A、目前的网络十分复杂,导致的就是网络速度不均匀,有地地方会出现网络死角、在移动过程中网速不稳定;(根据友盟的数据来看,目前2G和wifi的联网方式各占40%左右,3G的占20%左右)。

        B、不同设备的屏幕尺寸不统一,导致需要根据尺寸来进行内容适配,要达到两盒的视觉呈现还是有点费劲的;(IOS系列的产品有十余种,其中iPhone和iPad占比比较大;android系列的产品更是很多,友盟的数据有四十余种  http://umindex.com/#android_device   )。

        C、移动设备自身硬件能力具有局限性

        移动设备运行着APP,此时就相当于一个独立的服务器啊。首先电池容量小,这要求编写的app要能够省电;内存小,经常会出现应为内存不足而造成app闪退的现象(话说我之前搞的那个玩具在测试的时候也经常闪退呢);CPU处理能力有限,要进行复杂的逻辑处理,做好在云端服务器中处理掉;存储空间有限,这个受限于内存卡,大家都懂的。

        3、服务器端架构

        这个的话没有啥特别之处,典型的web应用的架构形式(为app提供http请求的服务,如果是静态图片或者静态文件,会有相应的CDN服务器,来加速这类的请求)。最前端有负载均衡处理器(例如运行的LVS程序的机器);然后是webserver(例如apache或者nginx,目前淘宝系主推tengine,一个改善的nginx的版本,有一个团队在维护);之后是appServer(作为java开发,我就暂且理解为java的web程序,appServer是分布式的,可以动态水平扩展,就是加减机器对于前台请求以及后台数据没有影响);然后再后面是数据库、缓存处理器、分布式文件系统等持久化设施。

        对于云阅读产品来说,貌似之前听说有几种获取信息的策略,虽然是坊间传闻,但是我觉得也差不多。

        A、开放平台对接,内容提供者通过调用API接口,把最新的文章信息同步给appServer对应的持久化设施,这种最方便,但是需要监控接口的稳定程度;

        B、内容提供者把内容维护在网易云阅读提供的后台,在后台直接录入文章等信息;

        C、网易云阅读搞一个服务端程序,去抓取内容提供者发布的信息,然后过滤、清洗,存储起来对外提供服务;

        下图是抓取服务的架构图:

        “网易云阅读”-移动架构

        Manager负责load第三方提供的URL信息,然后Crawler负责抓取信息,之后Analyzer负责分析页面的DOM结构,之后存储在DB中,对外提供服务。

        4、客户端架构

        从下面这张图来看,客户端设计是分层的,非常清晰。

        A、客户端本地数据库,负责存储用户个人信息、系统配置信息,以及缓存数据,这里存储的数据,是需要在服务器端也存储起来的,就是数据要同步,负责我更换了一个手机,之前设置的信息没有同步过来,是一个比较痛苦的事情;

        B、View层,总体负责View的展现、UI的优化。动画效果、以及页面回调等,类似web中的View层,就是负责展示的;

        C、网络层,我个人理解,负责网络请求的封装(组装参数、发起请求、解析返回结果);

        D、逻辑控制、服务组合和数据持久化我认为是一层,就是核心逻辑处理,运行在客户端,数据获取和存储依赖于网络层向服务器端发起请求;

        这样,客户端的架构就比较清晰,维护起来也就没那么蛋疼了。

        “网易云阅读”-移动架构

        5、优化策略

        A、图片服务器智能化,尽量返回客户端合适的图片,例如pad类的产品,就直接返回他尺寸大一点的图片,手机类的就返回尺寸小一点的图片,图片的剪裁和浓缩在服务器端完成,需要在客户端再来做这些事情;

        B、确定是否进行预加载和加载的优先级,图片或者文章,都有“下一页”和“上一页”的翻页操作,可以根据用户的使用习惯,来进行预先加载,例如用户在看文章的时候,习惯进行“下一页”操作,那我们就在用户“阅读当前页面”的时候,把下一页的文章加载进行,这样用户在进行下一页阅读的时候,体验会很好(可以在客户端维持几个变量,把用户的行为转变为可衡量的数字,这样就可以依赖这些变量来判断是否需要预先加载);

        C、缓存要进行管理,缓存是否需要失效,需要有判断的原则,一种是请求服务器端,如果数据过期,则直接进行失效即可,另外一种就是客户端根据容量情况来进行失效(这一点类似于服务器端缓存失效策略呵呵);

        D、数据压缩,要省流量,需要压缩(使用UC浏览器能省流量,原因也是由于压缩),网易云阅读使用的是GZIP的压缩方式,服务器端在发送数据的时候,把数据通过Gzip来压缩,然后客户端接受之后,再按照协议来解压缩,这样流量就省下了;

        E、使用http长连接(因为构建http链接是很耗时的操作,所以可以保值长连接,减少反复握手的网络和资源开销),断点续传(对于较大文件,能够减少网络流量),重连策略(如果网络异常,则可以根据适当的算法来进行重连,但是方法最好是幂等的);

        F、消息推送,IOS有自带的通知机制(IOS Push),android的话google有产品,但是在国内不好用,你懂的,需要自己为移动终端自建Push服务。有一个原则是网易云阅读分享出来的,一个是移动终端登录后和Push服务器保持连接,Push服务器主动心跳来保持这个连接(移动终端可以动态调整Push服务器的心跳间隔);

        6、系统复用

        A、 尽量使用现有的解决方案,因为成本低、风险小;

        B、UI组件复用、源代码复用、开源组件复用,框架设计巧妙,直接插件开发即可;

        最理想的情况是,集成现用的系统来创建新的应用。

        PPT中基本上介绍了“网易云阅读”这款产品的情况,十分详尽,后面作者有提到关于产品设计以及需求处理方面,这里就不多讲了。​