1. 程式人生 > >58同城架構師談:億級流量架構演進

58同城架構師談:億級流量架構演進

核心內容:58同城流量從小到大過程中

58同城億級流量架構演進

  • 架構是如何演進的?
  • 遇到了哪些問題?
  • 以及如何解決這些問題?

核心觀點:好的架構不是設計出來的,而是進化而來的。

如何演進:站點流量在不同階段,會遇到不同的問題,找到對應階段站點架構所面臨的主要問題,在不斷解決這些問題的過程中,整個系統的架構就不斷的演進了。

如何演進,簡言之:找到主要矛盾,並解決主要矛盾

建站之初

建站之初,站點流量非常小,可能低於十萬級別。這意味著,平均每秒鐘也就幾次訪問。請求量比較低,資料量比較小,程式碼量也比較小,幾個工程師,很短的時間搭起這樣的系統,甚至沒有考慮“架構”的問題。

和許多創業公司初期一樣,最初58同城的站點架構特點是“ALL-IN-ONE”

58同城億級流量架構演進

這是一個單機系統,所有的站點、資料庫、檔案都部署在一臺伺服器上。工程師每天的核心工作是CURD,瀏覽器端傳過來一些資料,解析GET/POST/COOKIE中傳過來的資料,拼裝成一些CURD的sql語句訪問資料庫,資料庫返回資料,拼裝成頁面,返回瀏覽器。相信很多創業團隊的工程師,初期做的也是類似的工作。

58同城最初選擇的是微軟技術體系這條路:Windows、iis、SQL-Sever、C#

如果重新再來,我們可能會選擇LAMP體系。

為什麼選擇LAMP?

LAMP無須編譯,釋出快速,功能強大,社群活躍,從前端+後端+資料庫訪問+業務邏輯處理全部可以搞定,並且開源免費,公司做大了也不會有人上門收錢(不少公司吃過虧)。現在大家如果再創業,強烈建議使用LAMP。

58同城億級流量架構演進

初創階段,工程師面臨的主要問題:寫CURD的sql語句很容易出錯。

我們在這個階段引進DAO和ORM,讓工程師們不再直接面對CURD的sql語句,而是面對他們比較擅長的面向物件開發,極大的提高了編碼效率,降低了出錯率。

流量增加,資料庫成為瓶頸

隨著流量越來越大,老闆不只要求“有一個可以看見的站點”,他希望網站能夠正常訪問,當然速度快點就更好了。

而此時系統面臨問題是:流量的高峰期容易宕機,大量的請求會壓到資料庫上,資料庫成為新的瓶頸,人多並行訪問時站點非常卡。這時,我們的機器數量也從一臺變成了多臺,我們的系統成了所謂的(偽)“分散式架構”:

58同城億級流量架構演進

我們使用了一些常見優化手段

  • 動靜分離,動態的頁面通過Web-Server訪問,靜態的檔案例如圖片就放到單獨的檔案伺服器上
  • 讀寫分離,將落到資料庫上的讀寫請求分派到不同的資料庫伺服器上

網際網路絕大部分的業務場景,都是讀多寫少。對58同城來說,絕大部分使用者的需求是訪問資訊,搜尋資訊,只有少數的使用者發貼。此時讀取效能容易成為瓶頸,那麼如何擴充套件整個站點架構的讀效能呢?常用的方法是主從同步,增加從庫。我們原來只有一個讀資料庫,現在有多個讀資料庫,就提高了讀效能。

在這個階段,系統的主要矛盾為“站點耦合+讀寫延時”,58同城是如何解決這兩個問題的呢?

第一個問題是站點耦合。對58同城而言,典型業務場景是:類別聚合的主頁,釋出資訊的釋出頁,資訊聚合的列表頁,帖子內容的詳細頁,原來這些系統都耦合在一個站點中,出現問題的時候,整個系統都會受到影響。

第二個問題是讀寫延時。資料庫做了主從同步和讀寫分離之後,讀寫庫之間資料的同步有一個延時,資料庫資料量越大,從庫越多時,延時越明顯。對應到業務,有使用者發帖子,馬上去搜索可能搜尋不到(著急的使用者會再次釋出相同的帖子)。

58同城億級流量架構演進

要解決耦合的問題,最先想到的是針對核心業務做切分,工程師根據業務切分對系統也進行切分:我們將業務垂直拆分成了首頁、釋出頁、列表頁和詳情頁。

另外,我們在資料庫層面也進行了垂直拆分,將單庫資料量降下來,讓讀寫延時得到緩解。

58同城億級流量架構演進

同時,還使用了這些技術來優化系統和提高研發效率

  • 對動態資源和靜態資源進行拆分。對靜態資源我們使用了CDN服務,使用者就近訪問,靜態資源的訪問速度得到很明顯的提升;
  • 除此之外,我們還使用了MVC模式,擅長前端的工程師去做展示層,擅長業務邏輯的工程師就做控制層,擅長資料的工程師就做資料層,專人專用,研發效率和質量又進一步提高。

全面轉型開源技術體系

