核心內(nèi)容：58同城流量從小到大過程中，架構(gòu)是如何演進(jìn)的？遇到了哪些問題？以及如何解決這些問題？

核心觀點(diǎn)：好的架構(gòu)不是設(shè)計(jì)出來的，而是進(jìn)化而來的。

如何演進(jìn)：站點(diǎn)流量在不同階段，會(huì)遇到不同的問題，找到對應(yīng)階段站點(diǎn)架構(gòu)所面臨的主要問題，在不斷解決這些問題的過程中，整個(gè)系統(tǒng)的架構(gòu)就不斷的演進(jìn)了。

如何演進(jìn)，簡言之：找到主要矛盾，并解決主要矛盾。

第一章：建站之初

---

建站之初，站點(diǎn)流量非常小，可能低于十萬級(jí)別。這意味著，平均每秒鐘也就幾次訪問。請求量比較低，數(shù)據(jù)量比較小，代碼量也比較小，幾個(gè)工程師，很短的時(shí)間搭起這樣的系統(tǒng)，甚至沒有考慮“架構(gòu)”的問題。

和許多創(chuàng)業(yè)公司初期一樣，最初58同城的站點(diǎn)架構(gòu)特點(diǎn)是“ALL-IN-ONE”：

這是一個(gè)單機(jī)系統(tǒng)，所有的站點(diǎn)、數(shù)據(jù)庫、文件都部署在一臺(tái)服務(wù)器上。工程師每天的核心工作是CURD，瀏覽器端傳過來一些數(shù)據(jù)，解析GET/POST/COOKIE中傳過來的數(shù)據(jù)，拼裝成一些CURD的sql語句訪問數(shù)據(jù)庫，數(shù)據(jù)庫返回?cái)?shù)據(jù)，拼裝成頁面，返回瀏覽器。相信很多創(chuàng)業(yè)團(tuán)隊(duì)的工程師，初期做的也是類似的工作。

58同城最初選擇的是微軟技術(shù)體系這條路：Windows、iis、SQL-Sever、C#

如果重新再來，我們可能會(huì)選擇LAMP體系。

為什么選擇LAMP？

LAMP無須編譯，發(fā)布快速，功能強(qiáng)大，社區(qū)活躍，從前端+后端+數(shù)據(jù)庫訪問+業(yè)務(wù)邏輯處理全部可以搞定，并且開源免費(fèi)，公司做大了也不會(huì)有人上門收錢（不少公司吃過虧）。現(xiàn)在大家如果再創(chuàng)業(yè)，強(qiáng)烈建議使用LAMP。

初創(chuàng)階段，工程師面臨的主要問題：寫CURD的sql語句很容易出錯(cuò)。

我們在這個(gè)階段引進(jìn)DAO和ORM，讓工程師們不再直接面對CURD的sql語句，而是面對他們比較擅長的面向?qū)ο箝_發(fā)，極大的提高了編碼效率，降低了出錯(cuò)率。

第二章：流量增加，數(shù)據(jù)庫成為瓶頸

---

隨著流量越來越大，老板不只要求“有一個(gè)可以看見的站點(diǎn)”，他希望網(wǎng)站能夠正常訪問，當(dāng)然速度快點(diǎn)就更好了。

而此時(shí)系統(tǒng)面臨問題是：流量的高峰期容易宕機(jī)，大量的請求會(huì)壓到數(shù)據(jù)庫上，數(shù)據(jù)庫成為新的瓶頸，人多并行訪問時(shí)站點(diǎn)非?？?。這時(shí)，我們的機(jī)器數(shù)量也從一臺(tái)變成了多臺(tái)，我們的系統(tǒng)成了所謂的（偽）“分布式架構(gòu)”：

我們使用了一些常見優(yōu)化手段：

（1）動(dòng)靜分離，動(dòng)態(tài)的頁面通過Web-Server訪問，靜態(tài)的文件例如圖片就放到單獨(dú)的文件服務(wù)器上；

（2）讀寫分離，將落到數(shù)據(jù)庫上的讀寫請求分派到不同的數(shù)據(jù)庫服務(wù)器上；

互聯(lián)網(wǎng)絕大部分的業(yè)務(wù)場景，都是讀多寫少。對58同城來說，絕大部分用戶的需求是訪問信息，搜索信息，只有少數(shù)的用戶發(fā)貼。此時(shí)讀取性能容易成為瓶頸，那么如何擴(kuò)展整個(gè)站點(diǎn)架構(gòu)的讀性能呢？常用的方法是主從同步，增加從庫。我們原來只有一個(gè)讀數(shù)據(jù)庫，現(xiàn)在有多個(gè)讀數(shù)據(jù)庫，就提高了讀性能。

