核心內容：58同城流量從小到大過程當中前端
- 架構是如何演進的？
- 遇到了哪些問題？
- 以及如何解決這些問題？
核心觀點：好的架構不是設計出來的，而是進化而來的。git
如何演進：站點流量在不一樣階段，會遇到不一樣的問題，找到對應階段站點架構所面臨的主要問題，在不斷解決這些問題的過程當中，整個系統的架構就不斷的演進了。程序員
如何演進，簡言之：找到主要矛盾，並解決主要矛盾github
建站之初web
建站之初，站點流量很是小，可能低於十萬級別。這意味着，平均每秒鐘也就幾回訪問。請求量比較低，數據量比較小，代碼量也比較小，幾個工程師，很短的時間搭起這樣的系統，甚至沒有考慮「架構」的問題。sql
和許多創業公司初期同樣，最初58同城的站點架構特色是「ALL-IN-ONE」數據庫
這是一個單機系統，全部的站點、數據庫、文件都部署在一臺服務器上。工程師天天的核心工做是CURD，瀏覽器端傳過來一些數據，解析GET/POST/COOKIE中傳過來的數據，拼裝成一些CURD的sql語句訪問數據庫，數據庫返回數據，拼裝成頁面，返回瀏覽器。相信不少創業團隊的工程師，初期作的也是相似的工做。後端
58同城最初選擇的是微軟技術體系這條路：Windows、iis、SQL-Sever、C#瀏覽器
若是從新再來，咱們可能會選擇LAMP體系。緩存
爲何選擇LAMP？
LAMP無須編譯，發佈快速，功能強大，社區活躍，從前端+後端+數據庫訪問+業務邏輯處理所有能夠搞定，而且開源免費，公司作大了也不會有人上門收錢（很多公司吃過虧）。如今你們若是再創業，強烈建議使用LAMP。
初創階段，工程師面臨的主要問題：寫CURD的sql語句很容易出錯。
咱們在這個階段引進DAO和ORM，讓工程師們再也不直接面對CURD的sql語句，而是面對他們比較擅長的面向對象開發，極大的提升了編碼效率，下降了出錯率。
流量增長，數據庫成爲瓶頸
隨着流量愈來愈大，老闆不僅要求「有一個能夠看見的站點」，他但願網站可以正常訪問，固然速度快點就更好了。
而此時系統面臨問題是：流量的高峯期容易宕機，大量的請求會壓到數據庫上，數據庫成爲新的瓶頸，人多並行訪問時站點很是卡。這時，咱們的機器數量也從一臺變成了多臺，咱們的系統成了所謂的（僞）「分佈式架構」：
咱們使用了一些常見優化手段
- 動靜分離，動態的頁面經過Web-Server訪問，靜態的文件例如圖片就放到單獨的文件服務器上
- 讀寫分離，將落到數據庫上的讀寫請求分派到不一樣的數據庫服務器上
互聯網絕大部分的業務場景，都是讀多寫少。對58同城來講，絕大部分用戶的需求是訪問信息，搜索信息，只有少數的用戶發貼。此時讀取性能容易成爲瓶頸，那麼如何擴展整個站點架構的讀性能呢？經常使用的方法是主從同步，增長從庫。咱們原來只有一個讀數據庫，如今有多個讀數據庫，就提升了讀性能。
在這個階段，系統的主要矛盾爲「站點耦合+讀寫延時」，58同城是如何解決這兩個問題的呢？
第一個問題是站點耦合。對58同城而言，典型業務場景是：類別聚合的主頁，發佈信息的發佈頁，信息聚合的列表頁，帖子內容的詳細頁，原來這些系統都耦合在一個站點中，出現問題的時候，整個系統都會受到影響。
第二個問題是讀寫延時。數據庫作了主從同步和讀寫分離以後，讀寫庫之間數據的同步有一個延時，數據庫數據量越大，從庫越多時，延時越明顯。對應到業務，有用戶發帖子，立刻去搜索可能搜索不到（着急的用戶會再次發佈相同的帖子）。
要解決耦合的問題，最早想到的是針對核心業務作切分，工程師根據業務切分對系統也進行切分：咱們將業務垂直拆分紅了首頁、發佈頁、列表頁和詳情頁。
另外，咱們在數據庫層面也進行了垂直拆分，將單庫數據量降下來，讓讀寫延時獲得緩解。
同時，還使用了這些技術來優化系統和提升研發效率
- 對動態資源和靜態資源進行拆分。對靜態資源咱們使用了CDN服務，用戶就近訪問，靜態資源的訪問速度獲得很明顯的提高；
- 除此以外，咱們還使用了MVC模式，擅長前端的工程師去作展現層，擅長業務邏輯的工程師就作控制層，擅長數據的工程師就作數據層，專人專用，研發效率和質量又進一步提升。
全面轉型開源技術體系
流量愈來愈大，當流量達到百萬甚至千萬時，站點面臨一個很大的問題就是性能和成本的折衷。上文提到58同城最初的技術選型是Windows，咱們在這個階段作了一次脫胎換骨的技術轉型，全面轉向開源技術：
- 操做系統轉型Linux
- 數據庫轉型Mysql
- web服務器轉型Tomcat
- 開發語言轉向了Java
其實，不少互聯網公司在流量從小到大的過程當中都經歷過相似的轉型，例如京東和淘寶。
隨着用戶量的增長，對站點可用性要求也愈來愈高，機器數也從最開始的幾臺上升到幾百臺。那麼如何提供保證整個系統的可用性呢？首先，咱們在業務層作了進一步的垂直拆分，同時引入了Cache，以下圖所示：
在架構上，咱們抽象了一個相對獨立的服務層，全部數據的訪問都經過這個服務層統一來管理，上游業務線就像調用本地函數同樣，經過RPC的框架來調用這個服務獲取數據，服務層對上游屏蔽底層數據庫與緩存的複雜性。
除此以外，爲了保證站點的高可用，咱們使用了反向代理。
什麼是代理？代理就是表明用戶訪問xxoo站點。
什麼是反向代理？反向代理表明的是58網站，用戶不用關注訪問是58同城的哪臺服務器，由反向代理來表明58同城。58同城經過反向代理，DNS輪詢， LVS等技術，來保證接入層的高可用性。
另外，爲了保證服務層和數據層的高可用，咱們採用了冗餘的方法，單點服務不可用，咱們就冗餘服務，單點數據不可用，咱們就冗餘數據。
這個階段58同城進入了一個業務高速爆發期，短時間內衍生出很是多的業務站點和服務。新增站點、新增服務每次都會作一些重複的事情，例如線程模型，消息隊列，參數解析等等，因而，58同城就研發了本身的站點框架和服務框架，如今這兩個框架也都已經開源：
- 站點框架Argo：https://github.com/58code/Argo
- 服務框架Gaea：https://github.com/58code/Gaea
這個階段，爲了進一步解耦系統，咱們引入了配置中心、柔性服務和消息總線。
引入配置中心，業務要訪問任何一個服務，不須要在本地的配置文件中配置服務的ip list，而只須要訪問配置中心。這種方式的擴展性很是好，若是有機器要下線，配置中心會反向通知上游訂閱方，而不須要更新本地配置文件。
柔性服務是指當流量增長的時候，自動的擴展服務和站點。
消息總線也是一種解耦上下游「調用」關係常見的技術手段。
機器愈來愈多，此時不少系統層面的問題，靠「人肉」已經很難搞定，因而自動化變得愈來愈重要：自動化迴歸、自動化測試、自動化運維、自動化監控等等等等。
最後補充一點，這個階段咱們引入了很多智能化產品，好比智能推薦，主動推薦一些相關的數據，以增長58同城的PV；智能廣告，經過一些智能的策略，讓用戶對廣告的點擊更多，增長同城的收入；智能搜索，在搜索的過程當中加入一些智能的策略，提升用戶的點擊率，以增長58同城的PV。這些智能化產品的背後都由技術驅動。
進一步的挑戰
如今，58同城的流量已經達到10億的量級，架構上咱們規劃作一些什麼樣的事情呢，幾個方向：
- 業務服務化
- 多架構模式
- 平臺化
小結
網站在不一樣的階段遇到的問題不同，而解決這些問題使用的技術也不同：
- 流量小的時候，咱們要提升開發效率，能夠在早期要引入ORM，DAO
- 流量變大，可使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC等方式不斷提高網站的性能和研發效率
- 面對更大的流量時，經過垂直拆分、服務化、反向代理、開發框架（站點/服務）等等手段，能夠不斷提高高可用（研發效率）
- 在面對上億級的流量時，經過配置中心、柔性服務、消息總線、自動化（迴歸，測試，運維，監控）來迎接新的挑戰
那如何學習才能快速入門並精通呢？
當真正開始學習的時候不免不知道從哪入手，致使效率低下影響繼續學習的信心。
但最重要的是不知道哪些技術須要重點掌握，學習時頻繁踩坑，最終浪費大量時間，因此有一套實用的視頻課程用來跟着學習是很是有必要的。
爲了讓學習變得輕鬆、高效，今天給你們免費分享一套阿里的Java架構師傳授的一套教學資源。幫助你們在成爲架構師的道路上披荊斬棘。
這套視頻課程，詳細講解了像（Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構）等這些成爲架構師必備的內容！
並且還把框架須要用到的各類程序進行了打包，根據基礎視頻可讓你輕鬆搭建分佈式框架環境，像在企業生產環境同樣進行學習和實踐。
加入架構交流羣：687107762 就能夠立刻免費得到這套價值一萬八的內部教材！先到先得。
最後，作一個愛思考，懂思考，會思考的程序員。