抓樂GO的系統架構是如何從0開始演進的？
每一步
每一步
關力瑒
00:00/04:43
本文是我在任職奇遇世界Java研發工程師兼架構師期間的一些個人架構經驗，主要概述一個從0開始如何在不斷演進的線上抓娃娃小遊戲的系統架構，參照大型分散式系統架構的目標：從高性能、高可用、可伸縮、安全性、可擴展、自動化及敏捷性等給出一個及格的架構設計思路。希望能對屏幕前的你有較好的參考價值！
抓樂GO架構的演進過程
一個成熟的的系統架構並不是起初設計時就要具備完整的高性能、高可用、高伸縮等特性的，而是隨著後期業務功能的擴展、用戶量的巨增逐漸演變完善的。所以好的系統架構往往是伴隨業務的成熟而逐步完善的，並不是一蹴而就，不同業務特徵的系統，都會有它們各自的架構側重點。例如淘寶，要解決海量商品信息的搜索、下單、支付；例如騰訊，要解決數億用戶實時消息的傳輸；還有百度，它要處理海量的搜索請求。
因為都有各自的業務特性，所以導致各自的系統架構也有所不同。儘管如此我們也可以從這些不同成功的架構背景中，總結一套更加抽象的系統架構模式來適用自己。
抓樂GO的萌新架構：
3月13號抓樂GO小遊戲正式發布，當時由於資源和人力因素的限制，支撐它的則是一個極其簡單的系統應用架構。應用程序、MySQL資料庫(免費開源版)、靜態文件資源(Java框架上傳下載存儲伺服器)和Redis非關係型資料庫(免費開源版)都部署在同一台雲伺服器上。
隨著用戶量的提升、遊戲內功能的不斷優化和業務線的擴展，導致客戶端對靜態文件的請求越來越頻繁，其次Redis是一個高性能的內存資料庫極其吃內存，導致伺服器整體性能下降，再加上整個業務架構中存在很多的定時任務導致服務常常被干奔，所以這種架構再也難以支撐發展中的業務需求。
應用、資料庫和文件等分布部署架構：
上面的萌新架構出現瓶頸的根本問題就是單台伺服器的性能難以支撐，所以為了滿足公司後期業務的發展，必須要引入新的伺服器來拆分各個組件部署到不同的伺服器上並協同提供服務。最後決定再準備累加倆台伺服器(北京和廣州)，將提供抓樂GO應用的所有介面服務和資料庫單獨放在一台新伺服器上(北京)，將定時任務的應用服務和Redis緩存服務遷移到另一台新伺服器上(廣州)，還有將後台管理服務和文件資源等都保留在之前的老伺服器上。最後根據各個應用服務的資源耗費情況調整不同的配置，達到最佳的性能效果。
分散式緩存和負載下的集群調度架構：
上面的分散式部署架構主要解決了硬體方面的性能問題，但主要還是要優化軟體和編碼層面的缺陷。首先參照了幾款成功的APP例如淘寶、快手等，發現他們都會利用緩存技術改善系統的性能，使用緩存主要源於熱點數據的存在，大部分應用訪問都遵循28原則（即80%的訪問請求，最終落在20%的數據上），所以我們可以對熱點數據進行緩存，減少這些數據的訪問路徑，進而提高用戶的體驗。
隨著後期遊戲體驗的不斷提升和日活量的巨增，單個應用服務作為大量玩家的遊戲入口會承擔大量的請求，這時單個應用服務的並發處理請求數不足以應付，所以通過搭建應用服務集群來分擔並發請求數，應用伺服器前面部署負載均衡伺服器(Nginx)調度用戶請求，根據分發策略將請求分發到多個應用伺服器節點同時提供用戶請求。
這裡選擇Nginx作為負載調度的原因很簡單：首先它對CPU、內容等資源的消耗非常低，而且非常穩定，其次它的並發數較高(官方測試5萬，生產環境至少可支撐2-3萬)，最後它不僅是一款高性能的http伺服器，還可以使用它提供的http服務作為系統中靜態資源的反向代理伺服器。
承載了以上架構的並發數和伺服器的性能提升，對之前自己搭建的那套開源免費版的MySQL資料庫也會達到一個性能瓶頸，所以這裡我選擇使用騰訊雲旗下高可用版的MySQL實例。
引進CDN提升抓樂GO資源的響應速度：
隨著抓樂GO的不斷改進，公司對APP內商品的圖片和應用資源的訪問速度有了更高的要求。到目前為止圖片資源和APK包的歷史庫還在不斷擴增，所以為了考慮不同地區用戶的體驗效果決定引進CDN來加速靜態資源的響應。
在現行的網路服務中，出現卡頓和訪問延遲的現象是非常明顯的，尤其是在訪問那些訪問人數比較多的伺服器時，卡頓和伺服器崩潰就更加正常了。CDN伺服器的引進，不僅僅可以加快資源的響應速度，還可以省下伺服器的一部分資源負擔，節省空間節省流量，艱苦創業，能省則省。
因為抓樂GO是一款線上抓娃娃小遊戲，對遊戲內各種圖片資源的呈現有很高的要求，之前在萌新架構中是單台伺服器提供所有的服務，性能本來就不是很高，再加上靜態資源是實時請求下載，所以響應速度非常慢。當時最為致命的是發布新的apk包後，要求用戶強制更新APP應用，所以伺服器經常被用戶干奔，儘管有了後來的分散式部署，但還是嚴重搶佔伺服器資源導致CPU和內外網帶寬被爆滿，報警簡訊每天轟炸LZ。
搭建分散式文件系統：
歷經5個月的鑄造抓樂GO終於要再次橫空爬上應用市場甚至推向國外，隨著公司內部運營策略的不斷完善也增加了不少熱門商品，展示效果也將計劃要從平面展示設計成3D模型的方式呈現，這樣一來，APP應用內商品的圖片將增加到幾十倍甚至更多，所以這時就有必要搭建一套分散式文件系統來支撐圖片資源的存儲及訪問。
經過商討：決定使用FastDFS來作為抓樂GO的圖片伺服器。
FastDFS是用C語言編寫的一款開源的分散式文件系統。專門為互聯網量身定製，充分考慮了冗餘備份、負載均衡、線性擴容等機制，並注重高可用、高性能等指標，使用FastDFS很容易搭建一套高性能的文件伺服器集群提供文件上傳、下載等服務。功能包括：文件存儲、文件同步、文件訪問（文件上傳、文件下載）等，解決了大容量存儲和負載均衡的問題。特別適合以文件為載體的在線服務，如相冊網站、視頻網站等等。
抓樂GO服務拆分，搭建分散式架構：
到目前為止，抓樂GO應用的業務線也算是擴展到很多方面了，例如遊戲服務、訂單服務、用戶服務和支付服務以及安全服務等，但是這些服務又是支撐各業務線的基本要素。所以我選擇將這些基本服務抽取出來利用分散式框架搭建一套分散式服務，其中dubbo是一個狠不錯的選擇。
Dubbo是阿里巴巴開源的分散式服務框架，它最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合），比如表現層和業務層就需要解耦合。
分散式就是將整個應用服務拆分成許多獨立的子應用服務，然後讓這些子應用服務通過遠程調用協同工作完成業務運轉。
大型網站的架構目標
高性能：始終以用戶為中心提供快速的請求訪問體驗。主要做到有較短的響應時間、較大的並發處理能力和較高的吞吐量等。
前端方面可以從減少HTTP請求數、使用瀏覽器緩存、啟用壓縮、CSS和JS位置、JS非同步、減少Cookie傳輸、CDN加速和反向代理等優化。
服務端可以從伺服器硬體性能如提高帶寬和CPU負載等，其次可以使用緩存、集群、非同步等方式優化。
數據存儲方面可以改用固態硬碟、光纖傳輸、分散式存儲框架和NoSQL資料庫等優化。
高可用：一個優秀的網站應該在任何時候都可以正常訪問，正常提供對外服務。行業內一般用幾個9表示可用性指標，比如四個9（99.99%），一年內允許的不可用時間是53分鐘。一般採用冗餘備份和失效轉移解決高可用問題。
服務端可以實現負載均衡集群調度、分級管理、服務分散式調用、服務降級等設計。
數據存儲方面可以實現冗餘備份（冷，熱備[同步，非同步]，溫備）、失效轉移（確認，轉移，恢復）等策略。
可伸縮：系統架構的伸縮性是指在不改變原有架構設計的基礎上，通過添加/減少硬體（伺服器）的方式來提高/降低系統的吞吐能力。在這點上很多架構師都習慣在數據層面實現分庫分表等操作。
安全性：從基礎設施安全、應用系統安全和數據保密安全三個方面給出建議。
基礎設施安全這塊一般採用正規渠道購買高質量的產品，選擇安全的操作系統，及時修補漏洞，安裝殺毒軟體防火牆。防範病毒，後門。設置防火牆策略，建立DDOS防禦系統，使用攻擊檢測系統，進行子網隔離等手段。
應用系統安全是最主要的一點，首先網站傳輸協議要採用https加密傳輸，其次要採用分散式單點登錄等，這裡可根據自身項目的性質去加固，保證項目的數據安全和用戶信息不被泄漏即可。
數據保密安全最基本的應該密碼加密存庫，數據定時備份等策略都應該做到位。
自動化：如果伺服器由於意外情況重啟，那麼希望你的應用進程都能夠自動重啟。這點我是深有體會，就在前不久公司的伺服器被可愛的用戶干奔了，第一由於疏漏沒有設置告警策略而沒有及時接到宕機的消息，第二沒有設置開機自啟。
敏捷性：網站的架構設計，運維管理要適應變化，提供高伸縮性，高擴展性。方便的應對快速的業務發展，突增高流量訪問等要求。
除上面介紹的架構要素外，還需要引入敏捷管理，敏捷開發的思想。使業務，產品，技術，運維統一起來，隨需應變，快速響應。
分散式網站架構部署案例
TAG:潛談Java |