在這個(gè)階段，系統(tǒng)的主要矛盾為“站點(diǎn)耦合+讀寫延時(shí)”，58同城是如何解決這兩個(gè)問題的呢？

第一個(gè)問題是站點(diǎn)耦合。對58同城而言，典型業(yè)務(wù)場景是：類別聚合的主頁，發(fā)布信息的發(fā)布頁，信息聚合的列表頁，帖子內(nèi)容的詳細(xì)頁，原來這些系統(tǒng)都耦合在一個(gè)站點(diǎn)中，出現(xiàn)問題的時(shí)候，整個(gè)系統(tǒng)都會(huì)受到影響。

第二個(gè)問題是讀寫延時(shí)。數(shù)據(jù)庫做了主從同步和讀寫分離之后，讀寫庫之間數(shù)據(jù)的同步有一個(gè)延時(shí)，數(shù)據(jù)庫數(shù)據(jù)量越大，從庫越多時(shí)，延時(shí)越明顯。對應(yīng)到業(yè)務(wù)，有用戶發(fā)帖子，馬上去搜索可能搜索不到（著急的用戶會(huì)再次發(fā)布相同的帖子）。

要解決耦合的問題，最先想到的是針對核心業(yè)務(wù)做切分，工程師根據(jù)業(yè)務(wù)切分對系統(tǒng)也進(jìn)行切分：我們將業(yè)務(wù)垂直拆分成了首頁、發(fā)布頁、列表頁和詳情頁。

另外，我們在數(shù)據(jù)庫層面也進(jìn)行了垂直拆分，將單庫數(shù)據(jù)量降下來，讓讀寫延時(shí)得到緩解。

同時(shí)，還使用了這些技術(shù)來優(yōu)化系統(tǒng)和提高研發(fā)效率：

（1）對動(dòng)態(tài)資源和靜態(tài)資源進(jìn)行拆分。對靜態(tài)資源我們使用了CDN服務(wù)，用戶就近訪問，靜態(tài)資源的訪問速度得到很明顯的提升；

（2）除此之外，我們還使用了MVC模式，擅長前端的工程師去做展示層，擅長業(yè)務(wù)邏輯的工程師就做控制層，擅長數(shù)據(jù)的工程師就做數(shù)據(jù)層，專人專用，研發(fā)效率和質(zhì)量又進(jìn)一步提高。

第三章：全面轉(zhuǎn)型開源技術(shù)體系

---

流量越來越大，當(dāng)流量達(dá)到百萬甚至千萬時(shí)，站點(diǎn)面臨一個(gè)很大的問題就是性能和成本的折衷。上文提到58同城最初的技術(shù)選型是Windows，我們在這個(gè)階段做了一次脫胎換骨的技術(shù)轉(zhuǎn)型，全面轉(zhuǎn)向開源技術(shù)：

（1）操作系統(tǒng)轉(zhuǎn)型Linux

（2）數(shù)據(jù)庫轉(zhuǎn)型Mysql

（3）web服務(wù)器轉(zhuǎn)型Tomcat

（4）開發(fā)語言轉(zhuǎn)向了Java

其實(shí)，很多互聯(lián)網(wǎng)公司在流量從小到大的過程中都經(jīng)歷過類似的轉(zhuǎn)型，例如京東和淘寶。

隨著用戶量的增加，對站點(diǎn)可用性要求也越來越高，機(jī)器數(shù)也從最開始的幾臺(tái)上升到幾百臺(tái)。那么如何提供保證整個(gè)系統(tǒng)的可用性呢？首先，我們在業(yè)務(wù)層做了進(jìn)一步的垂直拆分，同時(shí)引入了Cache，如下圖所示：

在架構(gòu)上，我們抽象了一個(gè)相對獨(dú)立的服務(wù)層，所有數(shù)據(jù)的訪問都通過這個(gè)服務(wù)層統(tǒng)一來管理，上游業(yè)務(wù)線就像調(diào)用本地函數(shù)一樣，通過RPC的框架來調(diào)用這個(gè)服務(wù)獲取數(shù)據(jù)，服務(wù)層對上游屏蔽底層數(shù)據(jù)庫與緩存的復(fù)雜性。

