原文来自于：http://www.infoq.com/cn/articles/fengche-co-architecture
风车这个项目开始于 2011 年 11 月份，之前叫做 Pragmatic.ly。从第一天开始我们基本上就定了大致的框架结构，在今天回头看，基本上整个架构都没有什么变化，可以算是个很成熟和很适合时代的方案，☺。
最近一两年，作为技术人员，我们都能很明显的感觉到前端技术的飞速发展，比如 HTML5 支持，移动端优先、响应式界面设计以及层出不穷的各种客户端框架。而所有这些，都是基于一点：浏览器的高速发展。Chrome、Firefox、Safari、Opera 甚至于 IE，最近几年发展的都很快，不夸张的说，这些浏览器已经不再是浏览器，而是成为开放平台，有各自的扩展插件机制。这些极大地改变了网站开发的方式，网站开始应用化。
风车即是如此，设计得非常接近桌面应用，比如下面这些特点：
- 重客户端，所有的业务逻辑都在客户端，响应非常迅速
- 单页系统，项目内操作不需要刷新页面，操作非常流畅
- 三栏布局，左中右栏自左向右各司其职，信息非常清晰
- 实时更新，项目内任何更新都会实时的同步到你的页面
而在这个设计的背后，就是其本身的技术栈。
总览
风车在客户端使用的是 Spine.JS，后端使用的是 Ruby on Rails。实时消息同步用的是 Pusher。(三个里面有两个因为莫名其妙的原因打不开... -.-)
Spine.js 是一个轻量级的 MVC JavaScript 库，由《Javascript Web Applications》的作者 Alex MacCaw 基于 Backbone.js 改良。Spine 库使用 CoffeeScript 编写，整体代码量仅一千行左右，比起 Angular.js, Ember.js 这些框架来说少的多，非常容易学习和上手。
Rails 目前我们在使用的还是 3.2 版本，基本上是用来做 API 服务器，只管数据，不做逻辑。上周活动有些朋友也问到基本只做 API 服务器，为啥不选用更轻量的方案如 Sinatra，Grape 之类。一是从开发上来说，Rails 默认这一套用起来比较舒服，我们除了 API 之外还有一些第三方应用的集成和管理性功能，所以整体建站更方便。二是我们目前还没遇到大的性能上问题，所以没必要去更换。如果下一阶段真有需要了，会把 RESTful API 专门独立出来。
Pusher 是一个基于 WebSocket 的实时消息推送服务，集成到应用中也非常方便。即使在不支持 WebSocket 的浏览器里（对，没错，说的就是 IE），也提供默认的备用方式，可选择 Flash Socket 或者 SockJS。整体体验来说，Pusher 算是一个很不错的解决方法，轻、快，给我们节省了大量开发时间，只需要关注产品的核心价值。不过如果你的应用对于实时性要求非常严格，比如交易系统，可能 Pusher 的稳定性还不够符合你要求，因为你懂的一些网络原因。
当浏览器刷新页面的时候，会向服务端发起一个请求。服务端收到这个请求后，会返回一个不带数据的纯 HTML 空模板。然后客户端渲染模板后，再次通过 RESTful API 向服务端请求项目的真实数据（JSON 格式），再由客户端对数据做处理并呈现，得到用户真正看到的页面。之后，会跟 Pusher 服务器建立一条 WebSocket 的长连接，接收推送信息。当服务端有任何更新的时候，会发送消息到 Pusher 服务器，再由 Pusher 服务器传输到客户端浏览器，页面同时也得到更新。以上，就是一个简单的过程。
客户端
上面也介绍过了，风车的前端用的是 Spine.JS 和 jQuery。在移动端稍微有点不同，是 Spine.JS Mobile 和 Zepto。在目前这个时候，我计算了一下，压缩后的 JS 和 CSS，包括所有第三方的库，已经将近 270 KB。这里感谢一下七牛云存储，风车的这些静态文件因他们的 CDN 服务，能很快的下载到用户端，加速页面的加载。
Spine.JS
Spine 上面已经介绍了不少，这里再介绍一个我很喜欢的特性：_Asynchronous interfaces_。当我们决定把逻辑从服务端移到客户端的时候，就是要提高用户的整个使用体验，要能非常迅速的对用户行为做出响应。所以，当用户做了一个操作更新数据的时候，不要再显示个 loading spinner，让用户去等待数据更新完毕，而是应该立刻给出页面的变化。这就是异步 UI，通过解耦客户端 UI 交互跟服务端数据同步，保证了交互的流畅性。
CoffeeScript + Eco
这里真的很佩服 DHH，当时力排众难固执地在 Rails 3 里面默认加入了 CoffeeScript，让 CoffeeScript 迅速地流行起来。Coffee 是那种一用就能上瘾的东西，我们几乎所有的 JS 代码都是用 Coffee 写的，最后编译出来的纯 JS 代码也很具有可读性。即使是让人诟病的调试复杂度，对于熟悉代码结构和 Coffee 的人来说也从来不是问题，更不用说现在还提供了 Source Maps 的支持。Eco 是 "Embedded CoffeeScript templates"，语法跟 ERB 很像，作为一个 Ruby 开发人员没法不喜欢，:)
Model-View-Controller
从 MVC 框架来说，Controller 层，主要负责接受请求并处理请求，对应到客户端，请求就是事件，所以 Controller 负责对 DOM 事件的处理和 Router 事件的处理。基于此，风车前端有两种类型的 Controller，一种是跟页面 DOM 打交道的，一种是跟路由打交道的。基于 DOM 的 Controller 是按照页面的结构设计，每个 Controller 对应于一个单独的 DOM 模块，比如风车里面的侧边栏对应一个 Controller，侧边栏里面的任务列表部分和团队成员部分又分别对应一个 Controller，等等。这些 DOM Controller 会监视 DOM 上事件的发生，以及 DOM 对应的数据的更新。而基于 Router 的 Controller 是按照 URL 来设计，用来监视页面 URL 的变化，比如每一项任务都对应于一个单独的 URL，那么点击行为会导致 URL 的变化，这个变化会被 Router Controller 捕捉到，执行相应的操作，整个过程跟 Dom 没有任何关系。
Model 层，负责所有跟数据有关的处理。绝大多数时候，数据是 URL 对应，所以 Model 层绝大多数时间只需要跟 Router Controller 交互。Router Controller 从 Model 准备好数据后，会触发一个事件，交由 DOM Controller 去渲染相应的页面。
除了 MVC 三层之外，风车在设计上还使用了很多 HTML5 的特性，除了之前介绍的 WebSocket 之外，还有 History、Web Notification、Drag & Drop 和 LocalStorage。
HTML5 History pushState
History 是 Router Controller 的实现基础。我们都已经很习惯了浏览器页面的前进后退来访问历史页面。而很多富客户端应用因为 URL 没有发生改变，就很难支持这点。HTML5 History 就是为了解决这个问题，而在 JavaScript 端提供的一个实现。当我们访问下一个页面的时候，会 push 这个 URL 到栈里，当我们按后退时，会 pop 出这个 URL。Router Controller 需要定义一系列要响应的 URL，这样一旦匹配，就会截获页面跳转，转而去执行相应的代码，渲染出对应数据。所以在风车里，每次页面的修改都是对应一个唯一的 URL，这样除了可以前进后退外，还有个额外的好处是刷新页面后，总是可以回到刷新前的 URL。当然，需要在客户端和服务端用同一套路由。
HTML5 桌面通知
Web Notification 是桌面端的通知，当一个跟用户相关的事件发生时，比如团队里有人分配了一个任务给你，或有人在讨论里 @ 了你，就会收到一个通知。目前 Chrome 和 Safari 已经直接支持 Web Notification，Firefox 最新版已经支持，老版本需要安装一个插件支持，而 IE 在 10 以上才支持，而且必须加入 pinned site 列表里。具体的可以参考我之前在风车官方博客里面写的这篇详细介绍 HTML5 Web Notification 的文章。
HTML5 拖放
Drag & Drop 之前已经有很多 JS 的实现了，比如 jQuery UI 里面就有 DnD 的支持，HTML5 在规范制定的时候，也把 DnD 加入了进来，做了标准化。风车里面是用的 HTML5 的规范，主要用于把任务拖到某个任务列表里，某个成员里和拖到同个列表不同的位置。
有限离线支持
上面也介绍了，Spine 里面有个特性是异步 UI，但是如果我们跟服务器之间的连接出现短暂的问题，比如网络断了，那么就会在客户端更新了，但是服务端却没有同步到，这样用户一刷新，就会发现丢数据了。我们针对这个情况，一般发现同步失败，就先把未同步的数据放到 LocalStorage 里面，每隔一段时间重试一下，直到同步成功。所以，在页面加载后，即使在离线情况下，短暂时间使用风车也不是问题。但是，因为我们目前实现的很有限，也没做版本控制系统，所以在极端情况下，比如团队里不同人对同一个任务做出了更新，后同步的数据会覆盖掉先同步的。因为这种情况很少发生，所以目前我们没花大时间去改进它。
服务端
风车的整个服务端是基于 Ruby on Rails，前面也已经给了一些介绍。我在之前的重构 Rails 项目之最佳实践介绍了一些可以用来写出更好的代码结构的方法。在风车中，我们也在标准的 MVC 三层之外，加了 Service 层和 Presenter 层。
Service Layer
为了保持 Controller 结构的尽可能简单，对于一些复杂的又不仅属于某个 Model 的请求处理逻辑，我们在 Controller 和 Model 之间引入了新的一层：Service 层。举个例子，风车目前集成了 GitHub、GitLab 和 BitBucket 的 hook。当用户向远端推送提交的时候，GitHub/BitBucket 会向风车的服务器发起一个请求，包含这些提交的信息。在风车这边收到这些请求的时候，首先需要去做特征判断，查明是来自于哪一个服务。然后分析推判断送消息，是否绑定到具体的任务。最后根据消息，判断是否要更新状态和创建讨论。整个处理的逻辑比较复杂又相对独立，涉及多个 Model 并且有多种不同的策略，非常适合抽象成一个 Service。另外的一些场景比如 Analytics Service，Password Service，Email Handler Service 等。
Presenter Layer
熟悉 Rails 开发的朋友一般都知道，View 层应该仅仅是用来显示数据，我们应该避免在 View 里面有逻辑。但是，很多时候会不可避免的会有一些很难维护的 View。去年 RubyConf China 2013，来自台湾的讲师 xdite 就介绍了如何写出可维护的 View，详见这里。不过对于风车而言，大量的 View 是在客户端，服务端很少，只是提供了一些数据准备，所以没用多少技巧。只是因为数据准备涉及到了多个 Model 的数据以及来自于 Redis 数据库里面的数据，所以我们独立出了 Presenter Object，用来管理这些逻辑，而不是放在 View 里面。
Observer
Observer 一般而言是监控数据的，当数据创建、更新或者删除时，可以执行一些相应的操作，比如用户注册后可以发送注册邮件。但是风车里面的 Observer 有些许不同，除了监控数据以外，我们还监控 Controller，来了解数据变化相对应的请求信息，比如操作用户是谁。这里主要借鉴了 Rails 自带的 Caching Sweeper，后面我们会专门写一篇文章来介绍。
Sidekiq
Sidekiq 是一个简单强大的消息队列系统，目前可以说是 Ruby 世界里后台处理的首选。同类的选择还有 resque、delayed_job 等，但是 Sidekiq 之所以能迅速成为首选是基于两个特点，一是基于 Actor 模式的并行处理机制，二是基于 Redis 的 pubsub 模型，所以能用更少的内存资源来获得一样的处理能力。在风车里只要是能延迟的操作我们就会全放到后台执行，比如发送通知、数据统计、创建初始数据等等。这样子，我们就能让每个请求在最短的时间内完成，提高整个系统的吞吐量。Sidekiq 在收到消息后会在后台处理，即使失败了也会重试，更加可靠。
Percona
风车的主数据库还是使用了关系数据库 Percona，是基于 MySQL 的一个分支，但是因为使用了 Percona 公司自己研发的 XtraDB 存储引擎，具有更好的性能。另外一点好处是 Percona 号称是最接近官方 MySQL Enterprise 发行版的版本，可以完全与 MySQL 兼容，我可以很方便的做切换而不用修改代码。
Redis
Redis 在风车里面主要是两个用途：1. 用作 Caching Store，存储 View Cache 和 Record Cache 2. 加速数据访问，在内存中存储一些会频繁读写的数据，减少对 Percona 数据库的访问，比如 UID 映射表、统计信息之类。使用 Redis 而不是 Memcached 的原因是首先 Redis 的数据是持久的，不会因为重启而丢失，因为我们有一些无法立刻重建的数据，比如用户的在线状态，第二点是 Redis 可以用来存储一些复杂数据结构，比如 List 和 Set，对于统计信息来说非常合适。今年 Redis 3.0 有望正式发布，到时有 Redis Cluster 的支持，可以期待带来更好的性能。
扩展性
以上但是风车整体的技术架构，不复杂，但是非常实用。目前我们只使用了 Linode 上的单台机器，因为业务逻辑主要在前端，后端以 API 为主，所以性能问题并不突出。但是还是得承认健壮性有所缺乏，一旦后台某点发生故障，比如数据库或者 Redis，都会影响到服务的正常运行。下面来谈谈后台架构的一些可扩展性，来源于我之前的工作，但并没有上风车实践。
Rails
Rails 一直被人诟病的是其的性能，最近也经常能看到不少类似 XX 应用从 Rails 迁移到 Node.js 后获得 YY 倍的性能之类的报道。上期 Teahour 跟朴灵也聊到，Node.js 是从框架上用事件驱动和非阻塞来保证高性能，减少程序员犯错。同样的效果，Ruby 也能做到，但是对程序员本身的要求会更高。几种可能的扩展方式。
- Rails 应用本身很好水平扩展，我们目前用 Unicorn 作为应用服务器，使用 Nginx 作为前端服务器。Unicorn 是由 GitHub 开源的一个基于 Rack 的高性能 HTTP 服务器，Nginx 作为反向代理，通过 Unix Socket 或者 TCP 协议跟 Unicorn 通讯。所以，如果短期内流量增多，扩充机器性能是一个办法，也可以通过增加机器，在前端加负载均衡，后端加 Unicorn 进程数来提交系统吞吐量和处理能力。
- 从 Rails 应用中抽取 API 部分为独立的应用，因为前端和后端之间基本只有 API 通讯。API 部分可以使用更高性能的方案，比如 Ruby 世界里有 Goliath + Grape。Goliath 跟 Node.js 的概念一样，都是异步非阻塞的高性能 HTTP 服务器。而 Grape 是非常轻量级的 API 框架。
- 当然也可以考虑用 JRuby 或者 Node.js 或者 Go，:p
Percona
目前在数据库方便的优化不多，我们也只是在优化索引和尽量避免连表查询。不过风车这个应用性质决定了不会是大数据，尤其是我们有些数据还不通过 Percona 存储。惭愧的是目前风车只是做到了数据的备份，但是还没有做 Cluster、主从、读写分离这些，不过都是会在遇到瓶颈时去尝试的。跳出关系型数据库，也许可以尝试一些文档数据库如 Mongo，应该也蛮合适的。
Redis
Redis 对于风车最大的作用是用来存储分析数据，节省掉数据库的访问和运算。因为 Redis 在 2.X 版本的时候没有 Cluster 实现，目前要做扩展只能在上层通过一致性哈希来获得有限的支持。3.0 目前已经发布 beta 版，内建的 Cluster 功能还在测试中，值得期待。另外对于 Redis 的主从复制，针对不同的应用场景会有不同的问题，比如 Redis 持久化策略、主从间同步策略等。在百万级别以上的数据上，Redis 就必须要调优了，同时，每次重启的时候也很痛苦，重建库要花不少时间。所以，有可能的话，对数据进行分片，尽量只让新鲜数据或者常用数据留在内存里，陈旧数据可以存储到磁盘上。
Sidekiq
Sidekiq 本身是基于线程的单进程运行模式，使用 Redis 做为消息队列。所以，Sidekiq 的并行能力很容易提升，只要多起几个进程就可以了，前提是数据库和 Redis 都扛得住，当然还有内存这些硬件资源。
Pusher
这个就是使用在线服务的好处，花点钱把性能问题留给他们吧，价格也算合理，:)
结语
目前来说，我相信这套架构还能让我们撑不少时间，也可以很方便的做水平扩展。对于一个技术驱动型团队，这是我们的优势，也是对待事情应有的态度。感谢所有风车使用到的开源软件和在线服务，才能让我们这么"小"的一个团队，能有更好的时间专注在产品的核心价值上，节省时间去做"大"事。作为一个团队协作工具，风车也想帮助你们更好的工作。如果你懂得时间的价值，那么你应该使用风车来管理你的项目。风车，让协作更简单，让协作更高效。
有想法吗？现在就试试吧！