雖然這篇文章寫的比較早，但是，還是很有參考意義，值得好好品讀思考。看看別人是怎么思考就架構(gòu)這種事情。

?

好的架構(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」，如下圖所示：

就像一個單機(jī)系統(tǒng)，所有的東西都部署在一臺機(jī)器上，包括站點、數(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# 這條路。現(xiàn)在很多創(chuàng)業(yè)公司可能就不會這么做。58 同城為什么當(dāng)時選擇了這條路？原因是公司招聘的第一個工程師和第二個工程師只會這個，所以只能走這條路。

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

很多創(chuàng)業(yè)的同學(xué)可能會想，如果我們初期希望做一個產(chǎn)品的話，我們應(yīng)該使用什么架構(gòu)？ 如果讓我們重來，可能我們現(xiàn)在會選 LAMP，為什么？首先是無須編譯，而且快速發(fā)布功能強(qiáng)大，從前端到后端、數(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)面臨問題包括：在流量的高峰期容易宕機(jī)，因為大量的請求會壓到數(shù)據(jù)庫上，所以數(shù)據(jù)庫成為新的瓶頸，而且人多的時候，訪問速度會很慢。這時，我們的機(jī)器數(shù)量也從一臺變成了多臺。現(xiàn)在的架構(gòu)就采用了分布式，如下圖所示：

首先，我們使用了一些非常常見的技術(shù)，一方面是動靜分離，動態(tài)的頁面通過 Web-Servre 訪問，靜態(tài)的像圖片等就單獨放到了一些服務(wù)器上。另外一點就是讀寫分離。其實，對 58 同城或者說絕大部分的站點而言，一般來說都是讀多寫少。對 58 同城來說，絕大部分用戶是訪問信息，只有很少的用戶過來發(fā)貼。那么如何擴(kuò)展整個站點架構(gòu)的讀請求呢？常用的是主從同步，讀寫分離。我們原來只有一個數(shù)據(jù)庫，現(xiàn)在使用多個不同的數(shù)據(jù)庫提供服務(wù)，這樣的話，就擴(kuò)展了讀寫，很快就解決了中等規(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ù)量越來越大，機(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ù)的特點，如果擴(kuò)展的話，配置中心自動下達(dá)消息，如果有機(jī)器要下線的話，配置中心會反向通過發(fā)郵件的方式進(jìn)行通知。

而柔性服務(wù)是指當(dāng)流量增加的時候，自動的新增服務(wù)。可以看到進(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ù)層。現(xiàn)在數(shù)據(jù)量越來越大，大家都要做數(shù)據(jù)切分，每個業(yè)務(wù)線都做切分，這個時候58同城的每個頁面都面對這樣的痛點，于是把這個痛點拿到集中的層面來解決。

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

這里需要補(bǔ)充一點，就是在產(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ù)實時計算，平臺化…

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

?from:??http://blog.oneapm.com/apm-tech/203.html

轉(zhuǎn)載于:https://www.cnblogs.com/jiujuan/p/11073704.html

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的58同城沈剑：好的架构是进化来的，不是设计来的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。