2009年，居然設計家(Homestyler)研發團隊正式成立，開始進行第一個版本的探索；如今，十年已過，居然設計家正式更名爲躺平設計家，用戶量近千萬。在兩年多的雲原生實踐改造過程中，整個團隊經歷了從運維數千臺服務器再到全部交付給雲，從探索上雲到利用Serverless和Service Mesh完成雲原生改造，最終整體可用性達到三個9以上，同時IT費用削減了近一半，本文分享了躺平設計家的雲原生實踐歷程。
自2013年由Pivotal的MattStine首次提出至今，雲原生（Cloud Native）這一概念正在逐漸重塑整個軟件生命週期。架構良好的雲原生系統在很大程度上是自修復、經濟高效的，並且可以通過CI/CD（持續集成/持續交付）輕鬆更新和維護。好在構成雲的服務器、磁盤和網絡與傳統基礎設施相同，這意味着幾乎所有優秀的架構設計原則仍然適用於雲原生架構。但是在雲中，關於這種結構如何執行的一些基本假設會發生變化。例如，在傳統環境中配置替換服務器可能需要數週時間，而在雲環境中僅需要幾秒鐘，這些都是應用程序架構需要考慮的內容。
在雲原生實踐的系列採訪中，InfoQ先後採訪了阿里巴巴、騰訊、京東、青雲等衆多廠商，對值得關注的開源技術及相關落地實踐進行了初步探索。本文，InfoQ對居然之家的躺平設計家研發總監謝康進行了獨家專訪，瞭解這家企業從傳統單體架構向雲原生演變的實踐路徑。
實踐背景
躺平設計家原名居然設計家（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應用，謝康表示，躺平設計家服務器裏則更多的運行着計算密集型任務，原來IDC機房中的大部分服務器都是48核，甚至96核的定製機型，類似的高配服務器多達幾百臺，而且長時間極限壓榨服務器算力的運行方式也導致機器故障率非常高。在改造過程中，如果想對這樣的系統進行大規模改造上雲並不是一件容易的事情。整個團隊與阿里雲的架構師和技術專家們共同改造，多次克服兩地協助諸多不便一起討論制定方案，測試最終在ECS雲主機上完美解決計算密集型任務上雲的問題。目前，躺平設計家已經退役全部線下渲染服務器並遷入ECS雲主機，完美運行再也不用擔心服務硬件設施故障導致的突然計算力雪崩，並能在用戶提交任務時動態調整集羣規模。
除了上述通過上雲解決計算資源按需伸縮的問題，謝康也表示，Serverless和Service Mesh在躺平設計家的運用也越來越廣泛，隨着雲原生改造的持續進行，越來越多需要按需伸縮的計算節點被解耦出來，重構掉之前嚴重依賴狀態和過程中頻繁讀寫外援數據的問題後，這部分邏輯全部遷移到了Serverless的節點中，通過一系列Trigger觸發。不僅讓整個系統變得更加靈活，僅需支付運行期間費用的方式也非常經濟。Service Mesh的集羣裏則承載了幾乎全部基礎服務，躺平設計家的第二階段改造其實是一個深度微服務化的過程，通過絞殺者模式逐步剝離原來一個個祖傳的龐然大物，最終使每個邏輯服務組都能自由擴展並能在故障時優雅降級。
起初，團隊也考慮過利用OpenStack自建私有云。但是不管私有云還是公有云，雲集羣管理都是由若干一系列獨立而又相互關聯的項目組成的，而每個項目又由若干個組件組成。這些組件相互合作，構建成了整個雲生態。這其中有負責集羣管理，負責網絡管理，負責存儲管理，還有負責鏡像管理等。對當時的躺平設計家而言，整體複雜度過高，而且雲研發的人才十分緊缺，即使願意投入資金想招募到這方面合適的人才都不是一件容易的事情，因此最終還是決定與公有云廠商合作，藉助公有云提供的基礎設施和服務，自身則更專注於核心算法及業務研發。
第三階段：DevOps實踐及後續規劃
目前，雖然第二階段的改造還在持續進行中，躺平設計家的技術團隊已經做好了下一步的技術規劃。接下來，DevOps推進、邊緣計算和基於Service Mesh/Serverless的規模化計算力整合提升將是整個研發團隊雲原生實踐的重要方向。謝康表示，目前在DevOps方面還有更進一步提升的可能，而原先基於公有云的通用方案也需要結合自身需求進行一些定製化改造。
簡單來說，在DevOps方面，謝康提及首先要做到及時感知，可以及時察覺到系統每個節點上的運行狀態；其次是可觸達，通過技術手段對每個階段出現的問題進行解決，而非簡單的重啓了事，核心鏈路上的每個環節都必須有自愈能力，保證系統面臨重大故障時可以通過熔斷或者降級解決，避免全局癱瘓；最後是智能化運維，通過機器學習的方式根據歷史數據對系統的整體健康情況進行把控，利用運維AI算法實現自動化，最終走向無值守運維。
此外，隨着雲原生越來越規範化，在高度自動化的CI/CD和邊緣計算方面也開始有所突破，這些同樣是躺平設計家的關注方向。謝康解釋道，目前公司主打的是雲端能力，但其實躺平設計家的整個用戶交互非常頻繁，過程中產生的流量也比較大。如果能將部分用戶行爲放到邊緣網絡節點而非全部集中到雲端節點處理就能大幅提高用戶體驗，如果邊緣計算上可以取得突破，將會對解決這個問題有非常大的改善，因此整個團隊對該領域的發展密切關注。
實踐效果
除了上文提及到的交互週期縮短，性能增強外，整個過程也讓躺平設計家的用戶數有了極大地提升。總結下來，謝康認爲可以概括爲如下四點：
1、基礎設施費用減半，在規模擴大的基礎上，在基礎設施上的投入還縮減了近50%；
2、研發成本降低，整個團隊50%以上的人員爲研發和產品，在基礎設施交付給阿里雲之後，整個團隊可以集中精力進行核心業務研發，交付速度大幅提升；
3、系統可用性提高到99.96%，在人員及成本縮減的情況下，整體可用性卻有了很大提升。
4、安全性提高，原來受限於整體架構，在達到99%之後，小數點之後的每一次提高的成本都是非線性的，而通過雲原生改造，可以用相對經濟的方式達到較高安全度。
結束語
回顧整個過程，這場改造絕非易事。謝康表示，躺平設計家至少是幸運的，可以在短時間內迅速確定改造計劃並實踐成功。對於希望進行雲原生改造的企業，謝康建議一定要做好相關技術儲備和接受刮骨療傷的心理準備，不要幻想不做任何工作就能實現平滑遷移，這不可能實現，技術改造必不可少。
其次，雖然雲原生相關規範及組件逐漸成熟，但對傳統企業而言，門檻依舊很高，如果迫切希望提升技術能力，組織內部要對架構調整達成共識，整個研發體系也需要做好充足的準備，決不能覺得託付給雲廠商後就可以坐享其成，就能一步上雲。整個上雲的過程，決策者時刻都要做好迎接變化的準備。
最後，如上文所言，傳統企業的決策鏈路通常是自上而下的形式，因此需要進行一次互聯網化改造，不僅僅是研發層面，整個公司的管理人員都需要做好知識升級和觀念更新，這也是躺平設計家在過去幾年的上雲之路所經歷的。
嘉賓介紹：
謝康，從業互聯網十幾年的資深技術老鳥，曾先後供職於盛大，攜程和同程藝龍，專注於大規模高可用的互聯網架構設計和雲原生的落地探索，擁有多年的平臺架構經驗，曾設計實現承載上萬服務的微服務和DevOps平臺。現就職於躺平設計家，主要負責整體技術架構和雲原生推進工作。