原文鏈接：http://www.iteye.com/topic/1058510

用rails3做目前的這個網站項目，已經有半年多了。我們這個團隊應該算是比較早使用rails3做項目的，3.0正式版剛發布就開始嘗試了，在項目開發期間針對很多問題也做了一些探索。談不上經驗，更稱不上最佳實踐，只是分享出來，經學見易，道家見淫，有需要的朋友各取所需。小公司小項目，適用于初中級用戶，大牛們可一笑而過。

1、網站需求

財經資訊網站，向用戶提供財經金融資訊，發布和宣傳公司研發的各種金融產品，引導用戶注冊和購買產品。當前網站的內容來源是公司的資訊平臺和行情數據庫，通過http接口和oracle sql獲取數據并展現，可能在中短期會有用戶互動和用戶原創內容（UGC）的需求。

在可預期的未來，即2到3年內，預計流量將達到10-100萬PV/天。因此在進行設計時，以該流量作為本架構能夠承載的上限。如果網站真的有幸活到了幾百萬PV以上的流量，那肯定就不缺錢了，凡是錢能解決的問題，都不是什么大問題。

2、架構設計

根據預計流量，在可預期的時間階段，結合該項目的運營要求和預算成本，網站主要以高可用（HA）和有限的水平擴展性（scale out）為核心架構理念，采用分布式無共享架構（distributed share nothing architecture），使用rails默認的cookie_store機制來持有和處理session，消除了有可能成為性能瓶頸的集中式session的缺點。而且在架構設計時，使得系統負載盡量平均分配到每臺服務器上。

單臺服務器如同XX的承諾，永遠都是靠不住的。單臺服務器會死機、掉電、停轉、拔線，所以在架構中盡最大可能避免每個功能組的單點故障，做到在服務器集群中，任意一臺服務器失效，或幾臺不相關服務器同時失效，網站仍可正常運行。而且無單點故障的架構，服務器可隨時重啟，也有利于操作系統的內核升級和安全補丁等日常維護工作。經過這幾個月的連續使用，各種原因的幾次單點故障均沒有影響到網站正常服務。

在數據庫的使用上，考慮到傳統的關系型數據庫已不太適應當前互聯網應用的海量數據和高負載特點，因此mysql只起到關鍵數據存儲作用，利用事務性和成熟性，保證網站數據的完整和安全。然后加入非關系型數據庫redis和mongodb，作為數據冗余存儲和計算中心，承載絕大部分的高負載數據請求，可有效減小mysql的壓力。這樣就不必費心配置復雜難用的可擴展mysql集群，使用單臺mysql服務器即可承載較高的網站流量。而redis和mongodb天生就是為互聯網應用設計的，它們的集群配置和水平擴展相對更為簡單方便。聽說現在已經有團隊只使用mongodb來作為網站數據庫，向他們的前衛和勇敢，致以我們團隊深深的敬意。



2.1 軟硬件平臺
當前正在運行的硬件是6臺dell 2U二手服務器，總價大約在1.6萬，物美價廉，居家必備。目前使用良好。另外借公司發展東風，已有8臺全新dell刀片進入機房，正準備把全部系統遷移至新服務器上。

服務器操作系統使用ubuntu server 10.04.2 x64，正在測試11.04，如可用并有益，則有可能在新硬件上安裝使用。11.04官方支持到2012年12月份，對人類來說已經足夠。2012之后，所有服務器已不復存在。

2.2 高可用方案。核心組件采用keepalived，使用master-backup機制來實施主備服務器的實時切換。

2.3 負載均衡
根據網站流量和實際需求，使用nginx作為七層交換，把前端進來的用戶請求round-robin到后端的應用服務器。nginx支持容錯轉移，如果后端的某臺應用服務器失效，nginx可把該臺服務器暫時移出可用列表。

同時，由于負載均衡服務器位于整個網站系統的最前端，一旦失效則整個網站立刻癱瘓，所以其重要性無與倫比。為保證高可用，使用keepalived實現雙服務器的故障實時切換。

2.4 應用層。使用ree+passenger+nginx作為rails web服務器，passenger易于管理維護，而且和ree配合較好。所有應用服務器地位均等，每臺服務器均發布完整的項目代碼，不在功能上做分布式，以利于維護。

2.5 數據庫。使用2臺mysql，做master-master復制，配合keepalived實現高可用。

2.6 緩存系統
緩存系統分為一級緩存和二級緩存。一級緩存用于存儲數據量不大，但對速度要求高的緩存數據。二級緩存用于存儲對速度要求相對較低，但存儲量巨大的數據。

一級緩存使用內存數據庫redis，優點是速度快，并發高。用于存儲首頁緩存數據，保存股票行情數據，以及配合redis-store作為rails默認頁面緩存，等等。目前存儲數據約2800條，使用內存100M。

二級緩存使用文檔型數據庫mongodb，優點是查詢功能強大，支持海量存儲。用于存儲部分資訊內容，提高頁面響應速度。目前存儲數據約10萬條，數據文件大小為4G。

2.7 文件系統。使用glusterfs，以其自身的機制可實現雙機熱備和單臺服務器失效返回后文件的自動同步。用戶上傳的文件會自動地同時保存于2臺glusterfs服務器上。對應用程序來說，它們只是將文件保存于本地某個指定目錄，glusterfs對應用是透明的。而且任何一臺服務器單獨失效都不會對用戶產生可察覺的影響，失效的服務器返回后，glusterfs會計算2臺服務器所保存文件的差別，對改動過的文件進行同步。

