銷售: 1-800-867-1380

Failsafe:具有恢復功能的雲端架構指引

更新日期: 2014年6月

作者:Marc Mercuri、Ulrich Homann、Mark Simms、Jason Wescott 和 Andrew Townhill

審稿者:Michael Thomassy、Curt Peterson、Stuart Ozer、Fran Dougherty、Tim O’Brien、Hatay Tuna、Patrick Butler Monterde、Mark Kottke、Lewis Curtis、William Bellamy

發行日期:2014 年 6 月

保全 (名詞)。設計成自動運作或生效的特定方式,以防止機制、系統或類似的架構發生故障。

個人無論是就員工、居民或消費者而言,都需要立即存取應用程式、運算和資料服務。連接的人數以及人們用來連接到這些服務的裝置數目正持續增長。在此始終保持服務運作的環境中,支援這類服務的系統務必設計成兼具可用性與恢復功能。

這些服務將會以預先定義的組態,部署在已填入各項商品的雲端環境中。在過去,您可能會購買更高階的硬體來向上延展;然而在雲端環境中,您必須做的是向外延展。您利用商用硬體來降低這些雲端環境的成本。但商用硬體總會有故障的時候,因此雲端環境對於架構的要求是不怕故障。您以往可能將焦點放在預防故障以及讓「故障發生平均間隔時間」盡量拉長。但在這個新環境中,焦點則轉到「影響最小之還原的平均時間」。

您所開發出來的服務很有可能會是複合型態。這些型態將由一或多個第一方或第三方平台和第三方提供者服務所組成。這些服務建置所在的雲端基礎結構終究會有故障的時候。因此,此架構還必須假設這些型態所用的服務也會有失敗的時候。和基礎結構的架構一樣,應用程式的架構設計也必須不怕故障。

Microsoft 內部的保全倡議計劃旨在提供建置具恢復功能雲端架構的一般指引、採用 Microsoft 技術實作這些架構的指引,以及針對特定案例實作這些架構的訣竅。本文件的作者是 Microsoft 的 Cloud + Enterprise 部門、高可信度電腦運算和 Microsoft 諮詢服務的成員。

本文件著重於設計可擴充且具恢復功能之系統在架構方面的各項考量。

本文內容歸納為以下幾個章節:

  • 依工作負載拆解應用程式:定義以工作負載為中心的方法如何能提供更妥善的成本控制、更靈活選擇最適合工作負載的技術,並對可用性和恢復功能賦予更精確的微調方法。

  • 建立生命週期模型:建立應用程式生命週期模型有助於定義應用程式在生產環境中的預期行為,並能深入洞察整體架構本身及其各階段的需求。

  • 建立可用性模型和計畫:可用性模型會識別您的工作負載所預期的可用性層級。此模型將供您在建立服務時據以做出諸多決策,因而至關重要。

  • 識別失敗點、失敗模式和失敗效應:若要建立具恢復功能的架構,就務必了解並能識別失敗點和失敗模式。您尤應主動了解可能導致服務中斷的原因並詳載備查,以確立可於進行分析及規劃時使用的綱要。

  • 恢復模式和考量:此為本文件中佔最大篇幅的一節,包含了遍及運算、儲存體和平台服務三方面的重要考量。這些考量著重於經實證可提供健全應用程式的作法,探討遍及運算、儲存體和平台服務三方面的重要考量。

  • 為作業人員進行設計:在服務預料將「始終保持運作」的環境中,服務的設計務必以營運為訴求。本節探討經實證可在整個生命週期持續營運的設計作法,包括建立健全狀況模型到實作遙測,乃至為營運人員和開發人員將遙測資訊視覺化。

應用程式通常是由多項工作負載所組成。

不同的工作負載可能 (且通常) 會有不同的需求、不同的商業關鍵性層級和不同程度的財務考量與其相關聯。若將應用程式拆解成工作負載,組織本身便能獲致價值不斐的彈性。以工作負載為中心的方法可提供更妥善的成本控制、更靈活選擇最適合工作負載的技術、將工作負載具體方法運用於可用性和安全性、彈性又靈活地加入和部署新功能等,不勝枚舉。

在考量恢復功能時,若有案例可循也許會對您有所幫助。以下是一些典型的案例:

  • 球賽資料服務

    客戶提供資料服務公佈球賽資訊。此服務有兩項主要工作負載:其一提供球員和球隊的統計資料,其二提供目前進行中賽事的兩隊得分和實況報導。

  • 電子商務網站

    線上零售店依循堅實建立的模型透過網站銷售貨物。此應用程式有多項工作負載,其中以「搜尋和瀏覽」及「結帳」最為常用。

  • 社交

    備受矚目的社交網站可讓社群成員參與論壇、使用者產生的內容和一時興起的休閒遊戲,彼此分享經驗。此應用程式有多項工作負載,包括註冊、搜尋和瀏覽、社交互動、休閒遊戲、電子郵件等。

  • Web

    組織想要透過其網站為客戶提供特定體驗。應用程式提供的體驗必須擴及一般電腦的瀏覽器與常用的行動裝置類型 (手機、平板電腦)。此應用程式有多項工作負載,包括註冊、搜尋和瀏覽、內容發行、社交評論、規範節制、遊戲等。

以下將仔細審視上述其中一個案例,並將之拆解成子項工作負載。電子商務網站可能有多項工作負載,包括:瀏覽和搜尋、結帳和管理、使用者註冊、使用者產生的內容 (評論和評比)、個人化等。

舉例而言,此案例的兩大核心工作負載其定義如下:

  • 「瀏覽和搜尋」可讓客戶巡覽產品目錄、搜尋特定物品,甚至是管理購物籃或願望清單。此工作負載可能具有各種屬性,如匿名使用者存取、幾近瞬間的回應時間和快取。若使用者負載超乎預期或應用程式容許中斷以重新整理產品存貨,便有可能隨著回應時間的增加而發生效能降低。在這類情況下,應用程式可選擇繼續提供來自快取的資訊。

  • 「結帳和管理」可協助客戶下訂單、追蹤訂單和取消訂單、選取交貨方式和付款選項,以及管理個人概況資料。此工作負載可能具有各種屬性,如安全存取、佇列式處理、存取協力廠商付款閘道,以及與後端內部部署系統的連接。儘管應用程式或可容許回應時間增加,卻不能容許訂單流失。因此,無論應用程式能否處理付款或安排交貨,設計上都要保證「一律」接受並且擷取客戶訂單。

應用程式生命週期模型定義了應用程式處於營運狀態下的預期行為。在不同的階段和時間,應用程式會對系統加諸各式各樣功能等級或延展等級的需求。生命週期模型將反映此現象。

工作負載應該在適當的資料粒度層級為所有相關和適用的案例定義生命週期模型。服務可能會有每小時、每日、每週或季節性的週期差異,這些差異經過模型化將能識別特定容量、可用性、效能和延展性需求隨著時間推移的趨勢。

Failsafe_03

圖 1. 不同產業和案例的生命週期範例

通常會有一些期間有自己的唯一生命週期,例如:

  • 假日期間尖峰需求的相關高峰。

  • 報稅截止日的前一天申報人數突增。

  • 上下班時段湧入通勤者。

  • 年底的員工績效考核建檔。

許多組織都了解這些案例類型和相關的案例特有生命週期。

拆解可讓您在工作負載層級有不同的內部服務等級協定 (SLA)。其中一個範例就是目標 SLA 為 99.99% 的球賽資料 API 範例。不過,您可以將該 API 拆解成兩項工作負載:“Live Scores + Commentary” 和 “Team, Player, and League Statistics”

對於 “Live Scores + Commentary” 工作負載,生命週期有 “off and on” 模式。不過,“Team, Player, and League Statistics” 的可用性則會保持不變。依工作負載拆解可讓您修改 SLA,以符合複合服務之彙總工作負載的可用性需求。

Failsafe_12

圖 2

識別生命週期模型之後,下一步就是建立可用性模型和計畫。適用於您的應用程式的可用性模型會識別您的工作負載所預期的可用性層級。此模型將供您在建立服務時據以做出諸多決策,因而至關重要。

您需要考量一些事情,也可以採取一些可能的動作。

在開發您的可用性計畫時,請務必了解您的應用程式所需的可用性、該應用程式內的工作負載以及在傳遞這些工作負載時所利用的服務。

了解工作負載的生命週期將有助於選擇您想要提供的 SLA。系統可能不會公開為您的服務提供特定 SLA。不過,您的架構應以您渴望達成的可用性基準做為目標。

視您建置的解決方案類型而定,提供更高可用性時會有一些考量和選項。商業服務提供者不會提供 100% SLA,因為要提供這樣一個層級的 SLA,其複雜度和成本不是窒礙難行,就是無利可圖。將應用程式拆解至工作負載層級,可讓您做出決定並實作各種可用性方法。對整個應用程式提供 99.99% 的執行時間或許困難至極,但是對應用程式中的某個工作負載這麼做則有可能。

即使在工作負載層級,您不一定要選擇實作每個選項。您選擇要實作或不實作哪些選項是由您的需求決定。不論您選擇哪些選項,您都應該做出有意識且明智的選擇,並考量所有的選項。

自主性是關於獨立以及減少服務整體組成組件之間的相依性。在設計服務時,必須透過將相關功能建立成服務內的自主單位的觀點,檢查與元件、資料和外部實體之間的相依性。這樣做會提供更新相異自主單位版本的靈活性、能夠以更細微的方式微調控制這些自主單位的調整等等。

工作負載架構通常是由不依賴手動介入的自主元件所組成,而且當這些架構所依賴的實體無法使用時,也不會失敗。應用程式是由自主元件所組成:

  • 可用而且可操作

  • 具有恢復功能而且能夠輕鬆地從失敗復原

  • 狀況不良之失敗狀態的風險較低

  • 容易透過複寫調整

  • 需要手動介入的可能性較低

這些自主單位通常會充分利用非同步通訊、提取方式的資料處理及確保持續服務的自動化作業。

市場在未來將會進化到某個程度,也就是垂直和水平案例的某些功能類型會有標準化介面。當實現這個未來願景時,服務提供者將能夠與不同的提供者合作,而且也可使用不同的實作方式來解決自主單位的指派工作。如果是持續性服務,這項作業將會以自主方式執行,而且會根據原則。

雖然期望能夠盡量提高自主性,但是大多數服務將會與協力廠商服務相依 (如果只限託管的話)。請務必了解這些相依服務的 SLA,並將其併入到可用性計畫中。

