一家中型網際網路公司的架構演進之路

在雲原生架構出現之前，大家談論最多的是微服務架構。有的企業可能只有一種架構，有的企業經歷過多種架構的演變。架構的選擇與企業當前所處的階段

有很大關係，好的架構都是為了解決當下企業面臨的業務問題而誕生的。

引用王小川老師在中國計算機大會（CNCC）分享的一句話： “技術與業務的關係就像汽車，汽車有三大元件—車輪、發動機、方向盤，分別代表了3種技術與業務的關係，分別是技術支援、技術驅動、技術顛覆。 ”95%的企業是技術支援型企業，一般都是先追求業務的快速迭代試錯，架構一般會滯後於業務的發展，在架構跟不上業務的迭代速度，或有巨大的歷史技術債務出現時，技術架構才會進行新一輪的迭代。 同時，沒有任何一個架構是“銀彈”，凡是能夠解決當下企業面臨的問題的架構就是好架構。

本章首先介紹企業級架構的演變過程，包括大 部分企業都會經歷的單體架構、分散式架構、微服務架構，以及最近幾年比較火爆的中臺架構； 然後結合自如的業務特性介紹自如技術架構的歷史變遷，還原一箇中型網際網路公司的架構演進之路。 相信很多讀者在讀完本章後，能夠找到自己企業的影子。

2.1技術架構的演進

什麼是架構？架構有哪些特點？架構有哪些分類？一萬個讀者可能有一萬個答案。

本節將從架構的定義出發，介紹幾類常見的架構形態及其演變路徑，從單體到分散式、從分散式到微服務、從微服務到中臺。並不是最新的架構就是最好的，符合企業當下業務形態的架構才是好架構。那麼，如何選擇符合自己業務的架構呢？讓我們從瞭解每個架構的特點開始。

2.1.1架構的定義與分類

1.架構的定義

架構（Architecture）這個詞源自建築行業，以下引用百度百科的描述。

軟體架構（Software Architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。軟體架構是一個系統的草圖。

通俗地來講，技術架構就是對軟體系統各個維度進行不同模組化的抽象，通過抽象使原本複雜的工程變得易於理解和分工實現。就像泰勒提出的科學管理，通過標準化的作業流程和分工，原本混沌複雜的軟體工程被拆分出前端、後端、質量、運維等多個崗位。以後端為例，根據不同的崗位職責，按照康威定律又被拆分出不同的組織，比如訂單組、使用者組、交易組等，進而使整體的生產力大大提升。因此，架構的本質是抽象分類，進而指導軟體系統的實現。

2.好的架構特徵

通常好的架構要能夠支援高併發、高可用、高擴充套件。這些都是架構設計中應該關注的特性。除此之外，好的架構還應該關注如下特性。

可用性和可靠性。由於軟體系統對於使用者的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。可用性和可靠性雖然是兩個不同的屬性，但本質都是為了提升業務連續性，使企業的業務儘可能不中斷。

高效能。高效能體現了架構在同樣的物理配置下的業務支撐能力，更高的吞吐量、更低的響應時間意味著對使用者更快速地響應。

易維護性。軟體系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟體需求反映給現有系統。一個易於維護的系統可以有效降低技術支援的費用。

可擴充套件性。市場和使用者總是在不斷變化的，為了適應業務的高速迭代，尤其是一些2B企業的個性化需求，架構要求能夠在最小的改動成本下滿足更多的需求。這要求架構可以根據客戶群的不同和市場需求的變化進行調整。

安全性。隨著《個人資訊保護法》和《資料安全法》的出臺，資訊保安已經成為架構設計中最重要的因素，安全合規不容小覷。

3.架構的分類

我們常聽到各種關於架構的名詞，比如業務架構、功能架構、應用架構、技術架構、物理架構等，很多讀者可能分不清，這裡我們簡單梳理一下這幾個架構的區別。

（1）業務架構

業務架構一般是指業務的關鍵流程、組織形式、資訊流。以電商為例，業務架構包括選品、採購、倉儲、物流、供應商、訂單等一系列的業務版塊。業務架構體現的主要是業務模式和流程，核心是定義業務痛點，釐清功能需求和非功能性需求。

（2）功能架構

