好架构是进化来的，不是设计来的
????? --58同城架構進化之路
文章出處：http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=400276397&idx=1&sn=ea044079667b82f6cad58bcb743af7bc&scene=5&srcid=10277H6aJ9ZwBQNzZB7nTqfC#rd
核心內容：58同城流量從小到大過程中，架構是如何演進的？遇到了哪些問題？以及如何解決這些問題？
核心觀點：好的架構不是設計出來的，而是進化而來的。
如何演進：站點流量在不同階段，會遇到不同的問題，找到對應階段站點架構所面臨的主要問題，在不斷解決這些問題的過程中，整個系統的架構就不斷的演進了。
如何演進，簡言之：找到主要矛盾，并解決主要矛盾。
?
第一章：建站之初
建站之初，站點流量非常小，可能低于十萬級別。這意味著，平均每秒鐘也就幾次訪問。請求量比較低，數據量比較小，代碼量也比較小，幾個工程師，很短的時間搭起這樣的系統，甚至沒有考慮“架構”的問題。
?
和許多創業公司初期一樣，最初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語句，而是面對他們比較擅長的面向對象開發，極大的提高了編碼效率，降低了出錯率。
?
第二章：流量增加，數據庫成為瓶頸
隨著流量越來越大，老板不只要求“有一個可以看見的站點”，他希望網站能夠正常訪問，當然速度快點就更好了。
而此時系統面臨問題是：流量的高峰期容易宕機，大量的請求會壓到數據庫上，數據庫成為新的瓶頸，人多并行訪問時站點非常卡。這時，我們的機器數量也從一臺變成了多臺，我們的系統成了所謂的（偽）“分布式架構”：
我們使用了一些常見優化手段：
（1）動靜分離，動態的頁面通過Web-Server訪問，靜態的文件例如圖片就放到單獨的文件服務器上；
（2）讀寫分離，將落到數據庫上的讀寫請求分派到不同的數據庫服務器上；
互聯網絕大部分的業務場景，都是讀多寫少。對58同城來說，絕大部分用戶的需求是訪問信息，搜索信息，只有少數的用戶發貼。此時讀取性能容易成為瓶頸，那么如何擴展整個站點架構的讀性能呢？常用的方法是主從同步，增加從庫。我們原來只有一個讀數據庫，現在有多個讀數據庫，就提高了讀性能。
?
在這個階段，系統的主要矛盾為“站點耦合+讀寫延時”，58同城是如何解決這兩個問題的呢？
?
第一個問題是站點耦合。對58同城而言，典型業務場景是：類別聚合的主頁，發布信息的發布頁，信息聚合的列表頁，帖子內容的詳細頁，原來這些系統都耦合在一個站點中，出現問題的時候，整個系統都會受到影響。
?
第二個問題是讀寫延時。數據庫做了主從同步和讀寫分離之后，讀寫庫之間數據的同步有一個延時，數據庫數據量越大，從庫越多時，延時越明顯。對應到業務，有用戶發帖子，馬上去搜索可能搜索不到（著急的用戶會再次發布相同的帖子）。
要解決耦合的問題，最先想到的是針對核心業務做切分，工程師根據業務切分對系統也進行切分：我們將業務垂直拆分成了首頁、發布頁、列表頁和詳情頁。
另外，我們在數據庫層面也進行了垂直拆分，將單庫數據量降下來，讓讀寫延時得到緩解。
同時，還使用了這些技術來優化系統和提高研發效率：
（1）對動態資源和靜態資源進行拆分。對靜態資源我們使用了CDN服務，用戶就近訪問，靜態資源的訪問速度得到很明顯的提升；
（2）除此之外，我們還使用了MVC模式，擅長前端的工程師去做展示層，擅長業務邏輯的工程師就做控制層，擅長數據的工程師就做數據層，專人專用，研發效率和質量又進一步提高。
?
第三章：全面轉型開源技術體系
流量越來越大，當流量達到百萬甚至千萬時，站點面臨一個很大的問題就是性能和成本的折衷。上文提到58同城最初的技術選型是Windows，我們在這個階段做了一次脫胎換骨的技術轉型，全面轉向開源技術：
（1）操作系統轉型Linux
（2）數據庫轉型Mysql
（3）web服務器轉型Tomcat
（4）開發語言轉向了Java
其實，很多互聯網公司在流量從小到大的過程中都經歷過類似的轉型，例如京東和淘寶。
?
隨著用戶量的增加，對站點可用性要求也越來越高，機器數也從最開始的幾臺上升到幾百臺。那么如何提供保證整個系統的可用性呢？首先，我們在業務層做了進一步的垂直拆分，同時引入了Cache，如下圖所示：
在架構上，我們抽象了一個相對獨立的服務層，所有數據的訪問都通過這個服務層統一來管理，上游業務線就像調用本地函數一樣，通過RPC的框架來調用這個服務獲取數據，服務層對上游屏蔽底層數據庫與緩存的復雜性。
除此之外，為了保證站點的高可用，我們使用了反向代理。
什么是代理？代理就是代表用戶訪問xxoo站點。
什么是反向代理？反向代理代表的是58網站，用戶不用關注訪問是58同城的哪臺服務器，由反向代理來代表58同城。58同城通過反向代理，DNS輪詢， LVS等技術，來保證接入層的高可用性。
另外，為了保證服務層和數據層的高可用，我們采用了冗余的方法，單點服務不可用，我們就冗余服務，單點數據不可用，我們就冗余數據。
?
這個階段58同城進入了一個業務高速爆發期，短期內衍生出非常多的業務站點和服務。新增站點、新增服務每次都會做一些重復的事情，例如線程模型，消息隊列，參數解析等等，于是，58同城就研發了自己的站點框架和服務框架，現在這兩個框架也都已經開源：
（1）站點框架Argo：https://github.com/58code/Argo
（2）服務框架Gaea：https://github.com/58code/Gaea
?
這個階段，為了進一步解耦系統，我們引入了配置中心、柔性服務和消息總線。
引入配置中心，業務要訪問任何一個服務，不需要在本地的配置文件中配置服務的ip list，而只需要訪問配置中心。這種方式的擴展性非常好，如果有機器要下線，配置中心會反向通知上游訂閱方，而不需要更新本地配置文件。
?
柔性服務是指當流量增加的時候，自動的擴展服務和站點。
?
消息總線也是一種解耦上下游“調用”關系常見的技術手段。
?
機器越來越多，此時很多系統層面的問題，靠“人肉”已經很難搞定，于是自動化變得越來越重要：自動化回歸、自動化測試、自動化運維、自動化監控等等等等。
?
最后補充一點，這個階段我們引入了不少智能化產品，比如智能推薦，主動推薦一些相關的數據，以增加58同城的PV；智能廣告，通過一些智能的策略，讓用戶對廣告的點擊更多，增加同城的收入；智能搜索，在搜索的過程中加入一些智能的策略，提高用戶的點擊率，以增加58同城的PV。這些智能化產品的背后都由技術驅動。
?
第四章、進一步的挑戰
現在，58同城的流量已經達到10億的量級，架構上我們規劃做一些什么樣的事情呢，幾個方向：
（1）業務服務化
（2）多架構模式
（3）平臺化
（4）...
第五章：小結
最后做一個簡單的總結，網站在不同的階段遇到的問題不一樣，而解決這些問題使用的技術也不一樣：
（1）流量小的時候，我們要提高開發效率，可以在早期要引入ORM，DAO；
（2）流量變大，可以使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC等方式不斷提升網站的性能和研發效率；
（3）面對更大的流量時，通過垂直拆分、服務化、反向代理、開發框架（站點/服務）等等手段，可以不斷提升高可用（研發效率）；
（4）在面對上億級的流量時，通過配置中心、柔性服務、消息總線、自動化（回歸，測試，運維，監控）來迎接新的挑戰；
轉載于:https://www.cnblogs.com/dengcw/p/4917989.html
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的好架构是进化来的，不是设计来的的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 解决Eclipse中文乱码
- 下一篇： uwsgi 的app变量名称必须为app