此章節會識別可以與服務產生關聯的不同 SLA 類型。每一種服務類型都有重要的考量和方法以及應該詢問的問題。

公用雲端平台服務

商業雲端運算平台所提供的服務 (例如運算或儲存) 擁有專門設計來容納大規模之大量客戶的服務等級合約。因此,這些服務的 SLA 是無法協議的。提供者可能會提供包含不同 SLA 的服務分層,但是這些層將無法協議。服務提供者使用每一層有不同 SLA 的服務層級來提供可預測的服務品質。

這類型的服務所要考量的問題:

  • 這個服務是否只允許此服務 API 的特定呼叫次數?

  • 這個服務是否會限制此服務 API 的呼叫頻率?

  • 此服務是否會限制可以呼叫此服務 API 的伺服器數目?

  • 此服務如何傳遞其可用性承諾的公開可用資訊為何?

  • 這個服務如何傳達其健全狀態?

  • 何謂有狀態的服務等級合約 (SLA)?

  • 其他協力廠商提供的同等平台服務為何?

協力廠商「免費」服務

許多協力廠商都有提供「免費」的服務給社群使用。如果是私營部門組織,執行這項作業主要是為了協助在其核心產品或服務周圍產生應用程式的生態系統。如果是公共部門,執行這項處理是為了提供資料給公民和企業,這些公民和企業表面上已經透過稅賦提供經費給政府來支付資料的收集。

大部分的服務不會隨附服務等級合約,所以無法保證可用性。當提供 SLA 時,它們通常著重在對於消費性應用程式所設的限制以及用來強制這些限制的機制。限制的範例包括在超過特定數目的服務呼叫、超過給定期間的特定呼叫數目 (每分鐘 x 個),或超過呼叫服務之可允許的伺服器數目時,解決方案的節流或列入黑名單。

這類型的服務所要考量的問題:

  • 這個服務是否只允許此服務 API 的特定呼叫次數?

  • 這個服務是否會限制此服務 API 的呼叫頻率?

  • 此服務是否會限制可以呼叫此服務 API 的伺服器數目?

  • 此服務如何傳遞其可用性承諾的公開可用資訊為何?

  • 這個服務如何傳達其健全狀態?

  • 何謂有狀態的服務等級合約 (SLA)?

  • 這是可從多個服務提供者取得必要功能及/或資料的商品服務嗎?

  • 如果是商品服務,此介面可橫跨其他服務提供者互通嗎 (直接或透過可用抽象層)?

  • 其他協力廠商提供的同等平台服務為何?

協力廠商「商業」服務

協力廠商提供的商業服務擁有專門設計來容納付費客戶需求的服務等級合約。提供者可能會提供包含不同可用性層級的 SLA 分層,但是這些 SLA 將無法協議。

這類型的服務所要考量的問題:

  • 這個服務是否只允許此服務 API 的特定呼叫次數?

  • 這個服務是否會限制此服務 API 的呼叫頻率?

  • 此服務是否會限制可以呼叫此服務 API 的伺服器數目?

  • 此服務如何傳遞其可用性承諾的公開可用資訊為何?

  • 這個服務如何傳達其健全狀態?

  • 何謂有狀態的服務等級合約 (SLA)?

  • 這是可從多個服務提供者取得必要功能及/或資料的商品服務嗎?

  • 如果是商品服務,此介面可橫跨其他服務提供者互通嗎 (直接或透過可用抽象層)?

  • 其他協力廠商提供的同等平台服務為何?

社群雲端服務

類似供應鏈的組織社群可能會提供服務給成員組織。

這類型的服務所要考量的問題:

  • 這個服務是否只允許此服務 API 的特定呼叫次數?

  • 這個服務是否會限制此服務 API 的呼叫頻率?

  • 此服務是否會限制可以呼叫此服務 API 的伺服器數目?

  • 此服務如何傳遞其可用性承諾的公開可用資訊為何?

  • 這個服務如何傳達其健全狀態?

  • 何謂有狀態的服務等級合約 (SLA)?

  • 身為社群的成員,有可能協議不同的 SLA 嗎?

  • 這是可從多個服務提供者取得必要功能及/或資料的商品服務嗎?

  • 如果是商品服務,此介面可橫跨其他服務提供者互通嗎 (直接或透過可用抽象層)?

  • 其他協力廠商提供的同等平台服務為何?

第一方內部企業範圍的雲端服務

企業可能會將核心服務 (例如股價資料或產品中繼資料) 提供給其部門使用。

這類型的服務所要考量的問題:

  • 這個服務是否只允許此服務 API 的特定呼叫次數?

  • 這個服務是否會限制此服務 API 的呼叫頻率?

  • 此服務是否會限制可以呼叫此服務 API 的伺服器數目?

  • 此服務如何傳遞其可用性承諾的公開可用資訊為何?

  • 這個服務如何傳達其健全狀態?

  • 何謂有狀態的服務等級合約 (SLA)?

  • 身為組織的成員,有可能協議不同的 SLA 嗎?

  • 這是可從多個服務提供者取得必要功能及/或資料的商品服務嗎?

  • 如果是商品服務,此介面可橫跨其他服務提供者互通嗎 (直接或透過可用抽象層)?

  • 其他協力廠商提供的同等平台服務為何?

第一方內部部門雲端服務

企業部門可能會將服務提供給其直屬組織的其他成員使用。

這類型的服務所要考量的問題:

  • 這個服務是否只允許此服務 API 的特定呼叫次數?

  • 這個服務是否會限制此服務 API 的呼叫頻率?

  • 此服務是否會限制可以呼叫此服務 API 的伺服器數目?

  • 此服務如何傳遞其可用性承諾的公開可用資訊為何?

  • 這個服務如何傳達其健全狀態?

  • 何謂有狀態的服務等級合約 (SLA)?

  • 身為部門的成員,有可能協議不同的 SLA 嗎?

  • 這是可從多個服務提供者取得必要功能及/或資料的商品服務嗎?

  • 如果是商品服務,此介面可橫跨其他服務提供者互通嗎 (直接或透過可用抽象層)?

  • 其他協力廠商提供的同等平台服務為何?

複合服務可用性的「真實的九」

充分利用現有的服務可能會提供極大的靈活度來傳遞組織或商業銷售用途的解決方案。雖然這樣很吸引人,但是請務必了解這些相依性對於工作負載之整體 SLA 的影響。

可用性通常會以給定年度的執行時間百分比表示。可用性百分比會以所謂的「幾個九」來表示。例如,99.9 表示有「三個九」的服務,99.999 表示有「五個九」的服務。

 

可用性 %

每年停機時間

每月停機時間

每週停機時間

90% (「一個九」)

36.5 天

72 小時

16.8 小時

95%

18.25 天

36 小時

8.4 小時

97%

10.96 天

21.6 小時

5.04 小時

98%

7.30 天

14.4 小時

3.36 小時

99% (「兩個九」)

3.65 天

7.20 小時

1.68 小時

99.5%

1.83 天

3.60 小時

50.4 分鐘

99.8%

17.52 小時

86.23 分鐘

20.16 分鐘

99.9% (「三個九」)

8.76 小時

43.2 分鐘

10.1 分鐘

99.95%

4.38 小時

21.56 分鐘

5.04 分鐘

99.99% (「四個九」)

52.56 分鐘

4.32 分鐘

1.01 分鐘

99.999% (「五個九」)

5.26 分鐘

25.9 秒

6.05 秒

99.9999% (「六個九」)

31.5 秒

2.59 秒

0.605 秒

99.99999% (「七個九」)

3.15 秒

.259 秒

0.0605 秒

一個常見的誤解與複合服務提供的「九」的數目有關。具體而言,通常假設當某個特定服務由 5 個服務組成時,每一個服務都會在其 SLA 中承諾 99.99% 的執行時間,最終的複合服務會有 99.99% 的可用性。但是,情況並非如此。

Failsafe_13

圖 3:與更常見的「九」有關的停機時間

此複合 SLA 實際上是考量每年停機時間的計算結果。如果服務的 SLA 有「四個九」(99.99%),則離線時間可以高達 52.56 分鐘。

將具有 99.99% SLA 的五項服務併入複合服務,會帶來 262.8 分鐘或 4.38 小時的可辨識 SLA 風險。在撰寫單一行程式碼之前,這樣會將可用性降低到 99.95%!

您通常不能變更協力廠商服務的可用性。但是在撰寫程式碼時,您可以使用如本文所述的技巧來提高應用程式的整體可用性。

note附註
有些服務可對不同的價格點或根據商業夥伴關係提供不同的服務層。

請仔細想想我們先前提到的球賽資料 API。使用者只在特定日子的特定幾個小時比賽。在這些期間內,SLA 會是 100%。若未安排任何比賽,此工作負載的 SLA 為 0%。“Team, Player, League Statistics” 工作負載有更為一致的生命週期模式。該工作負載的 SLA 也必須永遠為 99%。

Failsafe_14

圖 4

在利用外部服務時,了解 SLA 的重要性 (其對於複合服務的個別和整體影響力) 再怎麼強調也不為過。

若要建立具有恢復功能的架構,一定要充分了解此架構。具體而言,要主動去了解及記錄可能造成中斷的原因。

了解應用程式與其相關工作負載服務的失敗點和失敗模式可讓您針對恢復功能和可用性的策略做出更明智且更鎖定目標的決策。

失敗點就是失敗可能導致服務中斷的位置。重要焦點在於受限於外部變更的設計元素。

失敗點的範例包括:

  • 資料庫連接

  • 網站連接

  • 組態檔

  • 登錄機碼

常見失敗點的類別包括:

  • ACL

  • 資料庫存取

  • 外部網站/服務存取

  • 交易

  • 設定

  • 容量

  • 網路

失敗點會定義導致中斷的區域,失敗模式則會識別可能造成失敗的特定方式。

失敗模式的範例包括:

  • 遺失組態檔

  • 大量的流量超出資源容量

  • 資料庫到達最大容量

失敗效應就是失敗對於功能的影響。請了解失敗效應以及這些失敗類型的可能發生頻率。如此一來,您即可決定應用程式或服務之失敗點和失敗模式的處理優先順序及方式。

此文件將會探討不同運算、儲存和平台服務的重要考量。在涵蓋這些主題之前,請務必複習通常會造成誤解及/或未實作的幾個基本恢復功能影響主題。

如之前所述,恢復功能架構應該針對自主性最佳化。達成自主性的其中一個方法是讓通訊非同步。恢復功能架構應該預設為非同步互動,而同步互動只會當做例外狀況的結果發生。

