歐洲最大電商 Zalando 的微服務之道

寫在前面

Zalando 是歐洲目前規模最大的在線零售平臺，咱們與其餘競爭對手的主要區別在於，咱們在歐洲的大部分國家和地區提供免費送貨、100 天退貨以及便捷的免費退款服務。

Zalando 公司在歐洲的 17 個國家與地區開展業務，網站每個月訪問量超過 2.5 億，活躍客戶超過 2600 萬。目前，公司已經擁有 1 萬 5 千多名員工，去年收入約爲 54 億歐元。咱們也在進一步推進規模擴展，但願爲即將到來的黑色星期五購物季作好準備。

去年的黑五，咱們打破了銷售額歷史紀錄，共收到約 200 萬份訂單。在峯值時段，咱們每分鐘接到超過 4200 份訂單，這不僅表明着可觀的收入，同時也是一種巨大的挑戰。若是沒有可靠的底層技術做爲支持，這一切根本不可能實現。爲了提前作好準備，咱們從 2015 年就開始着手從單體架構遷移至微服務架構。到 2019 年，咱們已經擁有超過 1000 種微服務。咱們目前的技術部門擁有 1000 多名開發人員，編組成超過 200 個具體團隊。各個團隊立足自身職能涵蓋一部分客戶體驗與業務事務。此外，各個團隊也擁有具有跨學科技能的不一樣團隊成員，負責知足前端、後端、數據科學、用戶體驗、研究、產品以及團隊須要知足的一切客戶需求。

因爲業務規模很是可觀，咱們對於各支團隊須要管理的服務也肩負着端到端責任。固然，隨着從單體到微服務的遷移過渡，獲得受權的各個團隊也開始自主管理下轄的軟件開發工做。在實施過程當中，咱們發現讓各個團隊徹底按照本身的方式執行任務其實至關困難，因此咱們最終制定出軟件開發標準流程。流程的確立，離不開開發者生產團隊爲咱們提供的工具方案。如此一來，在各個軟件開發週期當中，每支團隊都能輕鬆啓動新的項目、着手設置，並逐步完成編碼、構建、測試、部署以及監控等環節。

結帳功能與實施架構

我專門負責結帳功能的開發，不少不熟悉的朋友可能以爲結帳這東西沒什麼大不了，但它但是顧客購物體驗中的最後一環，甚至是最關鍵的一環。咱們須要告知客戶如何配送、配送到哪裏、如何結算、以及怎樣完成下單。在團隊當中，每名成員都須要打理多項微服務。固然，不一樣的成員有着不一樣的開發風格，咱們的微服務也有 Java 、 Scala 以及 Node.js 等多種形式。咱們的主要通訊對象是 REST ，同時也經過消息傳遞機制與某些依賴項進行通訊。對於穩定的應用場景，咱們利用 Cassandra 做爲數據存儲方案。在配置方面，咱們則選擇 ETCD 來實現。

咱們的全部微服務都運行在 AWS 以及 Kubernetes 當中。當初從單體式架構遷移至微服務架構的同時，咱們也順帶完成了雲遷移。EC2 實例是咱們最先體驗的雲計算服務。最近兩年以來，咱們開始慢慢接觸 Kubernetes 。個人團隊在這方面貢獻了巨大的力量，主要負責 AWS 與 Kubernetes 中的軟件遷移與服務維護。目前，包括結帳功能與 Lambda 在內的各項微服務都運行在容器環境當中。全部微服務環境都限定在咱們的基礎設施以內。對於面向客戶的應用，咱們使用 React。固然，咱們也用到了多種其餘技術。

總而言之，咱們開發出一項至關穩定的結帳服務，運行效果不錯。它符合一切結帳功能須要遵循的規則，並可以與其餘 Zalando 依賴項進行交互，同時採用 Cassandra 做爲數據存儲。接下來，咱們還爲該後端開發出了相應的前端。這一樣是一項微服務，用於彙總來自結帳服務及其餘沒法在結帳功能以內獲取的 Zalando 服務的數據。例如，若是顧客在結帳當中極可能但願再次查看商品的相關信息，這部份內容顯然不屬於結帳數據，所以咱們必須與其餘微服務進行通訊。

接下來，咱們還有前端微服務。前端微服務負責提供服務器端片斷呈現結果。片斷屬於頁面的一部分，相似於頁眉、正文、內容以及頁腳。顧客在當前頁面上看到的雖然是一個總體，但其中各個部分極可能來自不一樣的開發團隊。在完成全部的片斷開發以後，咱們將提供 Tailor 服務，用於將這些片斷組合起來。順帶一提，Zalando 已經對 Tailor 進行了開源。Skipper 是 Zalando 開發完成的另外一個項目，做爲咱們的開源 HTTP 路由。經過這種方式，咱們能夠將全部頁面都存儲在 Zalando 在線時尚品銷售平臺當中。

全部這些組件都與「結帳」這一核心上下文相關，並且都對咱們的業務擁有相當重要的意義。結帳是客戶體驗流程中很是重要的組成部分，甚至直接影響着咱們的客戶感覺與業績結果。在 Zalando，咱們擁有大量微服務。若是其中某項微服務遭遇崩潰，並致使結帳操做沒法正常完成，那問題就嚴重了。換言之，只要結帳功能出了問題，全公司立刻就會跑來向咱們興師問罪……

結帳的挑戰與經驗教訓

正如前文所提到，利用微服務生態系統構建結帳功能，最主要的挑戰在於大量微服務之間的彼此交互。此外，咱們還須要與其餘 Zalando 微服務保持交互。這無疑顯著增長了可能的故障點，同時帶來大量接觸點組合——這些接觸點一樣可能引起問題。另外，咱們只掌握着一部分微服務，但卻沒法控制其餘依賴項的變動。所以一旦某些依賴關係受到影響，咱們的結帳功能也有可能迅速陷入癱瘓。

咱們須要從可靠性模式當中總結經驗教訓，以免此類故障的發生，最終確保結帳功能的可用性。咱們還須要審查本身的擴展方式，爲高達 2600 萬活躍用戶提供服務，並準備迎接黑色星期五等高流量活動。咱們也會審查監控記錄，藉此獲取正確的信號，深刻了解咱們的服務如何運行，以及在發生問題時如何作出響應。

下面，我會以結帳確認頁面爲例，向你們介紹如何以可靠方式構建微服務。這裏是客戶決定下單的最後一個環節。爲了順利完成結帳操做，其中會涉及到多種微服務以及依賴項。例如，咱們須要瞭解客戶所指定的配送目的地——多是顧客的家或者辦公室地址；咱們還須要提供配送服務選項，檢查顧客選擇了普通快遞、第二天達仍是價格更低的四日達等服務，外加顧客所選擇的商品及付款方式等等。全部這一切，都須要與結帳功能進行順利交互，然後才能完成整個結算及下單流程。只要其中一項未能正常起效，客戶就沒辦法完成結帳，並給咱們的業務形成直接影響。

以配送爲例，配送服務當中包含全部可用的配送選項，可以根據咱們在售的商品以及客戶的實際居住地進行郵費結算。若是該服務沒法正常起效，客戶就不能選擇適合本身的配送方式，更談不上最終結帳了。爲了改善這種狀況，咱們嘗試利用一些特定的模式改善與配送服務的交互，但願避免此類錯誤的發生。另外，結帳頁面也不能太醜；並且對我我的來講，語言顯示也得正確，畢竟若是跳出個德語頁面，我都不知道該怎麼操做。

具體的改善方法，就是重試。所謂重試，就是在某項操做（例如結帳頁面中的配送選項）在發生問題後，進行循環嘗試的具體次數。重試也有不少方法，自己能夠進行深度改進，但咱們的想法就是確保在發生網絡或者服務過載等瞬時錯誤時，經過再次操做來測試錯誤是否消失。若是錯誤消失，咱們就能得到成功的響應，從而順利完成結帳流程。

最終消失的錯誤屬於暫時性錯誤。另外，咱們還要確保不會對全部錯誤進行重試，畢竟若是錯誤源自某項與其餘服務相沖突的變動，那麼單純重試根本解決不了問題，只會讓流程陷入死循環。換句話說，這些錯誤不會自行消失，咱們要確保的是隻對那些會自行消失的錯誤進行重試。

再來看代碼示例。如今，我在嘗試運行部分 Scala 代碼，並努力保證應用模式匹配。若是結帳頁面中顯示出配送選項，就證實模式匹配成功，接下來能夠順利完成下單了。若是遇到瞬間故障，頁面就會重試。但若是有錯誤，咱們會彈出錯誤提示，然後嘗試進行解決。

