大型網站架構演進的五大階段盤點
一個創業公司起步時很可能就兩臺機器,一臺Web 伺服器、一臺資料庫伺服器,在一個應用系統中整合了所有功能模組,但隨著業務的發展、流量的增長,單應用遠遠不能滿足業務需求。
下面我們一同來聊聊網站架構發展所經歷的幾次主要演進,包括:從PHP 到Java 的改造、分散式改造、無線化改造、中臺的改造、國際化改造。
階段一 從PHP 到Java
很多網站早期都是基於Linux+Apache+MySQL+PHP 架構的網站,從當時來看,這種非常流行的個人網站架構的確也非常匹配當時的發展狀態。PHP 語言的特性是快速釋出,從頁面渲染到資料庫訪問,均可以在一個頁面裡全部搞定。
即使放到今天,這種架構仍然還有很多人在用,它的優點就是非常簡單高效,但缺點也非常明顯:擴充套件性和分散式不好,不適合企業級的、複雜業務邏輯的大規模協同開發。
隨著網站的發展,大家覺得應該將PHP 切換到Java。為什麼要切換到Java 語言呢?一般來說,企業選擇開發語言會有如下考慮。
(1)語言本身的特性。每種語言開發出來都有它的特性和所適合的場景,像Python、PHP 這類指令碼語言非常適合快速簡單的開發方式,而Java 則比較適合構建複雜業務邏輯的企業級開發,但是開發效率會比PHP 要差一點。
(2)程式設計師隊伍。企業選擇何種開發語言,還要看市場上的人才隊伍是不是足夠,是不是有很高層次的人才。是否有高層次的人才,取決於當前的行業老大是不是也在用這種語言,比如當前的頂級網際網路公司如果在用Java,那麼自然這些公司的Java人才比較多,這樣,他們的經驗可以被快速複製到其他公司中。
(3)語言所對應的工具生態是否完善。一個語言是否有生命力,要看這個語言對應的生態工具是否完善,它的社群是否活躍。因為我們要用到各種工具,而我們也不可能自己去寫每種工具,因此,是否能方便地利用開源工具,快速提升開發效率也是非常關鍵的。像現在很多大公司開源了很多Java 的中介軟體產品,這些中介軟體可以直接拿來使用,就不需要再重新開發了。
綜合以上因素,電商網站選擇Java 語言作為主要的系統開發語言是非常合適的。
從PHP 切換到Java 後,整個網站採用WebX+EJB+iBatis+JBoss+Oracle(後面又將EJB 改成Spring)的架構,但是隨著業務量的不斷增大,儲存層的瓶頸暴露出來。
為了解決儲存問題,就逐漸用上了非常昂貴的IBM 小型機、Oracle 的資料庫以及EMC的高階儲存(IOE);並對資料庫做了分庫的拆分,分散式快取(Tair)也隨之誕生,分散式檔案系統TFS 開始出現,CDN 也慢慢建立了。
階段二 分散式改造
所謂分散式改造,就是儘量讓系統無狀態化,或者讓有狀態的資訊封裝在一定範圍內,以免限制應用的橫向擴充套件。簡單來說,就是即便某個應用的少數伺服器“宕”掉,也不會影響整體業務的穩定性。
要實現應用的分散式改造必須先解決以下幾個問題。
(1)把應用微服務化:即將大量粗粒度的應用邏輯拆小,做服務化改造。
(2)必須先建立分散式服務框架。必須具備分散式RPC 框架、非同步訊息系統、分散式資料層、分散式檔案系統、服務的發現、註冊和管理。
(3)必須要解決分散式Session 問題。
為了做業務的服務化改造,我們大量拆分了當時的業務系統,形成了商品中心、交易中心、使用者中心、店鋪中心。這些服務作為底層服務供上層的前臺系統呼叫,此時的系統架構變成了下面的形式。
現在來看,系統的分散式改造為網站接下來5 年的發展奠定了很好的基礎,整個網站的擴充套件性非常好。幾乎每個初創企業都必須經歷一次分散式化的改造,才能為企業的長期發展奠定基礎。筆者前面提及的幾個重要的中介軟體產品和關鍵的分散式Session 等技術在《深入分析Java Web 技術內幕(修訂版)》一書中有詳細的介紹,感興趣的讀者可以自行去學習瞭解。
階段三 無線化改造
到了2013 年,無線技術已經非常火爆了。在此之前,無線的業務總是跟著PC 走,基本上是PC 做好後無線再複製一份,而且無線和PC 還不是同一個前臺系統,導致一個功能要做兩遍,並且無線部門的開發人員本來就不多。這些給業務的發展帶來很多問題。因此2013 年底,啟動了All in 無線專案,目標就是用一套系統、一套架構快速支撐多端的個性化,並在服務端做了很多模組化和元件化的改造。
隨著無線技術的發展,我們也開始嘗試一些新技術,最具代表性的就是Node。
Node 在業界很火,前端同學非常推崇,而且它也大幅提升了前端的開發效率和體驗。
目前大家也多方嘗試使用Node 技術,並且用在一些業務線上。但是,從今天來看,Node 並沒有達到我們想象中的發展前景。這其中有多種原因,本書的後續章節會專門介紹網站的無線化改造實踐,也將分享Node 在實際使用中的一些思考。
經過無線化改造的應用系統架構如圖。
階段四 中臺改造
中臺這個概念早期是由美軍的作戰體系演化而來,技術上的“中臺”主要是指學習這種高效、靈活和強大的指揮作戰體系。電商經過十幾年的發展,組織已經龐大而複雜,業務不斷細化拆分,也導致野蠻發展的系統越來越不可維護,開發和改造效率極低,也有很多新業務不得不重複造輪子,所以中臺的目標是為了解決效率問題,同時降低創新成本。
階段五 國際化
國際化一般會有兩種思路:一種是一套原始程式碼部署到多個地方,各地的系統基本沒有什麼關聯、保持相互獨立,每個地方再根據本地實際情況做一些個性化的定製。一般來說,會精簡原始程式碼,減少不必要的依賴。這種思路在一些跨國公司用得比較多,但是這個對技術要求比較低。
另一種思路就是我們所說的國際化,它主要是解決如何將一套系統部署到多地的問題。一般國際化有兩個發展階段:第一個階段是在國內實現了交易的單元化;第二個階段是實現了中美的跨國部署。
國際化的本質仍然是要解決以下的通用問題:多語言問題、多時區問題、資料路由問題、全球資料的同步與複製問題。
本文摘自《大型網站技術架構演進與效能優化》一書前言,作者許令波 ,電子工業出版社6月出版。
羅馬不是一天建成的,能夠支撐億級交易量的大型網站也不是一蹴而就的。作者以一名親歷者的身份,闡述了一個大型網站在數年時間內從雛形成長為巨人時所經歷的技術選型思考、方案選擇,以及遇到的眾多效能瓶頸和優化方案。
本書要表達的內容並不是簡單羅列所做過的事情,而主要是幫助讀者瞭解當網站遇到類似問題時,應如何思考不同的解決思路、為什麼要這樣做、如何做出最終的方案選擇……
相關文章
- 大型網站技術架構的演進網站架構
- 大型網站的技術架構演進過程網站架構
- 大型網站圖片伺服器架構的演進網站伺服器架構
- 大型網站架構體系的演變網站架構
- MySQL在大型網站的應用架構演變MySql網站應用架構
- 大型網站技術架構(二)--大型網站架構演化網站架構
- 大型網站技術架構(一)--大型網站架構演化網站架構
- 大型網站應用中MySQL的架構演變史網站MySql架構
- 大型網站架構網站架構
- 大型網站架構演變和知識體系網站架構
- 大型網站架構演化網站架構
- 大型網站架構演變過程、大併發伺服器架構網站架構伺服器
- 大型網站架構系列:電商網站架構案例(1)網站架構
- 大型網站架構系列:電商網站架構案例(2)網站架構
- 大型網站架構系列:電商網站架構案例(3)網站架構
- [轉載]大型網站應用中 MySQL 的架構演變史網站MySql架構
- 大型網站技術架構(八)--網站的安全架構網站架構
- 網站架構及架構演變網站架構
- B站公網架構實踐及演進架構
- 大型網站技術架構——2. 網站架構模式網站架構模式
- 大型網站技術架構(五)--網站高可用架構網站架構
- 漫談大型網站架構網站架構
- 大型網站技術架構(四)--網站的高效能架構網站架構
- 大型網站技術架構(六)--網站的伸縮性架構網站架構
- 淺析大型網站的架構(轉)網站架構
- 大型網站技術架構(三)--架構模式網站架構模式
- 大型網站技術架構(二)--架構模式網站架構模式
- 大型網站架構模式筆記網站架構模式筆記
- 大型網站架構之我見網站架構
- 大型網站架構演化歷程網站架構
- 大型網站--負載均衡架構網站負載架構
- 大型網站系統架構演化網站架構
- 淺談大型分散式Web系統的架構演進分散式Web架構
- 大型網站技術架構(七)--網站的可擴充套件性架構網站架構套件
- 大型網際網路系統架構演進 BATJ其實無需神化架構BAT
- 大型網站技術架構(四)--核心架構要素網站架構
- 架構的演進架構
- [轉載]淺析大型網站的架構網站架構