「雲原生上雲」後的聚石塔是如何應對 雙11 下大規模應用挑戰的

來源|阿里巴巴雲原生公衆號

主筆 | 在德（阿里巴巴技術專家）、佳旭（阿里巴巴技術專家）
聯合做者 | 杭羽、照前、嶺峯、大猿

雲原生被認爲是雲計算的重要發展趨勢，而且已經成爲數字新基建必不可少的一個組成部分。每一年的阿里巴巴 雙11 都是考驗各類前沿技術的最佳「實戰場」，而今年雲原生技術在 雙11 中的大規模應用，充分證實了雲原生技術的動力與前景。

本文會系統講解聚石塔在 2019 年 7 月份以阿里雲容器服務爲基礎設施，進行雲原生實踐的探索和經驗、帶來的價值與改變，及其在 雙11 中的應用，但願對雲原生化樹立能夠借鑑使用的案例和樣板。

聚石塔業務背景與介紹

聚石塔最先上線於 2012 年，是阿里集團爲應對電商管理和信息化挑戰，幫助商家快速解決信息化建設與管理的瓶頸打造的一款開放電商雲工做平臺。它的價值在於匯聚了整個阿里系的各方資源優點，包括阿里集團下各個子公司的平臺資源，如淘寶、天貓、阿里雲等，經過資源共享與數據互通來創造無限的商業價值。

依託於聚石塔，各類業務類型（如 ERP、CRM、WMS 等業務）的服務商爲淘寶、天貓等淘系的商家提供服務，服務商須要遵循聚石塔平臺的發佈規則、數據安全、穩定性建設等要求。這種關係決定了聚石塔平臺的技術和架構，更直接決定服務商的技術演進方向和先進性。

聚石塔業務痛點

聚石塔承接的業務大類能夠分爲兩個部分：

• 傳統電商鏈路中，訂單服務鏈路上的系統：好比 ERP 系統，CRM 系統，WMS 系統。
• 電商行業中直接面向客戶的小程序場景，好比手淘與千牛客戶端的小程序業務。

綜合聚石塔的的業務類型，存在以下的業務痛點：

1. 標準化和穩定性問題

對於訂單服務鏈路的系統而言，穩定性永遠是最前面的「1」，一個系統抖動可能就會致使訂單履約鏈路中斷甚至形成資損以及客訴。穩定性和標準化是不分家的，相信你們對此對有強烈的感覺。而此類系統的開發語言不統一，有 Java、PHP、.Net 等；技術棧複雜，涉及 Windows 系統、Linux 系統、單體應用、分佈式應用，可謂五花八門。所以須要一套跨語言、跨平臺的通用 PaaS 平臺來解決應用的標準化、運維的標準化問題，並提供通用的鏈路問題觀測手段，來幫助服務商和平臺規範發佈運維操做，發現鏈路問題，消除穩定性隱患。

2. 突發流量下的彈性問題

對於應用小程序的業務系統而言，最大的挑戰就是須要應對突發流量以及流量的不肯定性。尤爲在 雙11 期間，手淘端各種小程序插件會面臨比平時多十倍甚至百倍的流量。面對這種不肯定性的流量洪峯，聚石塔須要一套能夠實現流量預估、流量觀測、流量控制以及標準應用快速擴縮容的 PaaS 平臺。對於訂單服務鏈路的系統而言，彈性能力也是關鍵點，在原來的架構下擴容須要經歷建立虛擬機資源、部署並配置應用等諸多環節，服務商廣泛感受流程長、效率低。以上咱們都總結爲彈性能力的挑戰。

3. 效率和成本的問題

聚石塔在雲原生以前的應用部署基本都是基於 VM 直接部署進程，這種方式缺少進程間的資源隔離。同時當 ECS 數量變多，資源的統一管理就變得很是複雜，很容易形成資源爭搶致使應用穩定性問題以及資源浪費致使的多餘成本開銷。同時，在傳統的 VM 部署模式中，應用的擴縮容不只僅須要處理應用的代碼包啓動，還須要處理應用的端口衝突，應用所關聯的存儲資源分配，應用流量在 SLB 的掛載和摘除，應用配置的分發以及持久化，整個部署過程會變得很是耗時且容易出錯。

聚石塔雲原生落地方案