儘管如此，考慮到 Zalando 的龐大規模，以上方式仍有可能引起新的問題。每一秒鐘，Zalando 上均可能同時存在 1000 項請求，若是進行 3 次重試，那麼請求數量就會新增 3000 項。在此期間，那些發生過載的服務也須要進行重試，這無疑會令過載問題更加嚴重。整個系統都會陷入死循環，而咱們將無力迴天。爲此，咱們選擇在重試中引入指數積壓機制。簡單來說，就是在發生故障後不當即進行重試，而是等待一段時間再從新操做。每一次重試間的間隔都將以指數形式增長，這就能大大下降遠程服務全面過載的可能性。舉例來講，咱們的第一次重試請求間隔 100 毫秒，一樣失敗；接下來等待 200 毫秒，繼續重試；然後等待 400 毫秒……依此類推。

但這仍是沒法保證萬無一失。咱們可能會用盡重試次數，接下來暫時性錯誤就天然變成了永久性錯誤。若是遇到這種狀況，確定不能繼續容許其餘請求調用這項遠程服務了。爲了不這個問題，咱們須要避免可能致使調用永久失敗的操做。爲此，咱們引入了斷路器模式。其中的基本思路是，咱們把操做打包到一套迴路當中，只要遠程服務正常，就能繼續發送操做。但若是服務的健康狀態出現了問題（由相關指標決定），咱們再也不繼續發送請求，並快速廣播失敗問題。這樣總比長時間等待好得多。

這套迴路最重要的機制，就是判斷什麼時候斷開。閾值正是爲此而生，咱們選擇使用 Hystrix 完整閾值。若是閾值設置爲 50%，那麼一旦錯誤率高於該閾值，則再也不容許其餘請求調用此項遠程服務。在斷路完成後，結帳頁面中的獲取配送選項功能自動失敗。但問題是，這樣一來顧客仍然沒法順利完成下單，那該怎麼辦？應急預案須要馬上上線。這是個有趣的問題，做爲開發人員，咱們一直習慣於編寫優雅的代碼並處理其中存在的 bug——可是，有些問題可能跟代碼 bug 無關，這時候應急計劃就很是必要了。

固然，有些應急計劃須要由專人負責規劃；但好在咱們擁有一支完整的團隊，每位成員均可以針對結帳中的組件作出良好決策。經過討論，咱們發現標準寄送是絕大多數買家的首選，並且相關服務能夠保證隨時可用。所以，咱們決定將其設置爲默認配送方式。雖然能提供多種配送選項更好，但能結帳總比不能結帳強得多。

綜上所述，咱們用指數回退的方式進行操做重試，利用斷路器把操做打包起來，並在可行的狀況下利用預置選項應對故障。總之，咱們想盡一切辦法確保異常情況不致中斷顧客的結帳流程。

微服務擴展

下一項工做的重點在於微服務架構的擴展伸縮。首先介紹一下咱們服務中的典型流量模式：天天下午 4 點到午夜，訪問量都會迎來高峯。接下來，人們會上牀睡覺，所以流量急劇降低，直到次日上午 7 點再次開始回升。咱們須要確保服務足以應對一天中的各類流量強度，同時也隨着時間推移從中總結出一些固定的模式。固然，各個國家的狀況總有不一樣，所以也具備各異的具體模式細節。另外，促銷或者推廣活動期間，流量也會出現獨立於常規模式以外的浮動。下面是咱們在處理業務流量時採起的宏觀方式。

首先，咱們確保每項微服務都具備相同的基礎設施，並利用負載均衡器處理傳入的請求。接下來，咱們會將請求分發至多個實例內的微服務副本，或者是經過多個端口將請求分發至各 Kubernetes 節點。每一個實例都運行有基於 Zalando 的鏡像，此鏡像內包含大量須要遵循合規性與安全性要求的內容，確保整個業務流程始終符合當前運營策略。咱們是一家認真的企業，天然要以認真的態度對待本身的業務。

以此爲基礎，咱們利用容器環境運行各項微服務。這些容器環境能夠是 Node 環境、JVM 環境等等。至少在咱們的業務體系內，主要使用 Node 與 JVM。請求處理方式大致就是這樣。至於規模伸縮問題，咱們設置了兩種實現方式。第一種是橫向伸縮，這既是最方便的選擇，也是我在實踐中體會到的最簡單的選擇。由於咱們在架構設計時就已經爲每項微服務部署了三套副本以及三個對應的實例。一旦發現實例運行狀態不佳的跡象（基於某些特定指標，例如 CPU 利用率達到 80%），則表明現有資源容量可能短缺，因而咱們會當即啓動更多實例。目前，咱們僅使用 AWS 與 Kubernetes 中的自動規模伸縮策略來增長額外的實例或者端口。

