規劃檔案上傳原本都只打算使用 Client 的方式處理,但從「應用情境」出發點評估後,還是把 Web 的方式追加到系統之中,當然續傳的機制必須是內建的。畢竟動輒上百 MB 到 G 的檔案中間掛掉要再重新全部上傳,不要說使用者了連我自已都受不了。
環境評估很重要,但每個系統都有自已的考量,這裡是從管理總成本切入,所以使用 Azure Blob 來承載相關的檔案,背後的擴充機制並不在這次的討論之中。
規劃檔案上傳原本都只打算使用 Client 的方式處理,但從「應用情境」出發點評估後,還是把 Web 的方式追加到系統之中,當然續傳的機制必須是內建的。畢竟動輒上百 MB 到 G 的檔案中間掛掉要再重新全部上傳,不要說使用者了連我自已都受不了。
環境評估很重要,但每個系統都有自已的考量,這裡是從管理總成本切入,所以使用 Azure Blob 來承載相關的檔案,背後的擴充機制並不在這次的討論之中。
Azure Diagnostics 1.0 是以前標準的 Log 機制並且內建於 Azure SDK 之中,自從 Azure SDK 2.4 / Diagnostics 1.3 之後就可以針對 Cloud Service / IaaS VM 外掛 EventSource。而且這兩種的佈署方式差異非常大,剛好系統同時有 Trace 和 EventSource ( by SLAB ) 的 Log 方式,因此打算一併統一成相同的機制並且使用未來主流支援的方式。
如同剛剛所提到的 1.0 直接內建於 Azure SDK ,因此有跟 Visual Studio 開發工具整合,直接在 Azure 專案中按右鍵就可以選擇啟用診斷。而 1.2 以後的版本則是要用 PowerShell 的方式套用規則和啟動,另外這兩個版本無法同時啟動。
希望花了很多天踢完的鐵板可以讓各位節省一些時間 :)
Azure Blob Upload 遇到的錯誤
Update 20160216 Azure Search 相關的連結都重新整併到 Github 去了,而且內容已經有改版了雖然變化不大但請自行對照
https://github.com/Azure/azure-content/blob/master/articles/search/search-get-started-dotnet.md