流量越來越大,當流量達到百萬甚至千萬時,站點面臨一個很大的問題就是效能和成本的折衷。上文提到58同城最初的技術選型是Windows,我們在這個階段做了一次脫胎換骨的技術轉型,全面轉向開源技術:

  1. 作業系統轉型Linux
  2. 資料庫轉型Mysql
  3. web伺服器轉型Tomcat
  4. 開發語言轉向了Java

其實,很多網際網路公司在流量從小到大的過程中都經歷過類似的轉型,例如京東和淘寶。

隨著使用者量的增加,對站點可用性要求也越來越高,機器數也從最開始的幾臺上升到幾百臺。那麼如何提供保證整個系統的可用性呢?首先,我們在業務層做了進一步的垂直拆分,同時引入了Cache,如下圖所示:

58同城億級流量架構演進

在架構上,我們抽象了一個相對獨立的服務層,所有資料的訪問都通過這個服務層統一來管理,上游業務線就像呼叫本地函式一樣,通過RPC的框架來呼叫這個服務獲取資料,服務層對上游遮蔽底層資料庫與快取的複雜性。

58同城億級流量架構演進

除此之外,為了保證站點的高可用,我們使用了反向代理。

什麼是代理?代理就是代表使用者訪問xxoo站點。

什麼是反向代理?反向代理代表的是58網站,使用者不用關注訪問是58同城的哪臺伺服器,由反向代理來代表58同城。58同城通過反向代理,DNS輪詢, LVS等技術,來保證接入層的高可用性。

另外,為了保證服務層和資料層的高可用,我們採用了冗餘的方法,單點服務不可用,我們就冗餘服務,單點資料不可用,我們就冗餘資料。

這個階段58同城進入了一個業務高速爆發期,短期內衍生出非常多的業務站點和服務。新增站點、新增服務每次都會做一些重複的事情,例如執行緒模型,訊息佇列,引數解析等等,於是,58同城就研發了自己的站點框架和服務框架,現在這兩個框架也都已經開源:

  • 站點框架Argo:https://github.com/58code/Argo
  • 服務框架Gaea:https://github.com/58code/Gaea

這個階段,為了進一步解耦系統,我們引入了配置中心、柔性服務和訊息匯流排。

58同城億級流量架構演進

引入配置中心,業務要訪問任何一個服務,不需要在本地的配置檔案中配置服務的ip list,而只需要訪問配置中心。這種方式的擴充套件性非常好,如果有機器要下線,配置中心會反向通知上游訂閱方,而不需要更新本地配置檔案。

柔性服務是指當流量增加的時候,自動的擴充套件服務和站點。

訊息匯流排也是一種解耦上下游“呼叫”關係常見的技術手段。

機器越來越多,此時很多系統層面的問題,靠“人肉”已經很難搞定,於是自動化變得越來越重要:自動化迴歸、自動化測試、自動化運維、自動化監控等等等等。

最後補充一點,這個階段我們引入了不少智慧化產品,比如智慧推薦,主動推薦一些相關的資料,以增加58同城的PV;智慧廣告,通過一些智慧的策略,讓使用者對廣告的點選更多,增加同城的收入;智慧搜尋,在搜尋的過程中加入一些智慧的策略,提高使用者的點選率,以增加58同城的PV。這些智慧化產品的背後都由技術驅動。

進一步的挑戰

現在,58同城的流量已經達到10億的量級,架構上我們規劃做一些什麼樣的事情呢,幾個方向:

  1. 業務服務化
  2. 多架構模式
  3. 平臺化

58同城億級流量架構演進

小結

網站在不同的階段遇到的問題不一樣,而解決這些問題使用的技術也不一樣:

  1. 流量小的時候,我們要提高開發效率,可以在早期要引入ORM,DAO
  2. 流量變大,可以使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC等方式不斷提升網站的效能和研發效率
  3. 面對更大的流量時,通過垂直拆分、服務化、反向代理、開發框架(站點/服務)等等手段,可以不斷提升高可用(研發效率)
  4. 在面對上億級的流量時,通過配置中心、柔性服務、訊息匯流排、自動化(迴歸,測試,運維,監控)來迎接新的挑戰

那如何學習才能快速入門並精通呢?

當真正開始學習的時候難免不知道從哪入手,導致效率低下影響繼續學習的信心。

但最重要的是不知道哪些技術需要重點掌握,學習時頻繁踩坑,最終浪費大量時間,所以有一套實用的視訊課程用來跟著學習是非常有必要的。

為了讓學習變得輕鬆、高效,今天給大家免費分享一套阿里的Java架構師傳授的一套教學資源。幫助大家在成為架構師的道路上披荊斬棘。

這套視訊課程,詳細講解了像(Spring,MyBatis,Netty原始碼分析,高併發、高效能、分散式、微服務架構的原理,JVM效能優化、分散式架構)等這些成為架構師必備的內容!加群566290106可以免費獲取這些錄影,裡面還有些分散式,微服務,效能優化,Spring,MyBatis的等原始碼知識點的錄影視訊。

而且還把框架需要用到的各種程式進行了打包,根據基礎視訊可以讓你輕鬆搭建分散式框架環境,像在企業生產環境一樣進