第二種方法天然就是縱向伸縮了。這是一種須要根據狀況適當使用的選項。當遇到某些規模擴展問題，但當前設置又沒法處理更多請求時，咱們就須要增長單一實例的容量上限（不一樣於橫向擴展中的直接增長實例數量）。舉例來講，咱們能夠添加更多 CPU、更高的內存容量；若是使用的是 AWS 實例，咱們還能夠根據需求切換爲其餘擁有更多或更少計算核心的實例類型。這兩種方式各有優勢與缺陷，我我的認爲從長遠來看，橫向擴展通常更好，由於咱們不須要依賴於特定的設備類型，同時升級過程也會更加輕鬆。

固然，可規模伸縮性也會帶來負面影響。好比在黑色星期五期間，咱們就要進行容量規劃、業務預測、負載測試，並最終發現須要將規模擴大 10 倍。咱們想得很簡單，直接把本來的最小值 6 設置到了 60，就覺得自動伸縮機制部署到位了。但咱們沒有意識到的是，當實例數量增加時，也會帶來更高的數據庫鏈接需求。換言之，2600 萬活躍客戶平時實際上是在以較爲分散的方式使用咱們的網站；但如今，他們一股腦涌來，而咱們增加了 10 倍的實例又會將壓力進一步轉嫁到指向 Cassandra 數據庫的鏈接身上。

可憐的 Cassandra 固然沒法處理全部鏈接。最終，巨大的流量令 Cassandra 疲於應對，CPU 佔用率也開始一路飆升。而一個 Cassandra 實例的崩潰，又會很快引起下一個 Cassandra 實例的崩潰，不斷引起恐怖的連鎖反應。在這種狀況下，即便服務規模可以快速擴展，缺乏了數據存儲的支持，整個微服務架構也仍然會陷入癱瘓。這讓咱們瞭解到，即便是看似簡單的規模伸縮，也絕對沒有那麼無腦。另外，規模伸縮也會給依賴關係形成直接影響。所以，咱們決定經過改進 Cassandra 中的配置，同時調整 Cassandra 內的資源處理方式來解決這個問題。很幸運，效果使人滿意。

對單一微服務進行擴展不是什麼大事，但對於結帳這類複雜的功能系統，或者是其餘包含多個微服務與依賴項的方案，一旦其中任何一項沒法同步擴展，那麼整個流程都有可能遭遇故障。所以，咱們毫不能把各項微服務彼此割裂開來，而應將其視爲完整的生態系統。

低流量轉移

最後一個難題，就是在服務轉移期間的規模伸縮問題。這一點一樣很是重要，畢竟事先規劃得再好，真正部署時也有可能鬧出毛病。每次進行部署時，咱們都強調要將實例或者端口數量控制在最低水平。舉例來講，咱們可能會配備 4 個實例，具體數字來自咱們根據以往模式以及經驗積累得出的猜想性結論。好比當前負責承載 100% 流量的服務版本 1 採用 4 個實例，那麼版本 2 也會從 4 個實例起步。如此一來，咱們就可以比較輕鬆地以百分比形式進行流量調整；並且因爲版本 2 與版本 1 的容量相同，所以後者的流量能夠更安全地轉移到前者當中。

但對於流量較高的狀況，轉移過程會受到怎樣的影響？因爲自動擴展策略已經啓動，所以版本 1 必然要進行縱向擴展。擴展以後，新的版本 1 當中包含 6 個實例；而剛剛建立的版本 2 仍然運行有 4 個實例。到這裏情況就很明確了——即便逐步進行流量切換，版本 2 仍然可能出現實例過載的風險，服務可用性也有很大機率隨之下降。

咱們的系統中配備有負載均衡器，它會持續獲取不一樣實例的指標以判斷其是否正常工做，所以在過載以後，負載均衡器會中止發送流量。流量中斷意味着返回錯誤，客戶也就沒法正常使用服務。另外還有一種可能，就是咱們在微服務以內看不到任何異常，只是在各個國家 / 地區都呈現出請求速率降低的趨勢。

所以，在進行轉移時，請務必確保目標服務與當前服務擁有相同的容量。不然，即便是新增哪怕一項功能，您的服務可用性都有可能受到影響。總之，請慎重再慎重。

微服務監控