針對上述的業務痛點，聚石塔開始探索技術演進方向以及系統性的解決方案，以便爲淘系服務商帶來服務上質的提高。雲原生帶來的技術紅利，好比應用環境標準化、DevOps 思想、彈性伸縮、跨語言的服務化能力以及運維自動化等，都不只能夠幫助聚石塔的服務商解決現存架構中的穩定性和成本問題，同時也能夠幫助咱們引導服務商實現技術架構的升級。

所以，聚石塔進行了從新定位，主動擁抱雲原生。總體來看，目前的聚石塔雲原生技術底座基於阿里雲容器服務，平臺目標是賦能服務商應用架構的穩定性升級，打造基於雲原生的、面向業務連接的 DevOps PaaS 平臺。

那麼，爲何聚石塔會選擇阿里雲容器服務做爲雲原生基礎設施呢？

阿里雲容器服務 ACK（Alibaba Cloud Container Service for Kubernetes）是全球首批經過 Kubernetes 一致性認證的服務平臺，提供高性能的容器應用管理服務，支持企業級 Kubernetes 容器化應用的生命週期管理。做爲國內雲計算容器平臺的領軍者，從 2015 年上線後，一路伴隨並支撐 雙11 發展。

ACK 在阿里巴巴集團內做爲核心的容器化基礎設施，有豐富的應用場景和經驗積累，包括電商、實時音視頻、數據庫、消息中間件、人工智能等場景，支撐普遍的內外部客戶參加 雙11 活動；同時，容器服務將阿里巴巴內部各類大規模場景的經驗和能力融入產品，向公有云客戶開放，提高了更加豐富的功能和更加突出的穩定性，容器服務連續多年保持國內容器市場份額第一。

ACK 在今年 雙11 期間穩如磐石，深度參與了 雙11 衆多領域的支撐：在阿里巴巴集團內部支撐電商後臺系統 ASI，在零售雲支撐聚石塔，在物流雲支撐菜鳥 CPAAS，在中間件雲原生支撐 MSE，在邊緣雲支持支撐 CDN 和邊緣計算，並首度支持了數據庫雲原生化和釘釘音視頻雲原生化。

在過去的一年，ACK 進行了積極的技術升級，升級紅利直接運用到了 雙11 中，進一步提高了 ACK 的技術競爭力和穩定性，升級包括：高性能雲原生容器網絡 Terway 相比於社區社區提高 30%，高性能存儲 CSI 引入 BDF 等的支持支撐數據庫 5K 臺神龍主機對數十 PB 數據實現高效卷管理，極致彈性 ASK，Windows 容器等首次在 雙11 活動中參戰並應用等等。規模化調度方面，ACK 高效穩定的管理了國內最大規模的數萬個容器集羣，是國內首個完成信通院大規模認證（1 萬節點、1 百萬 Pod）的廠商。規模化管理的技術和經驗在 雙11 中支撐了全網客戶集羣 APIServer 數十萬的峯值 QPS。

所以，聚石塔選擇 ACK 容器服務，不管是從技術角度，仍是業務角度，是很是合理的，雙方的合做也是強強聯合、相互賦能、共同成長。

下面內容會講到聚石塔如何使用雲原生中的技術能力來解決實際的業務痛點和問題。

1. 應用和發佈標準化

聚石塔上彙集了上萬的開發者，可是不論規模仍是技術能力都良莠不齊。所以，聚石塔亟需爲用戶提供一套能夠屏蔽 Kubernetes 複雜性的、易用、靈活高效的發佈系統，進而下降用戶使用 Kubernetes 的門檻，幫助用戶享用雲原生的技術紅利，同時知足做爲管控方對於穩定性的要求。爲了應對各類不一樣業務形態的差別化，聚石塔經過標準化來解決，設計了一套通用的應用模型以及對應的發佈規範。

1）應用模型

Kubernetes 的一個重要思想就是面向應用的 DevOps，聚石塔 DevOps 平臺一開始就是以應用爲中心的 Paas 平臺，在應用模型的設計上，總體的設計原則是讓開發者人員關注應用自己，讓運維人員關注基礎設施運維，從而讓應用管理和交付變得更輕鬆和可控。

同時，爲了知足客戶需求的多樣性，好比對於同一個應用，SaaS 服務商爲不一樣商家提供不一樣規模的應用實例數量，或部署有差別性的代碼，聚石塔在應用下支持了多環境，並支持對測試和正式環境的隔離。

2）發佈

