Worktile 技术架构概要

其实早就该写这篇博客了,一直说忙于工作没有时间,其实时间挤挤总会有的,可能就是因为懒吧!从2013年11月一直拖到现在,其实我是不怎么擅长写技术博客的,因为语言表达能力和文采不是很好,每次写博客都不知道自己在写啥,作为一开始就参与 Worktile 开发的技术人员,今天就简单谈谈 Worktile 的技术架构吧 。

Worktile 自上线到现在收到了很多用户的喜欢,我们倍感欣慰,自己做的产品得到了用户的认可是件幸福的事情,其中有很多来自IT的用户,经常在官方群或者知乎上问一些关于Worktile的技术问题:

Worktile 采用的是怎么样的架构?
Worktile 前后端采用了哪些技术?
...

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/basic/worktile-real-time-notice

采用 Erlang 是因为我们的开发人员有这方面的经验,并且Erlang非常适合做这个高并发实时推送服务。

如果你熟悉 Node.js 肯定知道 Socket.IO,我们最初的实时推送其实是采用 Socket.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的服务器结构图参考如下: