摘要：所以，我們主要來講架構是如何進行演化的。此前，我提到同城最初的技術選型是，應該是在年的時候，整個網站的性能變得非常之低。對技術的要求越來越高，任何一個站點都不能掛，對站點的可用性要求也是越來越高。

【編者按】對很多創業公司而言，隨著業務的增長，網站的流量也會經歷不同的階段。從十萬流量到一百萬流量，再從一百萬流量跨越到一千萬甚至上億的流量，網站的架構需要經歷哪些變化？我們一起聽聽 58 同城的技術委員會執行主席沈劍在 OneAPM 技術公開課上的回答（以下演講整理）：

首先，非常感謝 OneAPM 技術公開課舉辦的這次活動。本場演講我主要闡述一下，58 同城從小流量、中等規模流量、大流量，到更大的流量過程中，架構是怎么演進的？遇到了哪些問題？以及如何解決這些問題？

好的架構不是設計出來的而是演進出來的

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

所以，我們主要來講架構是如何進行演化的。我們在每個階段，找到對應該階段網站架構所面臨的問題，然后在不斷解決這些問題的過程中，整個戰略的架構就是在不斷的演進了。

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

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

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

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

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

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

在這個階段 58 同城面臨的主要問題是什么？其實就是招人。很多工程師可能都是再培訓學校里培訓了3月就過來上班，所以他們寫 CURD 的話很容易出錯。當時，我們引進了 DAO 和 ORM。雖然那些培訓了幾個月的工程師可能寫CURD不是特別的擅長，但是他們寫面向對象的一些程序引入了 DAO 和 ORM，讓他們不再直接面對 CURD 語句，這樣就會相對容易一些。因為工程師比較擅長的是面向對象的數據，不是 CURD，所以我們當時引入了 ORM，總的來說，如果大家現在的項目處于一個初期孵化的階段，DAO 和 ORM 能夠極大的提高效率，而且可以降低出錯的概率。

中等規模：流量跨過十萬的階段，數據庫成為瓶頸

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

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

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

對 58 同城而言，典型業務場景是主頁，發布信息有發布頁，信息聚合、標題聚合有列表頁，點開一個標題有詳細頁，而這些站點都是耦合在一個程序中的，或者說耦合在一個站點中的，當我們有一個站點出現問題的時候，整個站點就會因為耦合一起出問題。

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

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

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

大流量：將整個 Windows 技術體系轉向了 Java 體系

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

其實，現在很多大的互聯網公司在流量從小到大的過程中都經歷過轉型，包括京東、淘寶等等。對技術的要求越來越高，任何一個站點都不能掛，對站點的可用性要求也是越來越高。

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

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

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

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

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

當架構變成「蜘蛛網」，人肉已很難搞定！

隨著用戶量、數據量并發量進一步的增長，58同城也拓展了很多的新業務，那么對產品迭代速度要求就非常高，整體的架構對自動化的要求越來越高。

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

而柔性服務是指當流量增加的時候，自動的新增服務。可以看到進一步解耦之后，有垂直業務、無線業務、集成業務等等，這些子系統之間都是通過配置中心相應之間發生關系的。

另一點就是關于數據庫，當某一點成為一個業務線重點的時候，我們就會集中解決這個點的問題。最初期的時候每個業務線都要訪問數據庫，訪問緩存，訪問用戶數據，于是我們把代碼集中的放到了服務層。現在數據量越來越大，大家都要做數據切分，每個業務線都做切分，這個時候58同城的每個頁面都面對這樣的痛點，于是把這個痛點拿到集中的層面來解決。

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

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

未來的挑戰

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

總結：

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

本文系「OneAPM 技術公開課」第一期演講嘉賓沈劍演講整理。「 OneAPM 技術公開課」由應用性能管理第一品牌 OneAPM 發起，內容面向 IT 開發和運維人員。云集技術牛人、知名架構師、實踐專家共同探討技術熱點。繼北京站、上海站第火爆上演之后，第三場將于?10?月?31?日在北京、成都「雙城」上演新一輪的「性能之戰」。

免費報名地址：http://www.huodongxing.com/event/5304101253200