Azure Web App的Scale Up、Scale Oute功能

作者： -

最近幾年高併發流量的網站需求快要變成開發/維運人員的日常。在過去我們小時候的那個年代，大抵不會有網站需要面對瞬間高流量的存取要求，而是大部分的流量是可以預估的。

但近年來，由於服務全球化的趨勢，網站常常要面對從國內外全球而來的用戶，加上幾乎每一個用戶都有手機、平板、PC…等各種不同的連線設備，只消隨便舉辦一個網路活動，或是出現一個網路新聞事件，又或者類似搶票之類的需求，流量的瞬間高峰就很容易出現。

這時，該如何讓網站能夠瞬間達成負載平衡? 或是讓網站能夠不停機(zero-downtime)即刻升級，以因應瞬間出現的流量? 快速的Scale up與Scale out就是我們需要的解決方案。

什麼是 Scale up 與 Scale out

Scale up指的是讓網站的伺服器本體的檔次升級，例如4G的RAM升級成8G的RAM，2核的CPU升級成4核的CPU…

Scale out指的則是伺服器的水平擴展，在流量出現的時候，把原本的一台伺服器，擴展成兩台、四台、八台…等，如此一來，就可以分散流量，也可以實現fail-over(當某台伺服器發生問題時，由其他伺服器接手流量) :

進行 Scale up

在azure web app中，要實現 Scale Up/Down功能，只需要在管理後台設定即可，瞬間完成:

進行 Scale out

S1以上等級的WebApp 就可以進行 Scale out，同樣是簡單的設定即可：

你可能會發現，才幾秒鐘的時間，五台伺服器就瞬間出現，Web App內建的負載平衡器，會幫我們自動導流的動作。

除了手動設定之外，其實還有Auto Scale功能，這讓我們可以透過建立設定檔，在高峰出現(例如CPU使用率、IO、流量增加…)的時候，自動化的進行Scale Out動作，在流量降低時，再自動還原，以降低成本。

請注意，Scale動作是以整個 App Service Plan為單位的。如果在相同的App Service Plan中有多個Web Site，將會被一起Scale唷

留言

張貼留言

這個網誌中的熱門文章

原來使用 .net 寫個 MCP Server 如此簡單

作者： -
圖片
MCP 的重要性與意義 MCP 的重要性在於它建立了一個標準化的架構，讓開發者能夠快速建構出給 AI Agent 呼叫的各種功能。 舉例來說，假設我們希望實現一個 可以透過自然語言對談的請假功能 ，傳統上我們必須建立一個前端 Chat Bot 作為 UI、還得撰寫後端 API、資料驗證邏輯、資料庫存取介面…等，另外還要設計 Chat Bot 的對話邏輯，才能把請假功能整合到Chat Bot的對談訊息中。 但在 MCP 的架構下，這樣的流程可以大幅簡化。 開發者只需要實作幾個「請假功能」的介面（Tool Interface），接著定義好運行這個功能需要輸入哪些參數（例如請假人、開始時間、代理人、事由…etc.），並透過 JSON 來描述這些參數的格式與驗證邏輯。接著，AI Agent 便可以在對話過程中，自動根據對談前後文理解使用者意圖，挑選出適合的Tool來運行，主動發出呼叫的請求。如此一來，大幅簡化了AI Agent開發的難度。(本質上就是 Function Calling 的概念) 而 .net 又把這個難度降低到人人可以開發的程度，底下是一個使用 .net 開發的 請假功能 MCP Server，並且使用 GitHub Copilot來呼叫的例子： 其實我之前用 Semantic Kernel做個類似的範例，只是如今 .net 讓它變得更簡單，而且輕易地可以透過MCP架構讓不同的 MCP Client端呼叫使用。 如何用 .NET 撰寫 MCP Server 要使用 .NET 撰寫 MCP Server 非常簡單，受益於 Microsoft.Extensions.Hosting 和 ModelContextProtocol 套件，我們可以在幾分鐘內輕鬆地實作 MCP Tool 和 MCP Server 。 以下是MCP Server的完整程式碼： using Microsoft . Extensions . DependencyInjection ; using Microsoft . Extensions . Hosting ; using Microsoft . Extensions . Logging ; using ModelContextProtocol . Server ; using System ...
Read more »

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

原來使用 .net 寫個 MCP Client 也如此簡單