2.8 異步和定時執行。使用resque作為基礎架構執行異步任務，以resque-scheduler執行定時任務。同樣，也以雙機互備來保證無丟失地產生和執行任務隊列。經過這幾個月的使用，除了解決了一些與其它系統交互時意外的隊列堵塞問題，目前看來resque還是值得信任的。

3、技術選型

在技術路線上，團隊擁有最大的自由度，因此我們可以按照自己的理念進行技術布局，而且可以大膽地使用最新的技術架構和解決方案，在完成公司開發任務的同時提高團隊技術水平，緊跟業界技術潮流。

3.1 網站使用rails 3開發，用到的主要組件和版本如下。未注明版本號的，為最新版本。

rails 3.0.7    # 基礎平臺
rake 0.9.0  gem 1.7.2  bundler 1.0.13    # 基礎工具
mysql2 0.2.7  ruby-oci8  activerecord-oracle_enhanced-adapter    # 數據庫驅動
nokigiri  yajl-ruby    # 解析器
authlogic  cancan    # 權限和驗證
ckeditor  paperclip  rmagick    # 編輯器和圖片
redis-store 1.0.0.beta5  mongoid 2.0.2    # nosql
resque  resque-scheduler  eventmachine    # 異步和定時任務
capistrano  capistrano-ext    # 代碼發布
open-flash-chart  formtastic  rspec    # 雜項

3.2 數據庫。使用mysql 5.1。因為5.5取消了在文件中配置replication，只能手動命令執行，個人感覺比較麻煩，不能做到服務器的無人值守。如果有同學找到了5.5自動配置的方案，還望賜教。謝謝。

3.3 redis 2.2.7。因為官網說redis原生的cluster方案，有可能將在2011年6月才出RC版，所以目前我們使用redis的master-slave機制，自己寫了一個監控腳本，配合keepalived，實現兩臺redis服務器之間的數據同步（replication）和容錯轉移（failover），以此來達成高可用。

3.4 mongodb 1.8.1。mongodb自身有原生的replset方案來實現數據同步和容錯轉移，因此在mongodb的層面直接使用該方案，配置2臺服務器即可實現高可用。

3.5 glusterfs 3.1.1。使用原生的雙機互備方案。

4、項目管理

第一期的開發從2010.11開始，到2011年元旦上線，大致為2個月的時間。上線后又經歷了大概1個月，基本穩定達到目前的狀態。純代碼約1萬行。開發人員4名。開發平臺有ubuntu desktop和windows 7，開發工具有aptana、netbeans、emacs等。對平臺和工具不做要求，在dos下能把活干好，也行。

4.1 源碼管理。使用git，采用所謂的“穩定分支模式”。有3個主要的分支：master、alpha、production。源碼合并的順序一般情況下是master -> alpha -> production。master用于日常開發，alpha用于發布測試版本，production用于發布生產環境的正式版本。如果有hotfix或者feature的需求，再另開其它臨時分支。每個開發人員對所有分支都擁有全部讀寫權限，使用公鑰認證的ssh訪問源碼庫。

4.2 發布管理。使用capistrano作為發布工具，結合capistrano-ext的multistage功能對多個不同的發布環境進行管理。并且結合了bundler的capistrano模塊對bundle gems進行發布時的自動安裝管理，做到了測試版本和正式版本的一鍵化發布。在99%的情況下不需要登錄服務器另外做配置或修改。

4.3 項目管理。使用redmine作為項目管理平臺，可以和git庫有機地結合起來。

4.4 測試。由于大部分功能都是調用其它平臺或訪問行情數據庫，邏輯比較簡單，因此rspec用得不太多，僅在支付接口等部分商業邏輯上使用。這是項目目前的一個缺陷，以后會著意加強測試方面的代碼量。

5、未來擴展

5.1 負載均衡的性能取決于接受請求的那臺服務器的性能，nginx的并發還是令人放心的。即使以后性能成為瓶頸了，可以用更好的服務器，或者換硬件交換機，直至F5。

5.2 應用層的擴展比較簡單，只需增加應用服務器節點即可。負載均衡的nginx可以設置權重以平衡負載。

5.3 mysql不太好擴展，但如前面所言，把負載盡量分散到nosql上，在百萬PV級別，mysql也就無需擴展了。實在要擴展，可以嘗試做讀寫分離等方案，或等待幾年后mysql搞定更漂亮的水平擴展方案。

5.4 redis和mongodb都比較方便水平擴展，多加服務器，做集群配置，即可分散流量提高負載。

5.5 glusterfs也具備水平擴展能力，再與nginx結合直接輸出文件，可承載較大流量。


項目基本架構就是如此，限于篇幅，很多地方都是一帶而過。下一步我準備寫如下內容，留作個人積累和公司文檔，包括但不限于：

1、keepalived的配置和使用，優缺點。
2、rails 3的優點，個性化設置，存在的缺點和臨時解決方案。
3、redis和mongodb的主從復制架構，相關問題的解決方案，各自的特點和基礎使用。
4、glusterfs的配置和使用。
5、resque系列組件的使用，異步和定時任務執行。
6、測試和產品多環境下的capistrano一鍵發布系統。

如果有朋友對此感興趣，我會選一些發上來。沒興趣的話我就據為己有了。


-------------------------------------------------------------
生活就像打牌，不是要抓一手好牌，而是要盡力打好一手爛牌。