C# 云模式和最佳實踐

    在云中，僅允許較短的延遲或停機時間，代碼必須為此做好準備，代碼要包含從這些平臺異常中成功恢復的邏輯。如果以前曾現(xiàn)場編碼，或編寫就地執(zhí)行的程序代碼，這是一個重要的思想轉(zhuǎn)變。需要忘掉很多有關管理異常的東西，學會接受失敗，并創(chuàng)建從這種失敗中恢復的代碼。

    需要將可移植性、可伸縮性和彈性等概念集成到在云運行中的程序里。但這里的可移植性有什么特殊含義？如果程序可在多個平臺上移動或執(zhí)行，例如Windows、Linux和macOS，該程序就是可移植的。一些ASP.NET Core特性位于開源技術(shù)的新堆棧上，為開發(fā)人員提供把代碼編譯到二進制文件中的選項，以便在這些平臺上運行。傳統(tǒng)上，開發(fā)人員使用ASP.NET編寫程序，在后臺運行C#，使用IIS在 Windows服務器上運行該程序。然而，從以云為核心的角度看，在沒有人工干預或程序化干預的情況下，程序及其所有依賴項從一個虛擬機移動到另一個虛擬機的能力是最適用的“可移植性”。記住，云中會出現(xiàn)失敗，運行程序的虛擬機(VM)可以在任何給定的時間消失，然后在另一臺虛擬機上重新構(gòu)建。因此，程序必須是可移植的，能從這樣的事件中恢復。

    “可伸縮性”意味著，當多個客戶使用代碼時，代碼能正常響應。例如，如果每分鐘有1500個請求，且請求的完成和響應在1秒鐘之內(nèi)完成，則大約每秒有25個并發(fā)請求。如果每分鐘有15000個請求，則每秒有250個并發(fā)請求。云程序能以相同的方式響應25個和250個并發(fā)請求嗎？如果是2550個并發(fā)請求呢？以下是幾個有效管理可伸縮性的云編程模式：

    ? 命令和查詢責任分離(Command and Query Responsibility Segregation, CQRS)模式——這種模式涉及把讀取數(shù)據(jù)的操作與修改或更新數(shù)據(jù)的操作分離開。

    ? 物化視圖模式——這會修改存儲結(jié)構(gòu)，以便反映數(shù)據(jù)查詢模式。例如，為極常用的查詢創(chuàng)建視圖可以執(zhí)行更有效的查詢。

    ? 分片(Sharding)模式——這把數(shù)據(jù)分解到多個水平碎片中(其中包含明顯不同的數(shù)據(jù)子集)，而不是通過增加硬件的容量進行垂直伸縮。

    ? 管家鑰匙(Valet Key)1i式一這允許客戶直接訪問數(shù)據(jù)存儲，以傳輸或上傳大文件。它不是讓Web客戶機管理數(shù)據(jù)存儲的守衛(wèi)工作，而是給客戶提供一把管家鑰匙，并允許直接訪問數(shù)據(jù)存儲。

    “彈性”是指程序響應和從服務故障和異常中恢復的程度。從歷史上看，IT基礎設施一直專注于失敗的預防，其可接受的停機時間是最短的，期望值是99.99%或99.999% SLA(Service-LevelAgreement，服務水平協(xié)議)。 但在云中運行程序，可靠性需要做思維轉(zhuǎn)變，我們需要擁抱失敗，要更關注恢復(而不是預防)。程序有多個依賴項，如數(shù)據(jù)庫、存儲器、網(wǎng)絡和第三方服務，其中一些沒有SLA，所以需要轉(zhuǎn)變視角。在出現(xiàn)中斷或非正常運行的情況下，如果仍能做出用戶友好的響應，會使云程序富有彈性。下面的一些云編程模式可用于將彈性嵌入云程序：

    ? 斷路器模式——這是一種代碼設計方式，它了解遠程服務的狀態(tài)，只有在服務可用的情況下，才會試圖連接。如果通過以前的失敗知道遠程服務不可用，就會避免嘗試請求和浪費CPU周期。

    ? 健康端點監(jiān)控模式一一這會通過實現(xiàn)端點檢測，檢查基于云的應用程序是否可用。

    ? 重試模式——在短暫的異?；蚬收虾笾卦囌埱?。這種模式在給定的時間段內(nèi)重試多次，當重試次數(shù)到達閾值時，就停止重試。

    ? 節(jié)流模式一一管理云程序的使用，以便滿足SLA，而且程序在高負載下仍然可用。

    使用上述一個或多個模式，有助于更成功地實現(xiàn)云遷移。上述模式會提高程序的可伸縮性和彈性，從而提高程序的可用性。這反過來會帶來更愉悅的用戶或客戶體驗。