從0到千萬級併發服務架構演化

背景介紹

回顧

ShareSDK，顧名思義，分享的SDK組件，公司基於互聯網，早期主要以ShareSDK起家。今日思來，很幸運，能陪着ShareSDK一塊兒成長。

如圖
經典的單體應用架構, 和不少初創企業同樣，當時採用這種架構。用redis等緩存擋住併發，用MySQL來存儲數據。
前端的報表分析直接操做MySQL便可。
我並不反對單體架構，反而我以爲很合適，因爲初創企業業務形態並不穩定，單體架構其實很容易調整，殺雞焉用牛刀。

公司是國內第一家作移動端分享SDK的企業，隨着業務發展，因爲幾乎每一個APP都會有分享功能的需求，業務發展飛快。
我記得當時一個「魔漫相機」App就佔據了咱們半壁帶寬。

問題與挑戰

分流

在業務請求的入口並未根據業務作輕重之分，致使數據交互類的接口以及日誌數據上報的接口共享網關。

• 業務高峯，請求擁堵，核心數據交互的接口失敗致使用戶體驗極差
• 服務降級沒法實施，相對而言，日誌上報接口並不屬於核心業務流程
• 沒法作線路區分，只能統一使用BGP，帶寬等成本高

統計分析

早期數據直接落地MySQL，經過MySQL作統計分析。

• 數據插入併發數受限，性能堪憂
• 存儲集羣未拆分，不能根據業務特色分而治之
• 查詢慢

業務支持受限

因爲整個架構比較簡單，對於複雜的業務以及大數據分析支持基本上談不上

基於單體應用，咱們基本上看不到將來，這除了單體應用自己的侷限性以外，在架構上自己也跑不動。這樣就造就了成本以及資源的重度浪費。

系統架構演化

服務架構

• 經過業務域名拆分以及智能DNS，實現不一樣地域國家省市&不一樣業務落入不一樣網關(不一樣機房)，不一樣帶寬線路
• 業務拆分、微服務化，不一樣業務區別對待，資源上也是分而治之
• 服務拆分： 公共服務 & 具體業務服務

梳理後的整個服務架構，從請求端到網關API再到具體的業務處理，流量上能夠隨意切割以及合併，很方便的作擴容以及縮容操做。

數據架構

數據分爲基礎數據以及統計分析數據。
將核心關鍵的基礎數據，好比配置信息等提取出來，分庫存儲，將全部的統計分析數據以及可異步存儲數據落地本地磁盤，再由flume實時拉走。這樣帶來的好處有不少：

• 基礎數據能夠選用高性能存儲，極大加速部分核心業務響應
• 採用模hash、一致性hash、日期等算法分隔不一樣的數據，分實例存儲，方便擴容
• 引入搜索引擎，專職前端&客戶端的查詢請求
• 引入Flume、Kafka，採用落地日誌 + Flume + Kafka實現數據流分發，即便Flume掛了，因爲日誌先落地，因此待Flume修復後，仍然能夠保證數據無丟失無斷層繼續傳輸，而在Flume上面，咱們採用了Kafka Channel，而不是普通的FileChannel、MemoryChannel等，使之即便在流量高峯，也不至於致使FlumeServer掛起
• 不一樣數據分析需求（如APM、業務統計等等）接入FlumeServer 或者 Kafka 按需獲取數據處理

心得體會

上述簡單講到了服務架構以及數據架構的演化，可是細緻各個環節能夠有不少道道。包括服務的自動化部署，DI/DC以及鏈路監控等並未細說說起。
對於我的，最深入的理解有兩點：

• 分而治之

充分理解各個軟件工具自己適合的領域，讓專業的軟件工具對付它們擅長的業務，而不是一招拍死

• 充分理解業務

架構基於業務，好很差的架構要看什麼樣的業務，若是換成公司的IMSDK，顯然這個架構徹底不合適。

• 追求架構簡單

數據每一次流動，均可能伴隨必定的異常。那麼架構簡單如何體現？
能用一兩層服務解決的事情絕對不使用三層服務，方便數據追蹤跟進以及業務排錯。
其次，服務業務儘量簡單，ShareSDK的配置服務以及社交信息服務等都是各自獨立，這在團隊分工優化上也顯得簡單。

結語

誠然，整個服務架構能夠輕鬆應對千萬級併發。可是，我認爲能夠優化的空間還有不少。指望，整個ShareSDK服務架構能伴隨公司繼續成長壯大。