**來源|**[**阿里巴巴雲原生公眾號**](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496854&idx=1&sn=d48f770e46f6f4aa103ba7ee9f06944c&chksm=fae6ff59cd91764ff5c7764a42329b6d8fcd224c55e6944920460d28600d534329586499cfad&token=1578756645&lang=zh_CN#rd)
![1.png](https://ucc.alicdn.com/pic/developer-ecology/01895a3c012c4cc3b374b1907ac19f1e.png)
主筆 | 在德（阿里巴巴技術專家）、佳旭（阿里巴巴技術專家）
聯合作者 | 杭羽、照前、嶺峰、大猿

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

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

# 聚石塔業務背景與介紹

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

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/26914b3ac0344ffe8f3b098b430d0b7c.jpg)

依託於聚石塔，各種業務型別（如 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 平臺，在應用模型的設計上，整體的設計原則是讓開發者人員關注應用本身，讓運維人員關注基礎設施運維，從而讓應用管理和交付變得更輕鬆和可控。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/5a9b41e3dc0543c0b963491a6dc172af.png)

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

### 2）釋出

穩定性的風險很大程度上來源於變更，Kubernetes 自帶的滾動釋出，雖然標準化了釋出環節，但在釋出期間無法暫停，即使服務起來了，可能功能和業務存在問題，最終也會隨著滾動不斷擴大影響面；對此，聚石塔設計了支援暫停的分批發布，透過提前批的“金絲雀”驗證，從而提升系統的穩定性。

以一個“無狀態”的應用為例，主要實現原理是，透過控制兩個版本的 Deployment 的滾動，來做到可暫停和金絲雀驗證。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/4d6f37dc6117437c8e47a6f341a76a5d.png)

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

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/6c8cab8c9737455bb439e7db64dbcabb.png)

另外，對於守護程式應用，則是透過對 DaemonSet 進行 Label 的排程來實現：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/da2d7946dd4747c5b1c845b6a9f2a838.png)

從而做到不同型別的應用，得到統一的操作體感和變更穩定性保障。

## 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 資源。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/d81ec1b25d00478fbb4734d424eb34d6.png)

### 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 叢集自身以及叢集核心元件的各個維度的監控。基於上述考慮，聚石塔充分打通阿里云云原生監控中介軟體產品，為聚石塔雲應用提供了分層一體化監控解決方案。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/5a447e590e9a4a5db4ce125714e0bd29.png)

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

### 事件中心

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

![9.png](https://ucc.alicdn.com/pic/developer-ecology/1b8a360f68d4405694bed35e786451d5.png)

- 使用者為叢集一鍵安裝 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 解析服務，從而避免了跨節點的訪問，很大程度上提高了效能。

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

![10.png](https://ucc.alicdn.com/pic/developer-ecology/d3975b2d250d4f9e9dbe03a92c3814a9.png)

### 2）Sidecar DNS

對於 ECI 的場景，由於不存在真實的宿主機，因此無法採用上述 Node Local DNS 的方案提高 DNS 效能，同時各個節點上的服務數量不同，並且不同應用對的 dns 解析併發量的不同，在極端的場景下可能會出現 DNS 解析併發量分佈不均，從而導致部分節點上 DNS 解析出現問題。

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

![11.png](https://ucc.alicdn.com/pic/developer-ecology/93ac900c254749789dd6717d5b0f701c.png)

透過在 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](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](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 的應用流量監測和控制，基於業務指標的彈性伸縮，分散式應用壓測與容災等領域繼續探索，將雲原生的技術價值賦能給客戶和業務，同時將電商垂直領域的雲原生技術實踐反哺雲原生社群。

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

相關文章

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

相關文章

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