穩定性的風險很大程度上來源於變動，Kubernetes 自帶的滾動發佈，雖然標準化了發佈環節，但在發佈期間沒法暫停，即便服務起來了，可能功能和業務存在問題，最終也會隨着滾動不斷擴大影響面；對此，聚石塔設計了支持暫停的分批發布，經過提早批的「金絲雀」驗證，從而提高系統的穩定性。

以一個「無狀態」的應用爲例，主要實現原理是，經過控制兩個版本的 Deployment 的滾動，來作到可暫停和金絲雀驗證。

同時，相對於其餘 Paas 平臺，聚石塔須要支撐更多的客戶應用場景，還支持有狀態應用（像 Zookeeper）以及守護進程應用（好比日誌採集）的分批發布，以知足不一樣客戶基於成本和防鎖定層面的需求。

而對於有狀態應用，主要原理則是經過控制 Kubernetes StatefulSet 的 Partition 分區來作到分批和暫停。

另外，對於守護進程應用，則是經過對 DaemonSet 進行 Label 的調度來實現：

從而作到不一樣類型的應用，獲得統一的操做體感和變動穩定性保障。

2. 彈性：ACK/ASK + HPA

隨着集羣規模的增大，資源成本的消耗愈加明顯，尤爲對於流量波動較大的場景（例如電商場景），問題更加突出。用戶不可能一直把集羣資源保持在高水位上，大多數狀況下用戶都會把集羣資源維持在足以應對平常流量的規模，並稍微冗餘一部分資源，在流量高峯在來臨前進行集羣資源的擴容。

對於 Kubernetes 集羣來講，啓動一個 Pod 是很快的，可是對於上述場景，啓動 Pod 前須要提早擴容 ECS，使之加入集羣后，才能進行擴容，而擴容 ECS 則須要數分鐘的時間。

以上的彈性能力比較弱，操做繁瑣，耗時過長，沒法及時響應流量變化，而且依然會存在不少的資源浪費，消耗成本。

1）ACK/ASK 與 ECI

阿里雲彈性容器實例（Elastic Container Instance），旨在用戶無需管理底層服務器，也無需關心運行過程當中的容量規劃，只須要提供打包好的 Docker 鏡像，便可運行容器，並僅爲容器實際運行消耗的資源付費。ECI 是 ACK 底層的一種資源形態，一個 ECI 能夠看作一個 Pod，無需提早擴容 ECS，即可直接啓動。

ECI 的價格與同等規格按量付費的 ECS 價格相近，且爲按秒付費，ECS 爲小時級別。若是用戶僅須要使用 10 分鐘，理論上 ECI 的成本是使用 ECS 的 1/6。

以下圖所示，Kubernetes 集羣經過 Virtual Node 使用 ECI，該技術來源於 Kubernetes 社區的 Virtual Kubelet 技術，無需提早規劃節點容量，不佔用已購買的 ECS 資源。

2）聚石塔結合 ECI 與 HPA

爲了帶給客戶更好的體驗，聚石塔基於阿里雲 ACK/ASK，結合底層的 ECI 資源，以及原生 HPA 能力，爲客戶帶來了更加靈活優質的彈性能力。

經過使用污點來控制一個應用的某一個環境是否但是使用 ECI，而且會優先使用集羣中 ECS 資源，資源不足時纔會使用 ECI，從而爲用戶解決額外成本。

同時聚石塔提供了標準的 HPA 能力，以及 cronhpa 能力，幫助用戶實現根據指標的自動伸縮（例如根據 CPU 的使用狀況自動伸縮 Pod 數量），以及定時伸縮的能力。

而且經過二者的結合，在流量動態變化的過程當中，無需手動購買 ECS，以及手動擴容 Pod，實現 0 運維成本。

以上能力在今年 618 前開始小範圍推廣，完美經過了 618 以及 雙11 的考驗，用戶在 雙11 期間單個應用使用 ECI 佔比最高達到 90%，爲用戶節約了一半的計算成本。在 雙11 期間 ECI 在電商業務場景下總體運行穩定，平均彈升時間在 15s 之內，相比 ECS 擴容至少須要 10 分鐘，大大減小了擴容的時間成本，保證業務應對峯值流量的穩定性。

3. 應用監控

