摘要：現(xiàn)在已經(jīng)成為的官方標(biāo)準(zhǔn)，如，以及的擴(kuò)展協(xié)議。作者簡(jiǎn)介李會(huì)軍，聯(lián)合創(chuàng)始人，關(guān)注團(tuán)隊(duì)協(xié)作領(lǐng)域，致力于用工具解決中小團(tuán)隊(duì)的協(xié)作問(wèn)題。

Worktile自上線兩年多以來(lái)，以良好的用戶體驗(yàn)和穩(wěn)定的服務(wù)，獲得了用戶的認(rèn)可和喜愛(ài)。截止筆者寫這篇文章的時(shí)候，已經(jīng)有超過(guò)10萬(wàn)家團(tuán)隊(duì)在使用Worktile。作為團(tuán)隊(duì)協(xié)作工具，從技術(shù)上分析首先要解決如下幾個(gè)問(wèn)題：

基于Web的跨平臺(tái)設(shè)計(jì)，讓用戶在任何地方都可以隨時(shí)通過(guò)瀏覽器訪問(wèn)

Web形態(tài)的產(chǎn)品要具有原生客戶端的體驗(yàn)，如任務(wù)的拖拽等

具有高效的實(shí)時(shí)消息系統(tǒng)，每個(gè)團(tuán)隊(duì)成員在Worktile中所做的任何操作，都要實(shí)時(shí)在其他成員的客戶端中自動(dòng)刷新

服務(wù)要穩(wěn)定，穩(wěn)定壓倒一切

那么Worktile是如何做到這幾點(diǎn)的？今天筆者在這篇文章里一一為大家揭秘。

先來(lái)說(shuō)說(shuō)Worktile中SPA（單頁(yè)應(yīng)用程序）設(shè)計(jì)，作為團(tuán)隊(duì)協(xié)作工具，需要盡可能減少用戶在不同頁(yè)面之間的跳轉(zhuǎn)，所以從一開(kāi)始我們就決定Worktile必須是單頁(yè)應(yīng)用程序，當(dāng)時(shí)面臨的選擇有很多，首先我們考慮使用大名鼎鼎的Backbone.js，但是很快又拋棄了，因?yàn)樵趯?shí)際使用中Backbone.js太復(fù)雜，另一方面開(kāi)發(fā)效率太低，最終我們選擇了Google出品的AngularJs，下面這幅圖是AngularJS的結(jié)構(gòu)圖：

選擇它主要基于以下幾點(diǎn)考慮：

自動(dòng)化雙向數(shù)據(jù)綁定功能，這一點(diǎn)在Worktile中非常重要，如任務(wù)的狀態(tài)變化都要實(shí)時(shí)變更到其他成員，如果具有自動(dòng)化雙向數(shù)據(jù)綁定功能，只需要綁定到UI的數(shù)據(jù)源發(fā)生變化，UI會(huì)自動(dòng)發(fā)生改變，不需要工程師再通過(guò)代碼去修改UI元素的改變，如下面這段代碼：

    
        
    
    {{task.name}}

語(yǔ)義化標(biāo)簽，AngularJS在設(shè)計(jì)之初信奉的理念就是：當(dāng)編寫UI的同時(shí)又需要編寫業(yè)務(wù)邏輯時(shí)，聲明式的代碼遠(yuǎn)比命令式代碼要好，命令式的代碼更適合寫業(yè)務(wù)邏輯，AngularJS在設(shè)計(jì)上就通過(guò)語(yǔ)義化的標(biāo)簽把對(duì)DOM元素的操作和邏輯代碼分離，如我們需要展現(xiàn)一個(gè)任務(wù)列表，只需要下面這段代碼即可：

模塊化設(shè)計(jì)，AngularJS堪稱模塊化設(shè)計(jì)方面的典范，通過(guò)模塊化設(shè)計(jì)我們可以非常好的實(shí)現(xiàn)Worktile的工程化，在Worktile中涉及的元素非常多，如有項(xiàng)目、任務(wù)、日程、文件、話題、文檔等等，而這每一個(gè)元素都可以設(shè)計(jì)為一個(gè)模塊，如下所示：

(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"
    ]);
}());

引入依賴注入，依賴注入是面向?qū)ο笾斜容^成熟的設(shè)計(jì)模式之一，為了解決面向?qū)ο笾幸蕾噯?wèn)題，得到了廣泛的應(yīng)用，AngularJS中大膽使用了依賴注入，極大的減少了各個(gè)模塊之間的依賴問(wèn)題：

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

