• <th id="b6par"><sup id="b6par"></sup></th>
  • 
    

    <u id="b6par"><sub id="b6par"></sub></u>

    1. <code id="b6par"><small id="b6par"></small></code>
      • 保存到桌面加入收藏設為首頁
      IDC話題

      以業務驅動型的美麗說HIGO架構演變

      時間:2016-06-29 09:59:10   作者:楊永杰   來源:《程序員》雜志   閱讀:25042   評論:0
      內容摘要:眾所周知,電商發展到今天,獲取用戶的成本越來越高,為此已經形成一條不成文的共識:無促不銷。HIGO在運營層面上也大致每月一大促、每周一小促、每天一專題的節奏來開展,復雜多變的業務場景對系統架構而言是非常大的挑戰和考驗,也驗證了互聯網系統架構鐵律:架構不是一成北淶模而是隨著業務需求不斷演變的。
      前言

             由于海外購物是最近一兩年的另一個風口熱點,已經有不少團隊進入了市場,競爭已然白熱化;HIGO是美麗說旗下的創l產品,目前仍在快速發展,鑒于當前特殊時期,本次分享為了避免透露公司敏感信息,關于系統架構的細節部分,不會是確數,代以倍數來強化說明架構演變帶來的性能提升。

             眾所周知,電商發展到今天,獲取用戶的成本越來越高,為此已經形成一條不成文的共識:無促不銷。HIGO在運營層面上也大致每月一大促、每周一小促、每天一專題的節奏來開展,復雜多變的業務場景對系統架構而言是非常大的挑戰和考驗,也驗證了互聯網系統架構鐵律:架構不是一成;變的,而是隨著業務需求不斷演變的。HIGO的架構從誕生至今,其中以2015.08為時間節點,發生過一次非常重大變化。但總體保持一致,都是基于Linux操作系統,采用成熟的LNMP架構和開源的高性能服務組件來實現,涉及具體使用場景的變化也很清晰,完全是為了適應業務而發生的,其;開源軟件功不可沒。

      蠻荒之力的石器時代“2015.08以前”

             簡單說明,服務端提供標準HTTP接口,響應客戶端請求,返回結構化的JSON;業務端主要使用PHP開發,使用了公司自主研發的一套基于PHP5 Namespace的輕量MVC框架??蛻舳薸OS、Android App的請求首先到達4層負載均衡器LVS,LVS將請求轉發到一組高可用nginx應用負載均衡器“nginx配置了fastcgi緩存”,再昃薟煌的業務,轉發到后端的php-fpm集群,響應具體的業務,將結果返還給客戶端。在具體的業務層,PHP會根據實際情況來會和緩存(Redis)和存儲(MySQL)做交互。1.0版中緩存使用單臺Redis “master + slaver”,采用VRRP協議實現高可用;數據庫交于美麗說主站維護,一主一從闍pp中的IM模塊采用開源的node.js框架meteor,圖片服務簡單的使用了NFS文件共享,掛載到php-fpm節點。IDCSPED這套成熟的架構在很長的時間段內,扛住了用戶快速增長和業務快速迭代需求帶來的壓力。

             v1.0版的架構有個明顯的單點,那就是基于NFS的圖片服務。但是由于架構夠使,而且公司為其購買了商業CDN服務,一直沒有報過重大問題,所以直到改版,都沒有花精力在上面。在此不得不說個插曲,由于海外買手不斷反饋App響應速度慢,IM聊天消息常常不n正常收發,當時的架構團隊決定將機房遷到了香港,雖然當時減少了買手的投訴,但后來的實踐證明之前的決策是個錯誤,8月份架構升級的時候,機器又遷回了北京。

      以業務驅動型的美麗說HIGO架構演變


      下面分享幾個實際遇到的問題和應對之策:

             6月份上旬的一天大促預熱,突然報上線服務巨慢,人工在預上線環境檢查確認,發現接口基本上都超時。通過商業和自有監控系統發現是MySQL鏈接數過高,已然超過DBA設定的閾值,php-fpm單節點進程數已經飆到了近2K,系統處于HANG住的狀態。多方排查,確定由于Redis配置問題,b上香港機房網絡抖動,導致Redis出現了兩個master,等于緩存層完全失效,所有的請求都直接穿透到MySQL;雪上加霜的是,由于業務工期緊張的緣故,PHP的業務層存在大量慢查詢,表結構沒有適當索引、不當的索引,子查詢以及聯合查詢等,將問題進一步擴大化,最終導致服務無法正響應。整個技術團隊也以此為契機,開啟了漫長的數據庫優化之路。

             由于公司戰略層的緣故,DBA沒有對HIGO業務給予足夠的重視,MySQL的一主一從卻一直存在從庫同步延遲超出可接受范圍,逼迫技術團隊在存儲上做了妥協,放棄從庫,只用主庫,導致主庫的壓力一直下不來,讀寫無法分離,性能瓶頸點始終在存儲層“使用xhproy做過性能分析,此結論成立”。

             Redis 緩存與持久化混合使用,導致緩存系統部署無法分布式,內存使用率不高,而且出現問題不易排查。

             這一階段主要面臨的壓力并非來自線上流量,而是產品和業務的需求壓力;主要目標是快速迭代,實現產品功能。我們上線的頻率非常之高,隨之不可避免的在線上生產環境引入了一些bug。由此可見,團隊的主要矛盾隨著公司的業務發展在不斷的發生著變化。

             美麗說大手筆購買了跑男冠名權,HIGO將會迎來一波流量爆漲期,預計的增長率10倍不止,v1.0的架構顯示不足以支撐,所以架構升級,勢在必行。

      移花接木的鐵器時代“2015.08始”

             從8月份開始,我們面臨的主要問題是暴漲的流量,而且是有明顯波峰的流量,需要我們全面升級系統架構,解決各種單點和系統性能瓶頸點,以應對外部流量對1們的壓力。v2.0架構主體繼承v1.0,著眼小處優化改進,具體的一些做法如下:

             借鑒淘寶,在LVS與nginx之間加了層流量控制,采用nginx + lua“openresty”實現,可以針對不同規則來進行服務降級,減少對核心業務的沖擊,保證服務可用性。

             將Redis的使用按業務場景分開:對于KV緩存的采用twemproxy代理分布式部署,以便水平擴展;對于需要持久存儲的計數器、隊列、集合等數據,單獨部署高可用Redis持久化存儲。升級后一來將請求分散,減少單節點的壓力;二來業務層依不同需求,選擇不同方案,也會更加清晰。

             php-fpm集群架構保持不變,隨時跟據業務增減節點即可,完全可伸縮,自不用多做介紹。

             DB層使用公司自主研發的一套dbproxy,能夠自動實現讀寫分離、分庫分表,SQL審計等。與此同時,業務層根據具體情況實現了拆庫分庫,例如拆分為用戶、商品、訂單、優惠券等系統,不同的業務調用對應的數據庫,跨業務通過公共lib庫調用,不容許相互之間直接訪問數據庫,盡可能高內聚低耦合,減少系統之間的耦合度。這樣做的好處顯而易見,但也引入不和諧因素,最直接受影響的就是統計,數據分散到各個不同庫,匯總統計無異惡夢。對此我們采取一個中庸的解決方案,DBA每12個小時將各庫全量導出,再全量匯總到線下統計庫,以犧牲統計實時性來降低線上服務的實現復雜度。

             曾經的單點圖片服務,則利用曲線救國思路,調用了主站現成的服務。IM亦是,交由主站專業的團隊來維護。

             目前v2.0的大部t功能已經上線,目前來看,效果達到預期,也讓我們跑男扛流量有一份自信。

      奔向文明時代之關于未來架構的演化

             隨著人員的不斷擴充,業務的不斷增漲,系統模塊服務化的需求越來越明確。我們之前小嘗試了服務化,但由于種種原因并沒有推廣開來,但我堅定的認為未來服務化終歸還是會被提上日程。

             未來我們系統還會不斷引入其他模塊和服務,但我們會盡可能保持架構的簡單性、清晰性,降低系統間的耦合度,打造高可用、可擴展、高性能的系統。

             如你所見,HIGO的架構一點也不高大上,完全是一個務實型的以業務為導向的架構,這正應了互聯網一句老話:沒有最好的架構,只有更適應業務的架構。是的,這不是美麗說HIGO系統架構演變的終點,而是才剛剛開始。

      關于升級前后的性能對比

             由于后端接口復雜度不一致,單純看某個接口的QPS意義不大,我參考QA同學的接口壓力測試報告,給出單個節點平均的升級前后的性能對比表:
      以業務驅動型的美麗說HIGO架構演變
      注:單個php-fpm節點,非精確值,僅供參考。


      IDCsped 提供最新的IT互聯網資訊,本著分享、傳播的宗旨,我們希望能幫助更多人了解需要的信息!

      部分文章轉載自互聯網、部分是IDCsped原創文章,如果轉載,請注明出處:www.idcsped.com !
      微信號:13430280788  歡迎加微信交流!

      標簽:美麗說HIGO  美麗說IDC架構部署  HIGO系統架構  
      相關評論

      銷售電話:13430280788

      Copyright © 2012-2017 | www.idcsped.com 版權所有

        粵公網安備 44010502001126號  粵ICP備12006439號-1
      Powered by OTCMS V3.61
      一级做a爱过程免费视频
    2. <th id="b6par"><sup id="b6par"></sup></th>
    3. 
      

      <u id="b6par"><sub id="b6par"></sub></u>

      1. <code id="b6par"><small id="b6par"></small></code>