.NET Walker

Cloud Shell是雲端的CLI環境，你可以從Azure Portal上直接啟動該環境： 這麼做的好處是，你即便在本機電腦(筆電)上沒有安裝AZ CLI，也可以透過網頁即可以命令列模式來管理雲端的資源。 另外，使用雲端版本的CLI還有一些額外的好處，諸如: 無須登入(az login…)，因為你使用Cloud Shell的時候，本來就有登入Azure Portal。 無須安裝其餘CLI工具或SDK，諸如 git, dotnet , python, docker, kubectl…這些內建通通都有。甚至，還有網頁(陽春)版的VS Code!!! 底下影片介紹如何操作Cloud Shell，第一次進入的時候，會讓你選擇一個Azure 儲存體(Storage)，並且選擇Linux或Windows環境: 所以，Cloud Shell內建就有Windows與Linux雙模式，你可以透過左上角的選項切換: 其實，Cloud Shell本身就是一個儲存體，你可以在該環境中建立資料夾，新增檔案，除非你刪除或無法存取該訂閱，否則這些資源都會保留在雲端儲存體中： 一般來說，如果要對雲端的Azure資源進行操作，我們常常會直接在Cloud Shell中，下CLI或Power Shell/Bash指令，省去在用戶端還需要安裝 CLI 並且做 az login 動作的麻煩。 有操作Azure的開發或維運人員，是一定得要試試看這個好工具的。

