來源| 阿裡巴巴雲原生公衆号
主筆 | 在德（阿裡巴巴技術專家）、佳旭（阿裡巴巴技術專家）
聯合作者 | 杭羽、照前、嶺峰、大猿
雲原生被認為是雲計算的重要發展趨勢，并且已經成為數字新基建必不可少的一個組成部分。每年的阿裡巴巴 雙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 的應用流量監測和控制，基于業務名額的彈性伸縮，分布式應用壓測與容災等領域繼續探索，将雲原生的技術價值賦能給客戶和業務，同時将電商垂直領域的雲原生技術實踐反哺雲原生社群。