結(jié)合以上特點(diǎn)，我們最終決定了前端框架使用AngularJS來(lái)實(shí)現(xiàn)，從Worktile上線兩年多的表現(xiàn)來(lái)看，我們的選擇無(wú)疑是正確的。當(dāng)然AngularJS也有一些缺點(diǎn)，在實(shí)際使用中還是要根據(jù)具體的產(chǎn)品類型來(lái)選擇使用，另外AngularJS 2.0也已經(jīng)初見(jiàn)端倪，和AngularJS 1.0有很大的不同，感興趣的同學(xué)可以先去嘗鮮一下。

我們?cè)賮?lái)看看Worktile的后臺(tái)服務(wù)設(shè)計(jì)，Worktile的整體服務(wù)架構(gòu)設(shè)計(jì)如下圖所示：

其中前端部分在上面的SPA一節(jié)中我們已經(jīng)說(shuō)過(guò)了，下面一一分析下其他的服務(wù)：

API服務(wù)，包括Web API、Mobile API、Open API，這些都運(yùn)行于NodeJS之上，選用NodeJS的原因主要是它的異步事件驅(qū)動(dòng)，對(duì)于高并發(fā)的支持比較好，另外一個(gè)原因是使用簡(jiǎn)單，對(duì)于前后端可以使用同一門語(yǔ)言去開(kāi)發(fā)。

緩存和隊(duì)列服務(wù)，Worktile中的緩存和隊(duì)列服務(wù)都是基于Redis來(lái)實(shí)現(xiàn)，Redis是一款非常優(yōu)秀的開(kāi)源緩存服務(wù)，并且可以選擇基于內(nèi)存還是進(jìn)行數(shù)據(jù)持久化，它提供的pub/sub模型對(duì)于Worktile來(lái)說(shuō)非常重要，對(duì)于一些實(shí)時(shí)性要求不高的處理，我們都是在Redis中pub一條消息，告知其他服務(wù)有數(shù)據(jù)發(fā)生了變化，那些服務(wù)在接收到Redis中的消息后，根據(jù)消息的類型決定應(yīng)該如何做出處理。

數(shù)據(jù)庫(kù)服務(wù)，Worktile產(chǎn)品本身的特點(diǎn)決定了它是一個(gè)對(duì)實(shí)時(shí)性和性能的要求，遠(yuǎn)超過(guò)對(duì)事務(wù)性要求的產(chǎn)品，所以在選擇數(shù)據(jù)庫(kù)時(shí)，我們選用了MongoDB數(shù)據(jù)庫(kù)，性能高，集群方便，數(shù)據(jù)以BSON結(jié)構(gòu)存儲(chǔ)，和Node.js天生完美結(jié)合。

文件預(yù)覽服務(wù)，使用Worktile的同學(xué)肯定知道在Worktile中所有的文件都可以做到無(wú)需下載到本地，而直接在線查看，這一切都是預(yù)覽服務(wù)的功勞，因?yàn)槲募愋偷母鞣N各樣，在實(shí)現(xiàn)文件預(yù)覽時(shí)也要根據(jù)文件的類型做出不同的處理，針對(duì)txt、pdf、代碼片段等文本型的文件，我們只需要讀取文件中的內(nèi)容，然后再前端用相應(yīng)的視圖展現(xiàn)出來(lái)即可，相對(duì)比較簡(jiǎn)單。但是對(duì)于Office類型的文件，如ppt、doc、xls等文件，就不能這么簡(jiǎn)單的處理，我們希望文件在Worktile中查看的效果和用戶在本地使用Word、Excel、PowerPoint查看的效果差不多，經(jīng)過(guò)我們的調(diào)研，最終選用了微軟官方提供的Office Web App服務(wù)。

消息推送服務(wù)是Worktile最核心的服務(wù)之一，前面提到過(guò)作為一款團(tuán)隊(duì)協(xié)作工具，要能夠?qū)崿F(xiàn)非常好的實(shí)時(shí)性，任何數(shù)據(jù)的變化都需要及時(shí)變更到團(tuán)隊(duì)所有成員當(dāng)前所在的視圖，如下面這幅圖，是一個(gè)典型的任務(wù)看板，團(tuán)隊(duì)所有成員可能同時(shí)在操作當(dāng)前項(xiàng)目中的任務(wù)，每個(gè)操作引起看板的變化都會(huì)實(shí)時(shí)更新，不需要用戶做任何刷新操作：

為了達(dá)到這種效果，需要在Web客戶端和服務(wù)器之間維持一個(gè)長(zhǎng)連接，當(dāng)有任何改變發(fā)生時(shí)，給客戶端發(fā)送不同的消息，告知客戶端哪些數(shù)據(jù)發(fā)生了變化，如下面是我們?yōu)槿蝿?wù)定義的消息中的其中幾個(gè)：

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"

實(shí)現(xiàn)實(shí)時(shí)消息推送，有以下幾種方式可供選擇：

