Worktile 技術架構概要

其實早就該寫這篇博客了，一直說忙於工做沒有時間，其實時間擠擠總會有的，可能就是由於懶吧！從2013年11月一直拖到如今，其實我是不怎麼擅長寫技術博客的，由於上學的時候語文不是很好，每次寫做文都不知道本身在寫啥，做爲一開始就參與 Worktile 開發的技術人員，今天就簡單談談 Worktile 的技術架構吧 。

Worktile 自上線到如今收到了不少用戶的喜歡，咱們倍感欣慰，本身作的產品獲得了用戶的承認是件幸福的事情，其中有不少來自IT的用戶，常常在官方羣或者知乎上問一些關於Worktile的技術問題：

Worktile 採用的是怎麼樣的架構？
Wortile 先後端採用了哪些技術？
...

Worktile總體架構一覽

Worktile 是企業協同辦公軟件，因此一開始註定就應該是單頁應用（SPA），由於使用SPA後，用戶在瀏覽器端能夠像操做原生客戶端程序同樣的體驗（速度和流暢度），對於開發者來講，先後端分離，服務端只提供RESTful API服務，移動端集成也很是的方便，具體能夠看下面這張草圖。

前端

1. Angular.js（客戶端MV*）
2. Bootstrap (CSS基礎庫和一些Javascript組件)
3. UI Bootstrap (Bootstrap 的 Angular.js版本)
4. jQuery (取代Angular.js中的jqLite，並做爲其餘第三方jQuery插件的基礎類庫)

Worktile的服務端基本上只是提供API數據服務的，不會渲染HTML，前端的代碼在發佈以前會使用 Grunt 工具打包合併壓縮成一個js文件。

Angular.js

既然是SPA程序，前端必然要選擇一個MVC（或者MVVM）框架，關於前端MVC框架有不少，當時面臨選擇的時候也是比較猶豫，由於在此以前咱們只初略的使用過 Knockoutjs 。
其實咱們當時就是急切的但願一個框架能作到：

1. 數據可以雙向綁定（或者只單向綁定）
2. 前端路由功能
3. 簡單易學的模板語言

最終咱們選擇了 Angular.js，具體其中選擇的細節就不一一描述了（以前在知乎上也回答過關於Angular.js 的問題：Angular.js 在實際應用中有哪些優缺點？），從開始使用到如今已經快2年了，事實證實當初的選擇仍是沒有錯的， Angular.js的確很適合 Worktile。

Bootstrap 和 jQuery

選擇Bootstrap主要是爲了使用它的基礎CSS功能，在它的基礎之上很容寫出規範的樣式代碼，固然咱們也須要使用其中的部分Javascrip組件功能，由於原生的 Bootstrap是基於 jQuery的，爲了在Angular.js中也能很好的使用它，咱們引入了 UI Bootstrap、關於jQuery你們再熟悉不過了，咱們使用的不少第三方插件是jQuery的，因此也一併引入了。

上面只是列出了 Worktile 主要使用的幾個Javascript框架和類庫，真正使用的類庫遠不止上面列出的這些。好比日曆庫 ui-calendar、underscorejs 等等...

服務端

1. Node.js
2. Redis
3. MongoDB

Node.js

服務端是構建在Node.js之上的，咱們的服務端MVC框架採用的是 Expressjs，剛開始是 Express 3.x版本，如今已經升級到 4.x，Expressjs提供了 Route和模板引擎的功能，因爲咱們的服務端基本只提供數據服務，因此關於服務端模板引擎這塊基本不使用（只有佈局和一些配置項輸出到界面時須要用到）。

選擇 Node.js 是由於它簡單，適合高併發的Web服務，並且咱們的開發人員可以熟練使用它，關於Node.js的優缺點我在知乎上也曾經回答過：使用 Node.js 的優點和劣勢都有哪些？。

Redis

Worktile 用戶的登陸狀態，一些臨時使用的數據、部分業務數據緩存 都是放在 Redis 裏面的，關於Node.js怎麼和 Redis 鏈接採用 Node Redis 模塊。

MongoDB

Worktile 並非那種高度事物性的系統或者傳統的商業智能應用，因此MongoDB很是適合，性能很是高，集羣方便，並且以BSON結構存儲，和Node.js完美集成。
Worktile 的數據層和MongoDB之間並非使用 原生的驅動 ，而採用了 mongoosejs，相似Java或者C#上的ORM框架，使用 mongoose 能夠很方面的定義數據 Schema，讀取操做 MongoDB。

推送服務

前面也說了 Worktile 是 SPA程序，用戶登陸到系統以後，基本上全部的操做都不須要刷新瀏覽器，由於是一個協同辦公軟件，其餘用戶多數據進行操做須要實時更新，因此客戶端必然要和服務端保持一種長鏈接，方面進行數據交互，咱們的實時推送服務是採用 Erlang 語言編寫的，感興趣的能夠查看：https://worktile.com/tech/bas...

採用 Erlang 是由於咱們的開發人員有這方面的經驗，而且Erlang很是適合作這個高併發實時推送服務。

若是你熟悉 Node.js 確定知道 Sockiet.IO，咱們最初的實時推送實際上是採用 Sockiet.IO的，後來因爲訪問量的增張，原有的Sockiet.IO 是基於Worktile Web站點的，沒有獨立成單獨的服務，重構的時候完全採用Erlang重寫了。

其實這2種技術都很是優秀，選擇哪一種主要取決於你擅長什麼。

文件預覽服務

使用過 Worktile 的人確定都知道，在系統中上傳一些文件，好比：word、excel、txt、pdf、ppt等等，都是能夠在線預覽的，關於 txt、pdf這些文件的預覽其實好辦，txt直接讀取文件內容便可，pdf採用瀏覽器自帶的預覽或者使用一些Js類庫都很方便的作到，可是對於 Ofiice 文件，是不能夠直接讀取的，因此咱們本身搭建了一套 Ofiice的預覽服務，這個服務主要是基於微軟的 Office Web App服務

Box 文件服務

Worktile 中全部的文件存儲在阿里雲的OSS上，爲了作一些權限的認證和安全問題，咱們經過一個Box服務作中轉，全部文件的上傳下載都是走 Box 服務。這要感謝 5樓的Box之父 @Shaun Xu 寫出了這麼好的Box 服務。

以上是Worktile用的全部技術和架構簡單介紹。

Worktile 自上線以來用戶的增加也是很是迅速的，因此 Web服務器從原先的1臺變成多臺，數據庫從單實例到如今的集羣，等等，關於目前Worktile的服務器結構圖參考以下：

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

文章轉載請註明出處。