今天看了一篇"程式設計師"上的文章:"大眾點評網的架構與實踐",因為裡面談的架構演變之路中所經歷的痛點對我的工作經驗來說感同身受,所以覺得文章裡的一些解決方案對我還是很有啟發.文中的幾點還是值得我們學習,實踐下的.
文中提到的V1,V2階段,也就公司起步階段,其實這個時間還談不上技術架構,此時更關注的是搶佔市場,產品快速麵世.這也是創業公司要注意的,在一開始的時候不要總想著用什麼牛逼的技術和架構,更應該快速推出產品,初探市場反映以及快速變化.
V3架構中主要引入瞭如下技術: 快取(Memcached),分散式檔案系統,搜尋引擎(Lucene),NoSql資料庫(MongoDB). 引入的方案其實也是順其自然的,就像文中所說,當訪問量大起來了後,針對整個系統中的瓶頸,哪裡痛就治哪裡.快取用來減輕db訪問壓力,分散式檔案系統解決海量圖片儲存,Lucene提供資訊檢索能力(複雜查詢無論從功能和效能上,資料庫的全文檢索都是滿足不了的),NoSql資料庫用來儲存非結構化資料.基本有了這些架構方案後,一般的不是很複雜的應用都可以頂住.
在V3架構體系中我們都是從系統的效能瓶頸上做了相應的措施方案,優化訪問速度上面做文章.但是隨著業務的增長,相應的支撐系統也會越來越複雜,通常我們的系統不是一個專案就全部包括了,而是分成為很多小系統,從業務上分為不同的產品線,從功能上分為基礎服務和應用服務,等等. 所以V4架構體系就是把大服務分成各個小服務去分別開發,管理. 比如使用者管理系統,積分系統,結算系統,等等. 這樣問題也就出來, 每個系統並不是孤立存在的, 它們要相互呼叫和依賴.如果其中的一個服務出現問題,往往會導致整個站點不可用.而且這種服務與服務之間的依賴的複雜度,會隨著系統數量的遞增而呈指數增長.相信每個開發員應都經歷過種痛苦. 還有就是系統的增長與依賴,會大大增加運維部署的複雜度.
所以在V5架構體系中要解決和探索的問題依舊是"服務治理"的問題.文中提到用"泳道架構與容錯隔離"方案,來提供系統的高可用性. 但是我個人覺得這種方案實施起來不是很容易,因為各泳道中的服務如果全部clone一套,對於資源的投入和部署升級的成本都還是挺大的. 在服務治理上, 可以借鑑阿里的經驗,比如Dubbo,畢竟也是經歷了億級別呼叫的產品. 在服務註冊, 發現, 負載上都是很好的實現.
在V5架構探索中,下面談的幾個方案如果利用起來,可以解決實際中很多問題:
- PaaS平臺: 定製化容器,主要用於對基礎元件的統一更新,配置載入管理. 使用業務開發人員只關注業務實現技術,對基礎元件,公用框架透明.
- Cat統一監控平臺: 對於分散式系統來說, 檢視日誌時,因為其整個行為操作分散在各個系統中,這對追蹤整個事務是很不方便的.往往是根據某個標識(如使用者id)在各個日誌系統中人工連續起來.而Cat系統可以用統一的messageID記錄日誌,通過系統進行整合,形成各個維度的日誌報表.
- code平臺,使用github,對gitlib二次開發,可以pull request進行程式碼審查.
- 還有一些其它方面的探索和展望,這裡就不再說了.因為每個公司發展一定階段,都會在經歷了各種痛苦的事情後會總結各種方案和開發輔助工具,幫助研發,運維人員去工作.