對 很多創(chuàng)業(yè)公司而言，隨著業(yè)務(wù)的增長，網(wǎng)站的流量也會經(jīng)歷不同的階段。從十萬流量到一百萬流量，再從一百萬流量跨越到一千萬甚至上億的流量，網(wǎng)站的架構(gòu)需要 經(jīng)歷哪些變化？我們一起聽聽

58 同城的技術(shù)委員會執(zhí)行主席沈劍在 OneAPM 技術(shù)公開課上的回答（以下演講整理）：

本場演講我主要闡述一下，58同城從小流量、中等規(guī)模流量、大流量，到更大的流量過程中，架構(gòu)是怎么演進(jìn)的？遇到了哪些問題？以及如何解決這些問題？

好的架構(gòu)不是設(shè)計出來的而是演進(jìn)出來的

對很多創(chuàng)業(yè)公司而言，在初期的時候，我們很難在初期就預(yù)估到流量十倍以后、百倍以后、一千倍以后網(wǎng)站的架構(gòu)會變成什么樣。當(dāng)然，如果在最初的時期，就設(shè)計一個千萬級并發(fā)的流量架構(gòu)，那樣的話，成本是也是非常之高的，估計很難有公司會這樣做。

所以，我們主要來講架構(gòu)是如何進(jìn)行演化的。我們在每個階段，找到對應(yīng)該階段網(wǎng)站架構(gòu)所面臨的問題，然后在不斷解決這些問題的過程中，整個戰(zhàn)略的架構(gòu)就是在不斷的演進(jìn)了。

其實，在 58 同城建立之初，站點的流量非常小，可能也就是是十萬級別，這也就意味著，平均每秒鐘也就是幾次的訪問。此時網(wǎng)站架構(gòu)的特點：請求量是比較低，數(shù)據(jù)量比較小，代碼量也比較小。可能找?guī)讉€工程師，很容易就做一個這樣的站點，根本沒什么「架構(gòu)」可言。

其實，這也是很多創(chuàng)業(yè)公司初期面臨的問題，最開始58同城的站點架構(gòu)用一個詞概括就是「ALL IN ONE」，如下圖所示：

就 像一個單機系統(tǒng)，所有的東西都部署在一臺機器上，包括站點、數(shù)據(jù)庫、文件等等。而工程師每天的核心工作就是 CURD，前端傳過來一些數(shù)據(jù)，然后業(yè)務(wù)邏輯層拼裝成一些 CURD 訪問數(shù)據(jù)庫，數(shù)據(jù)庫返回數(shù)據(jù)，數(shù)據(jù)拼裝成頁面，最終返回到瀏覽器。相信很多創(chuàng)業(yè)團(tuán)隊，初期做的工作也是類似，每天寫代碼，寫 SQL、接口參數(shù)、訪問數(shù)據(jù)等等。

這里需要說明一個問題，大家都知道目前 58 同城使用的是 Windows、iis、SQL-Sever、C# 這條路?，F(xiàn)在很多創(chuàng)業(yè)公司可能就不會這么做。58 同城為什么當(dāng)時選擇了這條路？原因是公司招聘的第一個工程師和第二個工程師只會這個，所以只能走這條路。

如果可以重來？那么會選擇LAMP

很 多創(chuàng)業(yè)的同學(xué)可能會想，如果我們初期希望做一個產(chǎn)品的話，我們應(yīng)該使用什么架構(gòu)？ 如果讓我們重來，可能我們現(xiàn)在會選 LAMP，為什么？首先是無須編譯，而且快速發(fā)布功能強大，從前端到后端、數(shù)據(jù)庫訪問、業(yè)務(wù)邏輯處理等等全部可以搞定，最重要的是因為開源產(chǎn)品，是完全免 費的。如果使用 LAMP 搭建一個論壇，兩天的時間就很足夠了。所以，如果在創(chuàng)業(yè)初期，就盡量不要再使用 Windows 的技術(shù)體系了。

在 這個階段 58 同城面臨的主要問題是什么？其實就是招人。很多工程師可能都是再培訓(xùn)學(xué)校里培訓(xùn)了3月就過來上班，所以他們寫 CURD 的話很容易出錯。當(dāng)時，我們引進(jìn)了 DAO 和 ORM。雖然那些培訓(xùn)了幾個月的工程師可能寫CURD不是特別的擅長，但是他們寫面向?qū)ο蟮囊恍┏绦蛞肓?DAO 和 ORM，讓他們不再直接面對 CURD 語句，這樣就會相對容易一些。因為工程師比較擅長的是面向?qū)ο蟮臄?shù)據(jù)，不是 CURD，所以我們當(dāng)時引入了 ORM，總的來說，如果大家現(xiàn)在的項目處于一個初期孵化的階段，DAO 和 ORM 能夠極大的提高效率，而且可以降低出錯的概率。

