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

注：本文首發于CSDN，轉載請標明出處。

前言

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

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

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

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

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

圖1 HIGO架構圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

關于升級前后的性能對比

由于后端接口復雜度不一致，單純看某個接口的QPS意義不大，我參考QA同學的接口壓力測試報告，給出單個節點平均的升級前后的性能對比表：

表1：單個節點平均的升級前后的性能對比

注：單個php-fpm節點，非精確值，僅供參考。

開源助力之系統使用到的開源組件

• LVS:  https://github.com/alibaba/LVS
• keepalived:  http://www.keepalived.org
• nginx:  http://nginx.org
• openresty:  https://github.com/openresty
• meteor:  https://github.com/meteor/meteor
• Redis:  http://redis.io
• twemproxy:  https://github.com/推ter/twemproxy

作者簡介： 楊永杰，美麗說HIGO部公司的高級架構師，專注于基于LNMP架構的互聯網技術，全棧架構師。

（責編/錢曙光，關注架構和算法領域，尋求報道或者投稿請發郵件qianshg@csdn.net，交流探討可加微信qshuguang2008，備注姓名+公司+職位）