數千臺服務器，千萬用戶量：竟然之家兩年雲原生改造歷程

導讀：傳統企業的決策鏈路一般是自上而下的形式，所以在互聯網化改造中，不只僅是研發層面，整個公司的管理人員都須要作好知識升級和觀念更新，這也是躺平設計家在過去幾年的上雲之路所經歷的。本文將聚焦竟然之家利用阿里雲容器服務（ACK） 進行雲原生實踐歷程，期待能幫助讀者瞭解傳統企業從傳統單體架構向雲原生演變的實踐路徑。

2009 年，竟然設計家 (Homestyler) 研發團隊正式成立，開始進行第一個版本的探索；現在，十年已過，竟然設計家正式改名爲躺平設計家，用戶量近千萬。在兩年多的雲原生實踐改造過程當中，整個團隊經歷了從運維數千臺服務器再到所有交付給雲，從探索上雲到利用 Serverless 和 Service Mesh 完成雲原生改造，最終總體可用性達到三個 9 以上，同時 IT 費用削減了近一半。本文分享了躺平設計家的雲原生實踐歷程。


自 2013 年由 Pivotal 的 MattStine 首次提出至今，雲原生（Cloud Native）這一律念正在逐漸重塑整個軟件生命週期。架構良好的雲原生系統在很大程度上是自修復、經濟高效的，而且能夠經過 CI/CD（持續集成 / 持續交付）輕鬆更新和維護。好在構成雲的服務器、磁盤和網絡與傳統基礎設施相同，這意味着幾乎全部優秀的架構設計原則仍然適用於雲原生架構。


可是在雲中，關於這種結構如何執行的一些基本假設會發生變化。例如，在傳統環境中配置替換服務器可能須要數週時間，而在雲環境中僅須要幾秒鐘，這些都是應用程序架構須要考慮的內容。


本文是對竟然之家的躺平設計家研發總監謝康進行的獨家專訪，有助於咱們瞭解這家企業從傳統單體架構向雲原生演變的實踐路徑。

實踐背景

躺平設計家原名竟然設計家（Homestyler），是竟然之家旗下專爲家裝設計打造的一站式服務品牌，包括相關工具和社區，主要服務於家裝設計師，目前國內有超過四十萬的設計師活躍在該平臺之上，國際設計師則已經超過九百萬。


在進行雲原生改造以前，竟然之家的技術棧相對傳統，早期的核心算法和系統都是基於 Scala 和 C++ 語言搭建，而現在已經很難招聘到經驗豐富的 Scala 工程師，短時間內用 Java 重構整個平臺代價又顯得過於高昂。與此同時，總體迭代速度很是慢，對需求的響應週期較長，創新能力也出現明顯不足，服務器運維、網絡等成本開支逐漸難以承受。


成立早期，傳統技術棧存在的問題尚沒有那麼明顯，總體業務只須要不到 10 臺服務器就足以支撐，基礎設施費用仍是能夠承受的。隨着用戶體量的不斷增大，尤爲是海外用戶的快速增加，即便服務器規模迅速擴展至數千臺，依然很難平穩度過每日的流量高峯。


因爲服務端渲染屬於計算密集型任務，對 CPU 資源需求很是高，每日高峯時段的任務數波動又比較大，常常出現高峯時段渲染出圖任務須要幾十分鐘甚至幾小時的等待，這麼長的等待時間對設計師來講是不可接受的。而更可怕是計算資源超過設計值集羣雪崩致使全部執行中任務所有崩潰。流量低谷時，大量服務器處於空轉狀態，資源並無獲得合理利用。


此外，躺平設計家整個研發團隊擅長的是在垂直領域，好比 3D 圖形以及圖像處理等領域的研發，卻不得不在非核心的方向，好比基礎設施運維上投入大量精力和金錢，並且隨着規模的持續增加，這部分紅本愈來愈高，致使軟件研發成本也開始愈來愈不受控，攤薄了本該用在覈心產品上的資源投入。


當時整個研發團隊陷入很是痛苦的狀態，謝康在採訪中調侃道：「當時與領先的互聯網公司的技術代差恐怕有 5 到 10 年之久。」


