原文網址連接：http://www.csdn.net/article/2015-10-24/2826028
摘要：對不少創業公司而言，很難在初期就預估到流量十倍、百倍以及千倍之後網站架構會是什麼樣的一個情況。同時，若是系統初期就設計一個千萬級併發的流量架構，很難有公司能夠支撐這個成本。前端
【編者按】對不少創業公司而言，隨着業務增加，網站的流量也會經歷不一樣的階段。從十萬流量到一百萬流量，再從一百萬流量跨越到一千萬甚至上億的流量，網站的架構須要經歷哪些變化？在「OneAPM 技術公開課」第一期中，58同城的技術委員會執行主席沈劍對此進行了詳細剖析。git
如下爲演講整理
本次演講主要會闡述，58同城從小流量、中等規模流量、大流量，到更大的流量過程當中，架構是如何演進的？遇到了哪些問題？以及如何解決這些問題？github
好的架構不是設計出來的，而是演進出來的
對不少創業公司而言，很難在初期就預估到流量十倍、百倍以及千倍之後網站架構會是什麼樣的一個情況。同時，若是系統初期就設計一個千萬級併發的流量架構，很難有公司能夠支撐這個成本。web
所以，這裏主要會關注架構的眼花。在每一個階段，找到對應該階段網站架構所面臨的問題，而後在不斷解決這些問題，在這個過程當中整個架構會一直演進。數據庫
在58同城創建之初，站點的流量很是小，可能也就是十萬級別，這也就意味着，平均每秒鐘也就是幾回的訪問，此時網站架構的特色是：請求量比較低，數據量比較小，代碼量也比較小。這個時候的站點能夠被幾個工程師輕易搞定，所以根本沒什麼「架構」可言。後端
其實這也是不少創業公司初期面臨的問題，最開始58同城的站點架構用一個詞歸納就是「ALL IN ONE」，以下圖所示：瀏覽器
就像一個單機系統，全部的東西都部署在一臺機器上，包括站點、數據庫、文件等等。而工程師天天的核心工做就是CURD，前端傳過來一些數據，而後業務邏輯層拼裝成一些CURD訪問數據庫，數據庫返回數據，數據拼裝成頁面，最終返回到瀏覽器。相信不少創業團隊初期都面臨一個與之相似的狀況，天天寫代碼，寫SQL、接口參數、訪問數據等等。緩存
這裏須要說明一個問題，你們都知道最初58同城使用的是Windows、iis、SQL-Sever、C#這條路。如今不少創業公司可能就不會這麼作。服務器
若是能夠重來？那麼會選擇LAMP
不少創業的同窗可能會想，初期什麼樣的一個架構合適？ 若是重來，站在如今這個角度上58會選擇LAMP，爲何？首先是無須編譯，並且快速發佈功能強大，從前端到後端、數據庫訪問、業務邏輯處理等等所有能夠搞定，最重要都是成熟的開源產品，徹底免費的。若是使用LAMP搭建一個論壇，兩天的時間就足夠了。因此，若是在創業初期，就儘可能不要再使用Windows。架構
在這個階段58同城面臨的主要問題是什麼？其實就是招人，最初工程師寫CURD都容易出錯。當時引進了DAO和ORM，從而避免直接面對CURD語句，而是面對工程師比較擅長的是面向對象，可以極大的提升工做效率，下降出錯率。
中等規模：流量跨過十萬的階段，數據庫成爲瓶頸
隨着58同城的高速增加，系統很快跨越了十萬流量階段。主要需求是什麼？網站可以正常訪問，固然速度更快點就行了。而此時系統面臨的問題有：在流量峯值期容易宕機，由於大量的請求會壓到數據庫上，因此數據庫成爲新的瓶頸，從而，人越多訪問越慢。而在這個時候，機器數量也從一臺變成了多臺，因此很天然的行程了分佈式架構，以下圖所示：
首先，使用了一些很是常見的技術，一方面是動靜分離，動態的頁面經過Web-Servre訪問，靜態的像圖片等就單獨放到了一些服務器上。另一點就是讀寫分離。其實，對58同城或者說絕大部分的站點而言，通常來講都是讀多寫少。對58同城來講，絕大部分用戶是訪問信息，只有不多的用戶過來發貼。那麼如何擴展整個站點架構的讀請求呢？經常使用的是主從同步，讀寫分離。同時原來只有一個數據庫，如今使用多個不一樣的數據庫提供服務，這樣的話，就擴展了讀寫，很快就解決了中等規模下數據訪問的問題。
在這個階段，系統的主要矛盾就是「站點耦合+讀寫延時」，58同城是如何進行解耦，如何緩解延時呢？
對58同城而言，典型業務場景是主頁，發佈信息有發佈頁，信息聚合、標題聚合有列表頁，點開一個標題有詳細頁，而這些站點都是耦合在一個程序中的，或者說耦合在一個站點中的，當一個站點出現問題，整個站點就會由於耦合一塊兒出問題。
第二個問題，你們都知道作數據庫讀請求和寫請求，分佈在不一樣的數據庫上，這個時候若是再讀取可能讀到的是舊數據，由於讀寫有一個延時。若是有用戶發帖子，立刻去找的話確定找不到，極可能帶來的後果就是陸續在發佈兩條信息，這就是一個很大的問題。尤爲是在請求量愈來愈大的時候，這個問題就更加突出。
在解決這些問題時，最早想到的是針對原來站點的核心業務作切分，而後工程師根據本身的站點和業務場景進行細分。首先，業務拆分是58同城最早嘗試的優化——將業務垂直拆分紅了首頁和發佈頁。另外，在數據庫層面，隨之也進行了拆分，將大數據量拆分紅一個個小的數據量。這樣，讀寫延時就立刻獲得了緩解。尤爲是在代碼拆分紅了不一樣的層面以後，站點耦合也獲得了緩解，數據加載速度也提高了不少。
當時，還使用了一些技術，前面也提到了對動態資源和靜態資源進行拆分。其中，咱們對靜態資源使用了CDN服務，便於數據緩存和就近訪問，訪問速度獲得很明顯的提高。除此以外，還使用了MVC模式，擅長前端的去作展現層，擅長協做邏輯的工程師就作Contorller，擅長數據的人就負責數據，效率就會逐步的提升，最後就是負載均衡技術。
大流量：將整個Windows技術體系轉向了Java體系
流量愈來愈大，當流量超過一千多萬時，58同城面臨的最大問題就是性能和成本。此前曾提到58同城最初的技術選型是Windows，整個網站的性能變得很是之低。即便進行了業務拆分和一些優化，依然解決不了這個問題，因此當時作了一個很是艱難的決定，就是轉型：將整個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技術編輯王鵬 責編/仲浩）