中等規(guī)模：流量跨過十萬的階段，數(shù)據(jù)庫成為瓶頸

隨 著 58 同城的高速增長，我們很快跨越了十萬流量的階段。主要需求是什么？網(wǎng)站能夠正常訪問，當(dāng)然速度更快點就好了。而此時系統(tǒng)面臨問題包括：在流量的高峰期容易 宕機，因為大量的請求會壓到數(shù)據(jù)庫上，所以數(shù)據(jù)庫成為新的瓶頸，而且人多的時候，訪問速度會很慢。這時，我們的機器數(shù)量也從一臺變成了多臺?，F(xiàn)在的架構(gòu)就 采用了分布式，如下圖所示：

首 先，我們使用了一些非常常見的技術(shù)，一方面是動靜分離，動態(tài)的頁面通過 Web-Servre 訪問，靜態(tài)的像圖片等就單獨放到了一些服務(wù)器上。另外一點就是讀寫分離。其實，對 58 同城或者說絕大部分的站點而言，一般來說都是讀多寫少。對 58 同城來說，絕大部分用戶是訪問信息，只有很少的用戶過來發(fā)貼。那么如何擴展整個站點架構(gòu)的讀請求呢？常用的是主從同步，讀寫分離。我們原來只有一個數(shù)據(jù) 庫，現(xiàn)在使用多個不同的數(shù)據(jù)庫提供服務(wù)，這樣的話，就擴展了讀寫，很快就解決了中等規(guī)模下數(shù)據(jù)訪問的問題。

在這個階段，系統(tǒng)的主要矛盾就是「站點耦合+讀寫延時」，58 同城是如何進(jìn)行解耦，如何緩解延時呢？

對 58 同城而言，典型業(yè)務(wù)場景是主頁，發(fā)布信息有發(fā)布頁，信息聚合、標(biāo)題聚合有列表頁，點開一個標(biāo)題有詳細(xì)頁，而這些站點都是耦合在一個程序中的，或者說耦合在一個站點中的，當(dāng)我們有一個站點出現(xiàn)問題的時候，整個站點就會因為耦合一起出問題。

第 二個問題，大家都知道做數(shù)據(jù)庫讀請求和寫請求，分布在不同的數(shù)據(jù)庫上，這個時候如果再讀取可能讀到的是舊數(shù)據(jù)，因為讀寫有一個延時。如果有用戶發(fā)帖子，馬 上去找的話肯定找不到，很可能帶來的后果就是陸續(xù)在發(fā)布兩條信息，這就是一個很大的問題。尤其是在請求量越來越大的時候，這個問題就更加突出。

在 解決這些問題是，最先想到的是針對原來站點的核心業(yè)務(wù)做切分，然后工程師根據(jù)自己的站點和業(yè)務(wù)場景進(jìn)行細(xì)分。首先，業(yè)務(wù)拆分是 58 同城最先嘗試的優(yōu)化。我們將業(yè)務(wù)垂直拆分成了首頁和發(fā)布頁。另外，在數(shù)據(jù)庫層面，我們也隨之進(jìn)行了拆分，將大數(shù)據(jù)量拆分成一個個小的數(shù)據(jù)量。這樣，讀寫延 時就馬上得到了緩解。尤其是在代碼拆分成了不同的層面之后，站點耦合也得到了緩解，數(shù)據(jù)量加載速度也提升了很多。

當(dāng) 時，還使用了一些技術(shù)，前面也提到了對動態(tài)資源和靜態(tài)資源進(jìn)行拆分。其中，我們對靜態(tài)資源使用了 CDN 服務(wù)，便于數(shù)據(jù)緩存和就近訪問，訪問速度得到很明顯的提升。除此之外，我們還使用了 MVC 模式，擅長前端的去做展示層，擅長協(xié)作邏輯的工程師就做 Contorller，擅長數(shù)據(jù)的人就負(fù)責(zé)數(shù)據(jù)，效率就會逐步的提高，最后就是負(fù)載均衡技術(shù)。

