24億級用戶超級APP背后的全技術大揭秘
進入十億級用戶“APP 俱樂部”，可以說是很多做 APP 的公司夢寐以求的目標。
2017年，剛剛成立2年的茄子科技（海外SHAREit Group）交出了一份亮眼的出海成績單，旗下APP SHAREit（國內茄子快傳）全球用戶總數(shù)達到了10億+，躋身十億級用戶“APP俱樂部”。
之后，SHAREit 仍保持著驚人的增長速度。2018 年，SHAREit 全球用戶超 15 億，2019 年，SHAREit 全球用戶超 18 億，月活超過 5 億。截止目前，茄子科技包括 SHAREit 在內的多款 APP 產品全球累計安裝用戶量近 24 億。
伴隨著 SHAREit 在全球成為“爆款”產品，茄子科技也成為國內出海潮中的眾多互聯(lián)網(wǎng)公司中先一步闖出一番天地的佼佼者。出海之旅愈發(fā)深入，抵達終點的路徑也就愈發(fā)清晰，這是一場關于產品、技術、運營的綜合考驗。
對于出海企業(yè)來說，如果把移動互聯(lián)網(wǎng)產品看作一根支起全球的“撬棍”，那么這根撬棍能發(fā)揮出多大的力量，離不開背后堅實的技術支撐。
近日，InfoQ 專訪了茄子科技多位技術 Leader，試圖從技術的維度探究下，幾十億量級的超級 APP 是怎樣“煉”成的，以及在技術的護航下，這家公司是如何支撐業(yè)務一路迅猛擴張到 24 億用戶規(guī)模的。
基于 24 億級這樣龐大的用戶規(guī)模，應該怎樣做基礎架構搭建？
成立 6 年來，茄子科技用戶規(guī)模從 0-1 的過程，實際上也是該公司的基礎架構從 0-1、從 1-10 的建設歷程。
茄子科技基礎架構負責人在接受 InfoQ 采訪時表示，無論從用戶角度，還是從服務端建設角度看，公司整個基礎架構從一開始簡單的、小規(guī)模的系統(tǒng)，逐步演進到了全面的分布式系統(tǒng)。
整個架構演進分為 2 個階段：
初級階段：
早期產品功能簡單，數(shù)據(jù)量少，算法相對簡單，業(yè)務迭代速度快，大約一周迭代一個版本，但面臨后端人力不足的挑戰(zhàn)。整個后端業(yè)務 100% 在公有云上，團隊充分利用公有云的 SaaS 和 PaaS 服務來支持業(yè)務迭代。
快速發(fā)展階段：
到這一階段，在某些業(yè)務場景下，公有云 SaaS 和 PaaS 服務已經無法滿足需求。
一是成本的需求。當業(yè)務規(guī)模小時，采用公有云的 SaaS 和 PaaS 服務的成本較低，但一旦業(yè)務規(guī)模擴大，數(shù)據(jù)規(guī)模和服務壓力成數(shù)量級增長后，成本會線性上漲。二是與功能 / 性能相關的需求。公有云的 SaaS 服務提供的多是標準化、通用的能力，其會為解決多租戶問題設限制。隨著公司業(yè)務發(fā)展，已觸發(fā)了諸多限制進而導致影響業(yè)務增長。
因此，茄子科技開始逐步減少對云廠商的深度依賴，在采用其基礎設施層面的 IaaS 服務的同時，與自研服務相結合，完成對業(yè)務的支持。
后來，在公司由工具型產品向內容產品轉型的過程中，數(shù)據(jù)量日益激增，推薦算法不斷增加，進一步提高了對數(shù)據(jù)存儲及算力的要求，于是，茄子科技結合開源軟件引入了大量自研架構服務。
目前，茄子科技的架構分為兩方面：一是 IasS 層面依托公有云提供基礎資源，整體采用混合云的多云架構，以最大化獲取云計算資源，充分應用每個云廠商的優(yōu)勢，提升議價能力。
二是根據(jù)自有業(yè)務場景采用開源 + 自研架構。在技術組件選擇方面，現(xiàn)階段主要以開源方案為主，并在此基礎上針對業(yè)務場景做深度擴展和定制，如在開源軟件基礎上定制自有的 KV 存儲系統(tǒng)。
茄子科技一開始只采用“一朵云”，后來綜合權衡容災、成本等因素，轉向多云架構。
但這一轉變并不容易。
在這個過程中，要做部分用戶和業(yè)務遷移。但以前在“一朵”公有云上時，與公有云的各種服務做了技術上的深度綁定，這導致無法直接平行遷移。需要對基礎架構和基礎服務升級改造后，再進行服務遷移。
服務遷移相對容易，麻煩的是做整個架構升級，因為它要求全公司所有業(yè)務線都要動起來，這極為考驗整體架構的擴展能力。在遷移過程中，還要保證零事故、無縫遷移保證高可用，讓用戶不受任何干擾。
而且，產品 / 業(yè)務迭代發(fā)展不等人，研發(fā)人力沒有冗余，留給整個遷移的時間窗口非常短，僅僅只有不到六個月時間。
時間緊張，基礎研發(fā)團隊通過倒排工期，快速推進，制定了“四步走”計劃：
一，和云廠商共同制定整體架構方案；
二，內部云平臺團隊與基礎架構團隊聯(lián)合制定自研方案，商討自研架構方案如何適配到業(yè)務側；
三，與業(yè)務研發(fā)部門一起制定零事故實現(xiàn)平行遷移和架構升級方案；
四，拉通所有團隊高效協(xié)作。
一步一步邁進，克服了所有挑戰(zhàn)后，最終，基礎研發(fā)團隊在規(guī)定時間內完成了遷移，在這個過程中，也成功做到了零宕機事故，對用戶零干擾。
上述負責人表示，現(xiàn)在乃至于未來一段時間，茄子科技還會采用混合公有云方案來支撐業(yè)務，應用架構朝著云原生架構方向走，“云原生，要生在云上，長在云上，要用云的各種便利性，例如，應充分利用公有云靈活的彈性擴縮容能力及多云融合跨區(qū)域的容災能力，來實現(xiàn)高可用性、高性能、高可擴展的架構”。
關于技術選型背后的邏輯，茄子科技側重綜合平衡項目、團隊、技術三個方面。
項目：明確項目的性質、規(guī)模、重要程度、時間要求。項目需求會影響甚至限制技術的選型，如果項目是實驗性項目且開發(fā)時間短，此時要重點考慮快速開發(fā)能力，框架選型考慮選用生態(tài)成熟的技術。如果項目重要且開發(fā)周期長，這時對并發(fā)性、實時性、可用性，數(shù)據(jù)一致性及安全性均有高要求，組件選型上尤其要慎重。
團隊：考慮技術團隊成員背景，針對較基礎的技術選型，如語言、框架、數(shù)據(jù)庫、中間件等，通常選擇適合團隊的、相對熟悉的技術。如果想選擇其他技術，要評估團隊是否 hold 住。
技術：從應用性、可維護性、可擴展性、性能等方面考慮技術特性，重點考察技術的成熟度、社區(qū)活躍度、架構匹配度等，側重評估技術是否適合業(yè)務場景。
隨著用戶量劇增，平臺復雜度會大大提升。如何解決復雜性的問題，上述負責人認為，首先從架構層面要做好分層解耦，業(yè)務系統(tǒng)層、中間件層、基礎服務層、云平臺層等權責明晰。分層后，需劃定好邊界，以避免各層互相推諉。另外，還離不開將單體服務微服務化、配置化，在微服務化拆分過程中要持續(xù)加強建設服務治理的生態(tài)體系。
出海環(huán)境下，移動互聯(lián)網(wǎng) APP 用戶群體遍布全球，這對做好個性化分發(fā)和推薦，滿足不同用戶深層次的個性化需求帶來了極大的挑戰(zhàn)。
茄子快傳的產品矩陣目前覆蓋全球 200 多個國家和地區(qū)，尤以新興市場 — 東南亞、南亞、中東、非洲、俄語地區(qū)為主。針對這么多國家，怎樣做算法推薦？
茄子科技大數(shù)據(jù)和 AI 負責人向 InfoQ 表示，針對不同國家，APP 采用相同的框架，但在內容推薦過程中，算法端存在差異，受眾群體變了，策略也要有相應調整。
在針對某一國家的用戶進行內容推薦前，團隊首先會從負責該國一線業(yè)務的人員處了解相關信息，如國家文化習俗，受眾特點、喜好等，再基于這些信息制定算法策略的 Baseline。
推薦算法的重心在于迭代。一方面會基于業(yè)務團隊反饋或者 Badcase 來調整，具象化共識。另一方面進行線上 AB 實驗，基于數(shù)據(jù)方法論來檢驗效果和調優(yōu)。
“茄子科技不光跟其他公司一樣面臨不同內容、類型的推薦，我們的推薦系統(tǒng)面向的受眾覆蓋眾多國家和地域，不似國內地域間差異不明顯。不同國家的差異有時候往往是巨大的，不同國家的用戶風格、習慣、偏好都存在較大差異。因此，我們的大數(shù)據(jù)投喂算法已覆蓋了多產品的多類內容，涵蓋業(yè)務種類多樣。在做好算法體系的擴展性的同時，我們針對不同國家、不同場景也會做額外的深度探察”，上述負責人表示。
現(xiàn)在個性化推薦已經不是社交產品發(fā)展的趨勢了，而成為了標配。但一個不能忽視的問題是，現(xiàn)階段個性化推薦還沒有那么智能。有時候，算法推薦的可能并不是用戶想要的，算法往往推薦給用戶大量相似內容，這反而會給用戶帶來困擾?！巴队脩羲谩焙汀巴诰蛴脩舻纳疃饶繕撕托枨蟆敝g的矛盾仍未完全調和。
對于這個問題，上述負責人認為，“投用戶所好”是淺度目標，而“發(fā)掘用戶深度需求”是深度目標，深度目標更難實現(xiàn)，難在其無法量化，不好刻畫。
他認為，這一矛盾的核心在于算法優(yōu)化目標。解決這類問題的前提是構建評價指標，進行推薦效果評估時，除評價單一目標優(yōu)化效果等目標外，還會從多目標的角度作評估，如關注多樣性、新穎性、驚喜度等。
當用戶偏好和深度目標發(fā)生沖突時，首先會基于場景分析業(yè)務目標，建立正向收益的同時，提出負向折損的忍耐度。在執(zhí)行中的判斷，會根據(jù)某些場景的獨立性、影響周期等做指標置換。但當深度目標不確定時，沖突比較難化解，對此，團隊在做置換的基礎上會基于價值取向，做更多服務于用戶長期增長的工作。
具體推薦過程中，團隊還會收集用戶端的反饋，來驗證推薦效果，推薦效果的 Feedback 和調優(yōu)是推薦最重要一個環(huán)節(jié)，團隊從方方面面全方位收集各種反饋，以此來做整體調優(yōu)。
據(jù)了解，茄子科技整個數(shù)據(jù)鏈路包括兩部分，一部分是偏技術方向的演變，另一方面是支撐多樣業(yè)務的演變。基于這兩類場景，采用兩類思路，第一類偏漸進，另外一類偏創(chuàng)新的思路。
其中，漸進思路往往映射通用解決方案，因為大數(shù)據(jù)從采集、處理、分析、架構，都有相對成熟的通用技術方案。茄子科技采用業(yè)界通用的流、批計算引擎，同時為了可靠性，并基于業(yè)務多變的訴求做漸進升級和二次開發(fā)，比如，茄子科技業(yè)務的特殊性使得在多云多區(qū)域上面臨不小挑戰(zhàn)，因此也會有針對性的做平臺層的封裝。
目前茄子科技還正在推進湖倉一體架構的逐步演變，將數(shù)據(jù)湖、數(shù)據(jù)倉庫等不同概念相融合。
前端工程化，通俗的理解是，盡可能快速地實現(xiàn)可信賴的產品。其中兩個關鍵詞，“快速” ，講求開發(fā)速度、構建速度、測試速度、問題定位速度；“可信賴”，包括代碼的質量、產品的性能、安全、及重現(xiàn)和定位問題能力。
茄子科技前端負責人介紹，SHAREit 的前端工程化建設經歷了三個階段：石器時代，工業(yè)時代，信息時代。
石器時代：
在石器時代，典型特征是單工程的 MVC 架構，公司發(fā)展初期人比較少，反而效率更高，問題也比較少。但隨著公司發(fā)展越來越快，SHAREit 從單業(yè)務發(fā)展到多業(yè)務的平臺型產品時，單工程架構在人員節(jié)奏方面出現(xiàn)了較多問題，如代碼耦合導致一些問題浮現(xiàn)出來。這時，便開始工程組件化重構，進入到工業(yè)化時代。
工業(yè)時代
工業(yè)化時代，典型的特征是組件化。茄子科技使用的是多工程、多倉庫的方案，每個組件或 SDK 都有自己獨立的倉庫，都可以獨立于主工程進行單獨的編譯和運行。這方面分為三大層：APP 的殼、業(yè)務層、基礎層，基礎層再往下還有更多、更細粒度的劃分。前端團隊自上而下通過 AAR 的方式進行依賴。組件化采用“分而治之”的思想，很好地解決了多團隊協(xié)同作戰(zhàn)的問題。
信息時代
隨著公司孵化更多產品，每個產品在不同國家定制不同功能，規(guī)模越來越大了，用以前的組件化形式很難高效地支撐現(xiàn)有的業(yè)務，于是，茄子科技引入了 Google Bundle 技術，進入到信息化時代。其實針對這一問題，國內多采用插件化的方案，但由于海外不能做插件化技術，茄子科技只能運用谷歌自有特性。
在信息化時代，典型的特征是 Bundle 組件化。Bundle 模塊具有反向依賴的特征。通過增加 Bundle 殼及自動化檢測工具的形式，讓 App Bundle 的特性和以前已有的組件化融合，讓開發(fā)者保持已有的開發(fā)模式。通過 App Bundle，可以做到針對每個國家用一個 APP 按需定制不同功能，如內容、直播、游戲等。
為提升效率和質量，茄子科技還搭建了客戶端 CI/CD 平臺，流程主要有編碼規(guī)范檢測、大文件 / 圖片檢測、靜態(tài)代碼掃描，關鍵文件觸發(fā) Review、代碼 Review、安全風險檢測，預編譯、包體積監(jiān)控，編譯速度監(jiān)控等，能做到自動打包、自動檢測、自動化測試與發(fā)布。
據(jù)悉，前端團隊已經涵蓋開發(fā)、測試、構建、部署一系列流程，通過自研 APM 系統(tǒng)的預警機制、自動分配、輔助信息等，能夠及時發(fā)現(xiàn)且快速定位問題，并優(yōu)化迭代，最終形成整個研發(fā)流程閉環(huán)。
如何保證全球 24 億級用戶使用產品的穩(wěn)定性，對茄子科技來說，是至關重要的一環(huán)。
“穩(wěn)定性” ，即產品可以給用戶預期內的服務。這句話看似輕松，但當面對海量用戶以及復雜的全球環(huán)境時，實現(xiàn)起來就不容易了。
具體而言，服務端高可用、客戶端高可用、傳輸連接速度、傳輸速度、在線內容拉取性能、播放成功率等都屬于穩(wěn)定性體系建設的范疇。
為了確保穩(wěn)定性，茄子科技搭建了一整套作用于整個軟件開發(fā)周期的體系化解決方案。在開發(fā)階段有一系列開發(fā)規(guī)范以及本地校驗流程，便于研發(fā)提前發(fā)現(xiàn)問題；而從提交 MR 開始，構建系統(tǒng)會自動執(zhí)行預設的校驗流程，全部完成后才能合入主干；在測試階段，除常規(guī)測試外，還會覆蓋全面的自動化測試。在用戶真實環(huán)境中，會自動采集用戶使用中的穩(wěn)定性指標如啟動速度、卡頓、內存、崩潰、網(wǎng)絡等問題，上報后 APM 平臺會進行數(shù)據(jù)清洗、加工處理、自動分配，結合報警，開發(fā)就可以第一時間開始排查線上發(fā)生的問題。
茄子科技平臺自身的高流量特點對穩(wěn)定性要求高。茄子科技認為，穩(wěn)定性的范疇不應僅局限在平臺建設上，還要擴大至涵蓋組織、人、工具、故障管理等多方面、完整的穩(wěn)定性體系建設。
首先，從公司整個組織結構看，公司自上而下、跨團隊（包括業(yè)務團隊、基礎研發(fā)團隊、產品團隊、內容運營團隊等），都要達成穩(wěn)定性的共識機制。因為各個團隊對穩(wěn)定性理解不同，如果達不成共識，穩(wěn)定性建設就無從談起。
此外，根據(jù)成本、業(yè)務容忍度，系統(tǒng)當前的穩(wěn)定性狀態(tài)，針對不同的業(yè)務系統(tǒng)，設定不同的穩(wěn)定性目標，核心業(yè)務的目標穩(wěn)定性顯然更重要。穩(wěn)定性體系建設過程中也要避免“一刀切”都是最核心指標，這需要我們做好穩(wěn)定性、成本、研發(fā)效率之間的平衡。
從人的角度看，開發(fā)、測試、運維、安全，需要每個人從自身崗位出發(fā)去做技術體系的建設，做好流程規(guī)范、開發(fā)規(guī)范、測試規(guī)范、運維上線規(guī)范、事故復盤等。
穩(wěn)定性建設還離不開工具作為手段。從工具的角度看，要通過客戶端鏈路埋點，服務端限流降級等一系列技術方案的需求，由基礎研發(fā)團隊輸出一系列的支持工具和平臺。
穩(wěn)定性建設里，最關鍵的一點是故障管理。故障管理分為故障前、故障中、故障后。
事前預防，包括做業(yè)務成熟度評估，分析其短板；做容錯測試，通過主動性測試提高故障處理能力；上線前做容量評估和規(guī)劃。還要建立流程，保證故障發(fā)生時能第一時間響應。
當故障發(fā)生時，又該如何應對？首先是機制保障，故障要是沒有機制保障，其他的事情便無從談起。這些機制包括，故障發(fā)生后相關團隊能否快速響應，共同成立臨時“作戰(zhàn)室”，快速解決線上故障；當故障升級或者高等級故障發(fā)生時，是否有足夠的資源投入等。針對一些底層的業(yè)務組件，茄子科技還會和云廠商一起聯(lián)合排障。
故障解決完了，但事情還遠遠沒有完。故障解決完后的總結、改進和跟蹤也不能忽視。故障處理完后，各個業(yè)務方會一起復盤故障原因，并列出整改措施。復盤結束后，相關人員會對措施關鍵節(jié)點進行追蹤、寫故障報告，最終輸出到故障知識庫，作為以后的查閱。
最后，會檢查類似 / 關聯(lián)服務是否存在隱患，通過舉一反三的思路，避免減少重復犯錯。
據(jù)悉，茄子科技已打通了公司多個內部系統(tǒng)，讓開發(fā)部門在解決問題時能得到更全面的信息，方便定位問題、解決問題。
“如果一句話來總結：我們的穩(wěn)定性系統(tǒng)，核心是數(shù)據(jù)，依托的是平臺，并且建立了一整套閉環(huán)體系化流程?！鼻炎涌萍记岸素撠熑吮硎?。
來源：infoQ
——————END—————— 歡迎關注“Java引導者”，我們分享最有價值的Java的干貨文章，助力您成為有思想的Java開發(fā)工程師！