作者： -
圖片
之前我發了一篇文章，標題是「原來使用 .NET 寫一個 MCP Server 如此簡單」。結果有不少朋友留言敲碗，說：「只有 Server，沒有 Client，這怎麼行？」 呃…我只能說，這個要求顯然 很有道理 。🙄 所以今天趁上課的空檔，補一篇文，來介紹如何撰寫 MCP Client ，把整個架構補齊。 你會發現，其實，開發 MCP Client 也非常簡單耶。 MCP 架構的本質 不過，在開始之前，有一個觀念需要釐清：無論是 MCP Server 或 MCP Client，其實都與 LLM（大型語言模型）沒有 直接關聯 ，這和很多人理解的不同。 MCP 架構的本質，只是為了讓 AI Agent（或 Chat Bot）更容易知道怎麼呼叫外部的服務提供者(就叫做MCP Server)，並且能方便地列舉出這些服務所提供的功能(就叫做MCP Server Tool)，以及清楚了解每個功能呼叫時所需的參數。某種程度上，它的角色有點類似早期 Web Service 時代的 WSDL/SOAP ，或是現代 REST API 架構中的 Swagger/OpenAPI 👉👉 都是用來提供一種 標準化的服務描述與呼叫方式 ，使服務整合變得更一致、更具可預測性。 至於， 什麼時候該呼叫哪一個功能 、呼叫時所要填入的具體參數 值 是什麼，這些判斷與決策的工作，才是由 AI(LLM) 來處理的。而真正去執行這些呼叫動作的，則是 AI Agent(或者稱之為，MCP Host)。 簡單的說就是，對談機器人(或AI Agent)可以藉由 LLM 來呼叫遠端的服務，而 MCP 架構則讓對談機器人可以得知有哪些服務可供呼叫，並且在呼叫時應該要傳入哪些參數。 因此，要開發一個能夠呼叫 MCP Server 服務的 Client 端，自然也需要建立一個具備決策與執行能力的 AI Agent。 這部分，我們待會會採用 Semantic Kernel 作為實作的基礎框架。 之前我們 早已介紹過 Semantic Kernel ，它不僅可以介接各種 大語言模型（像是 OpenAI 或 Azure OpenAI），還能彈性地設計與掛上各種 skills 與 plugins ，非常適合用來打造具備「對談 → 意圖理解 → 功能選擇 → 發出呼叫」這一整套流程的AI Agen...
Read more »

使用 Dify 建立企業請假機器人

作者： -
圖片
八卦與未來 上個月，前Google執行長Eric Schmidt在史丹福有場演講，媒體關注的是八卦消息(如果你也曾關注，網路上有很多鐵定可以找到)，但我注意到的則是他提到了自己認為接下來 AI(特別是大語言模型) 可能的發展方向，包含: Large Context Window AI Agent Text-to-Action 底下這邊有這一個段落的影片： https://www.youtube.com/watch?v=zl3k1ksFZdY 為何我會關注這部分? 因為上述的三個方向，也是身為開發人員的我，過去這一年，來與LLM打交道後的感想。昨天，我在 twMVC 的研討會分享中，展示了一個其實我過去早做過了N百次的範例，就是企業的請假機器人。(唯一不同的是，這次我幾乎沒有寫任何程式碼) 場景是，員工在家裡生病了，想要透過語音或是app進行請假，你可以看底下這個運行的範例 (git圖檔會循環播放，開始是 『我好像感冒了』)： 用自然語言對談的方式，即可完成請假。 我說過，類似這樣的範例我做過很多次，用 LINE Bot 搭配 C# 做過，用MS Bot Framework 做過，前陣子也用 Semantic Kernel 框架做過，更早期，還沒有AI的時代，我也在EIP和HR系統裡做過。 但我想說的是，這 就是 Text-to-Action 的呈現，也是一個典型的 AI Agent 的例子，它讓我們透過自然語言(可以是語音或文字)，直接命令機器人(Chat Bot、AI 助理、Agent、Assistant …不管你叫它什麼…)幫你完成一件事情(請假、售票、查詢資料、做財務報表、統計圖表、寫程式…etc.)。 這是一直以來人類對電腦最底層的需求與期待。 隨著 LLM 能夠處理和記憶的 Context 愈來愈被放大，AI Agent 所能夠處理的任務就更加的不受限制。 自然語言才是最符合人類直覺的操作 順帶一提，我昨天在研討會中講了一個故事。 有天，你覺得自己需要聘請一位助理，因此上網張貼徵人啟事，沒多久，你找到了一位號稱上知天文、下知地理的高材生，來幫助你更有效率的完成工作。 他什麼都好，唯一的一個小缺點是，你不能直接對這個助理下達指令，你必須用一種只有這個助理看得懂的語法，才能要求這個助理幫你完成特定的工作。這些語法還挺...
Read more »