摘要：現在已經成為的官方標準，如，以及的擴展協議。作者簡介李會軍，聯合創始人，關注團隊協作領域，致力于用工具解決中小團隊的協作問題。

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

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

Web形態的產品要具有原生客戶端的體驗，如任務的拖拽等

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

服務要穩定，穩定壓倒一切

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

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

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

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

    
        
    
    {{task.name}}

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

模塊化設計，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"
    ]);
}());

引入依賴注入，依賴注入是面向對象中比較成熟的設計模式之一，為了解決面向對象中依賴問題，得到了廣泛的應用，AngularJS中大膽使用了依賴注入，極大的減少了各個模塊之間的依賴問題：

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

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

我們再來看看Worktile的后臺服務設計，Worktile的整體服務架構設計如下圖所示：

其中前端部分在上面的SPA一節中我們已經說過了，下面一一分析下其他的服務：

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

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

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

文件預覽服務，使用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"

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

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

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

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）幾個部分?，F在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，關注團隊協作領域，致力于用工具解決中小團隊的協作問題。

您可以點擊Worktile技術博客查看更多干貨內容，歡迎訪問交流技術問題。

文章轉載請注明出處。