今天在微博上看到朋友们在讨论关于各类web推送技术的话题,内心一阵唏嘘,触景生情,想一想以为本身还真是与这个叫作“web推送”的技术渊源颇深,有必要就这个话题唠叨两句,来回顾本身的青春,如果这篇乱弹,能对刚接触这个东西的年轻朋友有些启示,也算哥肚皮上累积了7年的脂肪没有白长。java
Web项目里,其实有好几个场景都很是须要这个技术,好比:实时在线用户列表,聊天,文件上传的进度条,在页面上实时显示系统日志,web页面同步。哥几乎经历和使用过这个领域经常使用的全部技术,从早期本身实现轮询,长轮询,piggyback, IFRAME,到后来的flex插件, DWR。以及如今websocket和封装的相对成熟的socket.io等等,虽然说软件技术更新快速,但说实话,对这个领域的发展让人真的很不爽,这么多年过去了,直到今天还有没有那一种,让人在这个问题上真正省心。写到这里,基本上是进入一个吐槽的情绪,在正式吐槽以前,先撤点温情的话题吧,毕竟开头都说了这个文章主要是回顾本身的青春。node
开始之因此说本身与“推送”很有渊源,一是由于在过去的几年,在多个项目中,本身屡次用不一样的方式都用过相关的技术。二来,本身有两个有趣的经历与此相关。程序员
先说有趣的经历吧:web
第一段经历是,当年加入京东商城研究院面试的时候,面试官让我介绍了本身了解的web推送技术,恰好这些技术,我所有都用过,把本身从长轮询,iframe 到flex插件的各类使用经历都告诉了他,最后又展望了一下那时候尚未出来的websocket,面试官至关满意,我相信最后能拿到offer,这个问题起了很大的做用。面试
第二段是,在09年的一天,DWR的创始人,居然出如今个人办公室,没错,就是他-DWR的创始人,来到了我在成都的办公室,缘由是他是我老板朋友,因此来中国的时候,就过来玩玩,令当时还比较年轻的我,难以想象,一是本身不管如何没想到居然能接触到那个时代最有影响力的团队,二来这个传说中的大牛实际上是一个只有20多岁,有点腼腆的小伙子,真是没想到啊。有朋友要问,DWR是啥? 让哥告诉你把,08年先后全世界java社区最流行的ajax框架之一, 所谓的”反向ajax”,英文叫“Reverse Ajax”应该就是这个团队发明出的一个唬人的名词。虽然DWR看着很光鲜,其实BUG也是蛮多的,尤为是反向AJAX这一块,咱们团队就帮他打了很多的patch。ajax
OK,咸淡扯完进入正题。 网上关于实现轮询,长轮询,iframe stream、如何使用flex插件进行通讯,以及如何使用DWR, websocket如何使用,socket.io+ node.js 如何使用的文章多如牛毛,中间也不乏优秀程序员的精品文章,所以关于具体使用方面的问题,这里就再也不赘述,须要的朋友google一下,就很容易找到满意的答案。浏览器
今天这里主要使用吐槽方式,将本身过去几年里,在各类推送技术的使用中遇到的问题,和你们一块儿分享,以示对这个领域技术发展缓慢的不爽!!!!缓存
一说到吐槽web推送技术,你们确定就会说各类浏览器对 websocket的支持愈来愈好了,这个问题早就不是问题了,但真的就不是问题了吗? 服务器
那我们就从这个该死的websocket开刀,曾几什么时候,websocket是每一个程序员心目中的共产主义,想着有了websocket的一天,咱们就能够很轻松的实现进度条,聊天等等功能。今天,从IE10, firefox, safari,chrom几乎全部浏览器的最新版本已经支持了websocket,但是,美好的一天真的到来了吗? 哥不是这方面的专家,只说说哥在使用websocket中遇到的各类血泪史:websocket
哥要实现一个在线用户列表,但若是直接使用websocket,服务器端却没有一个API准确的告诉哥,客户端的在线状态,哥不得不像傻逼的同样每隔几秒钟发一个PING,去检测一个客户端的是否在线,并经过超时的方式来维护整个在线用户列表。至少从程序员的工做量上,这并无比轮询或长轮询节约任什么时候间。
从后台发送一条消息到客户端,服务器端并没有法知晓消息是否到达客户端,为了确保每一条消息到达,你就不得不在客户端作一些该死的额外工做:发送一个确认消息回去,让服务器知道,这条消息到达。若是你的功能要求每条消息必须到达,你的活儿就更多了,你还须要实现消息在服务器端的缓存,以备客户端网络很差时,须要重发,这些活儿可都很多啊。
这里只是讲了最多见的两个恶心的问题,其实在具体实践中还有更多更恶心的问题,好比客户端要定时检测网络,网络断开的时候还要本身重连; 要确保消息到达但还不容许重复发送,就须要更多的握手来确保,等等等各类恶心的问题,这实际上是有不少活儿要干的。
至少从程序员的工做量上来讲,相比其余的技术,websocket就没有带来任何的福利,此时此刻,真的很想说F开头的词语。更重要的是,至少在中国大部分系统还须要支持没有websocket的浏览器。
以上提到的这些问题websocket存在,long polling这些较早期的技术也一样存在。
Websocket根本不是将来战士,他拯救不了世界!
不少人可能以为这家伙吹毛求疵,要求过高,但哥跟你的观点不一样,别忘了如今是21世纪,各类推送技术已经发展了十几二十年,就这么简单一个东西,到今天为止,依然不能让你们省心,这真的使人费解,我相信不少程序员跟哥同样,不关心底层的实现,就须要一个像JDBC同样简单的东东,一两个小时让一个系统具有一套相对完整的推送功能,那么什么样的功能算是相对完整呢,哥认为,一个合理的推送技术,指望是这样(欢迎其余朋友补充):
1.客户端在线的时候,每条消息确保到达。
2.客户端网络掉线,服务器要有API及时准确捕捉。
3.服务器挂掉时,客户端有API及时捕捉。
4.客户端掉线后,一旦网络恢复,客户端能够自动重连。
5.断线期间的消息,在重连后能当即自动补发,确保每条消息不丢失。
6.能兼容全部浏览器,不论这个浏览器是否支持websocket。
7.像JDBC同样简单,一年经验的程序员一两个小时就能用起来。
你们可能又要说了,socket.io就能够自动重连,又支持全部浏览器。但我想告诉你的是socket.io也一样不是一个省油的灯。
若是你要使用socket.io,那么你就要会用node.js,或者其余语言实现socket.io通讯协议的后台程序。Node.js的工做量可很多,哪怕你是一个很是熟练的js程序员,想在一个月内开发一套很是稳定完善的系统都不是一件容易的事情。若是你恰好又是新手,你连NPM是什么都不知道,那恭喜你,不经历一番学习,你是不容易在短时间内作出这样的功能。
更具体的是,socket.io团队的对项目的支持效率很低,在低版本浏览器的支持上还有很多的问题,并且修复的很慢,至少哥给他们报的BUG一直没人理睬,想一想也是要哭了!
Fxxk,哥就是想在一个预算只有几万元,开发周期只有一两周的项目中加一个简单的文件上传的进度条,真的就有这么困难吗? 没错,若是您要实现一个稳定的功能,他就真没办法这么简单的搞定,这个东西就是这么Fxxk!
想一想这么多年过去了,各类技术更新换代,但就这么一个九十年代就存在的看起来不难的问题,20年过去了,依然没有可以是没能很好的解决,这难道不是一个巨大的悲剧吗!!!!
我是否是正在把你带向一个万劫不复的恶劣情绪?呵呵,请不要太入戏了,哥说的的是,目前没有一个成熟稳定的技术,能让程序员一两个小时就能将一个稳定完善的功能跑起来。哥强调的是:轻松、容易、短期,稳定完善。
这个东西真的很难吗?固然不是,哥就曾经用DWR和socket.io都分别开发出来过很稳定的推送功能,固然时间也是花了很多,不管是本身开发,仍是对社区中开源的项目进行二次开发,投入适当的人力和必定的时间,开发一个相对稳定的推送功能固然并不是什么难事。
难的是若是你想快速的在一个低成本,开发周期短的项目中实现一个这样的功能,那就真的是个很烦人的事情!!!
往往想到这些,哥就夜不能寐,巴不得瞬间化身为将来战士,拿出一个大招,开发一个小插件从根本上解决这个问题,为社区贡献一点点力量,一直有这样一个想法,但由于各方面的缘由,到如今还一直没能开始。
在个人大招出来以前,我的觉的一个稳定可靠的第三方推送服务多是现阶段比较稳妥的一个选择,因此哥本身动手搞了一个web推送服务,放在亚马逊的云服务上,供你们无偿使用,网址是https://goeasy.io 为了发扬国际共产主义精神,因此版面选择了英文版,国外也有许多蛋疼的朋友,须要帮助啊,固然咱也是撰写了完整的中文文档可供下载。但愿你们多提建议,对你们也能有所帮助。
关于web推送的话题,欢迎你们热烈讨论!
开发一个插件从根本上解决这个问题,也已经列入计划,对这个新插件个人指望是:
1.不须要学习node.js相似的后台技术
2.使用简单,半小时跑起来
指望这个小插件能在2016年早日与你们见面,欢迎你们关注个人博客,敬请期待。