昨天，老馮看到小紅書技術公眾號發(fā)了篇《》， 寫了篇簡單的技術評論，沒想到文章發(fā)出后反響激烈，不僅被阿里云投訴刪除，還被扣上個 的帽子。

短短二字，似乎想把一場百億級互聯(lián)網(wǎng)巨頭基礎設施戰(zhàn)略轉(zhuǎn)向的討論，封殺在“真與假”的二元對立之中，但這確實讓我感到十分詫異。

難道不是小紅書技術團隊自己在公眾號文章里明明白白使用了“下云” 的表述嗎？

我也不知道“謠”在哪里，難道是是 “標桿客戶”？那就更離譜了，小紅書要是不算標桿客戶，那誰算？

俺尋思，大概還是這些事實串起來太敏感了：一旦“下云”這件事坐實，小紅書將成為繼字節(jié)跳動之后又一家準備撤離阿里云的互聯(lián)網(wǎng)巨頭級客戶。作為月活超 3 億、不僅是 “中國版 Instagram” 更是當代年輕人生活方式圣經(jīng)的超級 APP，小紅書的基礎設施選擇就像是中國互聯(lián)網(wǎng)下半場的風向標代表 —— 如果連小紅書這樣的“云原生”代表企業(yè)都開始逃離公有云， 那么公有云廠商多年來編織的 “上云是大勢所趨” 敘事神話將面臨崩塌。

問題就來了， “小紅書究竟有沒有下云呢？”

小紅書官方是怎么說的？

事實勝于雄辯，我們先看當事人怎么說。

在今年 4 月的 QCon 北京大會上，小紅書容器研發(fā)專家孫偉祥在《混合云架構下的小紅書聯(lián)邦集群彈性調(diào)度實踐[1]》演講中明確透露：

“小紅書一直被稱作一家‘長在云上’的公司……直到近兩年，隨著資源總量達到較大規(guī)模，才開始開展 自建云 工作?！?“小紅書構建了以 ‘自建優(yōu)先’ 為原則的聯(lián)邦調(diào)度體系……當自建資源不足時，云上資源可以靈活兜底?！?/blockquote>

請注意這幾個字：開展自建，自建優(yōu)先。

這可是小紅書技術團隊對外的公開演講?！白越▋?yōu)先”四個字，意味著在基礎設施的頂層設計上，自有機房已經(jīng)取代公有云成為了“一等公民”。

阿里云如果覺得這是造謠，是否應該先去和小紅書核對一下口徑？人家前腳剛配合宣傳完“500PB 史詩級遷云”，后腳就在技術大會上講 “自建優(yōu)先”，到底是誰的劇本拿錯了？

事實上，小紅書目前的策略非常清晰：“自建機房為主、公有云為輔”。他們不僅不滿足于租機房，甚至已經(jīng)開始設計和運營自己的數(shù)據(jù)中心。

那么問題來了：這種“自建上位”的行為，算 “下云” 嗎？

混合云，是“下云”的遮羞布嗎？

云廠商最喜歡用的一套邏輯是：“小紅書用的是混合云，并沒有徹底離開公有云，所以說“下云”是造謠?！?也許在某些云廠商的邏輯里，似乎只有把云上資源全部清空、徹底解約，才叫“下云”。

在 Gartner、IDC 等權威咨詢機構的定義中，“云遣返/下云”（Cloud Repatriation/Cloud Exit）是指 企業(yè)將工作負載從公共云環(huán)境遷移回本地數(shù)據(jù)中心、托管設施或私有云的 過程，這一過程并不要求 100% 的徹底斷舍離。判斷“下云”與否，不看你是否還保留著云賬號，而要看業(yè)務重心的“主權”在哪里。

我們需要區(qū)分兩種截然不同的“混合云”：

?以云為核的混合云：核心業(yè)務依然依賴公有云的專有云版本（如 Apsara Stack），控制面和技術棧依然被云廠商鎖定，自建機房只是云的延伸與補充。?自主可控的混合云：企業(yè)基于 Kubernetes 等開源標準構建獨立的調(diào)度體系。自建數(shù)據(jù)中心承載絕大多數(shù)穩(wěn)態(tài)核心業(yè)務，公有云退化為純粹的“彈性資源池”和“備胎”。

小紅書走的正是第二條路。今年年初的一個真實案例，就側(cè)面印證了這一態(tài)勢： 2025 年 1 月，由于美國 TikTok 禁令風波，大量用戶涌入小紅書。 小紅書在應對流量激增時透露[2]：

“最終，小紅書選擇依托聯(lián)邦調(diào)度體系，將需要擴容的業(yè)務從自建機房平滑分流到云上。 流量高峰過去后，再動態(tài)釋放云上資源…保障了自建資源的核心地位和成本可控性?！?/blockquote>

翻譯成大白話就是：平時主力跑在自家機房（便宜），云上資源只是應急備用（貴），用完立刻關掉。

