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

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

基于Web的跨平臺設(shè)計，讓用戶在任何地方都可以隨時通過瀏覽器訪問

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

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

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

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

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

選擇它主要基于以下幾點考慮：

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

    
        
    
    {{task.name}}

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

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

(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è)計模式之一，為了解決面向?qū)ο笾幸蕾噯栴}，得到了廣泛的應(yīng)用，AngularJS中大膽使用了依賴注入，極大的減少了各個模塊之間的依賴問題：

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

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

我們再來看看Worktile的后臺服務(wù)設(shè)計，Worktile的整體服務(wù)架構(gòu)設(shè)計如下圖所示：

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

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

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

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

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

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

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

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"

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

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

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

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

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

ejabberd是xmpp協(xié)議的一種實現(xiàn)， xmpp廣泛應(yīng)用于即時通信領(lǐng)域。Xmpp協(xié)議的實現(xiàn)有很多種，比如java的openfire，但相較其他實現(xiàn)，ejabberd的并發(fā)性能無疑使最優(yōu)秀的。Xmpp協(xié)議的前身是jabber協(xié)議，早期的jabber協(xié)議主要包括在線狀態(tài)（presence）、好友花名冊（roster）、IQ（Info/Query）幾個部分?，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ù)的需要，我們對ejabberd的用戶認(rèn)證和好友列表模塊的源碼進(jìn)行修改，通過redis保存用戶的在線狀態(tài)，而不是mnesia和mysql。另外好友這塊我們是從已有的數(shù)據(jù)庫中（mongodb）中獲取Worktile中項目或團(tuán)隊的成員。Web端通過strophe.js來連接（http-bind），strophe.js可以以長輪詢和websocket兩種方式來連接，由于ejabberd還沒有好的websocket的實現(xiàn)，就采用了BOSH的方式模擬長連接。整個系統(tǒng)的結(jié)構(gòu)如下：

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

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

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

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