最終，在即將失去垂直領域先發優點的壓力下，面對着多種編程語言拼起來的龐大、臃腫的技術平臺，整個團隊最終咬牙決定「要革本身的命」，決定經過雲平臺打通底層技術棧，向雲原生架構遷移，放下一直揹負的包袱，注意力從新迴歸核心業務。

雲原生演變

在決定遷移以後，整個團隊對當時的雲平臺需求是比較清晰的。


謝康表示：

• 首先是穩定性，自建機房時期很難達到較高的穩定性，常常遇到各種網絡和軟硬件設施致使的問題；
  
• 其次是總體系統彈性，須要在流量高峯時迅速擴容，流量低谷時進行資源回收以下降成本；
  
• 最後是高性能，如前文所言，設計渲染對計算能力的要求較高，屬於 CPU 密集型計算，而上述這些都是傳統公司自建機房很難達到的。相比之下，自動化運維的便捷性和系統可靈活擴展的優先級則顯得不那麼迫切。
  

最終，通過多方考量和評估，整個團隊在 2016 年開始基於 AWS 進行雲原生改造 (後總體遷移至阿里雲)。

第一階段：組織架構調整及微服務改造

1967 年，馬爾文·康威提出康威定律, 用一句話歸納就是：「設計系統的架構受制於產生這些設計的組織的溝通結構。」按照康威定律的說法，組織結構必定會反映到系統架構上，而傳統企業大都習慣了自上而下的驅動方式。所以，在進行微服務改造以前，躺平設計家對組織架構和人員均進行了調整。


謝康表示，躺平設計家最初成立時大部分員工來自 AutoDesk，併入竟然集團後又受其影響，最終這些體如今決策模式，組織結構上均與國內互聯網企業有巨大差別。若是但願進行改造，就須要對組織架構先進行調整。具體來講，躺平設計家整個技術團隊在 3D 圖形及圖像處理等核心算法上有獨特優點，所以重點保留了研發工程師，將不得不作且又不擅長的中間件和基礎運維等工做交給阿里雲。


網絡和機房整個團隊基本在架構中消失，運維團隊大幅縮減，而產品團隊，算法團隊、大數據團隊，包括處理大規模實時計算的研發人員都在增長，並開始招募 ServiceStack 和 Docker 等雲原生相關研發人員。


在組織架構調整基本完成後，團隊開始進行微服務改造。此時，新的問題又出現了。


與大多數傳統企業相似，躺平設計家的系統最初採用的也是單體架構模型，可是規模很是龐大，上百個服務糅合在一塊兒，服務間的邏輯依賴異常複雜，若是上雲前先在本地進行微服務改造，整個拆解過程想必既耗時又耗力，甚至能夠說短時間內根本不具可能性。


謝康表示，當時，整個團隊採起了很是激進的作法，經過 Service Mesh 將服務治理能力下沉到基礎設施，這樣就能夠在不對系統進行深度改造的狀況下將應用運行在雲平臺之上。


之因此選擇 Service Mesh，也是由於最初的技術棧基於 Scala 和 C++ 編寫，不經深度改造其在雲上很難良好運轉，且當時微服務支持方面也比較欠缺。


隨後，團隊就能夠在不影響業務正常運轉的狀況下對應用進行微服務劃分和重構，總體運維和伸縮部署變得十分容易。謝康補充道，躺平設計家可能也是國內最先一批使用 Service Mesh 的公司。在通過一段不太長的遷移以後，躺平設計家的全部核心業務已經所有運行在阿里雲平臺之上，並部分完成了微服務化改造。


可是，嚴格來講，這一階段的「硬搬上雲」雖然經過上雲享受到了雲平臺自己提供的彈性、可用性及強大的計算能力等優點，但整體價值提高還並非很是明顯。


不過，整個團隊依舊按計劃進行第二階段改造，緣由以下：

• 一是由於持續的雲原生化已經成爲企業的必選項，不管是公有云仍是私有云，不借助雲原生的賦能，當時的 Homestyler (後來才改名爲躺平設計家) 與主流互聯網公司間的技術代差只會愈來愈大；
• 二是自從進入互聯網 2.0 時代，企業的規模化愈來愈重要，以當時的體量和產品迭代速度，若是不向雲平臺遷移，不經過快速轉型打磨出爆款產品快速成長起來，將很快失去先發優點而且後續的生存壓力也會很是大。
  

