我們有一個位於北歐地區的數據庫，Azure上有兩個AppServices節點（西歐&北歐）。我們使用流量管理器來路由流量。通過重構節點提高CPU利用率
我們的SQL數據庫和存儲位於北歐。
當我們啓動網站時，歐洲的地點最接近我們的客戶。
但是，我們看到了一個轉變，現在我們的大部分客戶都來自美國。
雖然我們在每個處理器上都有很多實例，但我們的處理器的CPU利用率很高。
的問題是：
由於我們的客戶大部分來自美國，很難重新定位數據庫，是它更好地保持應用程序的結構，因爲它是（北歐&西歐）或創建美國的一個新節點，但該節點仍然需要與北歐的數據庫進行通信？
謝謝
不建議您在美國地區和歐洲的數據庫應用程序。
這是幾個你會碰到的事情：
1）高延遲，因爲對數據的查詢將不得不往返於歐洲得到這個。
2）由於通常每個訪問數據庫的請求需要更長的時間，這會增加內存使用量，同時請求正在等待數據，這也會使應用程序的負載影響更嚴重。 3）跨區域數據出口，每次有查詢時，您需要爲所有從歐洲轉移到我們的數據支付費用。
一個更好的解決辦法是做到以下幾點：
1）建立一個新的數據庫在美國地區和掛鉤active geo-replication
在這一點上，你將有一個冷/熱配置，其中任何實例都可以用於從數據庫讀取數據，但只有主要實例可用於寫入操作。
2）在美國地區
3）適應你的代碼來了解你的地理分佈拓撲創建應用程序/應用服務計劃的新版本。
您的應用程序應該能夠將所有讀取發送到「最近」區域，並將所有讀取發送到主數據庫。
4）代碼部署到所有地區
5）新的區域添加到TM輪廓
雖然這不是理想的，因爲寫操作仍然可能要跳池塘，大多數應用程序有一個讀寫模式比對讀操作嚴重偏離（大概85％讀取/ 15％寫入），所以這種解決方案能夠解決您的問題，併爲您提供HA，以防其中一個區域出現故障。
您可能想要在look at this talk的地方瞭解如何使用App Service，SQL Azure和上述技術設置地理分佈式應用程序。
你有沒有考慮根據用戶的位置，分片你的數據？在性能方面它會更好，您可以在每個地區的非高峯時段提供維護。請允許我向您推薦this文章。
如果添加更多實例，CPU可能會關閉，在哪個區域無關緊要。美國地區可能會幫助延遲，但您仍然需要往返數據庫。你在美國考慮過翻閱嗎？ – Mikhail
@Mikhail你認爲在CPU利用率方面，處理器上數據庫成本的往返將比延遲更好嗎？我們已經達到了大量的實例。我們考慮了只讀副本，但我認爲這將爲每個應用程序添加兩個連接（讀/寫）並使編程複雜化。謝謝。 – Techy