在剛剛過去的“雙十一”購物狂歡季，阿里云經歷了一次大規(guī)模故障，導致阿里系產品集體中斷服務。11 月12 日，淘寶、釘釘、閑魚、阿里云盤等阿里系產品出現(xiàn)無法使用的問題， “阿里全系產品崩了” 的話題迅速引發(fā)眾多關注。此次故障不僅阿里自家的產品受到影響，據天眼查數(shù)據，阿里云的企業(yè)用戶超過 300 萬家，這些客戶由于云服務不可用，業(yè)務運營受到嚴重影響。

故障的地域范圍廣泛，覆蓋了包括華北、華東、華南、中國中國香港以及國際地區(qū)在內的多個地區(qū)。根據阿里云官網的官方通告，故障于 11 月 12 日 17:44 開始被阿里云監(jiān)控系統(tǒng)檢測到，直到 21:11，所有受影響的云產品最終恢復正常，整個事故過程持續(xù)了超過 3 個小時。

故障原因猜測

什么樣的故障能致使阿里云全線服務不可用，且故障范圍覆蓋全球各個區(qū)域，故障恢復長達 3 個小時?

由于故障涉及到多個機房和區(qū)域，不太可能是存儲或網絡等基礎設施的問題，因為這些通常采用多可用區(qū)部署。

現(xiàn)象主要表現(xiàn)為：被管控的資源，如云服務器 ECS 和云數(shù)據庫 RDS，仍然可以繼續(xù)運行，但用戶無法通過控制臺或API 進行管理操作。因此極有可能是 Auth 這樣的一種全球性的基礎服務。

雖然以上分析僅為推測，并不代表確切的故障原因，但不少業(yè)內專業(yè)也給出了類似的推測：

圖片來源：DevOpSec

什么是認證服務?

認證服務(Auth 服務)是一種用于身份認證和授權的基礎服務。它在許多系統(tǒng)和應用程序中起著關鍵作用，確保只有經過授權的用戶可以訪問受保護的資源和功能。大家常用的以下功能，都屬于認證服務的范疇：身份驗證、訪問控制、用戶管理、單點登錄(SSO)、安全審計。作為系統(tǒng)的基礎安全服務，它是建立安全、可信賴的系統(tǒng)和保護敏感資源的關鍵組成部分。

如何保證 Auth 服務的 SLA ?

對于如此重要的基礎安全服務，其企業(yè)相關負責人如何提高企業(yè)認證服務的 SLA，避免"全球性故障"?其使用者應該如何評估及挑選優(yōu)質的認證服務廠商?圍繞 "高 SLA (Service Level Agreement)的認證服務"，其核心指導思想為：防治結合。

防：在故障真的發(fā)生的時候，能及時收到故障通知，采用對應的降級策略，防止由于認證服務不可用造成全線服務不可用的大故障

治：在基礎設施層面，保持云中立、保證異地多活、提升系統(tǒng)可觀測性，擁抱容器化技術及微服務治理，從而全面提升整個系統(tǒng)的 SLA，避免出現(xiàn)“短板效應”

下面將以 Authing (Authing 就是身份云) 為例，為大家具體講解“防治結合”的實施落地方案。

防：事件通知驅動 + SDK 快速集成 + 啟動降級措施

為幫助認證服務使用方實現(xiàn) “在故障發(fā)生時，能及時收到相關事件，采用降級策略” 這一防御目標，其解題思路為：通過 SDK 方式快速接入認證服務，減少研發(fā)成本的同時，通過讓 SDK 訂閱 Authing 服務端的相關故障事件，及時采取降級措施。

多語言 SDK / API / 認證組件

通過豐富且兼容多種開發(fā)語言、多種開發(fā)框架的 SDK / API / 認證組件，可讓用戶 5 行代碼快速接入認證服務，讓其應用服務具備賬號密碼認證、短信驗證碼認證、社交賬號登錄、企業(yè)賬號登錄、單點登錄 SSO、多因素認證 MFA 等安全能力。

事件驅動的云原生身份平臺

事件表明狀態(tài)發(fā)生變化，即：某事已經發(fā)生。事件用于向相關方發(fā)出狀態(tài)發(fā)生變化的信號。在本案例中，事件即為“故障事件”;

Authing 3.0 是以事件驅動(EDA)架構重塑的云原生身份平臺，通過事件驅動架構大幅提升了平臺的響應速度、可擴展性和開發(fā)者體驗，并能夠實現(xiàn)更加及時的安全事件響應和更加卓越的客戶體驗。

