使用Azure雲服務構建多服務企業應用程序

Question

我對使用天藍雲服務構建企業應用程序有一些疑問。

背後的故事

我們有一個SQL後端由十幾WCF Windows服務的系統。我們目前有大約10個客戶端，但預計可能增長到100個，可能會增加系統吞吐量的一百倍。目前的系統設計不好，而且根本無法擴展。所以現在看起來是在蔚藍的平臺上重新設計的適當時機。

工藝流程

讓我簡要介紹一下服務的簡化集和流程，然後問了一些問題，我有一個關於利用Azure雲服務來構建新的系統。

服務A登錄到一個外部系統和下載數據連續

服務B登錄到第二外部系統和下載數據連續

有隻能爲一個在實例記錄的每個的服務A和B.

A和B都將它們的數據傳遞給服務C，以使來自兩個外部源的數據一致。

驗證和核對數據接着由C傳遞到服務d執行一些計費功能和隨後將得到的數據到服務E和F.

服務E被連續地登錄到外部系統和上傳數據到它。

服務˚F生成報告，並通過FTP等

他們發佈到客戶端的系統實際上是比這更加複雜，但上述說明所涉及的過程。該系統每週6天，每天24小時運行。隊列將用於緩衝所有服務之間的消息傳遞。

我們可以使用Azure持久性虛擬機構建此係統，並利用服務總線，隊列等，但這會將我們與垂直擴展策略聯繫起來。考慮到以下問題，我們如何利用雲服務來實現它？

問題

1. 鑑於服務A，B和E與外部系統的永久記錄有隻能永遠是每一個活動實例。如果我們將這些作爲單個實例工作者角色來實現，則存在停機時間和修補問題（這是不可接受的）。如果我們創建了每個實例的兩個實例，那麼是否存在一種標準方式來實現在Azure上使用角色的主動 - 被動負載平衡，還是需要構建自己的負載平衡器？對於這個問題還有沒有想過的另一個解決方案？

2. 服務C和D是使用多個工作者角色實例進行擴展的理想選擇。但是每個實例都必須處理相關數據。例如，我們可以爲5個單獨的客戶端分別處理4個實例。我們如何才能讓消息按每個實例進行分組處理（以客戶爲中心）？另外，當修補發生時，我們如何將一個實例的負載重新分配給剩餘的實例。例如，如果爲5個客戶端處理數據的實例1在進行操作系統修補時出現故障，則其客戶端的數據將不得不由其餘實例處理，直到它重新恢復爲止。同樣，如果我們決定啓動額外的員工角色，我們如何重新分配負載？

您能提供的任何見解或建議將不勝感激。

墊

Answer 1

問題1：你將不得不實現自己的負載平衡。這不應該非常複雜，因爲您可以使用Blob存儲租約功能在一個實例的存儲中的某個blob上保留一個互斥鎖，同時將連接保持在外部系統中。如果您知道連接仍處於活動狀態並且成功，則您可以每續期X次續約。角色中的其他每個工作人員都可以檢查該租約是否到期。如果它到期，下一名工人將跳入並獲得租約，然後打開與外部資源的連接。

問題2：查看Azure服務總線。它有能力允許客戶處理相關的消息。更多的信息在這裏：http://geekswithblogs.net/asmith/archive/2012/04/02/149176.aspx 所有的排隊方法意味着，如果一條消息被拾取，但沒有在可配置的時間內得到處理，它就會返回到隊列中，以便下一個可用實例可以拾取並處理它

您可以使用類似AzureWatch的東西來監控隊列（存儲或服務總線）的深度，並自動縮放C和D角色中的實例數量以匹配;和監控實例狀態的角色A，B和E，以確保始終有一個健康的實例有和經銷商的規模，如果準備實例的數量已降到0

HTH

Answer 2

首先，備份的一個步驟。在Windows Azure上查看應用程序體系結構時，我首先要做的一件事就是確定該應用程序是否適合遷移到Windows Azure。我特別關注應用程序中的集成程度 - 集成總是比預期的更加困難，在雲中執行集成時更是如此。如果大部分工作負載需要通過一個永遠在線的連接完成，那麼您將很難獲得我們轉向雲所提供的可用性和可伸縮性。

不知道您的應用程序的細節，但舉例來說，假設服務A & B是來自財務數據提供者的饋送。數據饋送提供商非常善於處理他們的工作，具有高可用性，併爲企業級成本提供「企業級」（無論這意味着什麼）。他們的建築也是老派，在某些情況下，還非常僵硬。因此，請首先考慮詢問您的供稿提供商（提供登錄/連接並希望您提取數據），以便通過Web服務將數據推送給您。暴露的Web服務是擴展和性能的解決方案，可用於Azure上的表存儲以及DynamoDB等高吞吐量數據庫服務。 （我會挑戰任何企業數據提供商來解釋像Amazon S3這樣的服務是如何使用米奇鼠標的。）如果數據供應商通過商定的API將數據推送到Web服務，則可以對服務執行各種擴展和可用性工程成本低。

正如您發現的那樣，您可以選擇構建一大堆東西，以確保您的架構符合數據供應商的單節點模型。雖然可以完成，但您將花費大量的工程現金 - 滾動一大堆分佈式計算原理。如果您打算採用主動 - 被動架構，則需要實施領導者選舉算法，以確定被動節點何時應該處於活動狀態。這不像聽起來那麼微不足道，因爲主動節點可能看起來已經消失，但仍在處理中 - 而且您不想插入另一個節點。那麼你會實現一個心跳，或者甚至是一個單獨的「見證」節點，除了關注哪些節點還活着以便對它們做些什麼之外什麼也不做。你提到停機時間和補丁是不可接受的。那麼可以接受什麼？幾分鐘或幾秒鐘，或不到一秒鐘？你想讓被動節點接管另一個節點，還是重新開始？

您可能會發現實現所有這些的開發成本低於構建和託管高可用性物理服務器的成本。也許你可以分開負載並在一個物理盒子裏共同運行數據饋送服務，並且可以在Windows Azure上完成處理。我甚至不會看Azure虛擬機，因爲雖然它們不像角色那樣回收，但它們偶爾會遇到問題 - 至少比企業級硬件要多。首先與您的供應商討論數據饋送 - 他們可能有解決方案，或者可以拼湊在一起的解決方案（例如，兩個登錄價格爲一個，而第二個帳戶/實例大多數則拋棄其數據）。

要非常小心傳統的企業整合。他們要求在今天以云爲導向的世界中看起來很古怪的事情。例如，我有一個請求，即我的呼叫服務具有固定的IP地址。您可能會發現，爲了解決別人的體系結構而編寫的代碼在購買物理服務器方面會更好。推回數據提供者 - 現在是他們走出90年代的時候了。

[免責聲明]'企業'，尤其是金融服務企業，一直在說他們的要求是特殊的 - 更高的吞吐量，更高的安全性，更高的法規和更高的可用性。除極少數情況（例如高頻交易）外，我傾向於在大多數情況下稱爲「公牛」。他們受到大型IT預算和昂貴套件供應商的青睞，這些套件讓他們喜歡上午餐，並且接受服務器信任的灌輸。我個人對企業硬件/軟件/服務業務的看法影響了這個答案。你的旅費可能會改變。