创世神域

Nothing is impossible.

@Puteulanus4年前

11/12
13:53
学习心得

TPRSS——看图没有国界

TPRSS,即Twitter Picture RSS,是一个能将指定用户的推文转化为RSS,并反代其中的图片的网站。

项目起源于一次聊天,我给群里的朋友发了一些Tumblr的RSS地址,顺便推荐了几个推特的发图机器人。和Tumblr可以直接用RSS阅读器看图相比,Twitter的就略不方便了。上网搜了一下,找到了twitrss.me,可以简单的把推文转化为RSS,使用Perl写成并开源。twitrss.me的一个问题是它不会输出图片,订阅之后也得点链接才能看到图,因为对Perl完全不熟,于是用PHP写了一个介于twitrss.me和用户之间的“中间层”,负责从twitrss.me获取信息,并将所有链接转化为真实图片地址,加上标签直接输出。这是TPRSS的雏形。

最先遇到的问题是有时订阅会失败,排查后发现原因是RSS阅读器的获取是有时间限制的。按最初的设计,阅读器在访问一个全图订阅时会依次抓取每条推文中网址的页面,然后通过正则表达式匹配得到真实图片的地址。也就是说,阅读器每次刷新,需要等待服务器依次下载10个网页并对其内容进行匹配。这样做非常耗时,导致阅读器在获取订阅内容时超时。为了解决这个问题,我增加了数据库部分,在受到访问时,会把用户推文中的地址与真实图片地址存入数据库中,再次访问时从数据库中调取记录,存在记录的直接读取,不存在的记录才会抓取网页获取。比起最初的设计,这样大幅度降低了重复访问时的响应时间。只有在新订阅用户或长时间没有对某用户的数据库进行更新时,才会出现耗时过长的问题。

然后遇到的是很无奈的问题——即使把推文中图片的真实地址加标签输出了,还是有看不到图的情况,因为推特全站连带图片资源站都是在墙外的。对于这个问题,最初直接给生成订阅的页面加了功能,将真实图片地址作为参数进行访问时,会从推特下载图片并返回给用户。这样,由绑定域名后的Openshift空间作为一层代理,输出RSS时输出带有真实图片地址参数的Openshift空间地址,大部分使用的人都能看到图片了。但实际上,Openshift在国内的访问效果并不理想,即使绑定域名之后,也会有访问速度慢或者无法访问的地方。为了进一步增强服务的稳定性,写了一个单独的图片反代作为TPRSS的子项目。反代托管在Coding上,使用演示页的方式部署。因为选用的是Coding的北京服务器,国内访问基本不会有问题。但因为Coding本身也是墙内服务器,和用户一样无法直接获取到推特的图片资源,所以在设计上使用了Openshift的空间作为跳转,即用户在访问一张图片时,先请求Coding上的图片反代,反代将参数传递给Openshift上的本体,由本体从推特获取图片资源后,传递给Coding的反代,再由反代返回给用户。这样的两层结构保证了用户看图的稳定性。同时,主站上的程序在输出RSS之前会检查反代的可用性,如果不可用即全部转为输出Openshift空间地址,这样即使在反代鼓掌时,用户的订阅也不会受到影响。不过双层结构也存在坏处,逐层请求带来的是巨大的延迟,即使在网络畅通的情况下,用户访问一张图片也需要等待1到2秒才能看见图片。对此的解决办法是,在Coding上利用演示页自带的1G存储空间建立了图片缓存。用户第一次访问的图片在从本体传回Coding时会被储存在本地,当再次有访问时,反代会从本地直接获取图片返回,实测中几乎没有延时。因为PHP貌似不好对文件夹大小进行统计,而演示空间存在每次部署文件重置的特性,在设计中放弃了使用数据库索引,转而使用文件名来标明大小。储存到本地的缓存图片会在文件末尾加上文件大小,在统计大小时,直接遍历目录用正则获取所有文件尾部的数字加在一起即为文件夹大小。缓存机制使用两个文件夹储存图片,在检测到pic-1超过250M时,会删除pic-2、将pic-1重命名为pic-2并新建空的pic-1,在读取缓存时,先尝试获取pic-1中的图片,如果失败再尝试获取pic-2中的图片,如果还是失败,则会经由Openshift从推特获取图片,缓存并返回。这样保证了不会因为清空缓存而造成大面积啊卡顿,所有缓存图片都有一定的生存周期。

之后计划尝试的优化方向是,利用ppython将抓取页面匹配图片真实地址的工作交给Python多线程完成,使即使在第一次访问时也能尽量减少延迟时间。

可惜,这时候出现了变故。由于twitrss.me使用了缓存,从那里获取到的信息不具有及时性,而在Openshift上新建Perl应用部署他的源代码又受阻,我只好寻找新的RSS生成程序作为它的替代品。在这个过程中,我找到了功能和TPRSS部分重合的Twitter to RSS proxy。

在阅读了他的代码并查阅资料之后,我发现原来使用OAuth协议可以直接从推特获取某人的时间线,而且官方API传回的信息中竟然是包括了图片真实地址的。这意味着之前设计的数据库功能完全丧失,因为无论从哪方面来讲,使用官方API获取信息都具有绝对的优势。于是我新建了TPRSS2项目,借鉴之前自己写的代码和Twitter to RSS proxy中使用的thmOAuth,从头开始写。现在TPRSS网站使用的即依靠OAuth协议获取时间线的TPRSS2。吸取上个版本的经验,TPRSS2在编写过程中更多的考虑了变量命名、代码可读性等问题,在细节方面尽量做到人性化,比如使用字符串截取函数保证了在遇到较长的中英混合退推文时RSS标题的易读性、清除了图片推末尾的本页链接等。

现在和TPRSS经过重新编写,用户体验高于上个版本。不仅适合使用RSS阅读器看图,也适合不方便挂代理、希望持续关注某人推特的情况。

项目一路走来,我也学到了很多。感谢对项目提建议的朋友,你们对我的帮助是巨大的。

最后用百度的招聘信息结尾吧。

一张网页,要经历怎样的过程,才能抵达用户面前?一位新人,要经历怎样的成长,才能站在技术之巅?

求学不易,且行且珍惜。

TPRSS——看图没有国界

          1. Puteulanus 文章作者
            UnknownUnknownUnknownUnknown

            有三个,两个常用。主账号都是些用完删的临时项目,用来试验写的东西,比如之前维持红帽应用运行的脚本就是在主账号上一个对照组一个实验组。一个小号放长期运行的项目,比如给学妹搭的签到站,现在的TPRSS。还有个马甲前段时间刚创的,丢了两个采集站结果被删了_(:з」∠)_,现在空着没用。。。不过其实真正一直运行着的也就只有小号的两个应用,一个账号其实也行。就是试验一些需要对照的东西可能略不方便。。。