使用 Authing 的事件相關 SDK，開發(fā)者可以訂閱 Authing 平臺產生的事件，當事件發(fā)生時，Authing 服務會實時把事件的類型及當前事件關聯(lián)的數(shù)據以 WebSocket 方式以 JSON 的數(shù)據格式主動推送給開發(fā)者。也可以在 Authing 控制臺添加自定義事件，然后使用事件 SDK 向 Authing 服務推送自定義事件，用來觸發(fā)特定的工作流程。式將事件內容以 JSON 格式進行推送。

借助事件驅動變化的理念，用戶可以訂閱“認證服務故障事件”，Authing SDK 在收到該事件后可根據用戶的配置和期望方式，實施降級措施，避免全服不可用的故障。

降級措施

降級措施是指在某種情況下，為了保證系統(tǒng)的可用性或確保某項功能的正常運行，采取的臨時替代方案或備用方案。當系統(tǒng)或功能遇到問題或無法以預期的方式運行時，降級措施可以幫助系統(tǒng)繼續(xù)正常運行，但會以降低的性能、功能或安全性為代價。

在本案例中，為了能讓系統(tǒng)正常運行，將會犧牲較小部分的安全性。其中一種實現(xiàn)方式為：在接收到“故障”事件后，通過忽略本地緩存的認證 Token 的過期時間，持續(xù)提供認證能力;待收到“故障恢復”的事件后，再恢復到常規(guī)的更安全的認證方式上，即重新申請 Token 并驗證 Token 的過期時間。

在主流的認證方式及協(xié)議，如 OAuth 2.0、OpenID Connect、單點登錄等，都會使用 JWT(JSON Web Token)用于在不同實體之間安全地傳輸信息。客戶端，例如瀏覽器等，會將 JWT 進行緩存，以便在后續(xù)的請求中使用。JWT 會有過期時間，用于指定 JWT 的有效期。在驗證 JWT 時，依賴方通過不檢查 JWT 的過期時間，持續(xù)使用本地緩存的 JWT 來提供認證服務，從而達到降級的目的。

治：云中立 + 異地多活 + 可觀測性 + 微服務治理

盡管“防”的手段，可以通過犧牲部分安全性或功能來換取系統(tǒng)可用性，但其治本之道還是需要從基礎建設、服務治理、可觀測性的角度提升整體認證服務和系統(tǒng)的可用性，從而提升整體的 SLA。

云中立

系統(tǒng)做到云中立，才能保證不被某一朵云廠商綁定，擁有了選擇權，促進數(shù)據流動和互操作性。一旦出現(xiàn)某一朵云服務故障的時候，可以迅速將流量切到其他云上提供服務，縮短不可用時間。

為了讓系統(tǒng)做到云中立，應該盡可能使用各個云的通用服務，減少對某一朵云的服務依賴;在設計服務架構時，最大程度去兼容用戶私有云、各類公有云的云環(huán)境。通過成熟 Kubernetes 容器化技術，使整套服務體系同時支持公共云、混合云和私有云部署，并且達到分鐘級別彈性擴容，最大可支持億級別用戶認證訪問場景。

Authing 使用 Kubernetes 作為容器編排和管理平臺，用于在跨多個主機和集群中自動化部署、運行、編排和管理容器化應用程序。同時在數(shù)據存儲層面，選擇通用標準的數(shù)據庫、緩存、KMS、消息隊列、日志等云服務，并在架構設計時，對各個云服務進行適配，從而達到靈活配置兼容各種云服務、多云部署、故障時能及時切換、系統(tǒng)云中立等目標。其架構如下圖所示：

異地多活

異地多活、多數(shù)據中心、兩地三中心等，每當提到這些主流措施，其本質在于：增加冗余副本服務，用于在故障發(fā)生時，迅速使用副本服務提供系統(tǒng)可用性。地理位置、網絡連接、副本個數(shù)和復雜性、數(shù)據同步復制、數(shù)據安全和合規(guī)性、SLA 等級、成本等是在設計異地災備時，要重點考慮和平衡的。

Authing 通過多云部署 + 多 AZ (Available Zone) + 智能 DNS 的方式，實現(xiàn)異地多活、國內外多 Region 部署、故障時自動切流的方式，提升系統(tǒng)整體的可用性和對客戶的 SLA。

可觀測性

可觀測性(Observability)是指在復雜系統(tǒng)中全面了解、理解和監(jiān)測系統(tǒng)的運行狀態(tài)、行為和性能的能力。它是一種系統(tǒng)設計和運維的理念，旨在提供對系統(tǒng)內部和外部的可見性，以便快速識別和解決問題，優(yōu)化性能，并提供對系統(tǒng)行為的深入洞察。