當一家企業(yè)把公有云從“基礎設施”降級為“水電煤一樣的臨時工具”，把核心數(shù)據(jù)和算力搬回自己家。這種從“全量托管”到“核心自建”的戰(zhàn)略重心轉(zhuǎn)移，就是最典型的 “下云”。

如果非要等到 100% 銷戶才叫下云，那這個世界上恐怕沒有一家大公司能算“下云”了。用“混合云”這個中性詞匯來掩蓋客戶核心資產(chǎn)流失的事實，是典型的文字游戲。

說到底，小紅書從一個自我定義為“原生長在云上”的公司，演進為使用 自建優(yōu)先 的混合云架構，如果這都不算“下云”，那什么才算？

下云這筆賬，到底該怎么算？

企業(yè)通過技術架構調(diào)整實現(xiàn)“自建優(yōu)先”，背后的核心驅(qū)動力就是商業(yè)理性。

根據(jù) Bloomberg 等媒體口徑，小紅書 2024 年的營收預計達到 48 億美元（約 345 億人民幣），凈利潤預計突破 10 億美元（72 億人民幣）。 在互聯(lián)網(wǎng)內(nèi)容平臺行業(yè)，IT 基礎設施成本（IaaS+PaaS+帶寬）通常占營收的 10% 到 15%。 對于擁有 500PB 數(shù)據(jù)湖且大力投入 AI 的小紅書，這個比例只高不低。

若按照行業(yè)通用模型推算，小紅書每年的 IT 基礎設施投入理論上可能高達 35億 - 50億人民幣。 這可能相當于小紅書 2024 年全年凈利潤（72億）的 50-70%！這都夠修兩三個超大規(guī)模數(shù)據(jù)中心了。 注：以上數(shù)據(jù)為基于公開行業(yè)數(shù)據(jù)的粗略估算，不構成對小紅書實際財務狀況的判斷。實際數(shù)字以小紅書官方披露為準。

小紅書斥資自建數(shù)據(jù)中心，難道是準備 Cosplay 世紀互聯(lián)掙 15% 的毛利當寓公嗎？當然不是。當一家互聯(lián)網(wǎng)公司下決心投入巨資自建大規(guī)模數(shù)據(jù)中心時，最符合常理的推測是：他們打算把最主要、最穩(wěn)定的那部分負載搬離公有云（畢竟建設這么高標準的數(shù)據(jù)中心當冷備，在財務上完全沒法說通） —— 也就是將過去長期托付在云廠商上的基石業(yè)務遷回自己的機房，以實現(xiàn)降本增效。

誰又是小紅書過去份額最大的那個云供應商？小紅書采用的是多云策略，但從公開信息和行業(yè)經(jīng)驗來看，阿里云無疑是其最大的云服務供應商。這也是阿里云自己宣傳與表態(tài) —— “2023年1月，阿里云成為小紅書第一大云資源供應商”。https://developer.aliyun.com/article/1424151

老馮在之前的專欄里多次用詳細的數(shù)據(jù)深入分析過，對于規(guī)模以上企業(yè)而言，下云可以實現(xiàn)效果驚人的降本增效。 ，。 如果半年的房租就能買下這套房子，誰還會會選擇租房住呢？如果你對這個主題感興趣，歡迎閱讀：

????

更何況， 并非小紅書一家之選，而是全球科技先鋒的前沿實踐：

?，他們公開表示自建成本僅為用云的 1/10。??Dropbox 下云后，兩年節(jié)省 7,460 萬美元，毛利率直接從 46% 飆升到 70%+。

除了顯性的賬單成本，更可怕的是 “鎖定稅”。 當你的身家性命全在云上，且沒有自建能力作為談判籌碼時，你就喪失了定價權。 小紅書斥資自建數(shù)據(jù)中心，就是在奪回對基礎設施的議價權。

對于正在尋求 IPO 或更高估值的小紅書來說，通過架構優(yōu)化每年節(jié)省數(shù)億乃至十億級別的成本直接轉(zhuǎn)化為凈利潤，還能通過PE放大幾十倍。 繼續(xù)賴在公有云上，才是對股東財富的揮霍。

安全感：雞蛋不能放在一個籃子里

如果說成本是“慢性病”，那么可靠性就是“心臟病”。

最近這幾年大型云廠商的故障記錄，只能說讓人不忍直視。雖然說任何一家云廠商都有可能發(fā)生故障。但正因如此，規(guī)模越大的客戶越傾向于分散風險。雞蛋不能放在一個籃子里 —— 即使是你的股東。

如果說 是 “全球同此涼熱”， 那么 2024年7月 則精準打擊了小紅書的大本營 。讓小紅書親身體驗了一把何謂 “把雞蛋放在一個籃子里” —— 單一云可用區(qū)的故障，瞬間令其主要服務陷入不可用。