大流量：將整個 Windows 技術(shù)體系轉(zhuǎn)向了 Java 體系

流 量越來越大，當(dāng)流量超過一千多萬時，58 同城面對最大的問題就是性能和成本。此前，我提到58同城最初的技術(shù)選型是 Windows，應(yīng)該是在 2006 年的時候，整個網(wǎng)站的性能變得非常之低。即使進(jìn)行了業(yè)務(wù)拆分和一些優(yōu)化，但是依然解決不了這個問題，所以我們當(dāng)時做了一個非常艱難的決定，就是轉(zhuǎn)型：將整 個 Windows 技術(shù)體系轉(zhuǎn)向了 Java 體系，這涵蓋了操作系統(tǒng)、數(shù)據(jù)庫等多個維度。

其實，現(xiàn)在很多大的互聯(lián)網(wǎng)公司在流量從小到大的過程中都經(jīng)歷過轉(zhuǎn)型，包括京東、淘寶等等。對技術(shù)的要求越來越高，任何一個站點都不能掛，對站點的可用性要求也是越來越高。

就 在這個時候，58 同城業(yè)務(wù)量也出現(xiàn)一個爆發(fā)期。于是我們招聘了很多的工程師，大家一起寫越來越多的站點，但是發(fā)現(xiàn)效率很低，經(jīng)常做一些重復(fù)性的工作比如參數(shù)解析等等。同 時，業(yè)務(wù)之間相互依賴，無論是分類的子系統(tǒng)還是信息的子系統(tǒng)，二手車業(yè)務(wù)、房產(chǎn)業(yè)務(wù)都要訪問用戶和信息等一些底層數(shù)據(jù)，代碼之間頻繁的溝通，效率也不可能 很高。

問題隨之而來，站點數(shù)越來越多，數(shù)據(jù)量越來越大，機器數(shù)從最開始的幾臺上升到幾百臺的級別。那么如何提供整個架構(gòu)的可用性呢？首先，在上層我們進(jìn)行了一些改進(jìn)和優(yōu)化，再做進(jìn)一步的垂直拆分，同時我們引入了 Cache，如下圖所示：

在 架構(gòu)的改進(jìn)上，我們構(gòu)建了一個相對獨立的服務(wù)層，這個服務(wù)層做的每個業(yè)務(wù)線都會寫對應(yīng)的代碼。如果用戶發(fā)出請求，就由這個服務(wù)層統(tǒng)一來管理，所有的上游業(yè) 務(wù)線就像調(diào)用本地函數(shù)一樣，通過 IDC 的框架來調(diào)用這個服務(wù)。整個用戶登錄先訪問 Cache，如果 Cache 變動了就直接返回，如果 Cache 不變動，就會訪問數(shù)據(jù)庫，這樣把數(shù)據(jù)庫的數(shù)據(jù)拿到本地再放回 Cache，再打回上一輪。如此一來，業(yè)務(wù)邏輯全部封裝在這個服務(wù)的上游管理，該業(yè)務(wù)邏輯只有服務(wù)層能夠編寫代碼，然后由這個服務(wù)層集中管理、集中優(yōu)化， 這樣就提高了效率。

除 此之外，為了保證站點的高可用，我們主要使用了反向代理技術(shù)。因為用戶而言，他主要為了使用 58 同城的服務(wù)，他不關(guān)注訪問是58同城或者有十臺首頁的服務(wù)器。58 同城通過反向代理技術(shù)，通過 DNS 群，通過 LVS 技術(shù)，來保證接入層的高可用性，同時還保證了服務(wù)層、站點層、數(shù)據(jù)層的高可用。另外，為了保證高可用我們經(jīng)常使用冗余的方法，無論是站點服務(wù)和數(shù)據(jù)服務(wù)都 可以使用這種方式進(jìn)行解決，一個站點不可用，我們就換一個站點，一個數(shù)據(jù)庫不夠用，我們就多加幾個。當(dāng)然，數(shù)據(jù)冗余也會帶來一些副作用，如果數(shù)據(jù)量更新的 話，那就需要將所有的“冗余”都要進(jìn)行更新。

58同城也做了一個圖片存儲系統(tǒng)，開始都是存儲在操作系統(tǒng)之上，隨著新增站點、新增服務(wù)，壓力就變得越來越大。于是，58 同城就自建了站點框架和服務(wù)框架，現(xiàn)在這兩個框架也已經(jīng)開源（如何降低站點開發(fā)成本？https://github.com/58code/Argo 如何降低服務(wù)開發(fā)成本？ https://github.com/58code/Gaea ）只需要修改一些基本的配置就可以使用了。

