2019ironman 10th – Everything on Azure – Day15 – 常用服務 3.Web service-(7)

分享

Day15 - 常用服務 3.Web service-(7)

建置流程

06

今天來談『app service 方案』的功能上最關鍵的相應增加以及相應放大

很多人會問說 這功能不是在『app service』上嗎?

這也沒錯

但是『app service』中看到的相應增加以及相應放大其實是連結到『app service 方案』

因為這兩個功能是硬體層

如果您的『app service 方案』上有10個『app service』

只要更改其中一個的相應增加所有的設定就會一並更改

所以直接從『app service 方案』上面改才是正途

相應增加 (App Service 方案)

這邊用來修改主機大小以及附加功能

這邊要注意的是類型別選越高越好

會非常貴

基本上使用服務就是夠用就好

如果有時候需要比較大的資源用相應放大就好

相應放大 (App Service 方案)

這邊只要是生產環境的類型就可以啟動自動擴擴展(S跟P系列)

啟動後如下圖

使用者就可以依使用量來設定自動調整

這邊通常都不是一次就可以抓準參數

基本上60-80%加主機30-40%減主機

這樣都不會錯

Read more

雲端架構延遲問題:為什麼AP與DB不能放太遠?

雲端與地端的架構差異認知不足導致的性能陷阱 前言 許多企業在上雲初期,經常基於成本考量或錯誤認知,將應用程式伺服器(AP)與資料庫(DB)部署在不同區域。這種做法在地端環境中影響較小,但在雲端環境中卻會造成嚴重的性能問題。本文透過台北-東京的實際案例,說明距離對雲端架構的致命影響。 核心問題: * 地端思維:同個機房內不同區域延遲可忽略 * 雲端現實:跨區域延遲可達數十毫秒 * 結果:連線建立時間從毫秒級暴增到秒級 1. 地端 vs 雲端的延遲差異 1.1 地端環境的延遲特性 傳統地端機房: 同機房不同機櫃:RTT < 1ms 同城市不同機房:RTT < 5ms 同國家不同城市:RTT < 20ms 地端架構師的經驗: * AP和DB分別放在不同機櫃:幾乎無延遲影響 * 災備機房放在不同城市:RTT約10-15ms,可接受 * 習慣性認為「網路延遲不是問題」

By Albert Yu