Hermes Container Hack Day参赛回顾

一路探索,只为跨界

谈起我们组建Hermes来参加Container Hack Day还是比较巧的,当时我们三个正在开发一款图片社交APP的后端,当时根据需求需要使用地理位置信息,但是发现国内比较知名的地图数据服务提供商,国内POI数据做的确实不错,但是国外基本都是一片白,当然国外的POI数据对于当前需求和市场不是很重要,但是这确实是我们发现的一个问题。比如说国内用户如果即将出国旅行,想要查看国外的街景数据,基本上国内的地图服务对国外位置是没有数据服务的,并且由于一些众所周知的原因,我们无法顺畅使用Google Map的Places API,我们不能保证每个开发者和用户都有能力去访问Google service,所以我们当初来参赛的目标就是利用首都在线的GPN来为国内用户提供无障碍的全球POI数据服务,当然这个要基于Google Service。

当时的想法比较简单,也很好实现,主服务放在美国的数据中心,获取Google Map Places服务,国内用户通过国内数据中心节点代理访问,这样我们做的东西基本就是一个代理,只是转接了一下用户对Google Map Service的请求而已,这当然不能拿去参赛。这样我们就寻求能否做一套SDK出来,提供给移动端,这样用户只需要关注上层的使用就可以,但是在开发过程中我们发现,Google Service的一套东西是完全闭源的,其SDK想要Hack非常困难,我们的目标是在其基础上进行修改,自己写一套一方面时间来不及,另一方面这不是三个人能够做的来的。如果这个方向继续做下去,Android只能进行root,IOS9以前需要越狱,以此来进行移动端的请求代理转发,这样做下去就会偏重于移动端,而比赛的重点我们觉得还是在于后端服务的创意和基于GPN跨界的想法,这样我们就不得不转型了。

做有价值的项目,解放用户时间

那么现在Hermes又回到起点了,我们期间花了很久来思考接下来该向什么方向努力,但是我们的中心点始终是围绕着跨界,和要做有价值有意义的项目而存在的。如果我们做的东西对用户没有吸引力,不能带来什么价值,这就是一个没用的东西。所以我们就把目光移动到了SOHO移动办公一族上来。

比如有一次,我开始用高德的志玲姐姐导航,躲避拥堵模式,然后手机没电了,然后由于不是走的大路,然后就迷路了,然后转悠了半天,哪哪都堵车,然后路上就花了三个小时……当时宝宝心里很苦,什么滴滴出行也好,真正从根本上解决出行问题,就是不出行,所以如果实现soho,能省掉多少路上浪费的时间啊!那么跨地域协作,soho办公一定会成为新的工作方式。

在这一想法的基础上,我们希望在首都在线的平台上搭建一套基于web的异地在线协同工作,线上视频教育系统,通过首都在线提供的GPN网络,让用户无论相隔多远,都能以一种稳定的速度享受彼此的连接,用户在我们实现的Hermes平台上,可以文字聊天,视频聊天,语音通话,共同显示分享一块可涂写的白板,协同工作,聆听远程讲师的讲解,无论用户在美国,还是欧洲,都可以通过首都在线提供的GPN网络享受稳定的视频语音聊天,不会出现视频显示音频连接不稳定的情况。

首都在线GPN网络图

那么想法已经有了,接下来就是如何实现了,谈技术,先看图:

上图是我们整体服务的一个架构,主服务都是搭建在国内节点上的,如果涉及到海外用户与国内用户的交互,就会通过搭建在国外节点上的代理,走GPN专线来完成通信传输。本项目的实现,借鉴和使用了很多现有的开源软件,在其基础上,我们团队使用docker,做了适应于GPN网络环境的竞赛作品,在多媒体视频流服务上,我们选用了Red5做为Flash流媒体服务器,为了实现用户相互之间的文字聊天,我们选用了redis的PubSub做为支持,为了实现用户的音频通话,我们团队选择FreeSWITCH做为基础支持,在这三大软件的基础上,并且借鉴BigBlueButton实现方式,展开了我们的在线协同工作平台。

Tech Stack

讲技术栈,还是先上图:

上面的结构图已经基本完整的展现了本平台提供的所有服务和组件,下面进行详细的描述:

 Client:

客户端就是运行在用户浏览器中的Flash应用,客户端使用RTMP协议连接了Red5服务器,但是在实际的工程中,我们在Red5前面放了一层Nginx做负载均衡,客户端实际连接的是nginx。

 Nginx:

Nginx在前端做了代理请求的分发,他是后面服务器中运行的tomcat的前端,同时在实现实时语音通讯上,nginx代理完成WebRTC与FreeSwitch的连接。

 Presentation Conversion:

为了让平台兼具协同工作的重任,协同文档展示是必不可少的,也就是说要让用户拥有文档上传的能力,但是最后都要统一显示成Flash的形式,所以存在转换工具,主要是使用了SWFTools.

 Redis PubSub:

Redis PubSub负责提供了用户之间的文字通信,即时通讯功能。同时我们也用它兼具了后台服务的消息中间件的功能。

 Redis DB:

本平台提供了会议记录的功能,当会议结束时,后台会将会议中所有的记录事件存放入redis DB中。

 FreeSWITCH:

FreeSwitch为整个平台提供了语音通话的能力,用户浏览器会通过WebRTC协议连接后台的FreeSwitch服务。

上面提到的所有组件在设计上都已经耦合度足够松散,所以我们将其都放入了Docker中,也就是说,如果用户不需要音频聊天了,那么OK,我们将含有Voice和FreeSwitch服务的Docker容器stop就可以了。

为了展现我们的服务,我们用J2EE在tomcat 上开发了一个demo聊天室,在使用上非常简单,进入聊天室不需要授权,在里面可以看到在线用户,这一系统仅仅作为一个demo展示,仅仅包含了我们计划的基本功能,比如视频,语音,文字聊天,白板文档共享。如下图展示的这样:

打破距离,节省时间,创造价值

到这里技术相关基本如上展示那样,为了在短时间内开发出一个功能完备,同时又能适应于GPN特殊的网络环境,我们在整体的实现上使用和借鉴了很多开源的实现,但是又结合了比赛的主旨和我们的想法。我们的目标就是沟通与跨界,远隔重洋的用户,通过这一平台可以无障碍的交流,速度稳定,视频,文字,通话,白板,文档,协同工作所需全部满足,世界的知识,不会因为地域的限制而无法获得,每个人都可以拥有平等顺畅的学习和沟通的能力。

相信有一天,我们可以在任何地点和任何人协同工作,无障碍沟通和学习,因为人生的意义本应该放在有意义的事情上,而不应花费在路上,而Hermes存在的意义就在于此。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章