無狀態的 Web 層或是具有分散式快取的 Web 層可能會在解決方案的前端提供這項處理方式。佇列可以提供這項功能,以供工作負載服務或工作負載服務內之服務之間的互動通訊使用。

後者允許將訊息放在佇列上,次要服務可以加以擷取。這可以根據邏輯、時間或數量考量邏輯來執行。除了讓此程序非同步以外,也允許以適當的方式從佇列調整「推送」或「提取」層。

發生暫時性失敗的常見區域是當您的架構連接到服務或資源 (如資料庫) 地方。當取用這些服務時,常見的作法是實作引進逾時概念的邏輯。此邏輯會識別預期回應的可接受時間表,而且在超出此時間表時將會產生可識別的錯誤。根據逾時錯誤的外觀,將會根據錯誤發生的所在內容採取適當的步驟。內容可包括這個錯誤發生的次數、無法使用之資源的潛在影響、給定客戶在目前期間的 SLA 保證等等。

在設計將會提供工作負載的服務時,您必須接受並且擁抱將會發生的失敗,並且採取適當的步驟加以解決。

要處理的其中一個常見區域就是暫時性失敗。因為沒有任何服務有 100% 的執行時間,所以預期您可能無法連接到工作負載所相依的服務是很合理的。無法連接或從其中一個服務所看到的失敗可能會一閃而過 (少於一秒) 或是永久性 (提供者關機)。

正常降級

您的工作負載服務應該比較想要以正常方式處理這些暫時性失敗。例如,Netflix 在其雲端提供者中斷期間,當主要資料存放區無法使用時針對客戶使用了舊的視訊佇列。另一個範例是電子商務網站在無法使用付款閘道時持續收集訂單。如此一來,當付款閘道再次可用時或是容錯移轉到次要付款閘道之後,將能夠處理訂單。

正常降級的高層級考量

在思考如何正常降級時,其重要考量如下:

  • 沒有完整要求內容的元件應放任它失敗並傳遞例外狀況訊息。若要解決此問題,請實作斷路器 (本文稍後將會說明) 以便在達到失敗計數臨界值時快速失敗。

  • 有暫時失敗特質的情況很常見。請使用本文稍後描述的「重試」模式來加以處理即可。

  • 呼叫者使用不同參數或不同路徑重試要求,或許能更正一些失敗的要求。

  • 如果要求的成功與否對案例而言並不重要,請以直接省略要求的方式處理失敗。

  • 您可以利用下列方式處理失敗:傳回成功訊息,並將失敗的要求排入佇列以便稍後資源回到正常狀態時進行處理。

  • 您可以傳回先前正確的事物,例如快取的認證、快取中過時的資料等。

  • 提供幾近正確的經驗 (例如:暫時存取、近似值、最佳猜測、noscript 等),可以處理某些失敗。

  • 您可以提供一些替代項目,例如隨機值、匿名權限、預設影像等,而不是擲回錯誤。

暫時性失敗處理考量

實作暫時性失敗處理有幾個重要考量,以下章節會有詳細的描述。

  • 重試邏輯

    暫時性失敗處理的最簡單形式為重試失敗的作業。如果使用商業協力廠商服務,實作「重試邏輯」通常會解決此問題。

    您應該注意,設計通常應該限制邏輯將會重試的次數。此邏輯通常會嘗試將動作執行特定次數、註冊錯誤及/或在失敗繼續時利用服務或工作流程。

  • 指數型撤退

    如果暫時性失敗的結果是因為負載過重的服務進行節流,重複嘗試呼叫此服務將只會擴充節流並影響整體可用性。

    通常需要減少此服務的呼叫次數,以避免或減少節流。這通常是以演算方式執行,例如在第一次失敗之後立刻重試、在第二次失敗之後等候 1 秒鐘、在第三次失敗之後等候 5 秒鐘等等,直到最後成功或是到達應用程式定義的失敗臨界值為止。

    這個方法稱為「指數型撤退」。

  • 等冪

    連接服務的核心假設如下:這些服務將不會 100% 可用,而且具有重試邏輯的暫時性失敗處理為核心實作方法。如果是實作重試邏輯的情況,相同訊息可能會傳送一次以上、有可能從序列送出訊息等等。

    作業應該設計為等冪,以確保傳送相同的訊息多次不會導致非預期或污染的資料存放區。

    例如,從所有要求插入資料時,如果呼叫服務作業多次,可能會導致多筆記錄被新增。一種替代方法是將程式碼實作為智慧型「更新插入」(upsert)。可以使用時間戳記或全域識別碼來辨識新的訊息與之前處理的訊息、只將較新的訊息插入資料庫,並在該訊息比過去收到的訊息較新時更新現有的記錄。

  • 補償行為

    除了等冪以外,要考量的另一個地方為補償行為的概念。在每一組連接系統都不斷成長而且複合服務不斷出現的現實世界中,了解如何處理補償行為是非常重要的。

    對於企業營運系統應用程式的許多開發人員而言,交易的概念並不是新的,但是參照系統通常會連結到本機資料技術和相關程式庫所公開的交易功能。根據雲端來檢視此概念時,必須將分散式服務的協調流程相關事項列入新的考量。

    服務協調流程可跨越多個分散式系統,並且在長時間執行且具有狀態。協調流程本身很少同步、可跨越多個系統,而且可以根據商務案例從秒擴充到年。

    例如,在相同工作負載活動中可將 25 個組織繫結在一起的供應鏈案例中,可能有一組 25 個或更多的系統在一個或多個服務協調流程中互相連接。

    如果成功的話,這 25 個系統必須察覺此活動已成功。對於活動中的每一個連接點而言,參與者系統可以針對它從其他系統收到的訊息提供相互關聯識別碼。根據活動類型而定,收到該相互關聯識別碼可能會讓該系統因為交易在名義上已經完成而感到滿意。在其他情況下,當所有 25 方的互動完成後,確認訊息可能會傳送給所有方 (直接從單一服務或是透過每個系統的特定協調流程互動點)。

    為了處理複合和/或分散式活動中的失敗,每一個服務都會公開服務介面和作業來接收要求,以便透過唯一識別碼取消給定的交易。在服務門面背後,將會設置工作流程來補償這項活動的取消。在理想情況下,這些會是自動化程序,但是可能會像是路由傳送給組織內的人員進行手動修復一樣簡單。

斷路器是一種交換器,當電流超出預設限制時會自動中斷電流的流動。斷路器最常當做安全措施使用,通過斷路的電流過量時可能非常危險。斷路器可以重設和重複使用,不同於保險絲。

相同模式適用於軟體設計,特別可提供給可用性和恢復功能為重要考量的服務使用。

在資源無法使用的情況下,實作軟體斷路器可以適當的動作當做回應,並且適當地回應。

斷路器的狀態有三種:已關閉、已開啟、半開啟。

[已關閉] 狀態是應用程式或服務的正常狀態。處於 [已關閉] 狀態時,要求會透過標準路徑傳送。計數器會追蹤失敗率並根據臨界值加以評估。如果失敗率超過臨界值,斷路器會變成 [已開啟] 狀態。如果資料庫資源的呼叫在 100 次連續嘗試連接之後失敗,繼續呼叫資料庫的價值可能很低。斷路器可能會在臨界值觸發,並且可採取適當的動作。

處於 [已開啟] 狀態時,斷路器會將要求傳送至安全防護路徑。這可能是快速失敗或其他形式的正常降級。切換為 [已開啟] 狀態時,斷路器也會起始計時器。計時器會在到期時切換為 [半開啟] 狀態。

[半開啟] 狀態將會開始透過正常路徑來傳送有限數量的要求。如果成功,斷路器便會切換為 [已關閉] 狀態。如果此有限數量的要求失敗,斷路器就會回到 [已開啟] 狀態。

在架構中納入斷路器模式時,請考量下列事項:

  • 在處於 [已開啟] 狀態時,斷路器可根據作業所擲回的例外狀況類型,叫用不同的安全防護或不同時間。

  • 斷路器應記錄所有的轉換狀態。這可讓操作人員監控轉換行為並微調計時器,以避免 [已開啟] 狀態時間過長或經常在 [已開啟] 與 [半開啟] 狀態來回切換。

  • 斷路器可以定期測試標準路徑以判斷其是否已恢復正常,而非使用計時器從 [已開啟] 狀態轉換至 [半開啟] 狀態。

  • 在處理會造成多個分區的作業時,請小心使用斷路器。這裡主要是考量到健全狀況可能屬於分區層級並可能導致以下兩種令人困擾的狀況:

    • 在只有一個分區失敗時切換至 [已開啟] 狀態。

    • 在一或多個分區處於正常狀態時意外切換至 [已關閉] 狀態。

這個模式的常見實作方式與存取資料庫或資料服務相關。活動的建立類型和層級失敗之後,斷路器就會回應。在資料中,這通常是由無法連接資料庫或是該資料庫前方的資料服務所導致。

如果資料庫資源的呼叫在 100 次連續嘗試連接之後失敗,繼續呼叫資料庫的價值可能很低。斷路器可能會在臨界值觸發,並且可採取適當的動作。

在某些情況下,尤其是連接到資料服務時,這可能是根據在給定期間超出允許之呼叫數目的用戶端來進行節流的結果。斷路器可能會在兩個呼叫之間插入延遲,直到已成功建立連接而且符合容錯層級為止。

在某些情況下,資料存放區可能無法使用。如果可使用重複的資料複本,系統可能會容錯移轉至該複本。如果真的複本無法使用,或是某個提供者內所有資料中心的整體資料庫服務當機,可能要採取次要方法。這可能包括透過替代資料服務提供者從要求的資料版本取得資料。這個替代來源可能來自快取、目前雲端提供者的替代持續性資料存放區類型、個別雲端提供者或是內部部署資料中心。如果無法使用這類替代來源,此服務也可能會傳回可辨識的錯誤,用戶端可以適當的方式處理該錯誤。

斷路器範例:Netflix

Netflix 是一家媒體串流服務公司,這家公司通常被視為恢復功能架構的一個絕佳典範。當討論 Netflix 的斷路器模式時,該團隊在其 Netflix 技術部落格中,描述了包含在其斷路器中的幾個準則。這些包括:

  1. 遠端服務的要求逾時。

  2. 用來與服務相依性互動的執行緒集區和界限工作佇列處於 100% 容量狀態。

  3. 用來與服務相依性互動的用戶端程式庫擲回例外狀況。

所有的這些都會造成整體錯誤率。當該錯誤率超過其定義的臨界值時,斷路器會「跳閘」,而且該服務的電路會立即服務後援,甚至不會嘗試連接遠端服務。