在享受 Kubernetes 雲原生技術帶來快速發佈、彈性伸縮等便利的同時，如何作到可監控可運維也是聚石塔的核心挑戰。一個合格的監控系統須要具體準確性、實時性、可用性，提供分析和解決問題的洞察力。傳統的監控方案，大部分是自頂向下的，配置一個監控的任務、採集端點，應用的生命週期與監控任務生命週期一致，採集目標也是固定的，不管應用如何重啓、變化，對於採集任務而言只要採集端點沒有變化，那麼任何的變化都是生命週期中的正常現象。與傳統應用相比，基於 Kubernetes 的雲原生應用容器實例是動態調度的、生命週期短，容器上層更是難以監控的如 Deployment、負載均衡 Service 等抽象，此外，還須要底層 ECS 計算資源、實例生命週期、Kubernetes 集羣自身以及集羣核心組件的各個維度的監控。基於上述考慮，聚石塔充分打通阿里云云原生監控中間件產品，爲聚石塔雲應用提供了分層一體化監控解決方案。

以事件監控爲例，介紹下阿里雲事件中心如何在聚石塔 PaaS 平臺落地。

事件中心

聚石塔藉助阿里雲日誌服務提供的集羣事件採集、索引、分析、告警等能力，將集羣和雲應用上的各類事件進行監控和告警。事件的範圍涵蓋全部 Kubernetes 原生 event、集羣組件 event 以及其餘各類定製的檢查。一般比較關心的是會影響雲應用正常運行的一些異常狀況，好比 Node 節點不可用、資源不足、OOM 等，好比 Pod 實例容器重啓、驅逐、健康檢查失敗、啓動失敗等。PaaS 平臺上雲應用實踐過程。

• 用戶爲集羣一鍵安裝 NPD 組件，爲集羣和應用分別配置告警規則，設置關注的事件類型和通知方式便可。
• 集羣上全部事件自動採集到 SLS 日誌服務，日誌服務上的告警規則由咱們根據事件類型和用途自動配置。
• 日誌服務告警回調以後，由咱們統一分析處理後進行消息推送。

事件監控和告警功能，不只能在平常幫助用戶排查和定位自身應用問題，也爲平臺對各個應用的運行狀況有較好的瞭解，從而制定個性化的優化方案以及大促保障方案。此外，對於集羣底層的組件，也能夠經過配置相應的規則進行告警通知，這次 雙11 大促，聚石塔爲核心集羣自動配置了集羣 DNS 組件的告警，以便及時擴容或者切換更高可用的 DNS 方案，從而確保業務穩定。

4. DNS 生產環境優化實踐

因爲聚石塔的用戶大可能是電商或小程序的場景，流量波動明顯，而且開發語言多樣化，有些語言沒有很好的鏈接池，致使每一次請求都須要進行一次 DNS 解析。Kubernets 默認的 CoreDNS 在高併發時會遇到性能瓶頸，部分用戶在平常活動中，已經遇到了 DNS 性能的問題，更不要說 雙11 期間，所以聚石塔對 DNS 的性能作了深刻的優化，確保 雙11 的穩定性。

1）Node Local DNS

默認的 CoreDNS 方式是採用的 Deployment 方式部署的無狀態服務，集羣中的 Pod，經過 service 對其進行訪問。經過上述流程能夠看到，DNS 解析須要跨節點請求，性能不是很高，在高併發的場景下，容易達到瓶頸。

爲了進一步提升性能，阿里雲提供了 ack-node-local-dns。原理以下，經過 DaemonSet 的方式，將 DNS 解析的服務在每一個節點上啓動一個實例，同時設置相應的 轉發規則，將 Pod 發出的 DNS 的請求轉發到各自節點上對應的 DNS 解析服務，從而避免了跨節點的訪問，很大程度上提升了性能。

聚石塔對該插件進行了相應封裝，可使用戶無感知的在兩種方式間進行切換。

2）Sidecar DNS

對於 ECI 的場景，因爲不存在真實的宿主機，所以沒法採用上述 Node Local DNS 的方案提升 DNS 性能，同時各個節點上的服務數量不一樣，而且不一樣應用對的 dns 解析併發量的不一樣，在極端的場景下可能會出現 DNS 解析併發量分佈不均，從而致使部分節點上 DNS 解析出現問題。

基於以上場景，聚石塔結合 Kubernetes 提供的 sidecar 能力，提供了 sidecar dns。原理以下圖所示。

經過在 Pod 容器組中加入 DNS 解析服務容器。實現容器組中，其餘容器全部的 DNS 解析請求均經過 sidecar dns 獲取。sidecar dns 能夠看作是業務容器的緩存，只爲自身所在的 Pod 提供服務，不會存在負載分配不均的問題，而且能夠爲 ECI 提供相應的 dns 解決方案。

5. Windows 場景落地

全球範圍內來看，Windows 的市場份額還不容小覷，在 StackOverflow 2020 最新的開發者調研中，在最受歡迎的的框架、開發包和工具中，.Net 的佔比超過了 35%；在最受歡迎的編程語言中，C# 雖然有所下滑，仍保持在 30% 以上。隨着雲原生的接受度愈來愈高，愈來愈多的傳統行業也對容器等雲原生技術的呼聲愈來愈高，迫切須要更好的支持。

1）限制

Kubernetes 最早是在 1.14 版本 GA 實現了 Windows Server 2019 上進程容器的調度，隨着後面的不斷迭代，Windows 容器在調度、安全、網絡、存儲和鏡像管理等模塊上都有了很大的進步，正在慢慢對齊 Linux 容器的功能並盡最大努力保持對異構容器管理的統一性。但咱們仍是能看到 Windows 容器有不少的限制，這種限制更多的是來自於操做系統層面的。

• 隔離不完全

目前 Windows 容器的實現模式分爲："進程容器"和"Hyper-V 容器"。"進程容器"是經過任務名管理來模擬資源隔離的，因此這種隔離是不完全的，最多見的限制就是無法 OOM kill。而"Hyper-V 容器"是經過內核隔離技術來實現，所以這種隔離是最完全的。

Kubernetes 默認支持的是"進程容器"，其實說"只支持"都不爲過，爲何呢？由於目前能支持"Hyper-V 容器"的運行時只有 Dokcer EE，而又受限於其實現，"Hyper-V 容器"不能支持 Multiple Container one Pod 的場景，再加上微軟把節點上能夠跑"Hyper-V 容器"的數目也 License 化，這就極大的阻礙了"Hyper-V 容器"Kubernetes 化的進程。

• 升級難平滑

爲了提升迭代效率，加速功能沉澱，微軟在 2017 年推出一種新的系統發佈里程："半年通道版"（Semi-Annual Channel）。相比於"長通道版"（Long-Term Servicing Channel），"半年通道版"是按照半年一次來進行 release 的，所 release 的內核是徹底兼容當前所支持的 "長通道版"的操做系統。比方說，Windows Server 1809 SAC，Windows Server 1903 SAC ，Windows Server 1909 SAC 等都屬於 Windows Server 2019 LTSC。

比起"長通道版"，顯然"半年通道版"來得更加敏捷高效，可是轉而來的是更復雜的升級管理。

• 嚴格內核版本要求的"進程容器"：因爲進程容器是經過任務名模擬的，這就致使了容器的 base 鏡像內核版本必須等於節點內核版本。換句話說，1903 SAC 的容器是無法跑在 1809 SAC 的節點上，反之亦然。
• 有限兼容的"Hyper-V 容器"："Hyper-V 容器"的向後兼容是有限制的。比方說，在 2004 SAC 的容器上，經過 Hyper-V 技術建立的容器，只能兼容 2014 SAC，1909 SAC 和 1903 SAC，而沒法運行 1809 SAC。
• 安全管理困境：當碰到安全補丁的時候，問題會變得更麻煩，除了節點要打安全補丁之外，容器也要從新re-package。詳情能夠參看：https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t。

• 文件難管理

目前的 Windows 容器的文件管理比較 tricky。因爲 Docker EE 只實現了主機目錄級別的掛載，這就致使 Windows 要讀寫某個文件的時候，必須把其整個目錄掛載進來。於此同時，因爲主機的 ACL 管理不能被投影到容器內，這就致使了 Windows 容器對文件的權限修改是不能被主機所接收的。

在 Secret 資源的管理上，在 Linux 上請求掛載的 Secret 資源會被暫存到內存裏面，但因爲 Windows 不支持掛載內存目錄，因此 Secret 資源的內容會被放置在節點上。這就須要一些額外的機制來對 Secret 資源作控制。

2）展望

不過隨着這幾年的努力，咱們正在迎來一個更加穩定和成熟的 Kubernetes Windows 解決方案。