功能架構一般是指產品具備的細分功能。例如，電商系統的功能架構可細分為使用者管理、登入註冊、商品管理、倉庫管理、訂單管理、購物車管理、支付管理等核心模組。功能架構圖體現的是一個產品的核心功能模組。

（3）應用架構

應用架構一般是指根據業務場景設計出應用的層次結構，制定好應用間的呼叫、互動方式，確保它們能夠融合在一起並滿足業務需要。比如，電商系統的應用架構可能有使用者中心、許可權中心、登入系統、商品中心、搜尋引擎、推薦體系、訂單系統、交易系統等。應用架構體現的是用什麼樣的微服務去支援功能的實現。

（4）技術架構

技術架構一般是指實現應用架構的關鍵技術棧，如Spring Cloud、ZooKeeper、RocketMQ、Redis、MySQL、Elasticsearch等中介軟體，以及各種核心流程的時序圖、狀態圖等資訊。

（5）物理架構

物理架構一般是指從物理視角來看IDC中的物理拓撲關係，如防火牆、Nginx、網路、應用伺服器、資料庫間的呼叫和資料流轉關係。物理架構關注的是如何通過硬體配置硬體和網路來配合軟體系統達到可靠性、高可用性、效能、安全性等方面的要求。

除了以上大家耳熟能詳的架構分類，還有很多與架構相關的名詞，如下所示。

框架（Framework）：通常指的是為了實現某個業界標準或完成特定基本任務的軟體元件規範，往往是基於一組類庫或工具，在特定領域裡根據一定的規則組合而成。

元件（Component）：一組可以複用的業務功能的集合，包含一些物件及其行為。元件可以直接用作業務系統的組成部分，顆粒度一般小於模組，也是一種功能的聚合形式，比如日誌元件、許可權元件等。

模組（Module）：基於業務資料或一組相關功能按照特定維度的邏輯劃分，也可以看作各種功能按照某種分類的聚合。例如，電商系統可以從業務上劃分為使用者模組、商品模組、訂單模組、支付模組、物流模組等。模組使一個複雜的軟體變得更加容易管理和維護。

服務（Service）：一組對外提供業務處理能力的功能，服務需要使用明確的介面方式（比如Web Service、RESTful等）。服務描述裡應該包括約束和策略（比如引數、返回值、通訊協議、資料格式等）。

平臺（Platform）：一般來說，是一個領域或方向上的生態系統，是很多解決方案的集大成者，提供了很多服務、介面、規範、標準、功能、工具等。

2.1.2單體架構

在Web應用發展早期，大部分工程都是將所有的服務和功能模組打包到一個單一的應用中，如以War包的形式執行在Tomcat程序中，直接與資料庫和檔案系統互動。

在業務發展早期，業務功能往往比較單一，為了快速支援業務，一般一臺伺服器、一個應用、一個數據庫，就足夠支撐起一個單一的業務功能。比如電商業務，登入、下單、商品、庫存都在一個單一的應用中進行管理和維護。單體架構在業務發展早期非常輕便，易於搭建開發環境，易於測試和部署。

隨著業務的不斷增長，使用者的訪問越來越多，單一應用對磁碟、CPU、記憶體、資料庫的訪問要求也越來越高。一臺伺服器一個應用的配置開始捉襟見肘，更改任何一個小的功能模組，整個應用都要重新進行編譯和部署。同時，當有多個需求並行時，釋出效率會非常低下，整體的功能耦合性非常大，一個小功能的變動可能會引起整個應用不可用。多種功能的強耦合迫使單體架構走向分散式架構。

2.1.3分散式架構

隨著業務壓力增大，併發訪問會成為單體架構的瓶頸，最簡單的解決方案就是把單體服務橫向擴充套件為多體架構，即將1臺伺服器分散擴容為N臺，分而治之，也就是從單體架構變為分散式架構。但是，擴容為分散式架構也有一個問題，即如何保證使用者的請求均勻分散到這N臺伺服器？倘若使用者的流量仍然集中訪問其中的某臺伺服器，這樣的分散式架構在本質上與單體架構沒有任何區別。要解決這個問題就必須增加一個新模組—負載均衡，此時的架構變成了如圖2-1所示。

圖2-1負載均衡架構圖