在相同的部落格文章中,Netflix 團隊表示,其每一個服務的斷路器都會使用以下三個方法的其中一個實作後援:

  1. 自訂後援 – 服務用戶端程式庫會提供可叫用的後援方法,否則會使用 API 伺服器上可用的本機資料 (例如 Cookie 或本機快取) 來產生後援回應。

  2. 在無訊息模式中失敗 – 方法會傳回 null 值給要求的用戶端,當要求的資料為選擇性時,這個方法很有效。

  3. 快速失敗 – 當需要資料或者沒有良好的後援可用時,就會將 5xx 回應傳回給用戶端。這個方法將焦點放在維持 API 伺服器的良好狀況,並且在受影響的服務回到線上時快速復原,但是這樣做對於用戶端 UX 可能會有負面影響。

若要強制執行 SLA,組織應該要強調其資料服務處理兩類極端值的方式 - 信任方和不良執行者。

信任方和白名單

信任方是指該組織可能與其之間有特殊安排的其他組織,而且可能會針對這些組織產生標準 SLA 的某些例外狀況。

  • 具有自訂合約的第三方

    服務的一些使用者可能會想要協議特殊定價條件或原則。在某些情況下,資料服務的大量呼叫可能會保證特殊定價。在其他情況下,給定資料服務的需求可能會超出標準使用量層中指定的數量。這類客戶應該定義為信任方,以免不小心被標示為不良執行者。

  • 白名單

    處理信任方的典型方法為建立白名單。當服務在處理客戶使用量時判斷該套用哪些商務規則時,就會使用可識別信任方清單的白名單。白名單的產生通常是由授權 IP 位址範圍或 API 金鑰來完成。

    當建立耗用原則時,組織應該識別是否支援白名單;客戶如何在白名單上套用;如何將客戶加入至白名單;以及在哪些情況下可從白名單移除客戶。

  • 處理不良執行者

    如果信任方位於客戶範圍的一端,另一端的群組則稱為「不良執行者」。不良執行者會對服務產生負擔,通常是因為嘗試「過度耗用」。在某些情況下,不良的行為真的是意外。在其他情況下是故意的,少數情況下則是惡意的。這些執行者標示為「不良」,因為其動作 (不論是否故意) 都能影響一個或多個服務的可用性。

    不良執行者的負擔可能會引進不必要的成本給資料服務提供者,而且會讓忠實地遵循使用條款而且對於服務有合理預期 (如 SLA 中所述) 的消費者存取遭到危害。因此,必須以規定、一致的方式處理不良執行者。對於不良執行者的典型回應為節流和黑名單。

  • 節流

    組織應該定義一個策略來處理資料服務取用者的使用量高峰。來自任何取用者的大規模流量爆發都會讓資料服務產生非預期的負載。當發生這類高峰流量時,組織可能會想要在某段期間針對該取用者的存取進行節流。在此情況下,此服務會在某段期間拒絕此取用者的所有要求,例如一分鐘、五分鐘或十分鐘。在這段期間,來自目標取用者的服務要求會產生錯誤訊息,該訊息會告訴他們因為過度使用而遭到節流。

    提出要求的取用者可以做出適當回應,例如變更其行為。

    組織應該判斷它是否要實作節流及設定相關的商務規則。如果它決定可以針對取用者進行節流,組織也必須決定哪些行為應該觸發節流回應。

  • 黑名單

    雖然節流應該修正不良執行者的行為,它可能不會每次都成功。在無效的情況下,組織可能會想要查禁取用者。與白名單相反的黑名單會識別哪些取用者被禁止存取服務。此服務將會回應,以便適當地存取來自黑名單客戶的要求,而且其回應方式會讓資料服務資源的使用降到最低。

    產生黑名單與白名單一樣,通常是使用 API 金鑰或 IP 位址範圍來完成。

    建立耗用原則時,組織應該指定哪些行為會將取用者置於黑名單、如何上訴黑名單,以及如何從黑名單移除取用者。

人總是會犯錯。不論是開發人員所做的程式碼變更可能有非預期的結果、DBA 意外卸除了資料庫中的資料表,還是作業人員進行變更但是未加以記載,我們經常都會不小心降低了服務的恢復功能。

為了減少人為錯誤,邏輯方法就是在整個過程中減少人力的介入。藉由引進自動化,您就限制了與預期行為之間有誤差的隨選、非故意行為危害您的服務的機會。

DevOps 社群中的模因 (meme) 有一個卡通人物,他經常說「將所有事情自動化」。在雲端中,大部分的服務都會以 API 公開。從開發工具到虛擬化基礎結構到平台服務到傳遞為「軟體即服務」的解決方案,大部分都可以撰寫指令碼。

強烈建議您撰寫指令碼。撰寫指令碼會讓部署和管理作業變得一致而且可預測,而且會讓投資產生極大的利益。

自動化部署

自動化的其中一個重要領域就是建立及部署解決方案。自動化可讓開發團隊輕鬆地測試及部署到多個環境。開發、測試、預備、試用和生產全都可以透過自動化組建輕鬆且一致地部署。跨環境一致部署的能力會確保生產中的內容可代表已經測試的內容。

請將下列各項視為「程式碼」:指令碼、組態檔和與部署有關的中繼資料。程式碼也會將這些成品的管理納入原始檔控制中,以便:

  • 記載變更。

  • 允許設定版本。

  • 提供以角色為基礎的存取控制。

  • 確定已備份內容。

  • 提供單一的真實來源。

建立和自動化測試工具

測試是另一個可以自動化的領域。就像自動化部署一樣,建立自動化測試對於確保您的系統具有恢復功能而且能夠隨著時間維持恢復功能非常寶貴。因為您的服務的程式碼和使用方式會不斷進化,所以維持進行所有適當的測試 (功能和規模上) 非常重要。

自動化資料封存和清除

很少被注意到的一個地方就是資料封存和清除。資料量不斷增加,而且比起過去的任何時間持續以更高數量和更多樣化的方式成長。根據資料庫技術和所需的查詢類型而定,不必要的資料可能會減少系統的回應時間,而且增加不必要的成本。如果是包含資料存放區的一個或多個複本的恢復功能計畫,移除必要資料以外的所有內容可以加速管理活動,例如備份和還原資料。

識別您的解決方案中與以下的資料有關的需求:核心功能所需的資料、規範用途所需但是可以封存的資料,以及不再需要而且可以清除的資料。

利用相關產品和服務所提供的 API,將這些需求的實作自動化。

當建立恢復功能架構時,了解故障網域和升級網域的概念也很重要。

故障網域

故障網域會根據已知的硬體界限以及特定中斷類型將會影響一組機器的可能性來限制服務的位置。故障網域定義為一系列可以同時失敗的機器,而且通常是由實體屬性 (特定機架的機器、共用相同電源的一系列機器等等) 所定義。

升級網域

升級網域類似於故障網域。升級網域會定義一組實體的服務,系統可以同時更新這些服務。雲端提供者的負載平衡器必須察覺升級網域,才能確保當特定網域正在更新時,整體系統會維持平衡而且服務仍然可以使用。

升級的可能發生位置:

  • Hypervisor 層級 (「HostOS 升級」)。

  • 作業系統層級 (「客體 OS 升級」)。

  • 將應用程式或服務升級部署到環境的結果。

根據雲端提供者和所利用的平台服務,故障網域和升級網域可能會自動提供、可能是您的服務可透過 API 選擇加入的項目,或者需要第一方或第三方解決方案。

升級期間容錯網域失敗時的恢復功能

容錯網域和升級網域並不相同,但也會有產生交集的時候。在該情況下,若同時間其他 VM 執行個體上正在進行升級,硬體故障會使虛擬機器離線。若是這樣的情況,兩部 VM 都會離線。如果服務部署僅包含兩部虛擬機器,此服務就會離線。因此在評估要提供想要的 SLA 所需的執行個體數目時,請將這點納入考量。

雲端平台通常能夠識別一組資源的同質層級。我們將這些資源稱為「同質群組」或「同質集合」。這有助於基礎平台將相關資源放在一起,以及將執行個體配置於容錯和升級網域。

內部部署解決方案通常依賴備援性來提供可用性和延展性的相關協助。從可用性的觀點來看,備援資料中心讓您在面對給定資料中心或部分資料中心的基礎結構失敗時,能夠提高業務續航力的可能性。

如果應用程式的取用者分散在不同地理位置,流量管理和備援實作會將使用者路由傳送到本機資源 (通常會減少延遲)。

note附註
資料恢復功能 (包括備援性) 是<建立資料備援性方法>一節中的個別主題。

備援性和雲端

在過去,內部部署備援性已透過硬體、軟體和網路的重複集合來達成。有時候,這會實作在單一位置的叢集中,或是分散在多個資料中心。

當您為雲端制訂策略時,將這三個向量之間的備援性需求合理化很重要。這些向量包含在雲端提供者的環境內部署的程式碼、提供者本身的備援性,以及雲端與內部部署之間的備援性。

部署備援性

當組織已選取雲端提供者時,針對提供者內的部署建立備援性策略非常重要。

如果部署到「平台即服務」(PaaS),這項作業可能大多由基礎平台處理。在「基礎結構即服務」(IaaS) 模型中,這項作業大多不是由基礎平台處理。

  • 在資料中心內部署 n 數目的角色

    最簡單的備援形式就是將您的解決方案部署到單一雲端提供者內的多個執行個體。藉由部署到多個執行個體,解決方案就可以限制只部署單一節點時所發生的停機時間。

    在許多「平台即服務」環境中,裝載程式碼之虛擬機器的狀態會受到監控,而且被偵測為狀況不良的虛擬機器會自動由狀況良好的節點取代。

  • 跨多個資料中心部署

    雖然在單一資料中心內部署多個節點有好處,但是架構必須考量整個資料中心有可能無法使用。當發生類似自然災害、戰爭等非司空見慣的事件時,可能會導致特定地理位置發生服務中斷。

    若要達到您的 SLA,針對選取的雲端提供者將解決方案部署到多個資料中心可能是適當的作法。有幾種方法可達到此目標,如底下所識別。

    1. 多個資料中心的完全重複部署

      第一個選擇是搭配流量管理提供者完成多個資料中心的完全重複解決方案。這個方法的關鍵考量如下:對於這種備援性類型的運算相關成本的影響,部署額外的每個資料中心將會增加 100% 的成本。

    2. 次要資料中心用於容錯移轉的部分部署

      另一種方法是將部分部署部署到縮小的次要資料中心。例如,如果標準組態利用了 12 個運算執行個體,次要資料中心將會包含由 6 個運算執行個體組成的部署。

      搭配流量管理執行的這個方法會在發生的事件僅影響主要中心後,允許透過降級的服務繼續提供業務續航力。

      當資料中心可以完全離線的次數受限時,這對於運算而言通常會視為具成本效益的方法,特別是平台可讓組織更容易在第二個資料中心開始執行新的執行個體。

    3. 在多個資料中心使用備份節點劃分部署

      對於某些工作負載而言,特別是垂直產業的金融服務,有非常大量的資料必須在很短且無法移動的期間內處理。在這些情況下,必須在較短的爆發期間內完成工作,而且會保證備援性的成本,以便在該期間內提供結果。

      在這些情況下,程式碼會部署到多個資料中心。將工作劃分及分散到多個節點,以進行處理。如果資料中心變得無法使用,預計給該節點的工作會傳遞到將完成此任務的備份節點。

    4. 每個資料中心都有適當地理規模調整的多個資料中心部署

      這個方法會利用存在於多個資料中心的重複部署,但是會根據地理位置相關群眾的規模適當地調整。

