嘉賓｜Wood（張木喜）

編輯｜薛梁

1 寫在前面

11 月 10 日，今日頭條正式與北美知名短視頻社交產品 .ly 簽署協議，將全資收購 .ly，在此之前，.ly 的全球 DAU 超過 2000 萬，但國內鮮有人知道這家公司和其業務。

2023 年初，從易寶離職的陽陸育 Louis 拉上同樣熱愛音樂的前同事朱駿一起創辦了 .ly。這是一個強調音樂元素的短視頻應用，用戶可以先拍攝一段生活中的視頻，然后在樂庫中配上音樂，從而快速地創建時長 15 秒的 music video；或者從喜愛的歌曲中獲得靈感，配上一段有意思的畫面，然后分享給自己的朋友。

巧合的是短視頻運營劣勢，即將于 2023 年 12 月 8-11 日在北京舉辦的 全球架構師峰會上，.ly 高級技術副總裁 Wood（張木喜）老師也是會議的聯席主席之一并兼任出品人。

借此機會，InfoQ 很榮幸地在會前采訪到他，請他聊聊 .ly 發展的這幾年在架構上的迭代經歷，以及未來支撐龐大業務背后的數據平臺架構該如何搭建等思路。本文基于采訪整理而成。

2 .ly 功能模塊及架構

木喜老師首先簡單介紹了 .ly。他說，.ly 是一個短視頻社交應用，從某種角度看，可以類比為短視頻的微博，包含視頻發布，視頻信息流，評論，關注，點贊，用戶主頁，私信，通知，話題等功能。

短視頻社區是一個與娛樂內容分享和觀看為主要特征的社區，所以短視頻的信息流和推薦無疑是用戶用得最多的功能，實際上用戶進入應用直接就到信息流頁面，.ly 是一個內容創建非常活躍的社區，平日每天創建的短視頻數接近 1000 萬，周末更超過 1500 萬。視頻的生產和消費是驅動社區發展的主干功能，而支撐社區互動的點贊，評論和關注則是緊隨其后的用戶用得最多的功能。

3 緊耦合架構的優勢和劣勢

我們關注到，.ly 最初的運營系統采用了傳統的緊耦合架構，這樣的架構固然存在優勢和劣勢，木喜老師回憶說，早期 .ly 的架構不是為大規模站點設計的，而且從今天的觀點來看，這也是當時最能適應業務早期快速迭代和功能驗證的架構。

當時采用的方案是經典的 加上 SSH 架構，數據庫用 MySQL，緩存用 ，簡單可靠，不需要開發人員有復雜系統經驗，所有的功能用一個 ，業務稍微成長也能通過簡單擴機器解決。實際上，在創業早期進行復雜的架構設計帶來了額外的成本，對快速推進業務有害無益。簡單，快速，滿足需要，是這種單一架構的優點。

.ly 這套架構一直支撐到接近 100 萬日活，但是這樣的架構劣勢也比較明顯：

正是在這樣的情況下，.ly 團隊開始進行全站微服務化改造。

現在回顧起來，這樣的演進路徑適合絕大多數的創業公司，就如軟件工程強調“不過度、不過早設計”一樣，早期在業務不確定性很大的情況下，把精力放在功能打造上，在業務成長起來后有足夠的時間去做更適合當前要求的設計。況且一般的早期創業團隊很難吸引高水平的技術人員加入，過早考慮規模問題更不可取。

4 微服務架構改造

.ly 技術團隊都有 Java 背景，剛開始進行改造的時候框架選用的是 框架：

在微服務架構基本成型之后，根據經驗，團隊對框架本身做了較多的改造，替換了更友好的注冊中心 ，采用了 gRPC 作為遠程調用框架，用 作為序列化框架短視頻運營劣勢，替換了熔斷和限流方案，集成了故障診斷和追蹤功能等等，這些改造對業務是透明的。

.ly 的應用層架構從上到下分為：

遵循的基本原則是：服務只能從上往下進行調用，同層之間不能互相調用，同層和底層業務對上層業務的耦合只能通過異步消息進行。這保證了接口調用深度的可控和最快的響應速度。

社交應用本質是事件驅動的系統。當用戶出發一個動作，會在各個子系統之間形成一系列后續動作，就跟漣漪效應一樣，事件會在系統范圍內擴散。所以 .ly 的架構是面向異步的，盡可能簡化同步調用所做的功能，而且盡量減少前端系統對后續動作的感知，把耦合的位置后置到數據庫之后。

舉個例子，用戶對一個視頻點了贊，對前端系統來說，做的是一個最簡單的操作，就是簡單驗證用戶對視頻是否可以點贊，然后就直接添加點贊記錄，這保證了用戶操作的快速響應。

.ly 技術團隊在系統中盡可能地使用變化捕捉技術 CDC，實際上就是盡可能地利用 MySQL 強大的 功能，通過對 的監控和處理，讓前端業務無需關注后續業務。CDC 捕獲變化后，會把數據庫的變化轉化為目標事件，注入消息隊列，采用了 Kafka，其最好的特性之一是單一事件可由不同的消費者消費多次，這樣無論擴展了多少種后續業務，只需要開發出不同的消費端即可，對原有系統不需做任何改變，很好地實踐了單一責任原則，極大地提升了系統的擴展性和穩定性。