除此之外，為了保證站點(diǎn)的高可用，我們使用了反向代理。

什么是代理？代理就是代表用戶訪問xxoo站點(diǎn)。

什么是反向代理？反向代理代表的是58網(wǎng)站，用戶不用關(guān)注訪問是58同城的哪臺(tái)服務(wù)器，由反向代理來代表58同城。58同城通過反向代理，DNS輪詢， LVS等技術(shù)，來保證接入層的高可用性。

另外，為了保證服務(wù)層和數(shù)據(jù)層的高可用，我們采用了冗余的方法，單點(diǎn)服務(wù)不可用，我們就冗余服務(wù)，單點(diǎn)數(shù)據(jù)不可用，我們就冗余數(shù)據(jù)。

這個(gè)階段58同城進(jìn)入了一個(gè)業(yè)務(wù)高速爆發(fā)期，短期內(nèi)衍生出非常多的業(yè)務(wù)站點(diǎn)和服務(wù)。新增站點(diǎn)、新增服務(wù)每次都會(huì)做一些重復(fù)的事情，例如線程模型，消息隊(duì)列，參數(shù)解析等等，于是，58同城就研發(fā)了自己的站點(diǎn)框架和服務(wù)框架，現(xiàn)在這兩個(gè)框架也都已經(jīng)開源：

（1）站點(diǎn)框架Argo：https://github.com/58code/Argo

（2）服務(wù)框架Gaea：https://github.com/58code/Gaea

這個(gè)階段，為了進(jìn)一步解耦系統(tǒng)，我們引入了配置中心、柔性服務(wù)和消息總線。

引入配置中心，業(yè)務(wù)要訪問任何一個(gè)服務(wù)，不需要在本地的配置文件中配置服務(wù)的ip list，而只需要訪問配置中心。這種方式的擴(kuò)展性非常好，如果有機(jī)器要下線，配置中心會(huì)反向通知上游訂閱方，而不需要更新本地配置文件。

柔性服務(wù)是指當(dāng)流量增加的時(shí)候，自動(dòng)的擴(kuò)展服務(wù)和站點(diǎn)。

消息總線也是一種解耦上下游“調(diào)用”關(guān)系常見的技術(shù)手段。

機(jī)器越來越多，此時(shí)很多系統(tǒng)層面的問題，靠“人肉”已經(jīng)很難搞定，于是自動(dòng)化變得越來越重要：自動(dòng)化回歸、自動(dòng)化測試、自動(dòng)化運(yùn)維、自動(dòng)化監(jiān)控等等等等。

最后補(bǔ)充一點(diǎn)，這個(gè)階段我們引入了不少智能化產(chǎn)品，比如智能推薦，主動(dòng)推薦一些相關(guān)的數(shù)據(jù)，以增加58同城的PV；智能廣告，通過一些智能的策略，讓用戶對廣告的點(diǎn)擊更多，增加同城的收入；智能搜索，在搜索的過程中加入一些智能的策略，提高用戶的點(diǎn)擊率，以增加58同城的PV。這些智能化產(chǎn)品的背后都由技術(shù)驅(qū)動(dòng)。

第四章：進(jìn)一步的挑戰(zhàn)

---

現(xiàn)在，58同城的流量已經(jīng)達(dá)到10億的量級(jí)，架構(gòu)上我們規(guī)劃做一些什么樣的事情呢，幾個(gè)方向：

（1）業(yè)務(wù)服務(wù)化

（2）多架構(gòu)模式

（3）平臺(tái)化

（4）...

第五章：小結(jié)

---

最后做一個(gè)簡單的總結(jié)，網(wǎng)站在不同的階段遇到的問題不一樣，而解決這些問題使用的技術(shù)也不一樣：

（1）流量小的時(shí)候，我們要提高開發(fā)效率，可以在早期要引入ORM，DAO；

（2）流量變大，可以使用動(dòng)靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC等方式不斷提升網(wǎng)站的性能和研發(fā)效率；

（3）面對更大的流量時(shí)，通過垂直拆分、服務(wù)化、反向代理、開發(fā)框架（站點(diǎn)/服務(wù)）等等手段，可以不斷提升高可用（研發(fā)效率）；

（4）在面對上億級(jí)的流量時(shí)，通過配置中心、柔性服務(wù)、消息總線、自動(dòng)化（回歸，測試，運(yùn)維，監(jiān)控）來迎接新的挑戰(zhàn)；