提供者備援性

雖然以資料中心為中心的備援性很好,但是 SLA 是服務等級和資料中心層級的事情。現今許多商業服務會將新版本部署至「部分」生產環境,以在生產環境中驗證程式碼。不過,提供者提供的服務有可能會在多個或所有資料中心變得無法使用。

根據解決方案的 SLA,可能也必須併入提供者備援性。為了實現這個目標,必須識別將橫跨多個雲端平台工作之可在雲端部署的產品或雲端服務。例如 Microsoft SQL Server 可在基礎結構內的虛擬機器中,針對大部分的廠商部署為服務解決方案。

對於雲端提供的服務而言,這樣會更具有挑戰性,因為並沒有設置標準介面,即使是類似運算、儲存、佇列等核心服務。如果這些服務需要提供者備援性,通常只能透過抽象層達成。抽象層可為解決方案提供足夠的功能,但是無法像基礎服務一樣快速創新,而且可能會讓組織無法方便地採用提供者提供的新功能。

如果保證有重複的提供者服務,則可以在幾個層級的其中一個 -- 整個應用程式、工作負載或某個工作負載層面。在適當的層級評估運算、資料和平台服務的需求,並判斷哪些必須真的有備援性以及哪些可以透過提供正常降級的方法來處理。

內部部署備援性

雖然相依於雲端提供者可能有財政方面的意義,但是可能會有某些業務考量需要內部部署備援性,才能符合規範及/或保有業務續航力。

根據解決方案的 SLA,可能也必須併入內部部署備援性。為了實現這個目標,必須識別將橫跨多個雲端類型工作之可在雲端部署的私人產品或雲端服務。如同提供者備援性的情況一樣,Microsoft SQL Server 是可以在內部部署或在 IaaS 解決方案中部署的一個理想產品範例。

對於雲端提供的服務而言,挑戰性會更高,因為沒有與介面和功能對稱的內部部署同等項目。

如果內部部署需要重複的提供者服務,可以在幾個層級的其中一個 -- 整個應用程式、工作負載或某個工作負載層面。在適當的層級評估運算、資料和平台服務的需求,並判斷哪些必須真的有備援性以及哪些可以透過提供正常降級的方法來處理。

備援性組態方法

當識別您的備援性組態方法時,也會套用前雲端已存在的分類。根據您的解決方案中所使用的服務類型,其中的某部分可能會由基礎平台自動處理。在其他情況下,這項功能會透過類似 Windows Fabric 的技術來處理。

  1. 主動/主動 -- 流量 (供失敗節點使用) 會傳遞給現有的節點,或是在其餘節點之間進行負載平衡。通常只有在節點利用同質軟體組態時,這項處理才會可行。

  2. 主動/被動 -- 提供每個節點的完全重複執行個體,此執行個體只有在其關聯的主要節點失敗時才會在線上工作。這項組態通常需要大部分的額外硬體。

  3. N+1 -- 提供單一額外節點,此節點會在線上工作來接管已經失敗之節點的角色。如果是每個主要節點上的異質軟體組態,額外的節點一般都必須能夠擔當其負責之主要節點的任何角色。這通常是指擁有多個服務同時執行的叢集;在單一服務的情況下,這樣會退化為主動/被動模式。

  4. N+M -- 如果是單一叢集管理多個服務的情況,擁有一個專用的容錯移轉節點可能無法提供足夠的備援性。在這些情況下,將會併入及使用一部以上 (M) 的待命伺服器。待命伺服器數目必須權衡考量成本和可靠性需求。

  5. N 對 1 -- 允許容錯移轉待命節點暫時變成使用中節點,直到原始節點可以還原或在線上工作為止,此時服務或執行個體必須容錯回復為原始節點,才能還原高可用性。

  6. N 對 N -- 主動/主動和 N+M、N 對 N 的組合會將失敗節點的服務、執行個體或連接轉散發到其餘的使用中節點,因此不需要 (如同主動/主動模式一樣)「待命」節點,但是會在所有使用中節點上引進額外容量的需求。

不論流量總是分散在不同地理位置還是會路由傳送到不同的資料中心來符合業務續航力情況,流量管理功能對於確保您的解決方案的要求會路由傳送到適當的執行個體非常重要。

也請務必注意,依賴流量管理服務會引進單一失敗點。請務必調查應用程式的主要流量管理服務的 SLA,並判斷您的要求是否保證替代流量管理功能。

雖然許多高延展性的雲端應用程式在分割其 Web 層方面的工作已經做得不錯,但是在雲端中調整其資料層的工作比較不出色。隨著不斷成長且多樣化的連接裝置出現在市面上,產生及查詢之資料的層級正以前所未有的速度成長。舉例來說,現在每天能夠支援 500,000 個新使用者的需求被視為合理的條件。

讓資料分割策略橫跨多個維度非常重要 (包括儲存、查詢或維護該資料)。

分解和資料分割

因為不同技術各有優點和權衡考量,所以利用最適合特定工作負載的技術是很常見的作法。

如果您的解決方案由工作負載所分解,您將能夠選擇最適合特定工作負載的資料技術。例如,網站可針對個人的內容利用資料表儲存,在使用者層級針對回應體驗利用資料分割。這些資料表資料列可能會定期彙總到關聯式資料庫,以供報告和分析。

資料分割策略可以 (而且通常會) 因選擇的技術而異。

定義策略時,也一定要識別需要修改過的策略或平行策略的極端值。例如,如果您在開發社交網路網站,正常使用者可能會有 500 個連結,而名人可能會有 5,000,000 個連結。

如果此網站預期有 100 萬個使用者,其中名人少於 50,000 個,則核心分割策略會針對一般使用者進行最佳化調整。您會以不同的方式管理名人。雖然您會將大量使用者分組到單一分割區時,但可將一位名人分配到其個人擁有的分割區。

了解 3 個 V

若要適當地設計資料分割策略,組織必須先了解它。

Gartner 所提供的熱門 3 V 會以三個不同資料層面來檢視。了解 3 個 V 如何與您的資料有關將可協助您針對資料分割策略做出明智的決定。

  • 磁碟區

    容量指的是資料的大小。容量對於資料分割策略具有非常實質的影響力。特殊資料技術的容量限制可能會因為大小限制、容量的查詢速度等原因而強制資料分割。

  • 速度

    速度指的是您的資料成長的速率。您可能會想要針對緩慢成長的資料存放區以及每天需要容納 500,000 個新使用者的資料存放區,設計不同的資料分割策略。

  • 多樣化

    多樣化指的是與工作負載相關的不同資料類型。不論是關聯式資料、金鑰-值組、社交媒體基本資料、影像、音訊檔、視訊還是其他類型的資料,了解資料都很重要。這包含了選擇正確的資料技術及針對您的資料分割策略做出明智決定。

水平資料分割

最常用的分割資料方法可能是以水平方式分割。以水平方式分割時,將會根據某個準則做出決定,以便將資料存放區分割成多個分區。每個分區都包含整個結構描述,以及將資料位置推入適當分區的準則。

根據資料類型及資料使用量,這可能會以不同方式執行。例如,組織可選擇根據客戶姓氏分割其資料。在另一種情況下,資料分割可能會以日期為中心,根據相關的行事曆間隔 (小時、天、週或月) 分割。

水平資料分割的圖表

圖 5:依姓氏水平分割的範例

垂直資料分割

另一種方法是垂直資料分割。這種方法會將資料以最佳方式置於不同的存放區,通常與資料的多樣性有關。圖 5 顯示一個範例,其中有關客戶的中繼資料置於一個存放區,而將縮圖和相片置於個別存放區。

垂直資料分割可能會以最佳方式儲存和傳遞資料。例如在圖 5,如果很少為客戶顯示相片,則每筆記錄傳回 3 MB 的資料可能會在隨收隨付模型中增加不必要的成本。

垂直資料分割的圖表

圖 6:垂直資料分割的範例。

混合資料分割

在許多情況下,建立混合資料分割策略是很適當的作法。這種方法在單一解決方案中提供兩種方法的效率。

圖 6 顯示這個方法的範例,現在添加了稍早所見的垂直資料分割,以便充分利用客戶中繼資料的水平資料分割。

水平資料分割的圖表

圖 7:水平資料分割的範例。

雲端運算的中心是網路。網路非常關鍵,因為它針對連接至服務的裝置以及連接至其他服務的服務提供了網狀架構或骨幹。在任何保全應用程式中,都要考量三個網路界限。