當你每年交著巨額的費用，卻依然還要擔心被“一波帶走”時，自建數(shù)據(jù)中心、掌握基礎設施的主動權，就成了安全感的來源。

小紅書的啟示：技術的成人禮？

小紅書之所以敢于挑戰(zhàn)阿里云的權威，在于其技術團隊這些年在架構演進中做對了幾件關鍵事情，巧妙避開了 深度供應商鎖定 的陷阱：

全面容器化與Kubernetes：小紅書是K8s的深度用戶，大量業(yè)務以容器形式部署在云上[3]。 這使得應用和底層基礎設施解耦——無論運行在阿里云ECS上，還是自建機房的裸機上，對應用來說幾乎無差別。這為大規(guī)模遷移提供了技術基礎。

擁抱開源中間件：在數(shù)據(jù)庫和中間件選型上，小紅書傾向于使用 業(yè)界主流的開源技術棧并自行定制優(yōu)化，而非過度依賴云廠商的封閉托管服務。 例如，他們的大部分數(shù)據(jù)存儲采用自建的 MySQL， MongoDB， Redis 集群。選擇開源方案意味著遷移時無需重寫應用邏輯，只需做好數(shù)據(jù)同步和配置切換即可。 這極大降低了從云托管服務切換到自托管服務的難度和風險。

擁抱開源，就是擁抱自由。 今天的開源生態(tài)（如 Kubernetes, Pigsty, Kafka 等），已經(jīng)讓企業(yè)具備了低成本構建“平替”云廠商核心能力的基礎。 云技術已經(jīng)祛魅，早已不再是云廠商的獨家秘籍了。

當然，“下云”之路并非坦途，我相信小紅書在推進過程中也會面臨各種挑戰(zhàn)：

數(shù)據(jù)重力的牽絆：計算易遷移，數(shù)據(jù)難遷移。小紅書有海量的數(shù)據(jù)湖和數(shù)倉。如果這些數(shù)據(jù)工作負載早期深度綁定了阿里云的大數(shù)據(jù)平臺（如MaxCompute/ODPS等）， 那么要將其遷回自建的大數(shù)據(jù)集群，將面臨巨大的數(shù)據(jù)搬遷成本和兼容性問題。這可能也是目前小紅書保持“混合架構”狀態(tài)的原因 —— 。

當然，“下云”之路并非坦途。數(shù)據(jù)重力的牽絆、數(shù)據(jù)庫的遷移、運維團隊的建設，都是巨大的挑戰(zhàn)。 但小紅書的選擇證明了：只要規(guī)模足夠大，你就有資格成為自己的云。

結語

小紅書的“下云”嘗試，不應被妖魔化成對云計算的否定，恰恰相反，這是中國互聯(lián)網(wǎng)企業(yè)走向成熟的標志，是一場必經(jīng)的“成人禮”。

與其說小紅書 “下云”，倒不如說它是 上岸 了 —— 從云廠商構筑的溫室中走出來，踏上了堅實的地基，一磚一瓦地搭建屬于自己的數(shù)字城堡。 而這，正是所有超級獨角獸從雛鷹到巨龍的必經(jīng)之路 —— 當你的規(guī)模足夠大，你就成了云本身。也許用不了多久，我們還能看到一個新的 “紅薯云” 出現(xiàn)。

將關于“下云”的技術探討定性為“謠言”，這種急于“蓋棺定論”的應激反應，恰恰暴露了行業(yè)舊秩序面臨崩塌時的集體焦慮。隨著字節(jié)跳動（火山引擎）、京東（京東云）甚至拼多多等巨頭紛紛驗證了“自建內(nèi)核+云服務外溢”模式的優(yōu)越性， 云廠商正面臨核心客戶流失的結構性挑戰(zhàn)。 真正有底氣的廠商，不應該急于封口，而應該大大方方地表示：“是的，小紅書長大了，他們具備了自研基礎設施的能力，我們祝賀客戶的成長?！?/strong>

老馮自己是開源 PostgreSQL 發(fā)行版 Pigsty 的作者，不靠自媒體吃飯，寫文章只是為了說點真話，也沒興趣和功夫去造謠誰。 我只是希望，在這個行業(yè)里，客戶不僅有選擇“上云”的權利，也有選擇“下云”的權利，更有討論“為什么要下云”的權利。

如果連這點討論的空間都沒有，那才是中國軟件行業(yè)的悲哀。

References

[1] 混合云架構下的小紅書聯(lián)邦集群彈性調(diào)度實踐: https://www.infoq.cn/article/ttq25vxglrfw3pruaesc
[2] 小紅書在應對流量激增時透露: https://explodingtopics.com/blog/rednote-surge
[3] 小紅書是K8s的深度用戶，大量業(yè)務以容器形式部署在云上: https://cloud.tencent.com/developer/news/901963

專欄：云計算泥石流

云故障

云資源

下云記