• 在運行層面，ContainerD 會加速替代 Docker EE。目前社區在 ContainerD 上集成了 HCS v2，實現了對單獨文件的掛載和容器優雅退出的管理，在 v1.20 上將會實現對 GPU 和 GMSA 的支持。另外，咱們也能夠看到實現"Hyper-V 容器"和"特權容器"也已位列 roadmap。
• 在鏡像層面，微軟在努力的削薄基礎鏡像層，從 1809 SAC 到 2004 SAC，整個 Windows Server Core 減小了將近一半的大小，可是功能卻愈來愈豐富，這是讓人很是驚喜的。這也爲後期的"Hyper-V 容器"打下來良好的基礎。
• 在功能層面，隨着 privileged proxy 模式的興起，不少以前無法容器化運行的方案都找到了合適的解決方式。比方說，CSI Windows 的實現方案，就是借力於 https://github.com/kubernetes-csi/csi-proxy 的實現。
• 在運維層面，藉助於 Kubernetes 的能力，徹底能夠打造一套 CICD 流來解決掉升級平滑的問題。

聚石塔上的傳統電商鏈路中，訂單類的各種 ERP、CRM、WMS 等系統，使用 Windows 技術棧開發的佔了一半以上。如何幫助 Windows 場景下的系統進行雲原生升級改造，對咱們也是一個全新的挑戰。半年來，聚石與阿里雲 ACK 技術團隊一塊兒作了許多嘗試，使用阿里雲 ACK 集羣 + Windows 節點池做爲底層基礎設施，聚石塔 PaaS 已經可以提供完整的發佈部署、負載均衡、基礎監控、擴縮容等功能。在今年的 雙11 大促中，已經有很多客戶的系統運行在 Windows 容器之上，平穩渡過 雙11 的業務高峯。

固然，Windows 場景下還有其餘一些特性暫不支持，好比 NAS 共享存儲、日誌採集、彈性伸縮、事件監控等，雙11 以後，聚石塔與與阿里雲 ACK 會繼續一塊兒努力，爲 Windows 容器的成熟和市場化貢獻更大的技術和業務價值。

雲原生帶來的業務和技術價值

在正在進行中的 2020 年 雙11 大促中，聚石塔雲應用 PaaS 已經落地開花，聚石塔的核心服務商的核心繫統也基本完成了雲原生化的改造。

在 雙11 第一波高峯中，構建在阿里雲 ACK 之上的聚石塔雲原生規模達到了上萬核 CPU，上千個集羣，承載 2 萬個 Pod。基於 Kubernetes，聚石塔 PaaS 封裝的應用與運行環境的標準化，發佈部署以及流量變動流程標準化已經成爲聚石塔服務商平常軟件交付流程中必不可少的一部分，經過這些努力聚石塔最大限度的減小了 雙11 期間沒必要要的應用變動，將聚石塔的變動數量減小爲平常的十分之一，保證線上系統穩定性；同時咱們推進聚石塔 PaaS 上的核心應用完成了基於閾值（CPU，內存，load）以及基於集羣事件（好比 Pod 驅逐，節點不可用）的監控告警，實現了線上問題先於客戶發現，及時解決止損；對於小程序的突發流量應用場景，聚石塔在普通 Kubernetes 集羣內引入了 vnode 和 ECI 的技術，保證集羣資源不足的狀況下，能夠實現 Pod 的秒級快速應急彈縮，應對突發的流量洪峯。

雲原生帶來的價值不止於此，基於聚石塔的用戶反饋，雲應用 PaaS 廣泛給開發者帶來了 30% 以上的研發效能提高，應用的擴縮容甚至實現了小時級到秒級的時間縮短；同時基於容器的運行環境以及計算資源標準化抽象，給大多數用戶帶來了 30% 以上的計算資源成本節約。基於雲原生的架構與運維規範也推進了服務商自身的軟件架構升級，好比從單體應用向分佈式應用的升級，從垂直擴縮的有狀態應用向可橫向擴縮的無狀態應用的升級。

雲原生在電商垂直業務下的實踐纔剛剛起航，後續聚石塔還將持續在雲原生技術領域深耕，在應用運維標準化 OAM，應用鏈路的可觀測性，基於 Mesh 的應用流量監測和控制，基於業務指標的彈性伸縮，分佈式應用壓測與容災等領域繼續探索，將雲原生的技術價值賦能給客戶和業務，同時將電商垂直領域的雲原生技術實踐反哺雲原生社區。