短輪詢，頁(yè)面端通過(guò)js定時(shí)異步刷新，這種方式優(yōu)點(diǎn)在于實(shí)現(xiàn)簡(jiǎn)單，但實(shí)時(shí)效果較差。

長(zhǎng)輪詢。頁(yè)面端通過(guò)js異步請(qǐng)求服務(wù)端，服務(wù)端在接收到請(qǐng)求后，如果該次請(qǐng)求沒(méi)有數(shù)據(jù)，則掛起這次請(qǐng)求，直到有數(shù)據(jù)到達(dá)或時(shí)間片（服務(wù)端設(shè)定）到，則返回本次請(qǐng)求，客戶端接著下一次請(qǐng)求，這種方式對(duì)于服務(wù)的要求較高，尤其在并發(fā)量很大的情況下，對(duì)服務(wù)端的壓力很大。

Websocket。瀏覽器通過(guò)websocket協(xié)議連接服務(wù)端，實(shí)現(xiàn)了瀏覽器和服務(wù)器端的全雙工通信。需要服務(wù)端和瀏覽器都支持websocket協(xié)議。

在Worktile一開(kāi)始我們選用了Socket.IO作為消息服務(wù)，但是隨著訪問(wèn)量的增大，需要做集群化的時(shí)候感覺(jué)到力不從心，尤其對(duì)于Socket.IO狀態(tài)數(shù)據(jù)的存儲(chǔ)，由于并沒(méi)有官方的解決方案，當(dāng)時(shí)我們采用了一個(gè)第三方的開(kāi)源項(xiàng)目，使用Redis來(lái)存儲(chǔ)，引起了一些性能上的問(wèn)題，在后來(lái)重構(gòu)時(shí)選用了基于Erlang語(yǔ)言的開(kāi)源XMPP服務(wù)ejabberd作為我們的消息服務(wù)。

ejabberd是xmpp協(xié)議的一種實(shí)現(xiàn)， xmpp廣泛應(yīng)用于即時(shí)通信領(lǐng)域。Xmpp協(xié)議的實(shí)現(xiàn)有很多種，比如java的openfire，但相較其他實(shí)現(xiàn)，ejabberd的并發(fā)性能無(wú)疑使最優(yōu)秀的。Xmpp協(xié)議的前身是jabber協(xié)議，早期的jabber協(xié)議主要包括在線狀態(tài)（presence）、好友花名冊(cè)（roster）、IQ（Info/Query）幾個(gè)部分?，F(xiàn)在jabber已經(jīng)成為rfc的官方標(biāo)準(zhǔn)，如rfc2799, rfc4622, rfc6121，以及xmpp的擴(kuò)展協(xié)議（xep）。Worktile就是基于XEP-0124、XEP-0206定義的BOSH擴(kuò)展協(xié)議。

由于自身業(yè)務(wù)的需要，我們對(duì)ejabberd的用戶認(rèn)證和好友列表模塊的源碼進(jìn)行修改，通過(guò)redis保存用戶的在線狀態(tài)，而不是mnesia和mysql。另外好友這塊我們是從已有的數(shù)據(jù)庫(kù)中（mongodb）中獲取Worktile中項(xiàng)目或團(tuán)隊(duì)的成員。Web端通過(guò)strophe.js來(lái)連接（http-bind），strophe.js可以以長(zhǎng)輪詢和websocket兩種方式來(lái)連接，由于ejabberd還沒(méi)有好的websocket的實(shí)現(xiàn)，就采用了BOSH的方式模擬長(zhǎng)連接。整個(gè)系統(tǒng)的結(jié)構(gòu)如下：

關(guān)于Worktile整個(gè)的技術(shù)架構(gòu)就揭秘到這里，通過(guò)上面的介紹，相信大家也能看到Worktile本身就是典型的MEAN（MongoDB、Express、AngularJS、NodeJS）架構(gòu)，外加上ejabberd作為實(shí)時(shí)消息推送服務(wù)，建議大家在自己的產(chǎn)品中，根據(jù)產(chǎn)品自身的特點(diǎn)和團(tuán)隊(duì)的技術(shù)背景，來(lái)選擇具體使用哪種技術(shù)。

李會(huì)軍，Worktile聯(lián)合創(chuàng)始人&CTO，關(guān)注團(tuán)隊(duì)協(xié)作領(lǐng)域，致力于用工具解決中小團(tuán)隊(duì)的協(xié)作問(wèn)題。

您可以點(diǎn)擊Worktile技術(shù)博客查看更多干貨內(nèi)容，歡迎訪問(wèn)交流技術(shù)問(wèn)題。

文章轉(zhuǎn)載請(qǐng)注明出處。