底下將詳述這些網路界限,並使用 Azure 當做提供環境的範例:

  1. 角色界限在傳統上稱為層。常見的範例是 Web 層或商務邏輯層。如果我們以 Azure 當做範例,它會正式引進角色做為其核心設計的一部分,好讓基礎結構能夠支援現代化、分散式應用程式的多層本質。Azure 保證屬於相同服務的角色執行個體會在單一網路環境的範圍內裝載,並由單一網狀架構控制器管理。

  2. 服務界限代表相依於其他服務所提供的功能。常見的範例包括關聯式資料庫存取適用的 SQL 環境及發行/訂閱 (pub/sub) 訊息支援適用的 Service Bus。例如在 Azure 內,服務界限是透過網路強制執行:不保證服務相依性將會屬於相同網路或網狀架構控制器環境的一部分。雖然可能會發生這個情況,但是任何有責任感的應用程式設計都必須假設,任何服務相依性都取決於不同網狀架構控制器所管理的不同網路。

    雲端服務角色執行個體的圖表
    圖 8

  3. 端點界限在雲端外部。其中包括任何 連接到雲端的取用端點 (通常假設為裝置),以便取用服務。由於網路的變動和不可靠的本質,您在這個設計部分必須進行特殊考量。角色界限和服務界限位於雲端環境的界限內,我們可以假設某個層級的可靠性和頻寬。對於外部相依性而言,無法做出這樣的假設,因此必須額外注意裝置取用服務、有意義的資料和互動的能力。

    網路在從網路的某一點傳遞資訊到另一點時,原本就會引進延遲。為了針對使用者以及相依服務或角色身分提供絕佳的經驗,應用程式的架構和設計應該尋找可盡量減少延遲以及明確管理無可避免之延遲的方式。減少延遲的其中一個最常見方法是避免牽涉到網路的服務呼叫 -- 資料和服務的本機存取是降低延遲的重要方法,而且會引進更高的回應能力。使用本機資料和服務也會提供另一層的失敗安全性;只要可以從本機環境服務使用者或應用程式的要求,就不需要與其他角色或服務互動,因此在失敗點無法使用相依元件的機率就會完全排除。

快取

Caching是一項技術,當無法在本機儲存資料時,可用來提升資料存取速度。目前大規模運作的大多數雲端服務中,Caching 的使用會產生極大的影響。如同 Wikipedia 大綱所提供的定義,快取會針對應用程式重複要求的資料提供本機存取。Caching 依賴兩件事:

  • 使用者和相依應用程式的資料使用模式主要是唯讀的。在某些情況下 (例如電子商務網站),唯讀存取的百分比 (有時稱為瀏覽) 最高可達網站的所有使用者互動的 95%。

  • 應用程式的資訊模型會提供一個額外的語意資訊層,該層支援最適合快取的穩定、獨特資料的識別。

裝置快取

雖然不是保全計畫的焦點,裝置快取依然是增加任何裝置 + 服務應用程式之可用性和強固性的其中一個最有效的方法。有許多方式可在裝置或用戶端層提供快取服務,範圍從 HTML5 規格 (可提供在所有標準瀏覽器中實作的原生快取功能) 到本機資料庫執行個體,例如 SQL Server Compact Edition 或類似版本。

分散式快取

分散式快取是一組強大的功能,但是其用途不是為了取代關聯式資料庫或其他持續性存放區,而是為了增加分散式應用程式的回應能力 (這類應用程式的本質是以網路為中心,因此很容易延遲)。引進快取會附帶一個好處,就是減少持續性資料存放區的流量,因此會將與資料服務之間的互動降到最低。

  • 已針對快取最佳化的資訊模型

    note附註
    本章節的許多內容都是根據 Pat Helland 在考量服務導向架構世界的資料時所產生的絕佳作品。您可以在 Microsoft Developer Network 上閱讀整篇文章

    快取資料的本質為過時的資料,也就是說,不見得是最新的資料。快取資料的一個絕佳範例 (來自一個非常不同的領域) 為傳送給數千戶家庭的產品目錄。當建立目錄時,用來產生產品目錄的資料是最新的。進入了印刷程序之後,目錄生產過程會花費許多時間,因此資料就會過時。由於快取資料已過時,所以與穩定性和獨特性相關的資料屬性對於快取設計非常重要:

    • 穩定性 - 在空間和時間當中具有明確解譯的資料。這通常表示不會變更的資料值。例如,大多數的企業絕對不會回收客戶識別或 SKU 號碼。建立穩定資料的另一個技術則是在現有資料中新增到期日。上述的印刷產品目錄就是一個絕佳的範例。通常零售商會接受任何給定目錄在兩個發行期間的訂單。如果在一年內發行目錄四次,產品目錄資料就會穩定 6 個月,而且可以用來處理資訊,例如下訂單或履行訂單。

      穩定的資料通常會當做主要或「參考資料」來參考。在保全計畫中,我們可以使用「參考資料」這個術語,因為它在語意上比主要資料的涵蓋性更廣。在許多企業中,主要資料有非常具體的意義,而且比參考資料更為狹義。

    • 獨特性 - 可以透過應用程式隔離的資料 (該應用程式的唯一可識別執行個體沒有或有很少的並行更新)。我們以購物籃為例。雖然購物籃將會清楚地更新,但是更新並不常發生,而且可以完全與儲存及處理觀點隔離。

      如同上面所述,可隔離的資料會當做「活動」資料或工作階段資料來參考。

      牢記這兩個屬性,就會產生以下的結構描述:

      資料類型的圖表
      圖 9

  • 資訊模型化

    許多應用程式結構設計師或開發人員在考量資訊模型化時,會考慮物件或實體模型。雖然物件或實體模型屬於資訊模型化的藝術和科學部分,還是有許多內容會進入保全應用程式的資訊模型。

    當今分散式世界所需之思考流程的第一個觀點著重於穩定性和獨特性。另一個重要元素是了解在與使用者/裝置的互動中或是要實作的商務流程中如何利用資料。物件導向的模型化在許多方面應該是資訊設計的一部分:

    • 資訊隱藏 - 隱藏或不提供對於使用者或商務流程無用的資訊存取是避免與關聯式資料庫中所儲存和管理的資源或共用資料發生衝突的最佳方式之一。

      有一個絕佳範例可示範如何利用資訊隱藏來獲得改善並行的極大影響力:典型 ERP 系統與 Amazon.com 管理大部分存貨案例的方式兩者之間的差異。在 ERP 系統的典型實作中,存貨資料表是其中一個最擁擠或熱門的資料表 (如果假設採用關聯式資料庫實作)。ERP 應用程式通常會嘗試鎖定存貨,直到使用者完成交易為止,以便在商業交易開始的時候提供精確的存貨計數給應用程式。有些系統 (例如 SAP) 會避免資料庫鎖定,但是會在其加入佇列系統中取得應用程式鎖定。目前已開發了資料庫層的許多絕佳技術來協助解決這個壅塞問題:開放式並行存取控制、中途讀取等等。但是沒有一個技術真的可以完全解決問題,而且全都有副作用。在某些情況下,您會想要鎖定資料表,但是這些情況應該是少數而且不常見。

      Amazon.com 使用非常簡單的方法來解決問題:他們提供使用者服務等級目標 (SLO),使用者可以選擇加入來接受或拒絕。SLO 大多表示為「通常可在 N 小時內使用」-- 使用者不會看到實際可用書籍或其他項目的計數,但是可以看到有關可用性的資訊。這樣不需要任何資料庫鎖定,實際上根本不需要任何資料庫連接。如果系統未能符合 SLO,它會傳送道歉啟事給買主 (通常透過電子郵件) 並提供更新的 SLO。

    • 可替代資源:字典中將可替代資源定義如下:「可替代資源 (特別是貨品) 擁有的本質或種類是要能夠自由地 (整個或部分) 交換或取代另一種具有類似本質或種類的資源」。使用資訊模型化的概念核心 (目標同樣是為了減少存取共用資料所發生的摩擦) 是要提供方式讓使用者與可替代的資料執行個體互動,而不是與特定的執行個體互動。預訂旅館房間就是一個很好的例子。我們可以表達許多具體要求,例如床數、有海景、吸煙/非吸煙等等,而完全不用指示 '123' 房。使用這類模型化就可以非常輕鬆地快取有關可替代資料的集區資訊、針對該集區執行商務流程,而且只有在入住登記完成後才指派該集區的特定房間。入住登記開始後,從特定集區移除特定房間的混合模型也是完全可行的。

  • 管理快取

    在適當的時間快取適當的資訊是成功快取策略的關鍵。有許多技術可用來載入快取:在分散式環境中快取有提供很好的概觀。另外,底下的章節會概述相依於分散式快取之保全應用程式設計的一些考量。

    • 參考資料 - 如果裝載環境 (網狀架構控制器或資料中心) 發生損毀,您的應用程式將會移至另一個環境。如果應用程式的使用中執行個體已在使用中 (主動-主動設計),您的快取已包含許多相關資訊 (尤其是參考資料) 的可能性極高。如果應用程式的新執行個體調整大小,快取節點中不會有任何資訊。您應該設計應用程式,以便在發生快取遺漏時讓它自動載入所需的資料。如果是新的執行個體,您可以擁有啟動常式,將參考資料大量載入快取中。這兩個的組合很好,因為使用者可能會在雲端基礎結構服務應用程式之後立即處於使用中狀態。

    • 使用中資料 - 針對參考資料所描述的基本技術對活動資料也成立。不過,活動資料有一個特殊訣竅。假設在應用程式的任何持續性存放區內都可使用參考資料。因為它比較不常變更,所以同步處理應該不是問題,不過還是必須考量這一點。不過,活動資料 (雖然會在隔離中更新而且頻率很低) 將會比參考資料有更大的變動性。在理想的情況下,分散式快取會定期保存活動資料,並在應用程式的不同執行個體之間複寫資料。請務必確定保存和同步處理的間隔夠大以免發生競爭,但是也要夠靠近,好讓資料遺失的可能性降到最低。

常見的誤解為關聯性,特別是平台和應用程式之間的責任領域。最麻煩的其中一個地方就是和資料有關的問題。

雖然類似 Azure 的平台將會在內部部署環境中儲存多個資料複本 (而且在某些服務中,甚至還會提供地理備援性),儲存的資料是由應用程式、工作負載以及其元件服務所驅動。如果應用程式採取動作來損毀其應用程式資料,平台會儲存它的多個複本。

當您建立失敗模式和失敗點時,識別可能會造成資料損毀的應用程式區域非常重要。雖然起點可能會有差異 (不論是程式碼錯誤或是訊息對您的服務有害),識別相關的失敗模式和失敗點非常重要。