下一個主題是微服務監控。在監控微服務時，請確保跟蹤整個微服務生態系統的運轉狀況。具體來說，咱們須要監控的不僅是微服務自己，也包括微服務運行所處的應用程序平臺、通訊環境以及硬件系統。咱們能夠將監控指標具體劃分爲基礎設施指標與微服務指標，藉此獲取不一樣的狀態信息，並以此爲基礎瞭解可以在哪些層面改進咱們的服務水平。

先以包含 JVM 技術棧的微服務爲例，這些微服務構建起穩定的應用程序並運行在 AWS 當中。對於此類微服務，咱們監控的是 AWS 指標，例如 CPU 利用率、網絡流量、內存以及磁盤使用率等。此外，咱們還須要監控通訊指標，例如負載均衡器狀態如何、目前存在多少個健康實例、ELB 與實例之間是否存在鏈接錯誤、內部負載的響應速率如何、外部服務負載的響應速率如何、ELB 中的請求率如何、這些請求順利進入了實例以內仍是因沒法鏈接而向客戶端返回了錯誤提示等等。

下面再聊聊微服務指標。這裏咱們之後端服務，也就是 API 端點爲例。咱們須要監控每個商戰，查看請求速率以及響應速率，從而瞭解其是否處於正常運做狀態。固然，咱們也爲依賴項制定了監控指標。對咱們來講，這種對依賴項交互方式的瞭解很是重要。咱們會跟進存在依賴項交互錯誤的帳戶，同時也會關注故障轉移、斷路器以及具體斷開位置等狀況。

再有，咱們也創建起指向特定語言的指標。對於 JVM，咱們須要監控線程數量，以瞭解咱們的應用程序是否擁有良好的線程使用率，或者在完成某一線程中是否遇到了問題。咱們還須要監控內存堆，藉此瞭解咱們的 JVM 設置是否正確，或者可以切實有效地整理出與後續改進相關的信息記錄。

第二個例子是前端微服務。示例前端微服務以 Node JS 爲環境，運行在 Kubernetes 當中。咱們會監控 Kubernetes 指標，包括端口數量、CPU 利用率、內存以網絡容量等等。整個體系與 AWS 相似，但一樣屬於基礎設施範疇。而後，咱們須要關注 Node JS 指標——因爲咱們在服務器端進行渲染，所以必須確保目前的 Node 環境設置可以以正確方式使用堆與事件循環。畢竟在 Node 當中，咱們就只有一個線程，絕對不容有失。

與後端服務同樣，咱們的前端微服務也擁有端點。兩者的差異在於，前端微服務端點返回的是 HTML。咱們會監控各個端點的速率以及具體響應時間。全部信息都能經過儀表板查看，很是方便快捷。另外須要強調一點，咱們只將儀表板做爲指標顯示窗口，而不會利用它檢測服務中斷。

那麼服務中斷該如何處理？咱們選擇的是警報機制——即收到通知、中止目前正在執行的操做、採起緩解措施，最後肯定問題所在。這裏的示例警報顯示，有五分之一的實例處於不健康運行狀態。引起問題的潛在緣由不少，有多是內存容量不足、JVM 配置錯誤或者結帳服務返回的 400 錯誤超過了預設的 25% 閾值。固然，問題也可能源自與 API 合約相沖突的新近變動，但遺憾的是咱們目前還檢測不到這一項。總之，能夠看到咱們在過去五分鐘內一筆訂單也沒有完成，下游服務正在檢測連通性問題。在這種狀況下，即便擁有看似可靠的服務模式，結帳操做仍然沒法順利完成。

結帳數據庫的磁盤利用率爲 80%。一個可能的緣由是，流量的快速增加致使數據庫存儲趨於飽和。總之，全部這些警報只是在對服務中當下存在的異常情況作出描述，並且所有描述都應具有可操做性。畢竟若是警報上報的是咱們無能爲力的狀況，那麼報不報其實就沒什麼意義了，由於咱們只能選擇忽略。另外，在結帳這個環節中，咱們不可能忍受長達數小時的服務不可用問題。因此，保證警報信息的可操做性相當重要。若是你們看到一條警報，但殊不知道如何應對這種情況，那麼極可能須要認真考慮這條警報的適用性問題。

一旦有了警報觸發器，下一步就是評估警報來源的具體症狀。若是當前團隊內部沒法解決問題，就須要經過協調與其餘團隊取得聯繫。另外，咱們會按照運行手冊的說明先儘快止損，採起緩解性措施，而後在取證階段追溯形成問題的根本緣由，同時確保取證結論有助於解決實際問題。最後，就是善後性質的收尾工做。這就是咱們在處理取證工做中的一個簡單流程。

