订阅云计算RSS CSDN首页> 云计算

团队协作工具Worktile技术架构揭秘

发表于2015-07-01 14:24| 次阅读| 来源CSDN| 0 条评论| 作者李会军

摘要:目前,已经有超过10万家团队在使用Worktile,作为一款团队协作工具,从技术上需要解决哪些问题,如何解决,Worktile创始人兼CTO李会军给你深度揭秘。

【编者按】本文节选自程序员电子刊7A封面专题“中国SaaS生态‘元素周期表’”,Worktile作为一款杰出的团队协作工具,自上线两年多以来,以良好的用户体验和稳定的服务,获得了用户的认可和喜爱,本文来自Worktile创始人兼CTO李会军关于Worktile整个技术架构的揭秘分享。

以下为全文:

Worktile自上线两年多以来,以良好的用户体验和稳定的服务,获得了用户的认可和喜爱。截止笔者写这篇文章的时候,已经有超过10万家团队在使用Worktile。作为团队协作工具,从技术上分析首先要解决如下几个问题:

  • 1.  基于Web的跨平台设计,让用户在任何地方都可以随时通过浏览器访问
  • 2.  Web形态的产品要具有原生客户端的体验,如任务的拖拽等
  • 3.  具有高效的实时消息系统,每个团队成员在Worktile中所做的任何操作,都要实时在其他成员的客户端中自动刷新
  • 4.  服务要稳定,稳定压倒一切

那么Worktile是如何做到这几点的?今天笔者在这篇文章里一一为大家揭秘。

SPA设计

先来说说Worktile中SPA(单页应用程序)设计,作为团队协作工具,需要尽可能减少用户在不同页面之间的跳转,所以从一开始我们就决定Worktile必须是单页应用程序,当时面临的选择有很多,首先我们考虑使用大名鼎鼎的Backbone.js,但是很快又抛弃了,因为在实际使用中Backbone.js太复杂,另一方面开发效率太低,最终我们选择了Google出品的AngularJs,下面这幅图是AngularJS的结构图:


选择它主要基于以下几点考虑:

1. 自动化双向数据绑定功能,这一点在Worktile中非常重要,如任务的状态变化都要实时变更到其他成员,如果具有自动化双向数据绑定功能,只需要绑定到UI的数据源发生变化,UI会自动发生改变,不需要工程师再通过代码去修改UI元素的改变,如下面这段代码:

<div class="entry-task-main" 
     ng-class="{1:'task-completed-style'}[task.completed]">
    <a class="entry-task-check" 
     id="task_check_{{ task.tid }}"
       wt-click="js_complete_task($event, entry, task)">
        <i ng-class="{0: 'icon-check-empty', 1: 'icon-check-sign'}[task.completed]"></i>
    </a>
    <a class="entry-task-title" href="javascript:;">{{task.name}}</a>
</div>

2. 语义化标签,AngularJS在设计之初信奉的理念就是:当编写UI的同时又需要编写业务逻辑时,声明式的代码远比命令式代码要好,命令式的代码更适合写业务逻辑,AngularJS在设计上就通过语义化的标签把对DOM元素的操作和逻辑代码分离,如我们需要展现一个任务列表,只需要下面这段代码即可:

<div ng-repeat="task in tasks">
     <wt-task view-type="item" show-project="false" 
            class="slide-trigger"
              hide_action="true"
              ng-click="locator.openTask(task.pid, task.tid)">
     </wt-task>
</div>

3. 模块化设计,AngularJS堪称模块化设计方面的典范,通过模块化设计我们可以非常好的实现Worktile的工程化,在Worktile中涉及的元素非常多,如有项目、任务、日程、文件、话题、文档等等,而这每一个元素都可以设计为一个模块,如下所示:

(function () {
    'use strict';
    angular.module('wtApp', [
        'wt.project.ctrl',
        'wt.team.ctrl',
        'wt.task.ctrl',
        'wt.event.ctrl',
        'wt.post.ctrl',
        'wt.file.ctrl',
        'wt.page.ctrl',
        'wt.mail.ctrl'
    ]);
}());

4. 引入依赖注入,依赖注入是面向对象中比较成熟的设计模式之一,为了解决面向对象中依赖问题,得到了广泛的应用,AngularJS中大胆使用了依赖注入,极大的减少了各个模块之间的依赖问题:

taskListCtrl.$inject = ['$scope', '$stateParams', 
            '$rootScope', '$popbox', 
            '$location', '$timeout', 
            'bus', 'globalDataContext', 
            'locator'];

结合以上特点,我们最终决定了前端框架使用AngularJS来实现,从Worktile上线两年多的表现来看,我们的选择无疑是正确的。当然AngularJS也有一些缺点,在实际使用中还是要根据具体的产品类型来选择使用,另外AngularJS 2.0也已经初见端倪,和AngularJS 1.0有很大的不同,感兴趣的同学可以先去尝鲜一下。

服务设计

我们再来看看Worktile的后台服务设计,Worktile的整体服务架构设计如下图所示:


其中前端部分在上面的SPA一节中我们已经说过了,下面一一分析下其他的服务:

1.  API服务,包括Web API、Mobile API、Open API,这些都运行于NodeJS之上,选用NodeJS的原因主要是它的异步事件驱动,对于高并发的支持比较好,另外一个原因是使用简单,对于前后端可以使用同一门语言去开发。