應用程式層級補救

  • 等冪

    連接服務的核心假設如下:這些服務將不會 100% 可用,而且具有重試邏輯的暫時性失敗處理為核心實作方法。如果是實作重試邏輯的情況,相同訊息可能會傳送一次以上、有可能從序列送出訊息等等。

    作業應該設計為等冪,以確保傳送相同的訊息多次不會導致非預期或污染的資料存放區。

    例如,從所有要求插入資料時,如果呼叫服務作業多次,可能會導致多筆記錄被新增。一種替代方法是將程式碼實作為智慧型「更新插入」(upsert),這種方式會在記錄存在時執行更新,或是在記錄不存在時插入記錄。可以使用時間戳記或全域識別碼來辨識新的訊息與之前處理的訊息、只將較新的訊息插入資料庫,並在該訊息比過去收到的訊息較新時更新現有的記錄。

  • 工作負載活動和補償行為

    除了等冪以外,要考量的另一個地方為補償行為的概念。

    當您退回使用信用卡支付的產品時,就可以看到真實世界的補償行為範例。在此案例中,消費者瀏覽一家零售商、提供信用卡號碼,然後就會向消費者的信用卡帳戶收費。如果消費者將產品退回零售商,將會評估一項原則,而且如果退貨符合該原則,零售商就會向消費者的信用卡帳戶發出購買金額的扣抵。

    在每一組連接系統都不斷成長而且複合服務不斷出現的現實世界中,了解如何處理補償行為是非常重要的。

    對於企業營運系統應用程式的許多開發人員而言,交易的概念並不是新的,但是參照系統通常會連結到本機資料技術和相關程式庫所公開的交易功能。根據雲端來檢視此概念時,必須將分散式服務的協調流程相關事項列入新的考量。

    服務協調流程可跨越多個分散式系統,並且在長時間執行且具有狀態。協調流程本身很少同步,而且可以根據商務案例從秒擴充到年。

    例如,在供應鏈案例中,可在相同工作負載活動中將 25 個組織繫結在一起。例如,可能有一組 25 個或更多的系統在一個或多個服務協調流程中互相連接。

    如果成功的話,這 25 個系統必須察覺此活動已成功。對於活動中的每一個連接點而言,參與者系統可以針對它從其他系統收到的訊息提供相互關聯識別碼。根據活動類型而定,收到該相互關聯識別碼可能會讓該系統因為交易在名義上已經完成而感到滿意。在其他情況下,當所有 25 方的互動完成後,確認訊息可能會傳送給所有方 (直接從單一服務或是透過每個系統的特定協調流程互動點)。

    為了處理複合和/或分散式活動中的失敗,每一個服務都會公開服務介面和作業來接收要求,以便透過唯一識別碼取消給定的交易。在服務門面背後,將會設置工作流程來補償這項活動的取消。在理想情況下,這些會是自動化程序,但是可能會像是路由傳送給組織內的人員進行手動修復一樣簡單。

備份

除了在應用程式層級進行補救來避免資料損毀之外,如果應用程式補救不成功,還有補救方法可提供其他選擇。

建立及還原資料存放區備份複本的程序 (不論是全部還是一部分) 都應該是恢復計畫的一部分。雖然備份和還原資料的概念並不新,在雲端執行這些作業還是有新的訣竅。

定義您的備份策略時,應該要清楚了解還原資料的商務需求。如果資料存放區因為發生災害而損毀或是離線工作,您應該要知道必須還原哪一種類型的資料、必須還原多少容量,以及業務上所需的步調為何。這樣會影響您的整體可用性計畫,而且應該會推動您的備份與還原規劃。

  • 關聯式資料庫

    備份關聯式資料庫並不是新的概念。許多組織都有工具、方法和流程可備份資料,以便滿足災害復原或規範需求。在許多情況下,傳統備份工具、方法和流程可能只需要很少的修改或完全不用修改就可以運作。此外,還可以考量新的替代方法或變種替代方法,例如在雲端架構 blob 儲存體備份資料和儲存複本。

    當評估現有的流程和工具時,評估哪一個方法適合雲端架構解決方案非常重要。在許多情況下,將會套用底下所列的其中一個或多個方法來補救不同的失敗模式。

    1. 完整備份 - 這是備份完整的資料存放區。完整備份的進行應該要根據您的資料量和速率所指示的排程。完整備份是針對您的服務提供服務等級合約所需的完整資料集。這種備份類型的機制通常是由資料庫/資料庫服務提供者或其供應商生態系統所提供。

    2. 時間點 - 時間點備份是指可反映資料庫內特定時間點的備份。例如,如果在下午發生錯誤而導致資料存放區損毀,可以還原中午執行的時間點備份,讓業務上的影響降到最低。

      隨著個人的連接能力等級不斷成長,在一天的任何時間都能使用您的服務的預期讓您必須能夠快速還原到最近的時間點。

    3. 同步處理 - 除了傳統備份以外,另一個選擇就是資料同步處理。例如,可以將資料儲存在多個資料中心,並且定期將一個資料中心的資料與另一個資料中心同步處理。除了在一般可用性計畫中,於使用流量管理的解決方案內提供同步處理的資料以外,這也可以在發生業務續航力問題時用來容錯移轉至第二個資料中心。

      因為個人取用服務時必須有持續的連接能力,所以在許多情況下越來越不能接受停機時間,而同步處理就是可取的方法。

      同步處理的模式可以包括:

      - 給定雲端提供者的不同資料中心之間

      - 不同雲端提供者的不同資料中心之間

      - 從內部部署到給定雲端提供者的不同資料中心之間

      - 取用者特定資料配量的資料中心與裝置的同步處理

  • 分區化關聯式資料庫

    在許多情況下,移至雲端的動作是因為需要促成大量使用者及高流量案例 (例如與行動或社交應用程式有關的案例) 而驅動。在這些情況下,應用程式模式通常牽涉到從單一資料庫模型移開到許多資料庫分區,這些分區包括整體資料集的一部分,而且已針對大規模管理而最佳化。最近有一個社交網路專案建立在 Azure 之上,此專案推出時一共有 400 個資料庫分區。

    每個分區都是獨立的資料庫,而且您的架構和管理應該可加速完整備份、時間點備份,以及備份和還原個別分區與完整資料集 (包括所有分區)。

  • NoSQL 資料存放區

    除了關聯式資料存放區之外,「不只是 SQL」或 NoSQL 資料存放區也應該考量備份原則。主要雲端提供者提供之 NoSQL 資料庫的最常見形式是高可用性金鑰-值組存放區的形式,通常稱為資料表存放區。

    NoSQL 存放區可能具有高可用性。在某些情況下,這些存放區也具有地理位置備援性,這樣可在特定資料中心發生災難性失敗時防止資料遺失。這些存放區通常不提供應用程式覆寫或意外刪除內容的防護。應用程式或使用者錯誤不是由平台服務 (例如 blob 儲存體) 自動處理,而且應該要評估備份策略。

    關聯式資料庫通常有現存且建立完善的工具來執行備份,但是許多 NoSQL 存放區則否。有一種常用的架構方法是在複本 NoSQL 存放區內建立資料的重複複本,並使用某種查閱資料表來識別來源存放區中的哪些資料列已經放入複本存放區。若要還原資料,將會使用這個相同的資料表,從資料表讀取資料,以識別複本存放區中可還原的內容。

    根據業務續航力的顧慮,可能會向相同的雲端提供者將此複本的位置裝載在相同資料中心及/或相同的 NoSQL 資料存放區。它也可能位於不同的資料中心、不同的雲端提供者及/或 NoSQL 資料存放區的另一個變種內。位置的驅動主要受到您的工作負載服務所需之 SLA 及任何相關的符合規範考量所影響。

    在做出這項決定時要考量的一個因素是成本,特別是因為成本與資料入站和出站有關。雲端提供者可能允許免費讓資料在其資料中心內移動,並允許免費將資料傳遞到他們的環境。但是沒有任何雲端提供者會提供免費的資料出站,而且將資料移到次要雲端平台提供者可能會產生大量的成本。

    note附註
    查閱資料表會變成潛在的失敗點,而且它的複本應該視為恢復功能規劃的一部分。

  • Blob 儲存體

    就像關聯式和 NoSQL 資料存放區一樣有一個常見的誤解:為 blob 儲存體解決方案實作的可用性功能將不需要考慮實作備份原則。

    Blob 儲存體也可能具有地理位置備援性,但是如同之前所討論,這樣並無法防禦應用程式錯誤。應用程式或使用者錯誤不是由平台服務 (例如 blob 儲存體) 自動處理,而且應該要評估備份策略。

    備份策略可能非常類似於 NoSQL 存放區使用的策略。因為 blob 可能會很大,所以成本和移動資料的時間將會是備份和還原策略的重要考量。

  • 還原備份

    目前多數人都已聽過如下的警示故事:組織建立備份原則並且努力遵循,但是從來沒有測試過資料的還原。在災難發生的那個致命日子,他們還原了資料庫備份,但是卻發現他們錯誤設定了備份,而且他們過去幾年來一直傳送到異地位置的磁帶並沒有他們所需的資訊。

    不論採用哪一種備份程序,都務必要建立測試流程,以驗證資料可以正確地還原及確保還原作業可及時進行並且對業務的影響最小。

內容傳遞網路 (CDN) 是針對經常要求的檔案提供可用性和增強型使用者體驗的一種常見方式。CDN 的內容會在第一次使用時複製到本機節點,然後在後續要求中,從該本機節點提供服務。內容將會在指定的期間之後到期,過了這段期間,下一次要求時必須將內容重新複製到本機節點。

利用 CDN 會有一些優點,但是也增加了相依性。就如同任何相依性一樣,應該要主動檢閱服務失敗的補救方式。

CDN 的適當用法

一個常見的誤解就是 CDN 是調整的萬靈丹。在某個案例中,客戶確信這是線上電子書店的適當解決方案,但並非如此。為什麼?在數百萬本書籍的目錄中,有小型的書籍子集將常被要求 (點擊),而有極大量書籍的要求機率很難被預測。經常被要求的書名將會在第一次要求時複製到本機節點,並提供具成本效益的本機規模及愉快的使用者經驗。至於其他那些極大量的書籍,幾乎每一個要求都會複製兩次 (一次複製到本機節點,一次複製給客戶),因為罕見的要求會導致內容定期到期。這是不適當的 CDN 會產生相反的預期效果的證明 -- 結果會產生更慢而且更耗費成本的解決方案。

在許多情況下,解決方案的作業人員要等到生命週期往前的途中才能規劃。若要建立真正具有恢復功能的應用程式,應該針對作業人員加以設計。針對作業人員的設計通常包括一些重要活動,例如建立健全狀況模型、擷取遙測資訊、併入健全狀況監視服務和工作流程,以及讓這些資料可由作業和開發人員付諸行動。

開發團隊經常忽略 (有時甚至完全忽視) 應用程式的「健全狀況」。因此,服務在進入生產程序時有兩個已知的狀態:啟動或關閉。具有恢復功能之服務的設計師應該開發健全狀況模型來定義應用程式的健全狀況準則、變弱的健全狀態、失敗和健全狀況相依性。

