團隊協作工具Worktile技術架構揭秘

jopen 9年前發布 | 20K 次閱讀 Worktile

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

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

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

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

  4. 服務要穩定，穩定壓倒一切
    那么Worktile是如何做到這幾點的？今天筆者在這篇文章里一一為大家揭秘。
    5. </ol>

    SPA設計

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

    團隊協作工具Worktile技術架構揭秘

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

    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_"
    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:;"></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有很大的不同，感興趣的同學可以先去嘗鮮一下。
      5. </ol>

      服務設計

      我們再來看看Worktile的后臺服務設計，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服務。
        5. </ol>

        消息推送

        消息推送服務是Worktile最核心的服務之一，前面提到過作為一款團隊協作工具，要能夠實現非常好的實時性，任何數據的變化都需要及時變更到團 隊所有成員當前所在的視圖，如下面這幅圖，是一個典型的任務看板，團隊所有成員可能同時在操作當前項目中的任務，每個操作引起看板的變化都會實時更新，不 需要用戶做任何刷新操作：

        團隊協作工具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協議。
          4. </ol>

          在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整個的技術架構就揭秘到這里，通過上面的介紹，相信大家也能看到Worktile本身就是典型的MEAN（MongoDB、 Express、AngularJS、NodeJS）架構，外加上ejabberd作為實時消息推送服務，建議大家在自己的產品中，根據產品自身的特點和 團隊的技術背景，來選擇具體使用哪種技術。

          </div> 來自：https://new.worktile.com/tech/basic/worktile-architecture-expose

           本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
           轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
           本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
            本文地址：http://www.baiduhome.net/news/view/1cf259e

相關資訊

相關經驗

相關文檔