當(dāng)架構(gòu)變成「蜘蛛網(wǎng)」，人肉已很難搞定！

隨著用戶量、數(shù)據(jù)量并發(fā)量進(jìn)一步的增長，58同城也拓展了很多的新業(yè)務(wù)，那么對產(chǎn)品迭代速度要求就非常高，整體的架構(gòu)對自動化的要求越來越高。

為 了支撐業(yè)務(wù)的發(fā)展，技術(shù)團(tuán)隊對架構(gòu)做了進(jìn)一步的解耦，另外就是引入了配置中心，如果要訪問任何一個服務(wù)，不會直接在本地的配置中留下一個服務(wù)，配置中心告 訴這個服務(wù)的特點，如果擴展的話，配置中心自動下達(dá)消息，如果有機器要下線的話，配置中心會反向通過發(fā)郵件的方式進(jìn)行通知。

而柔性服務(wù)是指當(dāng)流量增加的時候，自動的新增服務(wù)?？梢钥吹竭M(jìn)一步解耦之后，有垂直業(yè)務(wù)、無線業(yè)務(wù)、集成業(yè)務(wù)等等，這些子系統(tǒng)之間都是通過配置中心相應(yīng)之間發(fā)生關(guān)系的。

另 一點就是關(guān)于數(shù)據(jù)庫，當(dāng)某一點成為一個業(yè)務(wù)線重點的時候，我們就會集中解決這個點的問題。最初期的時候每個業(yè)務(wù)線都要訪問數(shù)據(jù)庫，訪問緩存，訪問用戶數(shù) 據(jù)，于是我們把代碼集中的放到了服務(wù)層?，F(xiàn)在數(shù)據(jù)量越來越大，大家都要做數(shù)據(jù)切分，每個業(yè)務(wù)線都做切分，這個時候58同城的每個頁面都面對這樣的痛點，于 是把這個痛點拿到集中的層面來解決。

最后一點就是效率矛盾，此時很多問題，靠「人肉」已經(jīng)很難進(jìn)行搞定了。這就需要自動化，包括回歸、測試、運維、監(jiān)控等等都要回歸到自動化。

這 里需要補充一點，就是在產(chǎn)品層面，我們引入了智能化，比如說智能推薦，主動推薦一些相關(guān)的話題；智能廣告，通過一些智能的策略，讓用戶對廣告的點擊更多， 增加對 58 同城的收錄；智能搜索，在搜索的過程中加入一些搜索的策略，可以提高搜索的權(quán)重，也可以增加 58 同城的 PV。當(dāng)然，所有的自動化的產(chǎn)品背后都是由技術(shù)在驅(qū)動。

未來的挑戰(zhàn)

現(xiàn) 在，58同城的流量已經(jīng)突破的 10 億的量級，那么架構(gòu)上未來面臨哪些挑戰(zhàn)呢？一方面是無線化、移動化。另一方面就是需求的變化，我們必須加快迭代一些東西。如果擁有10億的流量，卻跑在一 億的架構(gòu)上肯定是不行的。未來，我們會使用更多的并行計算、實時計算，如果能做到實時推薦，效果肯定非常好，這也是我們的挑戰(zhàn)。最后一點，58同城現(xiàn)在的 服務(wù)器大概在3000臺左右，未來將拓展到 10000 萬，這就是運維的挑戰(zhàn)了。

總結(jié)：

最 后做一個小的總結(jié)，網(wǎng)站在不同的階段遇到的問題不一樣，而解決這些問題使用的技術(shù)也不一樣，流量小的時候，我們主要目的是提高開發(fā)效率，在早期要引入 ORM，DAO 這些技術(shù)。隨著流量變大，使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC 等方式不斷提升網(wǎng)站的穩(wěn)定性。面對更大的流量時，通過垂直拆分、服務(wù)化、反向代理、開發(fā)框架（站點/服務(wù)）等等，不斷提升高可用。在面對上億級的更大流量 時，通過中心化、柔性服務(wù)、消息總線、自動化（回歸，測試，運維，監(jiān)控）來迎接新的挑戰(zhàn)。未來的就是繼續(xù)實現(xiàn) 移動化，大數(shù)據(jù)實時計算，平臺化…

【編輯推薦】