Trello架构分享
Trello架構學習
1.Trello簡介
Trello是由著名的軟件工程師 Joel Spolsky開發的一個團隊協作平臺，在TechCrunch Disrupt大會上正式發布。在不到3小時的時間內，Trello已經積累了5000多用戶。 Trello上的工作都圍繞“木板（board）”進行，同一小組的用戶可以在這里創建待辦事項列表（to do list）、創建任務，并分配給同事，當同事完成工作后可以把任務狀態標記為完成，類似于producteev。你可以為每個項目創建一張卡片，里面包括活動、附件、更新、溝通內容等信息。你可以把同事拖拽到這些卡片中，然后把卡片拖到列表里。 和其他的項目管理系統都是以開發者為中心的，過于復雜，對普通用戶缺乏吸引力。Trello則為各種流程設計，既可以當做公司的協作工具，也可以當做個人的列表管理工具。
2.CoffeeScript
CoffeeScript (GitHub repo) 是一個使用純Ruby編寫的新編程語言，創建者 Jeremy Ashkenas戲稱它是- JavaScript的不那么鋪張（買弄）的小兄弟。因為CoffeeScript會將Ruby編譯成JavaScript，而且大部分結構都相似，但不同的是，CoffeeScript擁有更嚴格的語法。
官方主頁：http://coffeescript.org/
3.client
Trello的服務器上實際上沒有運行html代碼。Trello的客戶端是單個的經過精簡和壓縮的js文件（2k）（包括第三方庫和編譯過的CoffeeScript以及Mustache模板，壓縮過的css代碼和內聯圖片）。所有的這些都在250k以下。而且通過Amazon cloudfront內容分發網絡提供的服務，所以在大多數地方都能提供低延遲的服務。在高帶寬的情況下半秒內就能在瀏覽器中加載client。與此同時，放棄了使用ajax獲取加載頁的數據文本，運用websocket予以代替。
3.1Backbone.js
主要提供了3個東西：1、models(模型) 2、collections(集合) 3、views(視圖)
? ? ? ?Backbone.js文件本身很小，壓縮后只有5.3KB，作為一個框架級別的核心JS文件，這個數字很可怕。除此之外，這個JS還必須依賴于另一個JS文件：underscore.js(包含許多工具方法，集合操作，js模板等等)。
用Backbone.Model表示應用中所有數據，models中的數據可以創建、校驗、銷毀和保存到服務端。當models中值被改變時自動觸發一個"change"事件、所有用于展示models數據的views都會偵聽到這個事件，然后進行重新渲染。
Backbone.Collection和我們平時接觸的JAVA集合類相似，具有增加元素，刪除元素，獲取長度，排序，比較等一系列工具方法，說白了就是一個保存models的集合類。
Backbone使用views渲染那些從服務器下載下來的Models，然后提供了如下簡易的方法。
1）通過views生成的html查看DOM事件，并且將這些事件與Models建立相關，這些模型會和服務器端重新同步
2）觀察Models的變化，重新渲染Models的html塊，以此來展示Models的變化。通過自己開發的客戶端Models緩 存處理模型的更新和Models的重用。
官方主頁：http://documentcloud.github.com/backbone/
3.2 Html5 pushState
? ? ? ? ?頁面加載完成后，不希望在頁面間的切換上花費任何時間。因此運用了html5 pushState在頁面間移動。這樣就能給與地址欄適當的和一致的鏈接。要做的僅僅是將載入數據并且交付給適當的Backbone controller處理。
3.3 MUSTACHE
? ? ? ?運用了mustache模板（一個邏輯很少的模板語言）來代替顯示model的html。mustache使我們能夠不用將將客戶端邏輯代碼與模板代碼混合的情況下復用模板代碼。??
4.pushing and polling（推送和輪詢）
? ? ? ?實時更新不是一個新的話題，但是對于一個協同工具是相當重要的。
4.1 socket.io and websocket
? ? ? ?客戶端和服務端之間建立websocket鏈接,這樣子服務端就能實時推送給在特定通道監聽的瀏覽器。運用socket.io和服務端庫，在占用cpu資源很少的情況下，同時維持好幾千個websocket鏈接。
4.2 ajax polling?
? ? ? ?當客戶斷不支持websocket時，當一個用戶活躍時，每幾秒進行少量的ajax請求更新；當一個用戶空閑時，每10秒進行輪詢。由于我們的服務器配置，能夠在使用很小開銷的情況下，提供https請求并且保持TCP鏈接打開。
? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖1 原先的客戶端架構 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ?但是其間遇到了一個問題，在調整輪詢活躍和空閑用戶狀態間隔后，解決了出現的怪異的問題。
?
5. server
5.1 node.js
? ? ? ? trello服務端主要用node.js實現。trello需要的是即時更新,這就意味著要保持許多鏈接處于打開狀態，因此消息驅動和非阻塞是一個好的選擇。node.js也是一個讓人驚訝的單頁面app開發的原型工具。原型版的trello服務端僅僅是一個函數庫。用來操作node.js單個進程的內存的Models隊列。客戶端僅僅是通過輕量級的websocket的封裝調用這些函數。
? ? ? ?我們增加了如下，是系統更為完善：
? ? ? ?1)一個真實的DB和Schema（node-mongodb-natice and mongoose）
? ? ? ?2)web基礎技術，routes和cookies（Express 和 Connect）
? ? ? ?3)多個服務器進程和零停機重啟（cluster）
? ? ? ?4)進程間切換和數據共享通過使用Redis（node_Redis）
? ? ? ?使用了一個異步庫async library，CoffeeScript，使我們的代碼簡潔并在可控制的范圍內。
5.2 HAPROXY
? ? ? ?用haproxy做為服務器間的負載均衡。
5.3 Redis
? ? ? ?trello使用redis在服務器進程間共享生命周期較短的數據，這些數據不會持久化到磁盤。例如，session的活躍水平；臨時地OpenID鍵。如果redis存儲的這些數據全部或者部分丟失，那么應用程序能夠自動恢復。我們在allkeys-lru配置下運行redis并且設置了比實際需要多5倍的空間。redis自動撤銷在不久的將來沒有被使用的數據，并且在需要時創建他們。
? ? ? 我們最有意思的應用是短輪詢回調為了發送變化的數據到models下載到瀏覽器端。當一個server端的對象改變，我們發送一個josn消息，通過合適的websocket通知所有客戶端瀏覽器，并且為受影響的model也存儲該消息在一個固定長度的list，并且注意有多少消息存儲在該list。這樣，當一個clinet通過ajax輪詢是否在服務端有對象改變時，在多數情況下我們能夠得到整個服務器的響應在權限檢查和檢查單redis的值。Redis能夠在一秒內做上千次這樣的檢查，所以它不會大幅削弱單個cpu的計算能力。
? ? ? ?redis也是我們的發布和訂閱服務器。我們用它發布對象的更改消息，來自服務器進程啟動向其他服務器進程的請求。一旦你有一個redis服務器，你會開始在各種情況下使用他。
?
5.4 MongoDB
? ? ? ?MongoDB彌補了許多我們對于傳統數據庫的需求。我們想讓trello變得很快。我們所知道的最酷的，對于性能很著迷的團隊就在我們隔壁StackExchange。在和他們的開發主管聊天時，了解到，即使用了sql-server作為數據存儲，他們還是運用了很多反規格化的數據，為了獲取更高的性能。
? ? ? ?為了高速的讀、寫，我們放棄了關系型數據庫的特征。并且有了反規格化的支持，我們能夠在一個文檔中存儲一個card的數據，同時也能檢索文檔的子域和建立索引。
? ? ? ? 在用戶增長很快的情況下有一個能夠在讀寫方面合理的濫用，是一件很慶幸的事情。MongoDB能夠很容易的進行復制、備份和恢復。
? ? ? ? 使用MongoDB松散文檔存儲的另一個好處是在同一個數據庫下，運行不同版本的Trello，無須進行數據遷移。
?
文章翻譯自：http://blog.fogcreek.com/the-trello-tech-stack/
?
中間有些省略了。可以和原文對照著看。
總結
以上是生活随笔為你收集整理的Trello架构分享的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 多变量分析”——数据挖掘、数据分析
- 下一篇： 【动态规划法】求解TSP问题