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

對(duì)很多創(chuàng)業(yè)公司而言，很難在初期就預(yù)估到流量十倍、百倍以及千倍以后網(wǎng)站架構(gòu)會(huì)是什么樣的一個(gè)狀況。同時(shí)，如果系統(tǒng)初期就設(shè)計(jì)一個(gè)千萬(wàn)級(jí)并發(fā)的流量架構(gòu)，很難有公司可以支撐這個(gè)成本。

因此，這里主要會(huì)關(guān)注架構(gòu)的眼花。在每個(gè)階段，找到對(duì)應(yīng)該階段網(wǎng)站架構(gòu)所面臨的問(wèn)題，然后在不斷解決這些問(wèn)題，在這個(gè)過(guò)程中整個(gè)架構(gòu)會(huì)一直演進(jìn)。

在58同城建立之初，站點(diǎn)的流量非常小，可能也就是十萬(wàn)級(jí)別，這也就意味著，平均每秒鐘也就是幾次的訪問(wèn)，此時(shí)網(wǎng)站架構(gòu)的特點(diǎn)是：請(qǐng)求量比較低，數(shù)據(jù)量比較小，代碼量也比較小。這個(gè)時(shí)候的站點(diǎn)可以被幾個(gè)工程師輕易搞定，因此根本沒(méi)什么“架構(gòu)”可言。

其實(shí)這也是很多創(chuàng)業(yè)公司初期面臨的問(wèn)題，最開(kāi)始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ì)初期都面臨一個(gè)與之類(lèi)似的情況，每天寫(xiě)代碼，寫(xiě)SQL、接口參數(shù)、訪問(wèn)數(shù)據(jù)等等。

這里需要說(shuō)明一個(gè)問(wèn)題，大家都知道最初58同城使用的是Windows、iis、SQL-Sever、C#這條路?，F(xiàn)在很多創(chuàng)業(yè)公司可能就不會(huì)這么做。

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

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

在這個(gè)階段58同城面臨的主要問(wèn)題是什么？其實(shí)就是招人，最初工程師寫(xiě)CURD都容易出錯(cuò)。當(dāng)時(shí)引進(jìn)了DAO和ORM，從而避免直接面對(duì)CURD語(yǔ)句，而是面對(duì)工程師比較擅長(zhǎng)的是面向?qū)ο螅軌驑O大的提高工作效率，降低出錯(cuò)率。

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

隨著58同城的高速增長(zhǎng)，系統(tǒ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ù)成為新的瓶頸，從而，人越多訪問(wèn)越慢。而在這個(gè)時(shí)候，機(jī)器數(shù)量也從一臺(tái)變成了多臺(tái)，所以很自然的行程了分布式架構(gòu)，如下圖所示：

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

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

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

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

在解決這些問(wèn)題時(shí)，最先想到的是針對(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ù)量。這樣，讀寫(xiě)延時(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同城面臨的最大問(wèn)題就是性能和成本。此前曾提到58同城最初的技術(shù)選型是Windows，整個(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ā)期。于是招聘了很多工程師，大家一起寫(xiě)越來(lái)越多的站點(diǎn)，但是發(fā)現(xiàn)效率很低，經(jīng)常做一些重復(fù)性的工作，比如參數(shù)解析等等。同時(shí)，業(yè)務(wù)之間相互依賴(lài)，無(wú)論是分類(lèi)的子系統(tǒng)還是信息的子系統(tǒng)，二手車(chē)業(yè)務(wù)、房產(chǎn)業(yè)務(wù)都要訪問(wèn)用戶(hù)和信息等一些底層數(shù)據(jù)，代碼之間頻繁的溝通，效率也不可能很高。

問(wèn)題隨之而來(lái)，站點(diǎn)數(shù)越來(lái)越多，數(shù)據(jù)量越來(lái)越大，機(jī)器數(shù)從最開(kāi)始的幾臺(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ì)寫(xiě)對(duì)應(yīng)的代碼。如果用戶(hù)發(fā)出請(qǐng)求，就由這個(gè)服務(wù)層統(tǒng)一來(lái)管理，所有的上游業(yè)務(wù)線就像調(diào)用本地函數(shù)一樣，通過(guò)IDC的框架來(lái)調(diào)用這個(gè)服務(wù)。整個(gè)用戶(hù)登錄先訪問(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ù)層能夠編寫(xiě)代碼，然后由這個(gè)服務(wù)層集中管理、集中優(yōu)化，這樣就提高了效率。

除此之外，為了保證站點(diǎn)的高可用，主要使用了反向代理技術(shù)。因?yàn)閷?duì)用戶(hù)而言，他主要為了使用58同城的服務(wù)，不會(huì)關(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ù)層的高可用。另外，為了保證高可用還使用了冗余的方法，無(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ù)量更新的話(huà)，那就需要將所有的“冗余”都要進(jìn)行更新。

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

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

隨著用戶(hù)量、數(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ò)展的話(huà)，配置中心自動(dòng)下達(dá)消息，如果有機(jī)器要下線的話(huà)，配置中心會(huì)反向通過(guò)發(fā)郵件的方式進(jìn)行通知。

而柔性服務(wù)是指當(dāng)流量增加的時(shí)候，自動(dòng)的新增服務(wù)?？梢钥吹竭M(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)用戶(hù)數(shù)據(jù)，于是把代碼集中的放到了服務(wù)層?，F(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)的話(huà)題；智能廣告，通過(guò)一些智能的策略，讓用戶(hù)對(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臺(tái)，這就是運(yùn)維的挑戰(zhàn)了。

總結(jié)

最后做一個(gè)小的總結(jié)，網(wǎng)站在不同的階段遇到的問(wèn)題不一樣，而解決這些問(wèn)題使用的技術(shù)也不一樣，流量小的時(shí)候，主要目的是提高開(kāi)發(fā)效率，在早期要引入ORM，DAO這些技術(shù)。隨著流量變大，使用動(dòng)靜分離、讀寫(xiě)分離、主從同步、垂直拆分、CDN、MVC等方式不斷地提升網(wǎng)站穩(wěn)定性。面對(duì)更大的流量時(shí)，通過(guò)垂直拆分、服務(wù)化、反向代理、開(kāi)發(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).

作者：58沈劍