摘要：所以，我們主要來(lái)講架構(gòu)是如何進(jìn)行演化的。此前，我提到同城最初的技術(shù)選型是，應(yīng)該是在年的時(shí)候，整個(gè)網(wǎng)站的性能變得非常之低。對(duì)技術(shù)的要求越來(lái)越高，任何一個(gè)站點(diǎn)都不能掛，對(duì)站點(diǎn)的可用性要求也是越來(lái)越高。

【編者按】對(duì)很多創(chuàng)業(yè)公司而言，隨著業(yè)務(wù)的增長(zhǎng)，網(wǎng)站的流量也會(huì)經(jīng)歷不同的階段。從十萬(wàn)流量到一百萬(wàn)流量，再?gòu)囊话偃f(wàn)流量跨越到一千萬(wàn)甚至上億的流量，網(wǎng)站的架構(gòu)需要經(jīng)歷哪些變化？我們一起聽聽 58 同城的技術(shù)委員會(huì)執(zhí)行主席沈劍在 OneAPM 技術(shù)公開課上的回答（以下演講整理）：

首先，非常感謝 OneAPM 技術(shù)公開課舉辦的這次活動(dòng)。本場(chǎng)演講我主要闡述一下，58 同城從小流量、中等規(guī)模流量、大流量，到更大的流量過(guò)程中，架構(gòu)是怎么演進(jìn)的？遇到了哪些問(wèn)題？以及如何解決這些問(wèn)題？

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

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

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

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

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

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

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

如果可以重來(lái)？那么會(huì)選擇LAMP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

未來(lái)的挑戰(zhàn)

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

總結(jié)：

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

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

免費(fèi)報(bào)名地址：http://www.huodongxing.com/event/5304101253200