負載均衡一般分為硬負載和軟負載，常見的負載均衡演算法有輪詢、加權、地址雜湊、最少連結等。有了負載均衡後，不會因為某一個服務的宕機而導致整體服務不可用，架構的可用性大大加強。除了應用的分散式，根據業務量的大小，資料庫也會進行水平或垂直拆分，通過分散式架構賦予整體架構高負載的能力。

分散式架構2.0階段不僅是在部署上實現分散式，應用的邊界也更加清晰，從單一架構的大單一職責，拆分出一些大的應用，逐步形成多種服務之間的分散式呼叫。還是以電商為例，這裡可能會拆分出使用者服務、訂單服務、商品服務、庫存服務四大應用，應用之間通過介面進行互動，呼叫形式可能是REST或者RPC。

1.分散式架構的優點

低耦合：有了功能模組的拆分，使用介面進行通訊，降低了對資料庫的依賴，模組耦合性降低。

職責清晰：把應用拆成若干個子應用後，一般也是由不同團隊進行維護的，這樣一來，不同團隊與應用的職責也就更加清晰了。

部署方便：每個應用的釋出互相獨立、互不干擾，釋出和部署更加靈活方便。

穩定性更高：不會因為某一個應用或功能模組出現問題導致整體服務不可用，整個系統的穩定性更高。

2.分散式架構的缺點

系統間的依賴和鏈路增多，會增加介面開發的工作量，同時增大服務之間的維護成本，但整體上利大於弊。

2.1.4微服務架構

分散式架構實現了應用從單程序到多程序的轉變，做了粗粒度的服務拆分，微服務架構是在分散式架構的基礎上對應用架構進行更細粒度的拆分。在微服務架構出現以前，SOA也曾風靡一時，本書將SOA和微服務合併到一起來討論。還是以電商為例，使用者服務可能會拆分成使用者中心、許可權、登入等服務，如圖2-2所示。

圖2-2微服務架構圖

隨著Spring Cloud的普及，微服務架構逐步成為大中型企業的主流架構。我們來看下微服務架構有哪些優點。

耦合性進一步降低：模組更獨立，功能拆分更加細化，使程式碼間的耦合以及資料庫、中介軟體的耦合進一步降低。

自治性更強：一個微服務就是一個獨立的實體，它可以獨立部署、升級，微服務與微服務之間通過REST等標準介面進行通訊，微服務只與其上下游有關，各個微服務之間更加獨立。

技術獨立：各個微服務之間可以用不同的技術棧，服務端應用可以用Java、Go、Python等多種語言實現，資料庫可以是MySQL、MongoDB、HBase等不同的型別。

高可用：隨著微服務增多、鏈路增長，異常也會被分散，一個微服務異常可以通過執行緒池隔離，利用熔斷等技術避免故障擴散和雪崩，大大增加了整個系統的高可用性。

在微服務架構成為主流架構的同時，很多缺點也被暴露出來。

複雜度高：微服務採用RPC或REST等方式進行互動，需要考慮網路抖動、訊息丟失、冪等、分散式事務等問題，程式碼的邏輯處理更加複雜。

粒度難定義：微服務拆成幾個合適？什麼樣的功能模組需要獨立成一個微服務？服務拆分的粒度是不好準確定義的，倘若拆得過粗，不利於服務間解耦；如果拆得過細，則會導致應用爆炸，增加系統的複雜性。

運維複雜度高：微服務的呼叫關係最終會形成一個大網，故障的定位和排查依託於更加完善的監控報警系統等配套工具。

效能變慢：微服務一般有一個很長的呼叫鏈路，鏈路過長導致整體介面的效能變慢，響應時間（Response Time，RT）會變長。

2.1.5中臺架構

隨著阿里巴巴“大中臺、小前臺”概念的提出，一線大廠紛紛建立自己的中臺體系，公認比較成熟有效的是資料中臺、業務中臺、技術中臺。中臺的本質是進一步提升應用系統的複用性，當組織規模擴大，更多業務場景紛紛湧現時，各部門之間會形成一個個“系統煙囪”。在“系統煙囪”中，重複冗餘的功能不斷被造出來。

以阿里巴巴為例，淘寶、天貓兩個事業部都需要使用者管理、商品管理、訂單管理等功能，許多業務功能是重複的，如果兩個事業部都重複建設，必然會造成極大的資源浪費。阿里巴巴技術棧全景圖如圖2-3所示。