在本案例中上述的“事件通知驅動”從而實施降級措施的基礎建設重要部分，即是系統(tǒng)的可觀測性。要做的系統(tǒng)的可觀測性，需要注重考慮：

1.監(jiān)測：通過收集、記錄和分析系統(tǒng)的指標、日志和事件，實時監(jiān)測系統(tǒng)的運行狀態(tài)和行為。

2.日志管理：管理和分析系統(tǒng)的日志數(shù)據，以了解系統(tǒng)的運行過程、事件和錯誤。

3.追蹤和分布式跟蹤：通過跟蹤請求在系統(tǒng)中的流經路徑，了解分布式系統(tǒng)中不同組件之間的相互作用和性能延遲。

4.事件管理：捕獲和處理系統(tǒng)中的事件，如警報、通知和異常情況。

5.可視化：通過儀表板、圖表和可視化工具，將系統(tǒng)和應用程序的指標、日志和事件以可視化的方式展示出來。

Authing 基于對上述理念的理解，在公用云部署架構、私有化部署架構中都進行了考慮和設計，通過 Tracing、Metrics、Logging 的采集，進行事件管控，并及時將變更推送到客戶端、服務端，從而啟動相關策略的變化。此外，可視化報表大屏可幫助客戶持續(xù)、及時地了解到一線的系統(tǒng)可用性指標情況、認證鏈路追蹤、系統(tǒng)性能指標變化等，從而做到“心知肚明”，“及時響應”。

微服務治理

微服務治理(Microservices Governance)是指在微服務架構中對微服務進行管理和控制的一系列實踐和策略。由于微服務架構的復雜性和分布式特性，需要一種有效的方式來確保微服務系統(tǒng)的可靠性、可擴展性和一致性。重要要考慮以下方面：

1.服務發(fā)現(xiàn)和注冊：可以幫助服務在集群中自動注冊和發(fā)現(xiàn)其他服務，并提供負載均衡和故障轉移的能力。

2.服務通信和協(xié)議：需要定義和管理服務之間的通信協(xié)議、消息格式和接口規(guī)范，以確保服務之間的互操作性和一致性。

3.服務網關：服務網關是微服務架構中的入口點，可以提供統(tǒng)一的訪問接口和安全性保護，并隔離客戶端與后端微服務之間的直接通信。

4.服務監(jiān)控和可觀測性：通過監(jiān)控指標、日志和分布式追蹤等工具，可以實現(xiàn)對微服務的實時監(jiān)控和故障排查。

5.服務安全和訪問控制：包括身份驗證、授權、數(shù)據加密和審計等安全措施，以保護服務免受惡意訪問和攻擊。

6.服務版本控制和演化：需要管理服務的版本控制、發(fā)布策略和回退計劃，以確保服務的無縫演化和兼容性。

7.服務質量和 SLA 管理：包括定義和監(jiān)測服務的性能、可用性和可靠性等指標，并確保滿足業(yè)務需求和用戶期望。

微服務治理是一個主流且較為成熟服務治理領域，Authing 也是按照上述的核心點進行具體的服務治理落地;但由于各個業(yè)務系統(tǒng)對微服務治理的需求和期望各有不同，這里不再具體闡述。

阿里云全球故障事件帶來的巨大影響，又一次給行業(yè)的從業(yè)者、系統(tǒng)設計人員、企業(yè)服務采購者敲了警鐘。雖然官方并未公布其故障背后的原因，但認證服務，作為最基礎的門戶安全服務，其 SLA 的高保證能最大程度避免這樣的“全線”、“全球性”故障。本文通過“防治結合”的理念詳細闡述了如何在認證服務領域，通過事件驅動設計理念、云中立理念、異地多活的措施、可觀測性的提升、微服務治理的策略等具體方式提高系統(tǒng)的可用性、為用戶承諾最高水平的 SLA。其設計理念也可以應用到其他服務領域。在具體落地時，還需要考慮具體 SLA 需求和成本的平衡，最終實現(xiàn)業(yè)務場景驅動技術迭代，技術迭代促進和保障業(yè)務場景。

作者：

潘娟，Apache Member & Incubator Mentor，Apache ShardingSphere PMC，AWS Data Hero，中國木蘭開源社區(qū)導師，騰訊云 TVP。曾負責京東數(shù)科數(shù)據庫智能平臺的設計與研發(fā)，現(xiàn)專注于分布式數(shù)據庫 & 中間件生態(tài)及開源領域。被評為《2020 中國開源先鋒人物》，2021 OSCAR 尖峰開源人物。CSDN 2021 年度 IT 領軍人物，2022 年在 ICDE 發(fā)表論文 “Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding”。

（免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）