主動開發健全狀況模型會概述失敗模式和失敗點,要求開發人員識別及學習應用程式設計階段的假設狀況。若要讓健全狀況模型可以操作,服務必須能夠傳達其健全狀況。它必須擁有程式設計方式來傳播這類資訊、提供可以互動方式查詢該健全狀態的介面、提供機制 (或現有機制中的勾點) 讓管理員可以即時監視應用程式健全狀況,以及建立機制讓管理員可以在必要時傳遞校正的「藥方」,讓應用程式回到健全狀態。

定義特性

對給定的服務或應用程式而言,應該採取診斷來識別資料點和值範圍,這些範圍至少要指示健全狀況的三個類別:狀況良好、狀況變弱中和狀況不良。使用這些資訊可自動化自我療癒服務。

定義介面

定義了健全狀態之後,服務應該公開與健全狀況相關的介面。這些介面將會提供以下類別的作業。

  • 向訂閱的合作夥伴服務發出健全狀態

    服務應該將健全狀況資訊發給訂閱的合作夥伴服務。這個健全狀態應該很簡潔,而且包含高層級健全狀況和基本診斷。

    此服務應該讓合作夥伴服務能夠訂閱健全狀況訊息。可以透過適合解決方案的路徑來進行健全狀況訊息的傳遞。其中一個路徑可以讓服務將健全狀態更新放在佇列上,並由訂閱者加以擷取。

    另一個方法則是讓訂閱者提供端點,在此端點上公開已知健全狀況報告介面。當健全狀況資訊變更時,它可以在其提供的端點上發出資訊給訂閱者。

  • 公開介面來傳遞遙測資料

    遙測對於作業人員非常有用,因為它有助於識別應用程式及/或服務在多個層級的目前健全狀況。它也可以在環境中發生了不尋常的狀況時快速識別出來。這樣會針對服務提供相當精細的檢視,而且會公開給服務提供者的操作員工、服務和儀表板。

    對於作業人員而言,遙測度量會針對服務上所建立的不同角色、服務和複合應用程式包括類似平均 CPU 百分比、錯誤、連接和佇列等資料。

    「應用程式特有的」遙測通常不會自動啟用而且會由平台本身直接監視,所以應該由服務和應用程式啟用遙測。

  • 公開介面來詢問服務,以找出其他健全狀況診斷資訊

    在理想情況下,服務應該也要提供介面來詢問其他健全狀況診斷資訊。訂閱者服務可能會根據健全狀態中所收到的高層級資訊來要求其他資訊,以決定其關係前進的路線 (此服務會提供其健全狀況詳細資料)。

    具體而言,如果此服務似乎處於不良的狀態,其他資訊將可讓取用服務決定是要繼續使用此服務還是容錯移轉到替代的提供者。

  • 公開介面,以便在服務和應用程式層級補救服務健全狀況

    如果健全狀況資訊的取用者為內部或相關服務,您可能會想要讓此服務能夠自我補救已知問題。就像人類的醫藥一樣,服務健全狀況的理解將會隨著時間而進化,而且健全狀況資料可導致不同的療程。

    服務應該公開介面,以便傳遞該治療方式。以最簡單的形式而言,其範圍可能從觸發服務的重新啟動或重新安裝映像,一直到容錯移轉至不同的內部資料或服務提供者。

    了解服務的健全狀況可讓服務提供者快速識別服務是否狀況不良。自動化作業可針對已知問題提供快速、一致和規定的補救方式,並讓服務自我療癒。本章節會更詳細地檢閱健全狀況的不同層面。

遙測就是「使用特殊設備來測量某個事物 (例如壓力、速度或溫度) 並透過無線電傳送到其他位置的程序」。

請務必從您的服務收集遙測資料。遙測通常可分為下面四種類型:使用者、企業、應用程式和基礎結構。

使用者遙測會以個別目標使用者的行為為目標。這可讓您深入了解使用者的行為,進而提供個人化的經驗。

企業遙測包含企業活動相關資料和企業的關鍵效能指標 (KPI)。企業遙測範例包括網站上有在活動的獨特使用者的數目、觀看的影片數目等。

應用程式遙測包含應用程式層與其相依服務的健全狀況、效能和活動等詳細資料。應用程式遙測包含資料用戶端呼叫和登入、例外狀況、API 呼叫、工作階段等的詳細資料。。

基礎結構遙測包含基礎系統之基礎結構的健全狀況詳細資料。這可能包含 CPU、記憶體、網路、可用容量等資源的資料。

在識別要收集哪些資料及其收集方式時,請務必了解這些資料以及您想要的用途。

首先,決定所收集的資料用途是通知或起始動作。要詢問的問題是:「我應該多快回應?」您會幾近即時地使用資料來視狀況起始動作嗎?或者,您會在逐月趨勢報告中使用此資料嗎?這些問題的答案會描繪出架構中使用的遙測方法和技術。

接著,識別您打算套用到所收集之遙測資料的問題類型。您是否會使用遙測來回答已知問題,或者,您是否會使用遙測來進行探索。例如,對企業而言,KPI 就是已知問題的答案。不過,想要探索裝置資料以得到造成錯誤之模式的製造商,可能會闖進未知的世界中。對此製造商而言,錯誤衍生自系統中的一或多個項目。此製造商正在進行探索並需要其他資料。

當您使用遙測技術來進行深入剖析時,必須考量進行深入剖析所需的時間。在某些情況下,您會利用遙測來偵測裝置感應器讀數的高峰 (持續幾秒鐘或幾分鐘的時間)。在其他情況下,您可以使用遙測技術來識別網站的逐週使用者成長情形 (持續期間較長)。

最後,請考慮您可以在時間範圍內從訊號來源收集到的用來進行深入剖析的資料量。您必須知道所需的來源訊號量。您可以接著判斷用來分割該訊號的最佳方式,以及建立適當的本機和全域運算混合。

另外,還需考慮如何記錄遙測中的事件順序。
許多組織會預設使用時間戳記。然而,時間戳記可能是一大挑戰,因為各資料中心的伺服器時鐘並非一致。雖然可以定期讓時間同步,但文獻證明伺服器時鐘會漂移 (慢慢地變得不準確)。此漂移現象會導致時間改變,進而損害分析的有效性。對於需要精確度的案例,請考慮替代解決方案,例如運用向量時鐘實作。

在識別遙測方法之後,請接著界定訊號。

您可以將訊號分為連續或離散訊號。即時事件資料即為連續訊號的範例。記錄檔項目則是離散訊號的其中一種。

若要符合您的方法的需求,您必須識別訊號中有多少資料。如果是連續資訊,您必須建立取樣率。如果是離散資訊,則必須識別要保留或篩選的記錄。

您也必須識別存取類型。某些情況很適合推送遙測資料。其他情況則要透過提取方式擷取遙測資料。

在更先進的系統中,您可能會發現從現有推送遙測方法取得的深入剖析,可能會導致有目標地提取其他資訊。例如,如果推送遙測方法指出目前並非最佳狀態,您即可透過提取方式來擷取其他診斷資料。

在某些狀況中,收集到的資料彼此可能有關聯,但並非所有遙測資料都必須一直不斷地傳送。根據遙測類型和衍生深入見解所需的資料量而定,您或許可以擷取較少量的資料。您可以使用本機運算來產生彙總、取樣或建立子集,以及將該資料傳送到服務。例如,如果您從標準遙測接收到的資料指出目前並非最佳狀態,服務即可要求其他資料。

在開發遙測策略時,請考慮適當的原則為何。遙測需要可用的連線,而且透過該連線傳送資料時會有成本。建立考量到環境、連線和成本的原則,並且視情況調整遙測。

您的原則必須考量目前狀態的環境,以判斷哪一項遙測適合立即傳送。從先前接收到的遙測所取得的深入分析和相關聯的商務需求會描繪出環境。此環境有助於指出遙測的收集方式和收集時的優先順序。

這些裝置可能有各種類型的連線 (WiFi、LTE、4G、3G 等),而且該連線可能會變化。裝置連線目前與判斷應傳輸哪些資料息息相關。在連線不可靠或連線速度緩慢的情況下,原則可以設定傳輸之遙測的優先順序。

連線通常都有提供成本。這些原則會考慮連線目前是計量付費或非計量付費的連線。如果是計量付費的連線,這些原則會識別相關的成本和使用上限 (若有的話)。許多裝置會在一天之內使用不同類型的連線。您可以根據提供成本,設定特定遙測的優先順序或延後其優先順序。

不同的對象通常會消化遙測資料並加以視覺化。作業人員和開發人員是很重視視覺化的兩大對象。不過,如下所述,每種對象的需求各自需要不同程度的資料粒度。

對作業人員而言,將高層級的作業狀態和較低層級的遙測資料視覺化非常重要。可能會根據遙測資料來備妥自動通知功能。不過,作業人員會想要有一個儀表板,以便將目前和過去的服務效能視覺化。

對於大規模的應用程式,此資訊有助於快速識別目前的問題或預測未來會發生的問題。此外,也可協助作業人員找出可能的影響和根本原因。

績效儀表板的圖表

圖 10

來自大型社交網站的上面圖表會查看 API 角色平均 CPU%、API 錯誤、線上使用者、Web 使用中連接、Web 角色 CPU%、Web 錯誤、Web 硬性連接、Web 共用連接、Web 應用程式佇列、Web 軟性連接。

上面顯示的遙測和報告類型在以下情況特別有用:作業人員可以補救錯誤,而不必自行針對服務修改程式碼。作業人員可以執行的活動範例包括部署更多的角色及回收執行個體。

您可以將過去和即時遙測資料的視覺化用於:

  • 疑難排解。

  • 對於即時網站問題進行事後檢討。

  • 訓練新進作業人員。

除了作業人員以外,軟體開發人員也是遙測資料的重要取用者。錯誤可能與作業環境無關,而是與基礎應用程式程式碼有關。擁有開發人員適用的遙測儀表板可讓他們採取導向動作。

以下兩個螢幕擷取畫面是僅針對此一目的所建立的範例公用程式。此儀表板會提供有關錯誤數目、錯誤的類別以及與每一個類別有關之特定資料的詳細資料。其中包括檢查資料,錯誤總數、遇到錯誤的角色執行個體總數以及發生錯誤的資料庫總數都包括在內。

儀表板的圖表

圖 11

儀表板的圖表

圖 12

對於有數百萬使用者的大型網站而言,將會發生較高的錯誤統計數,這完全可以被接受。如果擁有以開發人員為中心的儀表板來解譯遙測,則可以識別是否真的發生問題、是否適合參與以及問題發生在程式碼的何處。

另請參閱

本文對您有任何幫助嗎?
(剩餘 1500 個字元)
感謝您提供意見
顯示:
© 2015 Microsoft