架構重要的功能之一就是避免重複開發、提升複用能力。在這種背景下，如何避免重複造輪子，如何利用同樣的能力快速支撐相似的業務需求是架構需要考慮的問題，於是中臺思想應運而生。

中臺架構有哪些優點呢？我總結了以下幾點。

降本增效：中臺的關鍵就是降本增效，通過複用、抽象避免不必要的重複開發，提升開發效率。

支援業務更加快速迭代：通用的能力域可以快速支援新業務線落地，比如新的業務也需要登入、訂單的能力，完全不用從0到1構建一套新的體系，直接用中臺的能力即可。

圖2-3阿里巴巴技術棧全景圖

打造數字化運營能力：資料中臺使企業的資料化價值有更巨集觀的體現，通過分析核心資料，能夠更加精確地對業務進行調整和優化。

提升組織能力：中臺架構的落地一定伴隨著組織的調整，中臺會打破“部門孤島”，加深團隊間的合作。

然而，中臺在企業中落地很難，經過幾年的發展，真正落地中臺架構的企業很少。現在又有很多企業在質疑中臺，在拆中臺。並不是中臺架構不好，而是企業要根據自己的業務特性和當前所處階段去選擇是否要用中臺。

2.2自如的技術發展史

自如是提供租房產品和服務的O2O網際網路品牌，成立於2011年10月，目前已為近50萬業主、300萬自如客提供服務，管理房源超過100萬間。自如的主要客群是租房使用者，由於租房這個動作並不像電商、社交一樣高頻，因此自如的網際網路屬性也很少有高併發、高流量的特徵。

針對流量逐步從線下轉到線上、業務線從1條到10條、訪客從1萬到20萬的業務場景，我們應該選擇什麼樣的架構呢？本節會為讀者呈現一個典型的中型網際網路公司的技術架構變遷過程。

2.2.1業務背景介紹

自如是一家連線業主、房子、租客的C2B2C公司，業務邏輯如圖2-4所示。

圖2-4業務邏輯

左側的C是業主，作為市場的供給方，業主有房源，想要更快捷、更安全、更高收益地出租。業主的痛點是找不到合適的租客、拿不到高的租金，同時，業主也沒有精力打理房屋託管租期內的事宜。右側的C是租客，作為市場的需求方，廣大租客的核心痛點是找不到合適的房源、享受不到優質的租房服務。

在以自如為首的品牌公寓出現之前，房屋租賃市場有3個錯配。

首先是供需錯配，因為資訊差異，業主找不到放心的租客，租客找不到誠信的業主。其次是裝修錯配，業主房子的新舊程度、裝修風格差異性極大，對於租客而言，房子品質的可選範圍非常有限。最後是服務錯配，租客租到房子後，基本上都是“自掃門前雪”，廁所、客廳、廚房等公共區域髒亂差、噪聲大等問題非常突出。

自如先把業主的房源收集上來，然後進行精緻的裝修，為租客打造全新體驗的租住和服務產品。同時，自如通過開發App、小程式、線下管家使這一匹配模式更加高效。

2.2.2自如的技術演進過程

經過10年的發展，自如的業務規模和業務領域都大大增加。在業務規模巨增的背後，是自如業務系統的飛速演進。自如的技術發展大概經歷瞭如下幾個階段。

2015年之前，自如以資產應用為主，管理房源資訊、合同資訊、客戶資訊，為了快速迭代業務，主語言以PHP為主，程式碼倉庫以SVN來管理。到目前為止，老應用還存在部分未下線的功能，但是歷史程式碼已經達到了1GB。

2015年到2018年是架構服務化的階段，這時自如業務蓬勃發展，長租、短租、優品、家裝、服務等多條業務線崛起，各個業務線開始構建獨立的專屬服務，此時Java開始逐步替代PHP，成為新業務線使用的語言。各個服務間開始通過RPC進行通訊。這個階段自如從單體架構邁向了分散式架構，度過爆發性增長的3年。

到了2018年7月，基礎平臺成立，自如開始對已有的持續交付流程進行重構，引入大量開源技術棧，如Spring Cloud、Nacos、Pinpoint、Graylog、Apollo等，使各個業務線通用的能力得到下沉，同時建設了第二機房，使自如的架構第一次具備了同城災備的能力。

