如何判斷一家公司是否成功使用了現代應用開發技術呢？ 很簡單，看看客戶有沒有在社交媒體上抱怨就知道了。 客戶可能會抱怨新片看不了，網銀登不上去，購物車超時無法下單。
（我正要看一個我租借的電影，但是老是彈出“影片播放錯誤”的提示，並且網站幫助頁面的網址也打不開。 我的App是最新版本，我試過了退出重新登陸，也重啟過我的網路電視。 求個解決方案？ ）
即使他們沒有公開抱怨，也不代表就沒有問題。 我們的一位客戶 —— 一家大型保險公司曾告訴我們，如果他們未能在僅僅 3 秒內載入出主頁，便會面臨客戶流失的問題。
使用者對性能差或宕機問題的所有抱怨都指向了一個共同的元兇：缺乏彈性。 微服務技術（包括容器和Kubernetes）好就好在它能提高應用彈性，顯著改善客戶體驗。 為什麼呢？ 這一切得從架構說起。
微服務架構與單體架構存在本質上的區別。 打個比方，在老式的節日燈串中，只要有一個燈壞了，整串就都不亮了。 如果不換燈泡，那就只能將整串丟掉。 單體應用就像這種老式燈串一樣，其元件緊密耦合在一起，一損俱損。
但是，照明行業和軟體行業都發現了這個痛點。 如果現代燈串上的某個燈泡發生故障，其他燈泡仍會繼續照明。 同樣，對於設計良好的微服務應用而言，即使個別服務實例發生故障，整個應用也會繼續運行。
Kubernetes 流量管理
容器因其輕便、可移植和易於擴展的特點，非常適合需要使用小型獨立元件構建應用的場景，因而成為了微服務架構中頗受歡迎的一種選擇。 Kubernetes 已成為容器編排的事實標準，但若投入生產環境，還面臨著許多挑戰。 要想增強 Kubernetes 應用的可控性和彈性，成熟的流量管理策略是一個重要因素，它能夠讓您控制服務而不是數據包，並動態地或使用 Kubernetes API 調整流量管理規則。 流量管理在任何架構中都很重要，但對於高性能應用來說，有兩個流量管理工具是必不可少的：流量控制和流量精分。
流量控制
流量控制（有時稱為“流量路由”或“流量整形”）是指控制流量去向及其傳輸方式的行為。 在生產環境中運行Kubernetes 是必須的，因為它可以保護您的基礎架構和應用免遭攻擊和流量激增。 在應用開發過程中，您需要採用「速率限制」和「斷路」這兩種技術。
- 案例：我不希望服務接收過多請求
解決方案：速率限制
無論 HTTP 請求是惡意的（例如暴力破解密碼和 DDoS 攻擊）還是正常的（例如顧客蜂擁搶購），大量的 HTTP 請求都會導致服務癱瘓和應用崩潰。 速率限制技術可限制使用者在給定時間段內的請求數量。 這些請求可能非常簡單，例如存取網站主頁的 GET 請求，或是登錄頁面上的 POST 請求。 舉例來說，當受到 DDoS 攻擊時，您可以使用速率限制將傳入的請求速率限制為真實使用者的合理數值。
- 案例：我希望避免出現級聯故障
解決方案：斷路
當服務不可用或出現高延遲時，傳入請求的超時時間以及用戶端收到錯誤回應的時間可能很長。 長超時可能會造成級聯故障，即一個服務中斷導致其他服務超時，最終引發整個應用故障。
斷路器可監控服務故障，防止發生級聯故障。 當服務請求的失敗次數超過預先設定的閾值時，將觸發斷路器，斷路器一收到請求就向用戶端返回錯誤回應，從而對服務進行限流。
斷路器將持續攔截和拒絕請求，等過了指定的時長后再放行有限數量的請求以作測試。 如果這些請求成功，斷路器將停止限流。 如果不成功，則開始重新計時，期間斷路器繼續拒絕請求。
流量精分
流量精分（有時稱為“流量測試”）是流量控制的一個子類，目的是為了控制傳入流量的比例，這些流量會被導向到在環境中同時運行的不同版本的後端應用（通常為當前的生產版本和新版本）。 流量精分是應用開發週期中的重要一環，允許團隊在不影響客戶的情況下測試新特性和版本的功能和穩定性。 實用的部署場景包括調試路由、灰度部署、A/B 測試和 藍綠部署。 （業界對這四個術語的使用存在很大分歧，此處先按我們理解的定義來使用它們。 ）
- 案例：我準備在生產環境中測試新版本
解決方案：調試路由
假設您有一個銀行應用，現在您要為其添加一個信用評分功能。 在進行客戶測試之前，您可能想要看一下它在生產環境中的表現。 調試路由允許您公開部署新功能，同時又向真正的使用者“隱藏”它，根據session cookie、session ID 或group ID 等 7 層屬性，只允許特定用戶存取它。 例如，您可以只允許擁有管理會話cookie的使用者存取 —— 他們的請求將被路由到具有信用評分功能的新版本，而其他使用者則繼續存取穩定版。
- 案例：我需要確保新版本性能穩定
解決方案：灰度部署（又稱“金絲雀部署”）
金絲雀部署的概念來自一個歷史悠久的採礦實踐，當時的礦工將金絲雀裝在籠子裡帶入礦井，一旦發現金絲雀中毒就緊急撤離，因此金絲雀是“瓦斯報警鳥”。 在應用世界里，不會再有犧牲品了。 灰度部署為測試新特性或新版本的穩定性提供了一種安全、敏捷的方法。 典型的灰度部署是，先讓絕大多數（比如 99%）使用者使用穩定版，然後將一小部分使用者（剩餘的 1%）轉移到新版本。 如果新版本出現問題（例如崩潰或向用戶端返回錯誤），您可以立即將測試使用者轉移回穩定版。 如果新版本順利運行，您可以一次性或以可控的方式逐步（更為常見）將使用者從穩定版遷移到新版本。
- 案例：我需要瞭解新版本是否比當前版本更受客戶的喜愛
解決方案：A/B 測試
確認新特性在生產環境中運行無誤后，您可能還希望了解客戶對該特性的反饋，包括點擊量、回頭客比率或顯式評分等關鍵性能指標 （KPI）。 許多行業都使用 A/B 測試流程來衡量和比較用戶行為，目的是確定不同產品或應用版本在客戶群體中的受歡迎程度。 在典型的 A/B 測試中，50% 的使用者存取版本 A（目前的應用程式版本），剩餘 50% 的使用者存取版本 B（包含穩定的新功能的版本）。 KPI 綜合得分最高的版本將勝出。
- 案例：我希望在不停機的情況下將使用者轉移到新版本
解決方案：藍綠部署
現在，假設您的銀行應用即將進行重大版本變更，那麼，恭喜您！ 過去，版本升級通常意味著使用者停機，因為您必須先從生產環境中移除舊版本，然後才能再推送新版本。 但在當今競爭激烈的環境中，大多數使用者都無法接受停機升級。 藍綠部署極大地減少甚至消除了升級的停機時間。 您可以繼續在生產環境中運行舊版本（藍），同時在該生產環境中部署新版本（綠）。
大多數企業都不願意將所有使用者一次性從藍色轉移到綠色，畢竟，如果綠色版本發生故障怎麼辦？！ 解決方案是使用灰度部署，以最符合您的風險規避策略的增量方式轉移使用者。 如果新版本是一場災難，您只需敲擊幾下鍵盤，便可以輕鬆地將每個人轉移回穩定版。
NGINX 如何助您一臂之力
大多數 Ingress controllers 和 service mesh（服務網格）都可以説明您實現進階流量控制和分割。 使用哪種技術取決於您的應用架構和案例。 例如，Ingress controller 適用於以下三種場景：
- 您的應用只有一個端點，就像您遷移到 Kubernetes 的簡單應用或單體應用一樣。
- 集群中沒有 service 到 service 的通信。
- 集群中有 service 到 service 的通信，但您還沒有使用 service mesh。
如果您的部署複雜到要使用 service mesh 的地步，一個常見的案例是通過分割服務流量來測試或升級各個微服務。 舉例來說，您可能想在移動前端的兩個不同版本的地理位置微服務 API 之間進行灰度部署。
然而，有些 Ingress controller 和 service mesh 在設置流量精分時不僅非常耗時，而且容易出錯，原因有很多：
- 不同廠商的 Ingress controller 和 service mesh 具有不同的 Kubernetes 功能實施方式。
- Kubernetes 不是專為管理和理解 7 層流量而生。
- 有些 Ingress controller 和 service mesh 不支援複雜的流量管理。
借助 NGINX Ingress Controller 和 NGINX Service Mesh 您可在幾秒鐘內輕鬆配置穩健的流量路由和分割策略。 請觀看 NGINX 專家的現場演示，並繼續閱讀下文，瞭解我們如何通過簡化的配置、進階的自定義以及改進的可視化説明您節省時間。
NGINX Ingress 資源和 SMI 規範助您簡化配置
以下 NGINX 功能簡化了配置流程：
- 面向 NGINX Ingress Controller 的 NGINX Ingress 資源 —— 雖然標準的 Kubernetes Ingress 資源可簡化SSL/TLS 終止、 HTTP 負載均衡和 7 層路由的相關配置，但它不具備斷路、A/B 測試和藍綠部署所需的定製功能。 因此，非 NGINX 用戶必須求助於註釋、ConfigMap 和自定義範本，但它們都缺乏細粒度控制，並且不安全、易出錯且難使用。
NGINX Ingress Controller 自帶 NGINX Ingress 資源，作為標準 Ingress 資源（同時也支援該資源）的替代方案。 該資源採用了一種原生、類型安全的縮進式配置風格，可簡化 Ingress 負載均衡的實施。 對現有 NGINX 用戶來說，NGINX Ingress 資源還有一個額外的好處：它們可以簡化非 Kubernetes 環境中負載均衡配置的再利用，從而支援所有 NGINX 負載均衡器使用相同的負載均衡配置。
- 遵循 SMI 的 NGINX Service Mesh —— NGINX Service Mesh 實施了 Service Mesh Interface （SMI） —— SMI 是一個規範。 定義了在 Kubernetes 上運行的 Service Mesh 的標準介面，具有
TrafficSplit、TrafficTarget和HTTPRouteGroup。 等類型化資源。 借助標準的 Kubernetes 配置方法，NGINX Service Mesh 和NGINX SMI 擴展程式可簡化流量精分策略（如灰度部署）的部署，並最大限度地減少對生產流量的中斷。 以下是使用 NGINX Service Mesh 定義灰度部署的範例：
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
name: target-ts
spec:
service: target-svc
backends:
- service: target-v1-0
weight: 90
- service: target-v2-0
weight: 10我們的課程《使用流量精分的部署》介紹了利用流量精分的部署模式範例，包括灰度部署和藍綠部署。
借助進階定製實現更複雜的流量控制和流量精分
NGINX 的以下功能能夠以更進階的方式簡化流量控制和流量精分：
- 面向灰度部署的鍵值儲存 —— 當您執行 A/B 測試或藍綠部署時，您可能希望按特定的增量（例如0%、5%、10%、25%、 50% 和 100% 將流量過渡到新版本。 大多數工具都需要很多人工操作，因為您必須為每個增量編輯百分比並重新載入配置檔。 面對不小的工作量，您可能會冒險直接從 5% 過渡到 100%。 然而，藉助基於 NGINX Plus 的 NGINX Ingress Controller，您可以利用鍵值存儲更改百分比，且無需重載配置檔。
- 通過 NGINX Ingress Controller 斷路 —— 先進的斷路器能夠更快速地檢測故障和故障轉移，甚至針對不健康的上游服務啟動定製的格式化錯誤頁面，從而説明您節省時間和提高彈性。 舉例來說，搜索服務的斷路器可能會返回一組格式正確但內容為空的搜尋結果。 為了達到這種效果，基於 NGINX Plus 的 NGINX Ingress Controller 採用了主動健康檢查，主動監控 TCP 和 UDP 上游伺服器的健康情況。 由於監控是即時的，您的用戶端遭遇應用錯誤的概率將大大降低。
- 通過 NGINX Service Mesh 斷路 —— NGINX Service Mesh 斷路器規範具有三個自定義字段：
errors—— 斷路器觸發前的錯誤數
timeoutSeconds—— 斷路器觸發前發生錯誤的視窗，以及斷路器關閉前的等待時間
fallback—— o斷路器觸發后，流量被重新路由到的 Kubernetes 服務的名稱和埠
errors 和 timeoutSeconds 是標準的斷路器功能，而 fallback 支援您定義備份伺服器，進一步提高了彈性。 如果您的備份伺服器回應是獨一無二的，它們可以作為集群故障的早期指示器，讓您第一時間開啟故障排除。
借助儀錶盤解讀流量精分結果
現在，您已實現了流量精分…… 接下來該做什麼呢？ 接下來我們應該分析流量精分結果。 這可能是最難的一個環節，因為許多企業都缺乏對 Kubernetes 流量和應用運行情況的關鍵洞察。 NGINX 可通過 NGINX Plus 儀錶盤和預構建的 Grafana 儀錶盤，以圖示的形式展示 Prometheus Exporter 暴露的指標， 從而説明您更輕鬆地獲取洞察資訊。 如欲詳細瞭解如何提高可視性、獲取洞察，請閱讀我們的博文 《如何提高 Kubernetes 環境的可視性》。
NGINX 助您輕鬆掌控微服務
基於 NGINX Plus 的 NGINX Ingress Controller 提供 30 天免費試用版，其中包括可以保護容器化應用的NGINX App Protect。
如欲試用 NGINX 開源版 NGINX Ingress Controller，您可以獲取發佈原始程式碼，或者從 DockerHub 下載預建立的容器。
您可前往 f5.com 下載始終免費的 NGINX Service Mesh。