在Windows Azure雲服務上設計大型服務的最佳做法

今天的帖子來自于HTTP://www.aliyun.com/zixun/aggregation/16689.html">Jason Roth，主程式設計作家。 他提供了來自我們的客戶諮詢團隊的新白皮書的概述，涉及在Windows Azure上 設計大型服務的最佳做法。 我們最近發行了新的白皮書：在Windows Azure 雲服務上設計大型服務的最佳做法。 這份檔彙集了基於實際的客戶約定的設計模式和指導方針。 它結合了最好的策略和設計模式，始終如一地證明了真實世界的 Windows Azure 應用程式的成功。

首先要瞭解這個平臺

當您閱讀這個白皮書，你會注意有三個主要部分：

設計概念
探索 Windows Azure
最佳做法
您可能被誘惑去直接流覽最佳做法，但您應該意識到這些最佳做法源自前兩節中的資訊。 每個應用程式是唯一的。 首先去瞭解 Windows Azure 平臺和基本的設計原則是很重要的。 這對選擇正確的優化以及實現正確的執行都有説明。

好的設計 — — 值得努力

任何大型的應用程式設計需要認真思考、 規劃和潛在地複雜的執行。 對Windows Azure而言，最基本的設計原則是擴展。 而不是投資在功能強大 （且昂貴） 的硬體上，擴展策略通過添加更多的機器或服務實例回應不斷增加的需求。

對於每個Windows Azure服務而言，許多最佳做法涉及實現擴展。 例如，在Windows Azure中，不能放大運行在您的 SQL 資料庫上的伺服器。 相反，您必須設計應用程式用來利用額外的 SQL 資料庫實例。 這涉及到對你的資料的某些類型的分區策略。

當然，面臨的挑戰是選擇正確的分區策略，並成功地協調分區之間的工作。 本文試圖為您提供你所做選擇的技術性理解和過去客戶方案的實際建議。

請注意，分區提高了可擴充性，SQL 資料庫是只是很明顯的例子。 但是要最大化平臺的優勢，其他角色和服務必須以類似的方式擴展出。 例如，存儲帳戶的交易率是有上限的，虛擬機器的 CPU 和記憶體有上限； 最大限額通過多個存儲帳戶的使用、元件擴展出虛擬機器設定尺寸的服務來實現。

雖然可伸縮性是設計背後的驅動力，還有其他非常重要的設計注意事項。 檔強調，必須對遙測和診斷資料收集做規劃，這個變得越來越重要，因為您的解決方案變得更多元件化和分區化。 可用性和業務連續性是本文的兩個其它的主要焦點。 當您的服務出現故障或者不可避免地遺失資料，擴充性就與此無關了。

最佳做法和平臺演化

Windows Azure 不斷演變、 改進和增加新的服務。 在最近的版本中，已經增加了新的功能，例如 Windows Azure 虛擬網路和基礎設施作為一種服務 （IaaS）。 這些新功能給大型應用程式提供了更多的選擇。 然而，這份檔重點關注版本1.6，並不包括添加到平臺的一些最新的特徵。

要瞭解這個決定的原因，您必須重新審視這項工作的目標。 這篇文章將會提供在真實客戶實踐中成功的設計指導。 因為這些服務可能需要數月計畫、 測試和迴圈，在這篇文章更新了最新的服務和功能之前，它將會花費一些時間。 但所有檔中的設計原則仍然適用，而且同一類型的思維可以應用於Windows Azure 的任何新功能。

繼續，我們正在處理額外的檔、 代碼示例和說明，演示如何執行一些最佳的做法。

不是一個核對表

每個人都喜歡核對表。 思想是： 如果你可以選擇所有的選框，然後你知道你將會成功。 有了在 Windows Azure 雲服務上設計大型服務最佳做法，不要把這些資訊看作一個核對表。 您的應用程式是唯一的。 或許，在這個時刻，您的應用程式是"中等-高"的規模。 有可能當你理解了平臺和最佳做法後，只有一些建議在短時間內對你來說是至關重要的。 但展望未來，規劃你將會需要一些或所有的其他設計策略的可能性。