固然，因爲整個公司內部都遵循統一的取證方式，所以每個環節都必須很是清晰明確。例如，最近五分鐘沒有完成一筆訂單，客戶受到影響，2000 名顧客沒法結帳，業務受到影響，可能形成 5 萬歐元的訂單損失，對根本緣由作出分析。面對這些複雜的狀況，咱們一般使用「五個爲何」來簡化理解。首先是「爲何沒有訂單？」答案多是，「由於發生了服務過載，，並且自動規模伸縮策略沒起做用。」接下來要問的就是，「爲何沒起做用？」依此類推，直到咱們確認並收集到引起事件的全部因素。固然，最重要的是接下來的行動部分，各團隊甚至組織總體須要行動起來，確保從此不會再次發生相似的狀況。

咱們要求確保每次事件以後都進行過後分析。雖然編寫文檔確實至關枯燥無聊，但若是拿不出明確的影響信息，咱們就沒辦法給出「須要提升測試覆蓋率以擴大測試範圍」這類有針對性的處置意見。這類信息不只對企業運營而言很是重要，同時也是新功能設計與部署的必要前提。總之，過後取證與分析絕對不容忽視。

總結

總結來說，可靠性模式、可擴展性以及監控機制，共同構建起咱們順利應對黑色星期五的堅決信心。在具體籌備階段，咱們會進行一輪業務預測，發佈相應數量的訂單，從而在極高的負載壓力下測試客戶的實際體驗。

因爲咱們的業務總體運行在微服務生態系統當中，所以客戶的使用流程必須會涉及到每個團隊。在黑色星期五期間，顧客們可能會轉到某個目錄頁面，選定商品，將其添加到購物車，然後進行結帳。每一個環節都不能出錯，不然客戶體驗就不完整甚至根本沒法推動。在此基礎上，咱們須要肯定使用流程中涉及的全部服務，而後對其開展負載測試。本週以內，咱們就將着手進行容量規劃，並相應擴展服務，同時肯定性能瓶頸以及黑色星期五期間可能須要解決的其餘潛在問題。

此外，對於購物流程中涉及的每一項微服務，咱們還要整理出對應的檢查清單，用於覈查其中的架構與依賴項是否正確、是否肯定並強化過可能的故障點、是否爲全部微服務總結出可靠性模式，以及是否可以在無需部署的前提下實現配置調整等等。

以前我曾經提到，在高流量背景下進行服務轉移可能帶來風險。特別是在黑色星期五期間，咱們絕對不想在這個節骨眼上嘗試服務轉移。這不單是由於咱們懼怕出錯，也是由於咱們是一家認真負責的企業，不能允許這種不專業的問題出現。但必須認可，世上沒有萬無一失的辦法：以前就有1、兩年中，黑色星期五巨大的流量甚至耗盡了 AWS 的雲資源。咱們不想部署並啓動更多新實例，由於咱們可能再次遇到沒法獲取更多 AWS 資源的狀況。相反，咱們必須確保已經肯定的全部負載（例如業務規則、客戶微服務配置以及咱們但願關閉的一切功能切換機制）都可以在無需部署的前提下實現即時配置。

接下來，咱們又回顧了本身的擴展策略。在黑色星期五期間，咱們可能須要調整平時平常使用的典型自動伸縮策略。然後是是監控機制——全部警報都能正常起效嗎？咱們的團隊是否作好了 24/7 全天候響應服務速率波動的準備？

在黑色星期五的前一天，咱們還佈置了一間戰況室。與這波活動相關的全部團隊都彙集在這間戰況室當中——固然，每組只選派一名錶明。咱們會在這裏經過監控相互合做，並在發生任何緊急情況時聯手解決問題。

咱們的黑色星期五請求模式彙總中能夠看到，請求先是快速增加、達到峯值，然後持續降低。在最高峯處，咱們每分鐘須要處理超過 4200 份訂單。

回顧這段經歷，個人結論是咱們須要主動擺脫溫馨區，學會預判可能遭遇到的不一樣錯誤——而不是坐等錯誤出現再着手解決。咱們應當實施可靠性模式，同時確保全部服務都可以根據需求進行等比例規模伸縮。此外，依賴關係也值得關注，並利用監控手段識別微服務生態系統中的各種指標，從而保證當前環境正按預期方式運行且服務健康狀態良好。