2019年，自如開始搭建DevOps體系，所有應用運維往SRE（Site Reliability Engineer，站點可靠性工程師）方向轉型，開始學習編碼，準備為Kubernetes落地儲備人才。自如建設了大量的平臺功能，如閘道器、監控報警、配置中心、訊息佇列平臺、許可權平臺、使用者中心等，使技術中臺已具雛形。

2020年，伴隨著容器、Kubernetes的廣泛傳播，自如對持續交付流程做了顛覆性重構，完全改變了之前的釋出部署方式，對環境、分支模型都進行了重新定義，成為整個自如的技術演進過程中一個新的里程碑。

2.2.3當前技術架構

經過了10年的技術演進，當前自如的技術架構如圖2-5所示。

自如前臺有多條業務線，如業主、租住、家裝、客服等，每條業務線有獨自的產研團隊進行資訊系統的構建，下方有三大中臺進行支撐。

業務中臺：主要整合各條業務的通用業務能力，如卡券中心、評價中心、價格中心、訊息中心等至少能給2條業務線複用的能力才會抽象成中臺能力。自如業務中臺的建設還不是很成熟，真正可以複用的核心能力還在不斷完善中。

圖2-5自如技術架構圖

資料中臺：資料中臺基本上是最能有效賦能業務的通用能力域集合，核心的能力是自如的定價系統、使用者檔案、樓盤檔案、業主檔案、推薦系統，這些核心資料奠定了前臺業務快速響應、多維度聚合資料的基礎。

技術中臺：相比於業務中臺和資料中臺，技術中臺是自如目前能力域最多、最為成熟的中臺。技術中臺包括兩部分：一部分側重業務能力域，如使用者登入、許可權系統、敏感詞系統、即時通訊、推送服務、搜尋服務；另一部分側重基礎架構，如配置中心、註冊中心、監控報警、混沌工程、閘道器、熔斷限流、業務開關、服務治理、流量染色。技術中臺是自如業務研發使用最高頻的能力，是工程效能最核心的部分。

2.3自如技術架構遇到的問題

自如的技術架構經過10年發展，達到目前的架構狀態，並非一蹴而就，而是跟隨業務的增長不斷迭代和演化的。在這個迭代過程中，我們總結了許多當時遇到的問題，相信與眾多中小型網際網路公司有不少相似之處。本節會通過一些資料來解析自如在雲原生架構落地之前遇到的3個問題—穩定性問題、研發效率問題和流程體系問題。

2.3.1穩定性問題

2019年之前，自如某業務線的系統在30天內出現了13次線上故障，基本達到2天一次的故障頻率，面對如此高頻的線上問題，開發工程師疲於奔命，根本無暇迭代新功能，一線業務人員對系統也怨聲載道。如何保證系統穩定性、功能可用是當時開發團隊最為困擾的問題。

2018年年底，基礎平臺團隊的成立是自如系統從“易變”走向“穩定”的轉折點。基礎平臺重新盤點了線上故障型別，抓住核心短板，發現當時最迫切的問題是中介軟體的

治理。

首先是版本問題，各中心使用的MQ、Elasticsearch、Redis版本都極其老舊。以Elasticsearch為例，當時最新版本已經到了6.x，生產叢集使用的還是2.x版本，導致許多陳舊、低效的語法仍在使用，一些中介軟體新的特性沒有用於生產。

其次是叢集耦合太大，數箇中心共用一個MQ、一個Redis例項，經常發生業務部門A的佇列擁堵導致業務部門B的業務不可用，一箇中間件癱瘓，整個公司的業務停轉。經排查發現，這個情形與2.1.2小節介紹到的單體架構相似，原因是歷史研發人員為了方便，直接複製中介軟體配置程式碼，導致業務應用雖然做了解耦和獨立，中介軟體的依賴卻沒有分開。

最後是環境問題，程式碼分支、環境變數、開關配置經常出現測試環境與生產環境不一致等問題；人工參與過多，很多人為問題導致線上程式碼汙染，進而引發故障。

經過2年的治理，因中介軟體、人為配置導致的故障率大大降低，我們重新盤點了一下2019年的故障情況，大體分佈如圖2-6所示。

圖2-6故障分佈圖

可以發現，佔比最高的3個問題變成了程式碼錯誤、產品設計缺陷、資料原因，其中程式碼錯誤佔比45%。穩定性問題終於不再是系統故障的首要原因。