木喜老師說，技術團隊在微服務的基礎上，提出了泛服務的概念，提出一切皆服務，服務只有協議、功能和有無狀態的不同，通過服務注冊和發現完成耦合。數據庫、緩存、中間件、業務服務都是微服務，這極度簡化了 .ly 系統的概念模型。

5 基于云的系統高效部署和優化

目前，.ly 在系統運維上也嘗試了 AIOps，并做了很多努力，目標是讓系統在低風險的情況下盡可能地實現自動化運維，提高系統的可用性，降低手工干預的強度。

前面講到泛服務，其實 .ly 內部還有另一個概念，叫融合架構，就是從系統設計上，把業務架構、平臺架構、數據架構作為一個整體來考慮，把一切運行的程序都 API 化，這就為全面自動化和數據驅動以及更高大上的 AI 留下了切入的接口。

CI、部署、監控、伸縮容都是 API 化的，加上 .ly 的系統部署在云上，云本身也是可編程的（這是云最大的優點之一）。這樣 .ly 系統可以分為兩大類，業務服務和為業務服務提供支撐的系統服務。結合服務的全面 化，實踐了 IaC（ as Code）設計。通過 SPEC 來完成對部署和狀態的定義，而非過程化的腳本。基于目前的系統服務，實現了兩個比較有特色的功能：

接下來，實現系統的單元化部署，使系統能快速實現在全球不同數據中心的快速部署和復制是技術團隊的下一個目標。

6 國際化架構挑戰

.ly 的用戶遍布國內外，那么對于這種國際化業務場景，.ly 是如何克服網絡、本地化、部署及架構優化等等困難的？

木喜老師說，在世界的不同國家和地區，網絡情況差別很大，特別是新興市場國家，有些地區網絡情況非常復雜，運營商眾多。主要問題包括 DNS 解析延遲高，跨境距離?導致天然延時長，TLS 握手時間過長，傳統 TCP 缺陷導致的初始擁塞控制窗口小、存在慢啟動、無線弱網環境丟包概率大等。

.ly 技術團隊做了很多的努力來優化網絡連接，以部分實踐為例：

一、網絡協議：

二、本地架構：

7 如何能和 一樣支持 10 億日活用戶量？

木喜老師認為：支撐 10 億日活，挑戰來自于服務容量和數據處理能力兩個方面。

最基礎的還是業務的高并發以及大規模分布式數據服務，如何實現服務的可線性擴展和業務數據的海量存儲。

這是泛服務的延續話題。微服務的可伸縮性，業務服務器是無狀態的，理論上只有增加服務實例就可以實現業務容量的提升。所以關鍵在于實現有狀態服務的可擴展。.ly 的數據庫和緩存服務，在泛服務的理念下，也都是通過服務注冊進行耦合的。在這塊系統的設計上，團隊遵循組合優先及盡可能避免重復造車輪的原則，使用一套功能分離的組合服務來實現一套功能完善的分布式數據服務。在幾乎不改動開源軟件源代碼的情況下，通過膠水組件，完成系統的集成和耦合。

數據服務包含存儲，分布式，動態伸縮，高可用等模塊。以關系數據存儲為例，存儲是 MySQL，使用 來實現分布式訪問，MHA 用來做 HA，通過 .ly 自己開發的一些小組件來實現 MySQL 實例狀態和分片信息再 的動態更新，以及集群信息更新監控和 配置文件的映射，實現每個組件都干自己最擅長的部分，彼此互不感知，彼此分離，因而實現了最好的穩定性。

努力減少與系統正常進行無關組件與線上系統的耦合，集群的伸縮幾乎以離線的方式進行，只發生極短時間的切換，保證了系統的簡單可靠。目前的架構設計滿足支撐億級日活沒有太大問題，后續會隨著日活的增長進一步改進。

8 嘉賓簡介

張木喜（Wood），.ly 高級技術副總裁，2023 年底加入 .ly 蜜柚網絡科技，任高級工程副總裁，主持進行全面技術轉型。致力于高可用和柔性系統，以及從架構上促進業務和數據算法的融合，通過技術推動產品、運營。在此之前的工作經歷是點評架構師，阿里音樂天天動聽 CTO，有多年的系統架構、應用架構從業經驗，在微服務架構，分布式緩存，數據庫和大規模系統監控領域都有豐富經驗。2023 年加入天天動聽，領導產品技術團隊，進行天天動聽的基礎技術架構改造和產品研發。

再次感謝木喜老師接受采訪，期待木喜老師下周在 策劃的“架構升級與優化”話題，另外大會也榮幸地邀請到 .ly 技術部高級 Java 架構師杜鵬老師前來分享《基于社交關系的 Smart Feed 架構》，可識別下方二維碼或點擊 閱讀原文 進一步了解。