2.  缓存和队列服务,Worktile中的缓存和队列服务都是基于Redis来实现,Redis是一款非常优秀的开源缓存服务,并且可以选择基于内存还是进行数据持久化,它提供的pub/sub模型对于Worktile来说非常重要,对于一些实时性要求不高的处理,我们都是在Redis中pub一条消息,告知其他服务有数据发生了变化,那些服务在接收到Redis中的消息后,根据消息的类型决定应该如何做出处理。

3.  数据库服务,Worktile产品本身的特点决定了它是一个对实时性和性能的要求,远超过对事务性要求的产品,所以在选择数据库时,我们选用了MongoDB数据库,性能高,集群方便,数据以BSON结构存储,和Node.js天生完美结合。

4.  文件预览服务,使用Worktile的同学肯定知道在Worktile中所有的文件都可以做到无需下载到本地,而直接在线查看,这一切都是预览服务的功劳,因为文件类型的各种各样,在实现文件预览时也要根据文件的类型做出不同的处理,针对txt、pdf、代码片段等文本型的文件,我们只需要读取文件中的内容,然后再前端用相应的视图展现出来即可,相对比较简单。但是对于Office类型的文件,如ppt、doc、xls等文件,就不能这么简单的处理,我们希望文件在Worktile中查看的效果和用户在本地使用Word、Excel、PowerPoint查看的效果差不多,经过我们的调研,最终选用了微软官方提供的Office Web App服务。

消息推送

消息推送服务是Worktile最核心的服务之一,前面提到过作为一款团队协作工具,要能够实现非常好的实时性,任何数据的变化都需要及时变更到团队所有成员当前所在的视图,如下面这幅图,是一个典型的任务看板,团队所有成员可能同时在操作当前项目中的任务,每个操作引起看板的变化都会实时更新,不需要用户做任何刷新操作:


为了达到这种效果,需要在Web客户端和服务器之间维持一个长连接,当有任何改变发生时,给客户端发送不同的消息,告知客户端哪些数据发生了变化,如下面是我们为任务定义的消息中的其中几个:

实现实时消息推送,有以下几种方式可供选择:

on_task_trash            : "on_task_trash",
on_task_complete         : "on_task_complete",
on_task_move             : "on_task_move",
on_task_update           : "on_task_update",
on_task_comment          : "on_task_comment",
on_task_badges_file      : "on_task_badges_file",
on_task_unarchived       : "on_task_unarchived",
on_task_badges_check     : "on_task_badges_check"

1.  短轮询,页面端通过js定时异步刷新,这种方式优点在于实现简单,但实时效果较差。

2.  长轮询。页面端通过js异步请求服务端,服务端在接收到请求后,如果该次请求没有数据,则挂起这次请求,直到有数据到达或时间片(服务端设定)到,则返回本次请求,客户端接着下一次请求,这种方式对于服务的要求较高,尤其在并发量很大的情况下,对服务端的压力很大。

3.  Websocket。浏览器通过websocket协议连接服务端,实现了浏览器和服务器端的全双工通信。需要服务端和浏览器都支持websocket协议。

在Worktile一开始我们选用了Socket.IO作为消息服务,但是随着访问量的增大,需要做集群化的时候感觉到力不从心,尤其对于Socket.IO状态数据的存储,由于并没有官方的解决方案,当时我们采用了一个第三方的开源项目,使用Redis来存储,引起了一些性能上的问题,在后来重构时选用了基于Erlang语言的开源XMPP服务ejabberd作为我们的消息服务。

ejabberd是xmpp协议的一种实现, xmpp广泛应用于即时通信领域。Xmpp协议的实现有很多种,比如java的openfire,但相较其他实现,ejabberd的并发性能无疑使最优秀的。Xmpp协议的前身是jabber协议,早期的jabber协议主要包括在线状态(presence)、好友花名册(roster)、IQ(Info/Query)几个部分。现在jabber已经成为rfc的官方标准,如rfc2799, rfc4622, rfc6121,以及xmpp的扩展协议(xep)。Worktile就是基于XEP-0124、XEP-0206定义的BOSH扩展协议。

由于自身业务的需要,我们对ejabberd的用户认证和好友列表模块的源码进行修改,通过redis保存用户的在线状态,而不是mnesia和mysql。另外好友这块我们是从已有的数据库中(mongodb)中获取Worktile中项目或团队的成员。Web端通过strophe.js来连接(http-bind),strophe.js可以以长轮询和websocket两种方式来连接,由于ejabberd还没有好的websocket的实现,就采用了BOSH的方式模拟长连接。整个系统的结构如下:


后记

关于Worktile整个的技术架构就揭秘到这里,通过上面的介绍,相信大家也能看到Worktile本身就是典型的MEAN(MongoDB、Express、AngularJS、NodeJS)架构,外加上ejabberd作为实时消息推送服务,建议大家在自己的产品中,根据产品自身的特点和团队的技术背景,来选择具体使用哪种技术。

作者简介

李会军,Worktile联合创始人&CTO,关注团队协作领域,致力于用工具解决中小团队的协作问题。

本文选自程序员电子版2015年7月A刊,该期更多文章请查看这里。2000年创刊至今所有文章目录请查看程序员封面秀。欢迎订阅程序员电子版(含iPad版、Android版、PDF版)。


【预告】 首届中国人工智能大会(CCAI 2015)将于7月26-27日在北京友谊宾馆召开。机器学习与模式识别、大数据的机遇与挑战、人工智能与认知科学、智能机器人四个主题专家云集。人工智能产品库将同步上线,预约咨询:QQ:1192936057。欢迎关注。 


0
0