2.3.2研發效率問題

經濟學上講生產力有三要素—勞動物件、勞動者、勞動資料。對應在研發過程中，勞動物件是需求、專案、任務；勞動者是產品、研發、測試、前端、運維；勞動資料是原型、程式碼、環境、元件庫、IDE（Integrated Development Environment，整合開發環境）、硬體資源等，如圖2-7所示。

圖2-7研發效率圖

在2019年之前，自如研發的全生命週期是沒有完全數字化的，一個專案的開發週期、測試周期、上線週期、人員投入等資料是不完整的，90%的專案沒有管理，開發人員根據倒排時間進行排期上線。專案的線上質量指標也基本是原始狀態，研發效率低下。

2.3.3流程體系問題

研發效率低下，在很大程度上是勞動資料的問題，CI/CD是研發人員的必備工具。2019年，自如想重做CI/CD，對研發人員進行了一次摸底調研，發現研發人員對當前流程體系的滿意度平均只有5.76分。

問卷中幾個比較典型的使用者反饋值得與大家分享。

1.對於“程式碼釋出列表”你有哪些痛點？

□編譯錯誤時無法自動傳送編譯錯誤提醒郵件。

□“合併”與“釋出”的操作過於晦澀、比較難理解。

□釋出時效鎖定為2分鐘有點固化。

□準生產環境經常不穩定，希望有所改善。

□希望可以進行多分支並行釋出。

2.程式碼釋出上線過程你遇到的問題有哪些？

□上線操作煩瑣、流程複雜。

□釋出報錯後無法檢視相關的報錯資訊。

□釋出時沒有優雅關閉，會有流量損失和啟動過程中的流量衝擊。

□程式碼釋出過程視覺化程度不夠，沒有任何提示。

□功能很全，但是人工操作過多。

3.在使用作業系統平臺打包編譯時你遇到過哪些問題？

□指令碼編寫複雜，無法自動化打包、編譯。

□瀏覽器相容性不足，除了Win10自帶瀏覽器外，使用其他瀏覽器會報錯。

□自動建立釋出環境時需要配置的專案過多。

□不同環境的配置可能不一致，導致出問題後的排查與定位非常困難。

□釋出許可權與審批流程控制不合理。

□非釋出視窗釋出時，無法收到審批資訊。

□類似的反饋還有程式碼釋出歷史的體驗、釋出審批流程的問題、版本資訊管理、環境配置檢視問題等。

同時，問卷也統計了研發人員對新平臺的期待。

1.你覺得在專案上線流程中還需要新增哪些功能？

□建議增加程式碼檢查功能，提升程式碼質量。

□建議精簡審批流程。

□建議增加進度視覺化、釋出結果狀態可檢測功能。

□建議增加分組灰度釋出功能。

□建議增加預釋出環境進行上線前驗證。

□建議增加測試環境伺服器監控以及恢復機制。

□建議增加日誌查詢、進度查詢、批量釋出功能。

2.你對作業系統自動化平臺的願景是怎樣的，希望它是一個怎樣的自動化平臺？

□希望是一個高度自動化的平臺，人工介入越少越好。

□希望可以自己申請新增機器配置、檢視負載情況。

□希望能夠更智慧、更靈活、更可視、更易用、更高效可靠。

□希望在釋出上線前就做程式碼規範自動化檢測，功能更簡單易用。

□希望每個環境的專案資訊、IP、專案域名能夠完全正確匹配。

□希望釋出配置更加智慧化、簡易化。

經過此次調研，我們下定了重建CI/CD流程體系的決心，通過重建體系解決釋出部署的效率問題。

2.4本章小結

本章介紹了技術架構的概念，對常見的技術架構定義及分類做了區分，梳理了自如技術架構的演變過程。技術架構是隨著企業的發展階段不斷演變的，自如在啟動雲原生之路時遇到了穩定性、研發效率、流程體系問題，從第3章開始，將介紹自如是如何應對這些問題的。

以上內容摘自《雲原生落地：企業級DevOps實踐》一書，經出版方授權釋出。

推薦閱讀：

《雲原生落地：企業級DevOps實踐》

自如官方深度覆盤雲原生落地全過程，雲原生和DevOps實踐標準讀物，沈劍、孫玄、喬新亮、史海峰等17位專家力薦.