在Azure Cognitive Services 服務當中，文字分析(Text Analysis)服務可以針對用戶上傳的文字進行剖析，例如『文字情緒分析』、『關鍵字詞擷取』、『文字摘要』…等。這些服務都以rest api的形式出現，你只需要先取得呼叫API所需的金鑰與端點即可。 底下影片展示如何從 Azure Portal 建立『文字分析服務』，並且找到金鑰與端點: 有了金鑰與端點後，就可以透過程式碼來呼叫其功能。 例如其中的『擷取文章摘要』，是文字分析服務中剛推出沒多久的新功能，可以針對一篇文章、一段文字，抓取其中的重點。 呼叫的endpoint如下: POST { Endpoint } /language/:analyze-text?api-version = 2022-10-01-preview 除了header要傳遞key(金鑰)之外，body要符合底下json格式: { "displayName" : "Document ext Summarization Task Example" , "analysisInput" : { "documents" : [ { "id" : "1" , "language" : "zh" , "text" : "(要分析的文章)" } ] } , "tasks" : [ { "kind" : "ExtractiveSummarization" , "taskName" : "Document Extractive Summarization Task 1" , "parameters" : { "sentenceCount" : 3 }

最近這幾年，愈來愈多的網站改以前後端完全分離的架構來開發，而微服務盛行，許多後端應用、AI服務、甚或是商業邏輯，都改以WebAPI的方式來實作，更別說為數眾多的手機行動裝置App也需要以呼叫後端API的方式與伺服器端溝通，來完成各種功能。 因此，API開發成為最近幾年的顯學，API First也在許多場合被提起。Azure的APIM服務，就在這樣的情況下誕生了。 使用APIM服務 Azure APIM可以幫我們把企業內部的多組API打散或重新包裝，改以同一個endpoint對外，好讓使用者更方便使用，讓管理者更方便控制與管理。 另外，採用APIM還有一個好處，我們可以隔開用戶和真正的API，這樣除了可以保護後端真正的API，也可以在用戶透過APIM呼叫後端真正的API前，可以對往來(與回覆)的數據做一些加工處理，已達成我們需要的安全性或是API行為的改變，也更容易統一的進行全縣控制…等。 建立APIM 底下影片示範如何建立APIM服務，請注意APIM服務的建立，會花比較長的時間，可能會長達半小時以上: 完成之後，就可以建立好APIM服務了。 建立API集合 建立好APIM服務之後，接著可以在Azure Portal中，建立API集合，前面說過，我們會把實際上開發好的API，先整理成API集合，然後再包裝成產品(Product)，釋出給客戶。 底下的說明，我們將示範如何將現有的API(在具備spec definition的狀況下)，整理成待會要釋出的產品。我們以底下這組微軟官方的測試API為例: https://conferenceapi.azurewebsites.net?format=json 如果你點選上面這個網址，會發現，它出現的是json格式的API規格: 這是標準的 swagger 2.0規則，一般我們撰寫WebAPI之類的後端API服務，都可以透過工具自動產生這些規格文件。若具備這些規格文件。 你可以直接將API透過Import的方式匯入，請看底下操作影片: 從上面的影片當中，你會看到，我們利用 swagger 的json規格定義，把上面的微軟測試API，重新透過APIM封裝，建立另出了一組 endpoint 。 你可以發現API中有一個 GetSpeakers 方法，當我們運行(呼叫)這個方法，會以JSON格式回傳

OCR(Optical Character Recognition)指的是識別圖片中的文字，如果你先前已經成功使用Computer Vision API做影像識別(Image Analysis)，那使用Computer Vision API做OCR肯定也難不倒你。 請參考同樣的文件: https://westus.dev.cognitive.microsoft.com/docs/services/computer-vision-v3-2/operations/56f91f2e778daf14a499f20d 你會發現，ORC的API與先前我們介紹過的影像分析幾乎一模一樣，唯一差別是要給定的endpoint URL，最後的結尾是『ocr』。設定如下: 另外，如果要辨識中文，建議要給定language這個queryString參數，值為『zh-Hant』。 有這些資訊就夠了，我們一樣透過postman來測試，關鍵的資訊如下: 關鍵資訊 值 endpoint https://你的endpoint.cognitiveservices.azure.com/vision/v3.2/ocr?language=zh-Hant Ocp-Apim-Subscription-Key(http Header) 你的key Http body {“url”:“要辨識的圖片url”} 透過這些，我們就可以嘗試辨識了。透過Rest API將要辨識的有像位置(url)傳遞過去，辨識的結果會以JSON回傳。 操作影片如下: 影片中，辨識的文件是底下這張圖: 該圖片的網址為: https://i.imgur.com/PWQDiRj.png 你也可以自行試試看，你會發現，中文的辨識度其實非常高，幾乎正確的辨識出每一組文字。 回傳的物件是JSON格式，由於圖片上的文字可能有橫有直，辨識出的結果會是以 Regions, Lines, Words, Text 為結構回傳: 透過 computer Vision 中的 ocr API，取得圖片上的文字變得非常輕鬆。 tags: 電子書 - Azure Cognitive Services

什麼是非關聯式資料庫? 最近這幾年，非關聯式資料庫開始成為許多大型系統的架構考慮之一，原因有很多，但歸根究底核心原因我覺得是『全球化』。 過去企業(即便是大型的全球化企業)在建立資訊系統的時候，大部分都是以集中式為主的架構，也就是說，核心的資料庫只會有一份，頂多加上異地備援機制。 在傳統的企業營運需求上，這樣的設計完全沒問題，而且關聯式資料庫的特性就是 ACID ，有著結構清晰的資料表，經過正規化，存入的資料欄位都是固定的，這確保了資料的高可靠性與正確性，對企業應用系統來說，恰是所需。 但對於全球化的網際網路需求，可就不一定了。 當前的關聯式資料庫儲存資料有幾種類型，像是底下這樣: 你發現，這些資料的結構跟過去方方正正的資料表很是不同，現實生活中，有很多類似這樣的資料，例如: 若我們想表達一位用戶的朋友、資源、行事曆、檔案…等資訊，結構上就很可能不是傳統關聯式資料表所能表達的，這時候非關連式資料庫就開始派上用場。 除此之外，另外一個主因是 --『同步一致性』。 資料的同步問題 在企業內，資料的一致性似乎很重要，但一致性並非沒有代價，假設資料庫採分散式架構，在全球3-5個點都有資料庫，彼此之間進行同步抄寫。 這樣的架構底下，要維持一致性是很困難的，這也是大部分企業應用都採集中式架構的原因，但集中式架構最大的缺點是，如果總部斷線，就意味著全球各地區都別運作了。 但真實世界中，我們真的需要在全球有數個彼此同步抄寫的資料庫嗎? 過去沒有，但現在可能到處都是，最明顯的例子就是像FB之類的社群網站。 社群網站每秒中有數以萬計的留言對話，可能同時需要存入資料庫，如果採用傳統的關聯式資料庫，又是集中式設計，很可能根本無法運作，因為資料庫的loading太大了，光寫入資料就沒時間了，更何況還要承擔全球性的讀取。 所以非常有可能採用全球數個資料庫彼此抄寫的狀況，但這時候，『資料同步』將是個問題。 我鍵入一筆留言，在台灣的資料中心可以即時看到並回應，但在地球另一端的資料庫中卻可能還沒出現，因此我在國外的友人會隔一段時間才看到(需要等資料抄寫過去)，然後他才能回應，同樣的當國外的友人回應，在台灣的我可能也不會立刻看到，而會延遲一段時間。 這就是分散式資料庫可能會碰到的問題。 這對於開發人員來說，是兩難。因為 集中式效率會變低，分散式會導致資料的精確性或

Computer Vision 是Azure Cognitive Services中，一組作影像識別辨識的API，功能強大，可以進行圖片內容(意義)的識別。也可以找出圖片中的人臉，並且判斷年紀、性別。還可以進行OCR，找出圖片中的文字…等，該服務的官方網站位於： https://learn.microsoft.com/zh-TW/azure/cognitive-services/computer-vision/ 申請使用金鑰 使用上很簡單，可透過SDK或Rest API來呼叫，由於我們要透過程式碼來呼叫使用該服務，因此得先從Azure平台上申請一組Key，並取得Rest API的Endpoint。 請參考影片中的操作： 上面的影片中，你看到我們申請好Computer Vision服務，並取得金鑰與端點的位置。 使用Rest API呼叫識別服務 取得金鑰與端點之後就好辦了，參考官方文件，你會明白如何呼叫，以及API的詳細使用說明。 簡單的說，我們可以把圖片上傳給剛才我們建立好的服務端點(endpoint)，然後雲端AI服務就幫我們辨識出圖片的結果(以JSON回傳)，而呼叫的時候，需要一個key，僅此而已。 我在上課時，會刻意帶學員從網上找到底下這分文件，並且整個看過一次: https://westus.dev.cognitive.microsoft.com/docs/services/computer-vision-v3-2/operations/56f91f2e778daf14a499f21b 因為呼叫方式雖然常常快速迭代改版，但其實Azure Cognitive Services中幾乎每一個服務都有清晰的文件，只要能找到並看懂文件，抓到重點，呼叫上非常方便。 底下影片介紹你如何在文件中找到幾個關鍵，例如呼叫的參數、呼叫時的http method，以及上傳檔案給endpoint的方法: 看懂文件，你應該知道如何透過rest api呼叫該服務了(使用SDK的方式以後再談)，接著，我們可以透過免費的postman工具，來嘗試呼叫該影像辨識服務。 postman是網路上免費可下載的 rest api呼叫測試工具，非常簡單好用。下載位置位於: https://www.postman.com/ 取得postman之後，就可以透過該工具，來

Cache被稱作快取或緩存，是一種提高運作效率的資料存取方式。 Redis Cache本身是一套open source軟體，以記憶體作為緩存資料的位置，我們可以把一些時常(或大量)需要被讀取，或是不常更新的靜態資料，從傳統資料庫(或其他儲存體)複製一份放入Cache DB中，以便於提高讀取時的效能。 因為資料庫或一般硬碟儲存體的讀寫是物理性的IO存取，而Redis Cache則是記憶體的讀取，當有大量的讀取發生時，位於記憶體的Redis Cache效能會明顯的比實體的讀取提高很多。 一般來說，典型的Cache機制使用方式如下: Cache中的資料可能會定時或依照你所設定的條件更新，以便於抓取較新版的資訊。 在Azure PaaS平台上，也有現成的Redis Cache服務，你可以透過底下CLI指令來建立Azure Redis Cache服務: #設定資料中心區域 $myLocation = "eastasia" #建立資源群組 az group create -n test-redisdemo-rg -l $myLocation #設定redis cache名稱(取亂數以避免重複) $redisname = "testredis" + $( get-random -minimum 10000 -maximum 100000 ) #建立redis cache az redis create -l $myLocation -g test-redisdemo-rg -n $redisname --sku Basic --vm-size c0 結果如下(回覆JSON): 當然，也可以透過底下網址，從Azure Portal建立Redis Cache: https://portal.azure.com/#create/Microsoft.Cache 建立畫面如下: 建立完成之後，基本的使用就很簡單，你只需要從Portal上找到 Redis服務的 ConnectionString(位於存取金鑰)，即可操作該Cache: 有了ConnectionString後，利用SDK，透過ConnectionMultiplexer.Connect()方法，即可存取該料庫: var cache

Storage Queue是相對Service Bus而言較為簡單便宜的queue解決方案，以Storage為儲存體，在Storage中就可以直接建立: 透過程式碼操作的方式也很簡單，先找到key: 接著透過SDK，建立一個QueueClient物件即可操作: public static void CreateQueueClient ( string queueName ) { // Get the connection string from app settings string connectionString = ConfigurationManager . AppSettings [ "StorageConnectionString" ] ; // Instantiate a QueueClient which will be used to create and manipulate the queue QueueClient queueClient = new QueueClient ( connectionString , queueName ) ; } 請注意上面的程式碼使用了 Azure.Storage.Queues 套件，因此你必須從nuget安裝: dotnet add package Azure.Storage.Queues 我在github上有一個範例，讀者可以在建立好queue之後，透過git clone下載該範例運行: git clone https://github.com/isdaviddong/az204-DemoAzureStorageQueue.git 運行的流程請看底下展示影片: 身為一個簡簡單單的FIFO容器，Queue看起來沒啥大錄用，不過就是放放資料讓資料排隊慢慢處理，但記得前面提過的 Load Leveling嗎: (from Microsoft architecture center) 如果用的好，Queue可以幫你省下大筆 做 scale out的經費呢，總有人覺得雲端貴，但其實，往往

古時候的應用程式，大多是一座孤島，作業系統載入一個應用程式(例如計算薪資)，當它運行完畢，結束，就退出作業系統，釋放資源，把控制權交出來。當時的應用程式架構很簡單，就…把功能通通寫在一起，完畢。 時間快轉到今年，過去就表過不提，自從有了網路(特別是網際網路)之後，應用程式的架構開始愈來愈複雜。例如，現在很多Web應用程式是前後端分離的架構，後端採用Restful API，前端運行在瀏覽器上，透過javaScript(或某種js框架)，與後端Restful API互動，彼此交互以完成一個工作。 這是近代初學者，最常碰到的應用程式架構。 但當應用程式的功能愈來愈多，我們當然不可能(也不需要)在『一個』應用程式當中，一口氣去完成所有功能，我們可以把應用程式切小，然後透過應用程式和應用程式之間的合作，來完成一個比較大的任務，這時候，擔任應用程式與應用程式之間資訊傳遞橋梁的事件(event)和訊息(message)就顯得非常重要了。 事件(Event)和訊息(Message)的意義 在這一篇的討論當中，你看到的『事件』和『訊息』這兩個字眼，大多意味著某種資訊 --> 像是一組JSON資料、一個文檔、或是一個XML資訊、甚至，只是幾個bytes的字串。 總的來說，『事件和訊息』就是 應用程式A 傳遞給 應用程式B 的某種資訊，主要的用途是 溝通 。例如用戶在前端網頁上購物，產生了一筆訂單，這筆『訂單』就是一個訊息，Web的前台系統，會把這個訂單，傳遞給中台或後台的其他程式，來處理出貨、扣庫存、帳務處理…等動作(功能)。 你或許有一個疑問，為何不在前台網站系統用戶產生訂單的那一刻，就扣庫存和安排出貨呢? 技術上可以，但實務上常常不是這樣的。因為不是所有的系統都是一體的，企業的系統可能是分階段、分廠商開發的，甚至可能根本是外購不同廠商不同開發技術的系統拼裝起來的，所以系統和系統之間的溝通，並不一定會發生在同一個資料庫裏面。而且這麼設計，會把系統個體之間的相依性綁得太緊，導致以後牽一髮動全身。如果我們把每一個功能(購物網站、訂單、出貨、庫存、發票…等)都設計成獨立的系統，有各自獨立的資料庫(儲存體或資料表)，也都可以獨立運行，那在架構設計上，將會更加彈性和靈活(其實這也導致後來逐漸成形的微服務概念)。而這樣的設計，就會導致系統和系統之間，需要透過『訊息或事件』來

Service Bus中文叫做服務匯流排，在使用 Service Bus 前，請先透過底下方式建立: 建立好 service bus 後，接著我們就可以透過程式碼來操作，昨天的文章中，我們提過可以透過 service bus 中的 queue機制，來做 load leveling 架構。至於如何存取 service bus, 我有參考az-204課程，寫好一個範例程式碼，位於github，你可以透過底下指令來下載: git clone https://github.com/isdaviddong/az204-ServiceBusLab.git 從 github上clone我寫好的範例之後，你可以替換其中的連線字串，並且透過azure portal在service bus中建立名稱為『az204-queue』的 queue，即可執行該範例進行測試: 從上面的展示中你可以看到，我們透過兩個console app，一個作為訊息(message)的發送方，一個作為接收方，成功地透過service bus的queue來傳遞訊息與溝通。 如此一來，你就可以實現先前我們介紹過的 queue-based load leveling等機制。

Feature Toggle有很多名稱，也常被叫做 Feature Flag, Feature Switch…但不管他叫什麼名字，都無損他在這個時代的重要性。 為什麼重要? 他為這個時代所面對的問題，提供了適當的解決方案，這些問題包含: 實現A/B測試 實踐金絲雀佈署 實踐高強度的頻繁交付 實踐不同環境上的自動化佈署 … 乍看之下，上面這幾件事情都跟Feature Toggle無關，但實則有很大的關連性。在說明前，我們先理解一下 Feature Toggle 是甚麼? Feature Toggle的建立 他是一個後台控制的開關，與我們的程式碼有所連動，簡單的說，就是在我們的程式中，加上一些簡單的if…then判斷敘述，然後依照這個開關在後台所設定的on或off，來決定是否要執行(啟用)某個功能。 這麼簡單的機制，為何和自動化佈署有關? 又為何可以幫助我們實踐 A/B 測試? 先談『高強度的頻繁交付』，以及『在不同環境上實現自動化佈署』這件事。 如果你對CI/CD或敏捷開發有概念，大概能夠理解近代軟體開發都希望能夠頻繁交付，頻繁的程度因團隊而異，高強度的頻繁交付，可能需要一天更版數次，而無論是一天更版數次，或是一周交付數次，都意味著開發團隊很可能每天多次合併程式碼，在這種狀況下，程式碼版控的多分支方案(例如gitflow)將變得不可行，而會慢慢收斂成單一分支(feature branch)或根本沒有分支的狀態，在這種狀況下，程式碼的整合和交付將可以變得非常頻繁。 但衍生出一個副作用，就是在這個狀況下，開發到一半的功能怎麼辦? 如果團隊需要急著修復用戶反饋的某一個bug, 必須立刻整合上版，但卻又同時需要等某幾個功能都做完，才能一次上線，這就產生了矛盾。 這時，feature toggle就會派上用場，它可以幫我們在正式環境上，先關掉不想開放的功能，等幾個具有相依性的功能都完成，再從後台一次打開開關放行。 這就是feature toggle在近代敏捷開發與CI/CD潮流下，非常重要的原因，因為它有效的分離了釋出(Release)與(Deployment)。 可以實現佈署(Deployment)，但不開放(Release)功能的效果。 配合A/B測試 與 金絲雀佈署 你可能有聽過 A/B Testing，它指的是，我們會在p

不是所有東西都要寫程式的。 最近幾年，又開始流行No Code/Low Code Solutions，RPA(Robotic Process Automation, 機器人流程自動化)就是其中之一。 微軟在SaaS和PaaS平台都有相關的服務，M365的SaaS平台中，Power Automate就是RPA解決方案，可以讓power user用拖曳設計的方式，撰寫少量或幾乎不用撰寫程式碼，就可以完成一些自動化流程。 而PaaS平台上，就是Azure Portal中的 Logic App 。 什麼是Logic App 技術人員可以把透過Logic App，用拖拉組合的方式，把一個流程設計出來，定時或在特定事件發生時，觸發後續的一連串動作。例如，當用戶把檔案上傳到 OneDrive，就自動進行圖像的人臉辨識，然後把辨識結果發送mail給特定人，如今這樣的流程，你完全不需要寫一行程式碼即可以完成。 透過這樣的方式，你可以大幅的簡化人工作業流程，乍聽之下，它跟Azure Functions, Power Automate都很像，但還是有些差異，Azure Functions雖然有binding功能，但主要還是透過撰寫function code來進行核心邏輯的處理，而Power Automate比起Logic App則比較偏向於End-User用戶端，Logic Apps中的connector和trigger則比較偏向雲端服務的整合。 具體差異可以參考微軟官方文件『 Logic Apps、Functions、WebJobs 和 Power Automate 之間做選擇 』 建立Logic App服務 當你建立好一個Logic App服務之後，緊接著可以建立工作流程，底下影片展是如何在 Azure Portal 上 建立一個Logic App服務: 建立與使用Logic App自動化流程 建立好了服務之後，我們接著就可以建立一個流程，建立的過程中，我們需要選定 trigger 也就是觸發條件。 請看底下的例子，我們在用戶上傳檔案到 onedrive 的時候，觸發流程，然後透過 outlook connector 來進行後續的自動化動作，將上傳的檔案名稱與路徑寫入mail中發送給特定用戶: 從上面的設計展示影片中你可以看到，onedrive conn

應用程式大致都會有環境變數，一般來說，我們在做網站時，除了把環境變數或是資料庫連線字串…等這些設定資訊，存放在 WebApp 的 App Config(組態設定)中，我們還有幾種不同的選擇。 Azure上獨立的App Config服務就是其中之一，中文名稱叫做『應用程式組態』。 建立『應用程式組態』服務 你可以透過 Azure Portal 建立該服務: 比起一般的config服務，從上面影片建立該服務的過程中，你也看到了，它額外具備了雲端特有的『異地備援』、『虛刪除』…等功能，讓資訊的保存更加安全可靠。 此外，它除了組態總管(Configuration Explorer)，還有功能管理員(Feature Management): 你只需要透過端點(endpoint)與金鑰匙(Key)就可以存取該服務。當然，存取的過程中，需要建立類似資料庫的連線字串: 保存在該服務裡的組態資料，都是以 key-valut pair 的形式被建立的，你可以透過組態總管來建立: 撰寫程式碼抓取config資訊 建立好組態資料，接著就是在程式碼中存取。要在程式碼當中抓取存放於雲端的config資料，也相當容易，我們嘗試建立一個console app來測試: md testappconfig cd testappconfig dotnet new console dotnet add package Microsoft.Extensions.Configuration.AzureAppConfiguration code . 上面這幾行CLI指令，會建立出一個 console application，並從NuGet引用’Microsoft.Extensions.Configuration.AzureAppConfiguration’套件。 然後，我們透過VS Code 開啟該專案，並且撰寫底下程式碼: using System ; using Microsoft . Extensions . Configuration ; using Microsoft . Extensions . Configuration . AzureAppConfiguration ; namespace appConfigTest { class

無論是實踐單一登入(SSO)所需要的身分驗證，或是採用OAuth機制，讓用戶授權第三方應用程式來存取受管理的資源，都會從『建立一個應用程式』開始。 Google, 微軟, Twitter, LINE…都有自己的OAuth機制。Google 位於API Console, 微軟位於Azure AD，而LINE 則是使用LINE Login…這也是你常常會看到現在許多網站都有支援各種SSO身分驗證機制的原因: 在Azure AD註冊應用程式 底下我們以微軟的身分驗證機制，拿Web類型的第三方應用程式來做例子，這段影片，示範了如何在Azure AD上建立一個應用程式: 從上面的展示，你會看到我們在Azure Portal上建立好一個 App, 並設定Redirect URL，並取得App ID。建立時，身分驗證類型有四種: 分別是: A. 企業用，只支援該AAD所屬企業 B. 企業用，支援所有具有AAD的企業 C. 企業(to B)+個人(to C)，上述B加上個人帳號( 例如hotmail.com , outlook.com , msn.com …等) D. 僅限個人帳號登入，例如 hotmail.com , outlook.com , msn.com …等 接著，我們要建立並取得待會Web應用程式需要進行身分驗證時，所需要的 App Secret: 另外別忘了，再次檢查設定好的redirect URL，測試階段我們先用 localhost: 完成之後，我們就可以來測試一下，如何使用OAuth的身分驗證機制來取得access token。 OAuth Authorization Code Flow 依照OAuth的Authorization code flow流程，我們的作業流程分成兩個階段， A> 第一個階段我們做身分驗證，並取得代碼(code)， B> 第二階段再拿code去跟伺服器端要access token。 第一階段，我們需要提供底下這些資訊(剛才都已經蒐集到): App Clinet ID redirect URL 微軟AAD使用的 endpoint 為: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?respon

Azure Storage 是 Azure中主要的儲存體，擔任一切儲存的任務。Azure Storage本身具有四種不同的存儲形式，分別是: Files 可模擬SMB檔愛存取機制，類似雲端硬碟。 Blobs 適合存取各種檔案，類如影片、圖檔、文件、logs…etc. Tables NoSQL形式的資料儲存體。 Queue FIFO(先進先出的佇列儲存體) 典型的Storage durability形式有底下幾種: LRS(本地備援儲存體) - 單一資料中心內備援三份 ZRS(區域備援儲存體) - 將資料同步複寫至三個不同的區域。每個區域具備獨立的電源、冷卻和網路的不同實體位置 GRS(異地備援儲存體 - 基於LRS，再將資料以非同步方式複製到位於數百英哩外的另一個位置，實現真正的 異地 備援。 RA-GRS - 基於GRS加上可從異地支援讀取功能。 底下影片示範如何建立azure storage，並且建立一個 container，以及上傳檔案(blob)到container中。觀察影片中的操作，你會發現，當我們把 container的存取權限調整之後，blob檔案的URL就可以存取了，否則會變成找不到上傳的檔案: Container 的 匿名存取層級有三種: 無公用讀取權限︰只能讓有授權的用戶存取容器及其 Blob檔案。(此選項是預設值) 僅對 Blob 有公用讀取權限：您可以透過匿名要求讀取容器內的 Blob，但您無法匿名使用容器資料。 匿名用戶無法得知容器中有哪些blob檔案。 容器及其 Blob 的公用讀取存取權限：匿名要求可以讀取該容器中所有 Blob 檔案，也可以列出容器中有哪些blob檔案。 Shared Access Signature (SAS) 針對特定的 blob 檔案，可以產生具有SAS(簽章)的連結，可讓特定IP在特定時間內，存取該blob檔案。 產生SAS簽章的方式如下: 透過具有簽章的連結，可以在特定時間區間內，從特定的IP位置存取該blob檔案，是控制權限很好的方式。 參考資料: https://learn.microsoft.com/zh-tw/azure/storage/common/storage-redundancy