第二階段：從上雲到雲原生

在第一階段改造接近尾聲之際，躺平設計家立刻開始了第二階段的改造，就是系統的深度微服務化改造和集羣的規模自動化及集羣自動化治理和按需伸縮能力。謝康表示，第二階段已經開始從單純上雲向雲原生方向改造，價值也比較明顯，改造完成後總體的交付速度和運維自動化能力均有大幅提高。


舉例來講，雲原生改造以前，躺平設計家的交付週期可能以季度爲單位，現在的交付週期已經縮短至以周爲單位，每兩週還會進行大的功能升級。並能在流量高峯時，作到以分鐘爲單位計算集羣擴展，高峯時間段也能夠作到及時出（設計）圖，這一點甚至超過了部分本地化軟件，再也沒發生大範圍的計算停滯故障。


與其餘互聯網公司同樣，躺平設計家也有着大量 Web 應用和微服務，這些都運行在阿里雲容器服務（ACK）中。


不過謝康表示，不一樣的是，躺平設計家服務器更多運行着計算密集型任務，原來 IDC 機房中的大部分服務器都是 48 核，甚至 96 核的定製機型，相似的高配服務器多達幾百臺，並且長時間極限壓榨服務器算力的運行方式也致使機器故障率很是高。


在改造過程當中，若是想對這樣的系統進行大規模改造上雲並非一件容易的事情。整個團隊與阿里雲的架構師和技術專家們共同改造，屢次克服兩地協助諸多不便，一塊兒討論制定方案，測試最終在阿里雲上完美解決計算密集型任務上雲的問題。


目前，躺平設計家已經所有退役線下渲染服務器，並遷入阿里云云主機和阿里雲容器服務 ACK，實現應用服務層面的彈性伸縮與完美運行，不再用擔憂服務硬件設施故障致使的忽然計算力雪崩，並能在用戶提交任務時動態調整集羣規模。


除了上述經過上雲解決計算資源按需伸縮的問題，謝康也表示，Serverless 和 Service Mesh 在躺平設計家的運用也愈來愈普遍，隨着雲原生改造的持續進行，愈來愈多須要按需伸縮的計算節點被解耦出來，重構掉以前嚴重依賴狀態和過程當中頻繁讀寫外援數據的問題後，這部分邏輯所有遷移到了 Serverless 的節點中。


經過一系列 Trigger 觸發，不只讓整個系統變得更加靈活，僅需支付運行期間費用的方式也很是經濟。基於阿里雲的 Istio on ACK 能夠建立、管控以及觀測微服務功能，並輕鬆實現負載均衡、服務間認證以及監控等能力。


Service Mesh 的集羣裏則承載了幾乎所有基礎服務，躺平設計家的第二階段改造實際上是一個深度微服務化的過程，經過絞殺者模式逐步剝離原來一個個祖傳的龐然大物，最終使每一個邏輯服務組都能自由擴展並能在故障時優雅降級。


起初，團隊也考慮過利用 OpenStack 自建私有云。


可是無論私有云仍是公有云，雲集羣管理都是由若干一系列獨立而又相互關聯的項目組成的，而每一個項目又由若干個組件組成。這些組件相互合做，構建成了整個雲生態。這其中有負責集羣管理，負責網絡管理，負責存儲管理，還有負責鏡像管理等。


對當時的躺平設計家而言，總體複雜度太高，並且雲研發的人才十分緊缺，即便願意投入資金想招募到這方面合適的人才都不是一件容易的事情，所以最終仍是決定與公有云廠商合做，藉助公有云提供的基礎設施和服務，自身則更專一於核心算法及業務研發。


衆所周知，Kubernetes 已經成爲事實標準，躺平設計家使用阿里雲容器服務（ACK） 以後， 成熟的容器和容器編排能讓研發無視 IaaS 的複雜性，同時提供強大的配置和管理功能，極大簡化研發的配置管理工做。

