作者：山獵，珑乘
背景
波司登創始于1976年，專注于羽絨服的研發、設計、制作，是全球知名的羽絨服生産商。波司登用一系列世人矚目的輝煌成績證明了自己的實力：連續26年全國銷量領先，連續22年代表中國向世界釋出防寒服流行趨勢，産品暢銷美國、法國、意大利等72個國家，全球超過2億使用者。作為羽絨服革命的旗手，波司登引領了行業内的“三次革命”。
在産品力和銷售成績單背後，波司登在生産、倉儲、物流、銷售各環節已完成數字化轉型和創新改造。除生産端的智能生産工廠，波司登對倉儲和物流環節也進行智能化改造，提升小單快反、拉式補貨的比重，最大限度減少困擾服裝企業多時的“庫存”問題；為了精準分發銷售端産品，波司登建立資料中台，打通全管道資料，賦能消費者研究、商品企劃、管道比對等。現在，波司登每件羽絨服從生産到抵達消費者，背後都是一段數字之旅。
雲原生技術發展
随着波司登數字業務的飛速發展，背後的 IT 技術也在不斷更新疊代。波司登極為重視客戶對服務的體驗，并将系統穩定性、業務功能的疊代效率、問題的快速定位和解決視為建構核心競争力的基石。服飾行業會積極參與各大電商平台的促銷活動，業務流量的波峰波谷現象明顯，如果由于資源配置設定不合理導緻高峰時期訂單溢出、運力不足，會極大影響顧客和商家的體驗。此外，波司登自研了使用者營運平台（使用者洞察系統、内容管理系統、使用者管理 CRM 系統及使用者小程式）、零售營運平台（線上平台訂單管理 OMS 系統、線下管道管理系統、門店收銀 POS 系統）、商品營運平台（訂單進行中心 OPC、庫存計算中心 ICC、商品訂貨系統、商品營運 iMOS 系統、采購制造 GiMS 系統、物流管理 EWM 系統、機器人排程 WCS 系統） 等諸多垂直業務功能，在市場需求的快速變化下，産品功能創新和疊代效率問題也是對技術架構的一大挑戰。
這些現狀的解法和雲原生架構帶來的核心能力不謀而合，在波司登系統改造上雲的過程中，CIO 戴建國親自帶隊，圍繞着雲原生技術體系，推動波司登的各條業務線進行技術更新改造，加快數智化發展程序。在技術選型上，波司登始終遵循着2條原則：
全面擁抱開源開放的主流技術标準。使用開源開放的主流技術标準可以確定技術方案的成熟度，更便捷的從開發者社群擷取技術資源和最佳實踐，也能夠幫助企業更好的招募技術人才。此外，這樣的政策也避免了被封閉技術體系和特定雲廠商所捆綁。
盡可能利用雲計算的價值。将穩定性保障、底層技術實作、技術元件維護、彈性伸縮等非功能性需求盡可能交給雲廠商解決，讓技術團隊将更多的精力投入到業務創新上。
這2個原則并不沖突，相反，它們之前可以非常好的融合，是所有使用雲計算的企業使用者都值得借鑒的架構選型标準。比如 Kubernetes 就是典型的滿足開源開放标準的技術标準，阿裡雲提供的 Kubernetes 産品可以簡化使用者的搭建成本，更好的與雲計算資源進行內建。同時使用者依然可以基于開源 Kuberntes 的标準協定與 API 使用雲産品，這就是2條選型原則互相融合的最好展現。
容器化改造
雲原生趨勢下，Kubernetes 毫無疑問已經成為了企業新一代雲 IT 架構的基礎設施。從2021年開始，波司登就開啟了微服務和容器化改造計劃，将 IT 系統的底座逐漸從虛拟機遷移到 Kubernetes。
在 Kubernetes 平台的選擇上，基于技術選型的2條原則，波司登選擇了阿裡雲容器服務 ACK 。ACK 以阿裡雲可靠穩定的 IaaS 平台為底座，向下封裝了 30+ 款雲産品，形成了自動化運維和雲平台互動的新界面，進而提升企業業務系統的彈性和自動化運維能力。
基于容器服務 ACK 的易用性以及內建能力，波司登IT系統容器化改造工作比預想中的要順利得多。對于每一個業務系統而言，從虛拟機遷移到 Kubernetes ，僅僅是底層的承載發生了變化，不會涉及到太多的改造成本。在關鍵的容器網絡實作上，容器服務 ACK 通過雲原生 Terway 網絡模式，直接基于阿裡雲的虛拟化網絡中的彈性網卡資源來建構的容器網絡，将容器和虛拟機納入同一層網絡中，便于業務雲原生化遷移。這樣完全可以對傳統架構實作漸近式容器化改造，在不中斷業務的前提下一點一點的從虛拟機往 Kuberntes 上搬。在容器化改造的過程中，當波司登技術團隊遇到疑難問題的時候，可以第一時間從阿裡雲獲得最佳實踐指導，包括叢集規劃、平台運維、應用适配、安全防護、可觀測等多個方面，這也更進一步的提升了容器化改造的速度。
目前，波司登的自研系統已經 100% 基于 Kubernetes。相比傳統的基于虛拟機部署方式，容器化幫助波司登在資源使用率上提升了30%，在運維效率上提升了40%。波司登的技術團隊也在容器化改造的過程中，掌握了管理超大規模Kubernetes叢集的能力，并促成了更多雲原生新技術的運用。
統一微服務架構
與容器化改造幾乎同步進行的是對微服務架構的統一。在此之前，波司登的各個業務單元多種技術棧并存，彼此之間互相通訊複雜度高，項目成員的交接往往要耗費巨大的精力，極大程度上阻礙了數字化轉型的進展，是以微服務架構統一勢在必行。在 CIO 戴建國的帶領下，波司登經曆了1年多時間完成了這一項艱巨的工作，雖然投入精力巨大，但收益是立杆見影的，而且可以持續發揮作用：不論是内部團隊還是三方 ISV ，在技術架構上都有統一的标準可以遵循，各團隊共享技術棧後，研發效率成倍提升。
關系到未來多年的 IT 戰略，在微服務架構的選型上，高開放性、高成熟度、高普及度這三條标準缺一不可，考慮到波司登以 Java 為主要開發語言，Spring Cloud Alibaba就成為了微服務架構的最佳選擇。
Spring Cloud Alibaba 緻力于提供微服務開發的一站式解決方案，包含開發分布式應用微服務的必需元件，友善開發者通過 Spring Cloud 程式設計模型輕松使用這些元件來開發分布式應用服務。這些元件一部分以 SDK 的形式內建到代碼中，一部分以中間件的形式獨立運作，後者往往可以選擇托管版雲産品，以降低開發者的工作量。比如阿裡雲微服務引擎 MSE 就提升了開箱即用的注冊配置中心 Nacos，以及雲原生網關。
微服務架構的挑戰
微服務對單體架構進行了拆分，不同子產品之間通過網絡進行通訊，本質上來講，這并沒有降低系統的複雜度，反而讓系統複雜度大幅度提升，在管理難度上也為開發者提出了更高的挑戰。随着微服務架構的深入使用，波司登技術團隊遇到了2個難題：
性能問題定位困難。随着業務規模的增長，對于每一個來自使用者的請求，鍊路變得越來越長，這也代表着應用之間的調用關系變得越來越複雜。傳統的依賴于單機業務日志的監控手段根本無從下手，這就需要建立全新的鍊路跟蹤機制，幫助開發者全面洞察系統運作狀态，并在系統遇到異常的時候快速的定位和解決問題。這個挑戰相對比較容易解決，阿裡雲的 ARMS 應用監控提供了無侵入式方案實作微服務鍊路跟蹤，在易用性、功能性、穩定性上都有突出的表現。波司登把部署在容器服務 ACK 的微服務應用一鍵接入 ARMS 應用監控後，接下來要做的事情就主要是熟練掌握工具，并配合 Promethues/Grafana 實作統一大盤，并利用報警平台實作事件閉環，ARMS 也通過開箱即用的方式在雲上提供了相關工具。
應用變更頻繁造成事故。為了适應網際網路業務需求的不斷變化，應用變更在大型微服務架構中，是極為頻繁的工作。新應用的上線、新版本的釋出、新配置的推送、應用擴容、應用縮容，這些都屬于應用變更的範疇。微服務架構的複雜性以及業務的快速疊代，讓波司登的技術團隊在每次應用變更中都疲憊不堪，因為絕大多數生産環境的事故都由應用變更導緻。這個難題不能簡單靠雲産品來解決，需要技術團隊深入剖析每一次事故的根因，針對性的進行優化，并建立一整套安全變更的行政機制，確定每一次變更都能讓團隊高枕無憂。
第2個難題屬于微服務治理的範疇，微服務治理是微服務化深入的必經之路，涵蓋流量治理、服務容錯、安全治理等多個領域，幫助更低成本、更穩定、更高效地開發，運維微服務應用。在波司登的實戰經驗中，上下線有損問題和安全變更問題造成的業務影響最大，波司登的技術團隊圍繞着這幾個問題進行了深入探索。
下線有損問題
微服務化之後，有一個問題長期困擾着波司登的技術團隊：每次有應用下線的時候，都會導緻一部分前端使用者的請求失敗。應用縮容和版本更新這2種情況都會産生應用主動下線行為，這兩種情況對于波司登的業務系統都是每天都要執行的日常工作。為了盡可能的保障使用者體驗，波司登最先考慮的是讓版本更新都在使用者量相對比較少的淩晨進行，以縮小問題的影響面，但這其實并不能太好的解決問題。一方面，為了提升資源使用率，應用縮容基本上發生在白天；另一方面，淩晨進行版本變更加重了 IT 團隊的負擔，若是遇到了新版本的 bug，也不利于團隊進行保障，始終不是長久之計。是以還是要從根本上找到問題的原因，通過技術方式解決問題。
我們通過下面這個圖看一下微服務節點下線的正常流程
- 下線前，消費者根據負載均衡規則調用服務提供者，業務正常。
- 服務提供者節點 A 準備下線，先對其中的一個節點進行操作，首先是觸發停止 Java 程序信号。
- 節點停止過程中，服務提供者節點會向注冊中心發送服務節點登出的動作。
- 服務注冊中心接收到服務提供者節點清單變更的信号後會，通知消費者服務提供者清單中的節點已下線。
- 服務消費者收到新的服務提供者節點清單後，會重新整理用戶端的位址清單緩存，然後基于新的位址清單重新計算路由與負載均衡。
- 最終，服務消費者不再調用已經下線的節點。
看似無懈可擊的邏輯，但在微服務系統的實際運作過程中，會存在一些微妙的差别。其本質在于，從服務提供者确認下線，到服務消費者感覺到服務提供者下線之間，存在時間差，這個時間差就是導緻服務調用失敗的視窗期。比如 Spring Cloud 使用的 Ribbon 負載均衡預設的位址緩存重新整理時間是 30 秒一次，那麼意味着即使服務消費者實時地從注冊中心擷取到下線節點的信号在負載均衡的位址緩存沒有重新整理前，依舊會有一段時間會将請求發送至老的服務提供者中。
了解到下線有損問題的本質後，波司登技術團隊嘗試對微服務應用進行了一些改造。對所有的微服務應該都增加一個向外暴露的 /offline 接口，并把對這個接口的調用加入到 Kubernetes 的 Prestop 腳本中，這樣可以在 /offline 接口中加入服務登出相關的邏輯。/offline 接口要實作的第一件事情是主動從注冊中心下線，這件事很好做，隻需要一段代碼，但這并不夠，因為服務的消費者依然需要在一段時間後才能從注冊中心感覺到這個事情。是以 /offline 接口還要實作主動通知服務消費方的邏輯，而這件事情在 Spring Cloud 架構中實作起來要複雜一些，因為沒有 channel 模型，服務提供方還不能真正實作主動通知服務消費方的需求，隻能通過間接的方式實作。在請求的 Response Header 中帶上 ReadOnly 标簽，服務消費者收到 ReadOnly 标簽後，會主動重新整理負載均衡緩存，保證不再有新的請求通路下線過程中的服務提供者。這其中會存在少量的漏網之魚，也就說明，依然有少量請求會失敗。
此外，在下線的過程中，還有一部分請求屬于在途請求：服務提供方已經收到了請求，但還沒有處理完成。要徹底解決下線有損的問題，需要服務提供者端等待所有在途請求處理都完成之後，再完成下線動作。具體等多久，這個時間是不确定的，是以漏網之魚始終存在，問題并沒有完全解決。
由于 /offline 接口的實作需要侵入代碼，而收效又有限，最終沒有能夠在波司登大面積推廣，這樣就隻能繼續從業務上容忍下線有損問題了。
上線有損問題
與下線有損問題相對應的是上線有損問題，擴容、應用新版本釋出、Pod 重新排程都會産生應用上線行為，相比下線有損問題，上線有損問題很容易被忽視，這是因為上線有損問題隻有在高并發大流量的場景中才會暴露出來，其中最典型的場景就是高峰期的應用彈性伸縮。
網際網路應用的使用者流量存在明顯的波峰波谷，波司登也積極參與大促類營銷活動來提升品牌曝光度，高峰期的應用彈性伸縮是一項正常技術手段。但波司登的技術團隊發現應用彈性伸縮所達到的效果往往不及預期，其具體的表現是新擴容出來的應用執行個體在啟動後會有3-5分鐘左右的性能瓶頸期，在這一段時間内，會造成部分使用者通路延遲劇增，在極端大流量場景下甚至拖垮了整個應用的性能，存在雪崩效應的風險。
通過排查，波司登研發團隊找到了應用上線後存在性能瓶頸期的多個原因：
異步連接配接資源阻塞。在 jstack 日志中，發現不少線程阻塞在 taril/druid 等異步連接配接資源準備上，這是因為應用執行個體啟動後，資料庫與 Redis 連接配接池中的連接配接未提前建立的情況下，就會接收來自上遊的流量負載，進而導緻大量線程阻塞在連接配接的建立上，在大流量場景下性能問題會更加突出。解決問題的思路是預建資料庫連接配接等異步建連邏輯，保證在業務流量進來之前，異步連接配接資源一切就緒。
ASMClassLoader 類加載器阻塞。由于 ClassLoader 加載類的代碼其預設是同步類加載，在高并發場景下會有大量線程阻塞在 fastjson 的 ASMClassLoader 類加載器加載類的過程中，進而影響服務端性能，造成線程池滿等問題。解決的思路是類加載器被加載前開啟其并行類加載的能力。
JVM JIT 編譯引起 CPU 飙升。當虛拟機發現某個方法或代碼塊運作特别頻繁時，就會把這些代碼認定為熱點代碼，為了提高熱點代碼的執行效率，在運作時，虛拟機将會把這些代碼編譯成與本地平台相關的機器碼，并進行各層次的優化。這是 JVM 提升性能的重要技術手段，但JIT編譯本身會消耗大量計算資源，造成編譯期間的 CPU 使用率飙升。解決這個問題最好的方式是小流量預熱，讓 Java 應用在啟動後可以先接收少部分流量，達到觸發 JIT 編譯的條件，在編譯完成之後再接收正常的業務流量。
日志同步列印導緻線程阻塞等其它問題。通過應用代碼優化實作無損上線，并不是一件簡單的事情，需要植入大量非功能性邏輯。特别在小流量預熱這項技術上，需要讓所有上遊應用感覺到應用上線的事件後，動态調整負載均衡規則，改造工作量極大。是以波司登的技術團隊并沒有自行從代碼層實作無損上線，而是往無代碼侵入的方向尋找無損上線的最優解。
安全變更問題
随着波司登微服務架構的不斷演進，系統支援的業務也越來越複雜，與此同時，業務的疊代速度也發生了翻天覆地的變化。在進行微服務改造之前，新版本釋出的頻度是以月為機關，這跟現在每周有多個應用需要釋出新版本的情況完全不在一個數量級。在經曆了多次新版本釋出導緻的生産事故之後，波司登的技術團隊吸取了之前的教訓，參考阿裡巴巴的安全變更經驗，提出了安全變更”可灰階、可監控、可復原“的原則，這就對波司登技術團隊的變更管理提出了更高的要求。特别是在灰階政策上，簡單的應用滾動更新不能控制業務流量通往新版本的比例，不能夠滿足安全變更的要求，需要有更高階的灰階技術來支撐。
為了實作灰階過程中的路由可控，波司登最初采取的方式是通過實體隔離的方式建構2套環境，每套環境都包含了全部的微服務應用，以及 Message Queue、Redis 等其他中間件。通過前置的網關層實作流量路由，決定使用者的流量發送到正式環境還是灰階環境，路由的規則可以基于流量特征進行比對，也可以設定為百分比。
這套架構搭建完成之後，是能夠非常好的勝任安全變更原則的，每次有新版本釋出的時候，都可以基于可控的流量進行小規模驗證。通過充分的驗證之後再決定是否放大進入新版本的流量比例，或者及時復原。
但随着實體隔離方案的推廣，其局限性也越來越明顯的暴露出來。首先這樣的架構存在嚴重的資源浪費問題，雖然可以盡可能利用雲計算的彈性能力适配流量規模，但也隻是降低了一部分資源，不能從根本上解決資源浪費的問題。而且需要用到的中間件産品往往不能像微服務應用一樣靈活的彈性伸縮。
此外，更重要的問題在于隔離方案需要整條業務線甚至全公司統一版本釋出節奏，因為大家隻有一套共享的灰階環境。微服務架構的規模越大，團隊之間的分工會越明确，每個團隊所負責的微服務應用在整個微服務架構中所占的比重也就越小。這樣的方案在多團隊協同作戰的時候，極難協調多個團隊的版本釋出節奏，實際上嚴重拖慢了業務系統的創新疊代速度。
因為實體隔離方案在實際生産中的局限性，業界更為推崇的是邏輯隔離方案。當需要對某一個微服務應用釋出版本的時候，可以獨立部署灰階版本，通過調用鍊路上的流量控制使得灰階流量能在灰階環境和正式環境間流轉，實作灰階微服務應用的正常運作，幫助業務方進行新功能驗證。邏輯隔離方案不需要做整套環境的備援，大量節省了資源成本。更為關鍵的是，邏輯隔離方案可以讓不同的團隊各自決定自己的灰階節奏，并不需要所有團隊都在同一個容器期進行灰階驗證。這樣不僅可以大幅度提升業務系統創新疊代速度，還能更進一步降低變更所帶來的風險，因為職責分享以後，每個團隊都可以擁有更長的灰階視窗期，灰階驗證過程中遇到了問題也能更精确的定位到責任方。
然而邏輯隔離的技術實作極為複雜，實體隔離方案僅需要在網關層控制路由政策，而邏輯隔離需要每一個微服務應用都必備識别灰階辨別并動态控制路由政策的能力。在 Spring Cloud 架構下，微服務應用之間互相調用的負載均衡機制由 Ribbon 實作，實際上屬于應用層 SDK 的能力範圍。動态控制路由政策相當于動态控制 Ribbon 的負載均衡政策，改造起來會有比較大的工作量。
邏輯隔離機制更為複雜的技術實作在于灰階辨別的全鍊路透傳，也就是針對每一個使用者請求，如果在微服務應用間流轉的過程中被打上了灰階辨別，這個灰階辨別就必須在接下來的鍊路中一直傳遞下去。比如上圖 B 服務的灰階服務在調用 C 服務的時候，因為 C 服務并沒有灰階版本，是以加到了 C 服務的穩定版本，但接下來的 D 服務是同時存在穩定版本和灰階版本的。這裡就存在一個潛在的需求：凡是經過了服務 B 灰階服務的流量，都應該發往服務 D 的灰階版本。這個需求能夠實作的必要條件，就是灰階辨別的全鍊路透傳。
微服務應用之間的灰階辨別全鍊路透傳可以借助于 ARMS 等鍊路監控工具而實作，存在一定的代碼改造工作量。但更為複雜的是，如果鍊路中存在基于消息中間件的異步調用，就不能僅僅通過調整應用層的負載均衡機制來控制路由政策了，需要對消息中間件的服務端和用戶端都進行适配，存在大量改造工作量。跟無損上線一樣，波司登的技術團隊也沒有急于求成對應用層代碼進行大刀闊斧的改造，而是與阿裡雲團隊共同探讨更優雅的解決方案。
MSE 微服務治理方案
微服務引擎 MSE 是阿裡雲面向業界主流微服務生态提供的一站式微服務平台，包括注冊配置中心、雲原生網關和微服務治理3款可以獨立輸出的産品。對于注冊配置中心和雲原生網關，波司登已經比較熟悉了，分别為微服務架構提供了 Nacos 以及 Kubernetes Ingress 服務。關于第3款産品微服務治理，波司登的技術團隊有過深入的研究，對于解決安全變更領域的多個難題都能帶來幫助，但對于微服務應用全面接入 MSE 微服務治理，波司登還是存在一些顧慮。
主要的顧慮點集中在技術改造複雜度、侵入性、穩定性等方面，波司登的技術團隊與阿裡雲的專家團隊經過深入的溝通，對所有潛在風險點逐一進行了評估。經過大量的預研後，波司登決定将微服務應用全面接入MSE微服務治理。這個方案除了在功能層面能夠滿足波司登微服務治理的需求之外，波司登的技術團隊更看中的是這幾個方面的特性：
無侵入。MSE 微服務治理能力基于 Java Agent 位元組碼增強的技術實作，無縫支援市面上近5年的所有 Spring Cloud 的版本。研發團隊不用改一行代碼就可以使用，甚至在研發階段都不需要考慮應用部署的時候是否接入 MSE 微服務治理，讓研發團隊更聚焦于業務的創新。這是一個非常重要的特性，展現了這套方案的開放度，也能確定方案不會有廠商鎖定問題。
接入簡單。使用者隻需在阿裡雲容器的應用市場安裝 pilot 元件，就可以通過 MSE 控制台對一個命名空間的所有 Java 應用開啟治理功能，這個時候 pilot 元件會自動為 Java 應用所在的 Pod 注入 Agent 。當然，更通用的方式是通過 Kubernetes 的聲明式描述，來控制每個應用是否開啟治理功能，也就是對 Pod 的 yaml 檔案加上一行注解，這樣能更友善的和 CI/CD 工具內建。當然關閉服務治理功能也是非常容易的，隻需在控制台關閉服務治理，或者修改 yaml 檔案上的注解就行，不需要改變業務的現有架構，根據需要随啟随停。
高穩定性。同時服務于阿裡集巴的内部應該以及多個外部客戶，經過了大規模實戰驗證。
可觀測能力。提供完整的流量可視化視圖，支援全局看闆、網關執行個體監控、日志檢索、業務 TOP 榜、日志投遞、以及報警管理等功能。能夠幫助使用者直接的了解到微服務治理能力開啟後産生的效果，更全面的了解微服務應用的運作狀态。
支援混合雲場景。不論是線上下 IDC，還是其他雲上部署的微服務系統，隻要網絡可以通，也能夠享受到治理能力的增強，用法保持一緻。
擁抱雲原生。與 Kubernetes 體系完美內建，無損上下線使得應用在彈性伸縮的過程中保持流量無損，通過 Jenkins 建構 CI/CD 實作在 Kubernetes 環境下的金絲雀釋出，基于 Ingress 實作全鍊路灰階等。
無損下線
MSE 實作無損下線的原理很簡單，流程如下：
當一個微服務應用執行個體接收到下線指令後，紅色字段辨別的3個步驟由 Agent 自動實作
從注冊中心下線。這一步執行完之後，服務的所有消費者有機會從注冊中心感覺到下線行為，但在 Spring Cloud 體系中，這個感覺存在時間差，并不能立即通知所有消費者，是以我們不能單純依賴這個步驟實作無損下線。
主動通知所有消費者。這是最為關鍵的一步，Agent 繞過注冊中心，直接給所有消費者發送了執行個體下線的通知，這樣消費方能夠立即感覺到下線行為。
消息者更新負載均衡。收到執行個體下線通知後，服務的消費方将下線的執行個體從負載均衡執行個體清單中移除，進而不再發請求到下線的執行個體。
這幾個步驟都完成以後，收到下線指令的應用執行個體才會在處理完所有在途請求的情況下，進入真正的下線狀态。是以整個過程不會有任何一次服務請求失敗的情況發生。這項技術不需要修改任何一行代碼，就能在版本更新或應用縮容的時候提升使用者體驗，增加微服務系統的穩定性。
如果一個微服務應用處在鍊路的入口位置，通過 Ingress 暴露給使用者，這個時候并不存在挂上了 Agent 的服務消費者應用，無損下線機制還能正常工作嗎？答案是肯定的，如果 Ingress 這一層是由 MSE 雲原生網關實作的，所有的适配工作都已經完成，無損下線機制依然可以完美運作。
無損上線
MSE 實作無損上線也是基于類似的原理：
- 微服務消費者可以快速感覺微服務提供方的上下線事件
- Agent 可以動态更新微服務消費方的負載均衡規則
是以，使用者可以為每一個微服務消費者配置一定時長的預熱視窗期，比如2分鐘。在這一段時間内，如果感覺服務提供方的執行個體新上線，就在視窗期通過小流量對新上線的執行個體進行預熱，并逐漸增量流量規模，直到視窗期結束後恢複正常的流量比例，這樣就可以規避 Java 應用啟動初期所存在的性能問題。
完整的流程如下：
不論是無損上線還是無損下線，都通過從 MSE 的控制台清晰的觀察到微服務治理帶來的效果。
全鍊路流量治理
通過 MSE 微服務治理，長期困擾波司登的安全變更問題得到了解決，因為波司登一直在追求的邏輯隔離灰階方案可以通過 Agent 技術輕松實作。為了實作邏輯隔離灰階，可以先從金絲雀釋出開始入手，金絲雀釋出在業界有廣泛的使用，是應用版本更新的常用灰階手段。金絲雀釋出會對流量進行比例分割，一開始為新版本的執行個體配置設定較小比例的流量，經過一段時間的運作，确認新版本運作正常後再逐漸提高所配置設定流量的比例，直到最終全量切流。通過這種方式做釋出可以在新版本出現問題時控制影響面，提高系統的穩定性。
金絲雀釋出通常通過流量染色和版本打标來實作。在 MSE 的實作中，流量染色可以通過識别流量特征而實作，在下圖的例子中，可以通過 HTTP Header 裡面的具體字段來決定一個請求是否進行灰階染色。而版本打标是利用 Kubernetes 的聲明式部署實作的，通過在 Pod 上添加 Annotation ，可以讓對應的版本打上灰階辨別。這樣就可以限制隻有被染過色的流量才會進入打上了灰階辨別的版本，進而實作新版本業務的小規模驗證，一旦發現新版本存在任何問題，可以及時復原，把對業務的影響降至最低。
金絲雀釋出最終會演變成全鍊路流量治理能力，進而真正實作基于邏輯隔離機制的高階灰階方案。對于穿梭在微服務鍊路上的流量，一旦被染色，就能将染色資訊傳遞到整條鍊路。這個機制和泳道非常類似，微服務在同一時間點可能存在多個并存的業務版本，每條泳道象征着一個業務版本，隻有經過染色的流量，才會進入到對應泳道中。
波司登經過半年時間的實戰探索，在 MSE 微服務治理的幫助下，最終駕馭了大規模微服務架構的全鍊路流量治理能力，并形成了成熟的流程機制，通過全鍊路流量治理對每一次應用變更進行充分的灰階驗證。有了這項技術之後，每個團隊都可以靈活的決定應用變更的時間周期，但對于安全變更的要求變得更高了，一旦造成了生産事故，在行政上會有更嚴厲處罰措施。是以需要每個團隊在實施應用變更的時候，都通過全鍊路流量治理確定穩定性，這樣即使新版本存在漏洞，對于整體業務的影響也能控制在極低的範圍内。這項技術被各團隊廣泛采納後，波司登的業務疊代頻率實作了2倍以上的提升，因為應用變更導緻的生産事故降低了 70% 以上。
全鍊路穩定性治理
另一個被波司登廣泛使用的微服務治理能力是全鍊路穩定性治理，對于波司登這樣需要頻繁舉辦線上營運活動的企業，全鍊路穩定性治理是非常重要的技術。MSE 提供的全鍊路穩定性治理，在流量防護方面形成可拓展閉環，能夠通過故障識别模型發現不同層次的問題，如接口層的狀态碼與異常類型、作業系統層的名額異常。在識别出問題後，發出異常告警，友善使用者進行針對性的流量治理，如進行自适應限流防護或場景化限流防護；防護規則設定後，系統便按照預設的門檻值與防護手段保護系統，而系統防護的效果可通過監控檢視，另一方面，也可通過監控反向審視流量防護規則設定的合理性，及時調整。
對于防護政策以及防護規則的設定，波登司主要通過全鍊路壓測獲得參考。波司登通過阿裡雲 PTS 模拟使用者流量，對系統進行了多次全鍊路壓測。在壓測的過程中不斷優化微服務架構各個環境的容量配比，确定系統在真實業務中表現出來的系統上限，同時也确定在大流量場景下需要使用到的流量防護政策。為了更進一步提升微服務系統在高并發大流量場景的性能，并提升資源使用率，波司登還充分利用了 ACK 叢集的彈性伸縮能力，在業務高峰期讓應用和叢集資源同時實作自動水準擴擴充，并在業務高峰期自動回收資源。
除了在業界廣泛運用的單機流控手段（包括并發控制、自适應防護、熔斷、主動降級、熱點防護等一系列技術）和網關流控手段之外，波司登還深入使用了MSE提供的資料庫治理能力，特别是基于 SQL 的流控、降級、容錯，避免嚴重的慢 SQL 發生後拖垮整個資料庫，對線上業務産生阻斷性的風險。
在全鍊路穩定性治理和彈性伸縮的幫助下，再加上頁面靜态化、請求攔截、資料隔離、異步處理等正常技術手段，波司登已經建立起在秒殺業務場景中支撐百萬級并發量的技術能力，并確定雙11活動過程系統的穩定運作。
總結
技術能力的不斷進步，幫助波司登使用數字化手段對業務進行不斷創新，并取得了一系列重要的戰果。數字化能力的提升也直接展現在銷量與利潤上，波司登在羽絨服的銷售額和銷售量上都登上了全球第一，連續5年實作了營收與利潤的雙位數增長。波司登的技術團隊在雲原生微服務治理方面的不斷探索，讓他們在超大規模微服務架構領域沉澱寶貴經驗，但這隻是支撐業務高速發展所經曆的多項技術變革中的一個重要組成部分。波司登會繼續擁抱雲計算，通過更先進、更高效的技術，更數字化的營運方式，引領服飾行業激發創新活力，與各行各業的時代變革者共同成長。