Scalable Web Architecuture with Rails 3 Index

不得不说,从Ruby on Rails上学到了很多东西,不仅是技术层面,还有那种分享的精神,所以也一直想通过某种方式来回馈。这也是这个系列的主要目的。

http://l.yimg.com/g/images/soup-share.jpg

###主题起源

这个系列的博客起源于一场主题分享,通过Rails 3来讲述一下我对好的架构的一个理解。只能说是很有幸,能呆在Microsoft这样的公司,能有机会参加CSDN, InfoQ,Taobao及其他社区等组织的活动,观摩和学到很多好的一面,特别是MSN时对架构的一些认识。在11.11的RubyConf听到TB关于淘宝网黄小勇:Rails3在淘宝测试平台的应用,及InfoQ的系列专题:Rails系统重构 – 从单一复杂系统到多个小应用集群,和我所理解的架构都有着一致的理解,就是合理折分,具体为什么拆如何拆后面会有提及。

还有,进公司时就答应老吴做一场有关RoR的分享,也一直说经给@laokun 分享Rails使用过程中的一些小技巧,就也借这个机会一起补上了。

我还为这次分享做了一个Slide,在下面的Link,由于被分享申请迟迟未批,加上最近在忙Phoenix Engine的事,一直没有去写,接下来会和Blog同步更新。
http://bigrails.heroku.com

[关于分享申请被拒绝:我总认为一家技术公司是要有技术储备和研发能力的,对技术的面也不应限制在够用的层面,所以常说这不是技术主导公司。修了一年Bug的人表示,青春不是这样挥霍的!]

###这次的话题分为以下几个部分:

####1. 谈谈Ruby,Rails的社区文化

为什么是Ruby,我觉得重点要提的并不是技术,而是它所在的社区文化 ,我常举例,有些公司做敏捷,那是填鸭式的,文化上是抵触的,最终劳民伤财,但在Ruby社区里,敏捷是一种内在的东西,就像所有的作者都会在代码前先写上测试,就像所有新的测试理念都来源于这个社区一样。

####2. Architecture

在整个敏捷中我最质疑的就是关于架构的话题,但一个系统若在起初时没有一个好的架构体系,显然在后期中会花费更多的代价来修补。好的架构是可以满足后期业务的变更的,技术层面上有点像设计模式的原理,通过有效隔离将变化限制在一个层内,有效的复用减少代码量增加效率。当然架构不会只是技术层面的,也会有相应的组织架构来相匹配。

####3. Framework as Service

这是管理和业务层面上的话题,技术上Rails早已如此,MSN也是基于这种模式,我发过微博来阐述这种关点,可能有点抽像,好多人都不大明白,明白的人也觉得不大可能实现。这里重点讲下。

####4. RubyGem / Bundler

Ruby中通过Gem对Ruby进行扩展,类似于Java中的jar包,.NET中的NuGet,只是Ruby中更加Native,在依赖的问题解决上Bundler也让Rails开发人员更加Happy,同时Fx as Service的实现也是如此。

####5. Rails 3 Engine

Rails 早期版本中对大型项目的扩展不是件轻松的事,虽然Rails有着很好的项目结构,但如果项目超过一定的阀值,复杂度会急剧上升,导致维护成本大增。民间有很多的探讨,Rails 2.3中也引入了plugin,但直到Rails 3中加入了Engine,才让这一问题根本性的解决,Spree是一个很棒的例子,同时我本人也基于Engine写了一个示例,Phoenix Engine,用来做本次Session的示例代码。

####6. 架构服务

好的架构不会只是在架构本身,它会有好的配套工具, 像代码的自动生成,Automation的指导规范。

这个长的Session会在2012旧历年前完成,也算作是11年最后的任务。