第三階段：DevOps 實踐及後續規劃

目前，雖然第二階段的改造還在持續進行中，但躺平設計家的技術團隊已經作好了下一步的技術規劃。


接下來，DevOps 推動、邊緣計算和基於 Service Mesh/Serverless 的規模化計算力整合提高，將是整個研發團隊雲原生實踐的重要方向。謝康表示，目前在 DevOps 方面還有更進一步提高的可能，而原先基於公有云的通用方案也須要結合自身需求進行一些定製化改造。


簡單來講，在 DevOps 方面：

• 首先要作到及時感知，能夠及時察覺到系統每一個節點上的運行狀態；
• 其次是可觸達，經過技術手段對每一個階段出現的問題進行解決，而非簡單的重啓了事，核心鏈路上的每一個環節都必須有自愈能力，保證系統面臨重大故障時能夠經過熔斷或者降級解決，避免全局癱瘓；
• 最後是智能化運維，經過機器學習的方式根據歷史數據對系統的總體健康狀況進行把控，利用運維 AI 算法實現自動化，最終走向無值守運維。
  

此外，隨着雲原生愈來愈規範化，在高度自動化的 CI/CD 和邊緣計算方面也開始有所突破，這些一樣是躺平設計家的關注方向。謝康解釋道，目前公司主打的是雲端能力，但其實躺平設計家的整個用戶交互很是頻繁，過程當中產生的流量也比較大。


如何能將部分用戶行爲放到邊緣網絡節點，而非所有集中到雲端節點處理就能大幅提升用戶體驗？若是邊緣計算上能夠取得突破，將會對解決這個問題有很是大的改善，所以整個團隊對該領域的發展密切關注。

實踐效果

除了上文說起到的交互週期縮短，性能加強外，整個過程也讓躺平設計家的用戶數有了極大地提高。總結下來，謝康認爲能夠歸納爲以下四點：

• 基礎設施費用減半，在規模擴大的基礎上，在基礎設施上的投入還縮減了近 50%；
  
• 研發成本下降，整個團隊 50% 以上的人員爲研發和產品，在基礎設施交付給阿里雲以後，整個團隊能夠集中精力進行核心業務研發，交付速度大幅提高；
  
• 系統可用性提升到 99.96%，在人員及成本縮減的狀況下，總體可用性卻有了很大提高；
  
• 安全性提升，原來受限於總體架構，在達到 99% 以後，小數點以後的每一次提升的成本都是非線性的，而經過雲原生改造，能夠用相對經濟的方式達到較高安全度。
  

結束語

回顧整個過程，這場改造絕非易事。謝康表示，躺平設計家至少是幸運的，能夠在短期內迅速肯定改造計劃並實踐成功。


對於但願進行雲原生改造的企業，謝康建議必定要作好相關技術儲備和接受刮骨療傷的心理準備，不要幻想不作任何工做就能實現平滑遷移，這不可能實現，技術改造必不可少。


其次，雖然雲原生相關規範及組件逐漸成熟，但對傳統企業而言，門檻依舊很高.若是迫切但願提高技術能力，組織內部要對架構調整達成共識，整個研發體系也須要作好充足的準備，決不能以爲託付給雲廠商後就能夠不勞而獲，就能一步上雲。整個上雲的過程，決策者時刻都要作好迎接變化的準備。


最後，如上文所言，傳統企業的決策鏈路一般是自上而下的形式。


所以須要進行一次互聯網化改造，不只僅是研發層面，整個公司的管理人員都須要作好知識升級和觀念更新，這也是躺平設計家在過去幾年的上雲之路所經歷的。

---

嘉賓介紹：
謝康，從業互聯網十幾年的資深技術老鳥，曾前後供職於盛大，攜程和同程藝龍，專一於大規模高可用的互聯網架構設計和雲原生的落地探索，擁有多年的平臺架構經驗，曾設計實現承載上萬服務的微服務和 DevOps 平臺。現就任於躺平設計家，主要負責總體技術架構和雲原生推動工做。

瞭解 ACK 容器服務，請查看：https://www.aliyun.com/produc...
阿里雲容器服務中國最佳，進入 Forrester 報告強勁表現者象限