作者：曾孟琪（山獵）
背景
波司登創始於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年實現了營收與利潤的雙位數增長。波司登的技術團隊在雲原生微服務治理方面的不斷探索，讓他們在超大規模微服務架構領域沉澱寶貴經驗，但這只是支撐業務高速發展所經歷的多項技術變革中的一個重要組成部分。波司登會繼續擁抱雲計算，通過更先進、更高效的技術，更數字化的運營方式，引領服飾行業激發創新活力，與各行各業的時代變革者共同成長。