如何評估並將現有的 ASP.NET 網站上至雲端 - [Azure Web App]

前言
先前有一個客戶想要將現有的公司內部的 ASP.NET 網站佈上 Azure 的 Web App ，他們希望我能夠提供諮詢與協助，本篇文章是將這個網站轉換並放置到 Azure Web App 的經驗分享。

 

現有環境

  • Windows Server 2008 R2 ==> 顧名思義 執行在 IIS 7.5
  • ASP.NET WebForm 網站
  • .NET Framework 4.0
  • MS SQL Server 2008 R2

 

評估現有網站是否可以上雲端
看到上方的「現有環境」，相信讀者應該也注意到了這是一個 ASP.NET WebForm 所開發的網頁應用程式，但事實上移植到 Azure 並沒有差別，因為 Azure WebApp 也是提供 IIS 包含一個 AppPool 的執行個體，好比你在地端的 IIS 上開一個 IIS AppPool 來執行應用程式一樣沒什麼差別！

 

但是在 PaaS 上執行還是有一些限制存在，一般來說，要評估一個現有的網站是否可以上至雲端，我們會透過以下幾點來評估：

  • Web Apps 僅支援連接埠 80 (適用於 HTTP) 和連接埠 443 (適用於 HTTPS 流量)的繫結，系統將會忽略不同的連接埠組態，並將流量路由傳送至 80 或 443
  • Web Apps 預設支援匿名驗證以及應用程式所指定的表單驗證 只有與 Azure Active Directory 和 ADFS 整合，才能使用 Windows 驗證，目前不支援所有其他形式的驗證 (例如基本驗證)
  • Web Apps 不支援全域組件快取GAC，如果您的應用程式會參考部署至 GAC 的組件，就必須部署至 Web Apps 上的應用程式 bin 資料夾
  • Web Apps 不支援 IIS5 以前的相容性模式
  • 應用程式集區 - 在 Web Apps 中，每個網站及其子應用程式都在相同的應用程式集區中執行
  • 如果您的網站上有多個利用多個應用程式集區(AppPool)的子應用程式，請將它們彙總到具有通用設定的單一應用程式集區，或將每個應用程式移轉至個別的 Web 應用程式
  • Web Apps 不允許在平台上註冊 COM 元件，如果您的網站或應用程式使用任何 COM 元件，您必須以 Managed 程式碼予以重新撰寫，並與網站或應用程式一起部署這些元件
  • Web App 為了高可用性 HA (High Availability) 與附載平衡 (Load-Balances)，因此，不支援 SessionState，如果您有使用到請考慮將 Session 存放至 SQL Database 或是 Redis Cache 中
  • 在 WebApp 上，若你需要上傳檔案至檔案系統，請務必使用 Storage/Blob 來存放，而不是使用 WebApp (VM) 本身的儲存體，因為儲存體的資料會因為動態配置時被刪除或消失

 

應用程式要上 Azure Web App，除了排除前面的已知的注意事項、與定價資訊(評估)外，需要上 PaaS 的項目部分，我們得要分以下幾個來看：
1. ASP.NET Website
2. (應用程式/網站) 所使用的 MS SQL Server 也需要上 Azure SQL Database
3. ASP.NET Website 的 Session 導向 SQL Database 或 Redis Cache 中
     A. 如果要導向 Redis Cache 中，那麼根據目前網站的使用者數、每一個 Session 工作階段所使用的量來評估的話，最少得使用 C1 標準 定價等級的 Redis Cache
4. 原有的 ASP.NET 網站若有檔案上傳 (FileUpload) 的部分，這得要再開一個 儲存體帳戶 來存放上傳的檔案，因此也得要將這個 Storage 成本估算進來。
5. 如果網站需要走 SSL 也要將憑證的租用費用算進來
6. 多少使用者、平均用量 (頻寬／價格)

 

作業開始
以下開始進行上雲端的作業，首先，評估的項目是，因為可能要將 Session 導向至 Redis Cache 中，但 Microsoft.Web.RedisSessionProvider 如果要使用叢集，官方建議使用 2.0.1 或更高版本，否則會擲回例外狀況，但這樣可能需要使用 .NET 4.6 的執行環境會較理想，但是現有的網站是 .NET 4.0，所以勢必要升級。

 

而升級，我們會面臨到幾個挑戰，如下方我們一個個來談：

1. Entity Framework 4.0 升級到 5.x 以上

在 Entity Framework 4.x 之前的版本使用的是 「擴充功能」裡的 System.Data.Entity.DLL 提供的實體物件功能，但這從 5.x 開始改由  NuGet 提供，所以這個問題稍微棘手一點，因為該舊網站使用的是 Entity Framework 4.0 而且使用的還是 Model Designer from existing Database

 

在我們改使用 NuGet 安裝 Entity Framework 且升級到  6.1.3 之後，馬上編譯就會發生錯誤如下：

因為原本的 ObjectContext 定義在 System.Data.Objects 中，且在 System.Data.Entity.DLL 這顆組件中，但 5.x/6.x 是定義在 EntityFramework.DLL 這個組件中，且命名空間更換到 System.Data.Entity.Core.Objects 裡。解決方式也很容易，首先，移除掉 「System.Data.Entity」、「System.Data.Objects」、「System.Data.Objects.DataClasses」這三個命名空間，如下：

這時候按下 快速鍵 Shift+alt+F10 小燈泡就會自動列出可以引用的項目。

剩下的 [assembly: EdmSchemaAttributes()] 使用 IDE 工具幫我們找回應該要 using 的命名空間即可。

 

注意：

您也可以改寫為 DbContext，從 Entity Framework 5.x 開始改以 DbContext 取代 ObjectContext，DbContext 是 ObjectContext 的輕量版，比較適合套用 Repository Pattern 樣式來實作 Data Access Layer，詳細的比較可以參考 Stackoverflow 上的解釋「ObjectContext vs DbContext」

 

2. 更新 AjaxControlToolKit

這部分比較沒什麼問題，原先所使用的 AjaxControlToolKit 是 4.1.51116，且不是由 NuGet 安裝，是自行下載參考進來的，這部分還好 NuGet Market 上還可以找到 4.1.51116

 

到這裡，初步可以在開發環境先測試使用 Entity Framework 6.1.3 與 執行原本的 CRUD 是無問題，以及驗證 AjaxControlToolKit 在 .NET Framework 4.6 下所有 WebControls 的執行是否如預期，可搭配一些自動化測試工具，如：Selenium。

 

開始上雲端

如果驗證無誤，由於應用程式本身使用到 Session，前面提到客戶希望此應用程式使用 Redis Cache 來存放 Session，現在我們要開始安裝 Microsoft.Web.RedisSessionStateProvider

接著是調整 Web.Config 中的 <sessionState> 區段，將 mode 調整為 “custom”，並定義 customProvider，如下：

assessKey 以及連線字串中的 password 可由 Azure Portal 中取得。

 

資料庫也要上雲端 (PaaS 服務的 SQL Database)

當然，我們得先建立一個 SQL Database 服務，建立方式筆者就不再熬述，可參考 Microsoft Docs 「

在 Azure 入口網站中建立和查詢單一 Azure SQL Database」 的說明。

 

在 SQL Database 建立完成之後，接著就是將現有地端的 MSSQL Database 匯出來，可使用命令列工具 BACPAC 工具匯出，或是使用 SSMS 工具執行匯出，筆者這裡採用 BACPAC 工具匯出。

匯出方式如下：

不過在執行匯出時，如果你的 Store Procedure 的撰寫方式如果是 [DBName].[dbo].[TableName] 方式是不會過的，原因很減單，因為 SQL Database 本來就不支援跨 DB 的寫法，因為他只是提供單一 Instance 給你。

 

匯入方式如下圖：

 

註：

BACPAC 命令列語法可參照官方說明「SqlPackage.exe 說明」

 

在前棉的步驟都完成之後，我們可以將這個 ASP.NET WebForm 的應用程式發佈到 Azure WebApp 上 （發佈到 Azure WebApp 上可參考：Publish the App to Azure WebApp 這類說明官方都非常完整，筆者就不再熬述）

 

開始測試

萬事俱備後，緊張的時刻來了，希望執行時不要掛掉 XD，不過事實上，總是事與願違，一執行隨即收到錯誤訊息…..

根據錯誤訊息可以推斷是有物件 Class 並未標記為 [Serializable] 導致無法序列化並儲存到 Redis Cache 中，於是立馬執行簡單的 Code-Review 作業，搜尋所有程式碼裡面有使用到 Session 的部分，並確認都加上 [Serializable]，但重新發佈後在測試還是相同的結果，案情這時候陷入膠著…………

 

於是，唯一作法就是先寫 Log 吧！重新發佈程式後，再由 Log 去查看問題出在什麼地方？

後來在 Log 中發現，在將 SecurityLevel 物件塞入時發生這個 Exception，詳細查看這個 SecurityLevel 類別後發現，他的屬性 Property 裡面居然有一個父類型是 System.Web.UI.Page 類型的物件，疑！這不是 Web Page 的型態，這就搞笑了，倒底是誰把 Web Page 塞到 Session 裡？（怒～翻桌）… 這當然會序列化失敗。

 

調整後，果然測試成功！！！

 

後記

現在越來越多企業對於內部系統上 Azure PaaS 躍躍欲試，筆者手上光是今年就有三家客戶想將現有系統移植上 Web App，以前將 ASP.NET MVC 網站佈署至 Azure 上大部分是玩票性質，直到真的有企業進行現有系統的 Migration 後才會真正遇到一些實際的狀況。

留言

張貼留言

這個網誌中的熱門文章

軟體工程師 - 成長的 10 個階段

圖片
軟體工程師 - 成長的 10 個階段 前言 先前，我在 Study4 小聚 #6 分享的一場關於軟體工程師 & 架構設計的養成之路，在該議程中，我分享了軟體工程師的 10 個階段（你的階段如有雷同、應該是...純屬巧合。XDDD） 哪 10 個階段？ 我將軟體工程師的成長依序分為 10 個成長階段，因為隨著技能的提升，你該擴充的 不會只是只有軟體開發技術，溝通與協作能力尤其重要 ，也像是『康威定律』中所提到的， 你的軟件的設計 & 或系統設計本質上反映了企業的組織機構。系統各個模塊間的介面的設計，也反映了企業各個部門之間的信息流動和合作方式，這些技能再進行軟體架構設計時也息息相關 ，團隊在進行模組設計時需要頻繁的溝通，這些、都是是否能將軟體做好的關鍵因素。 如 Logo 圖片，我依序說明每個階段的成長歷程。 1). 初始開發階段、熟悉 Programming/Developer 階段（PM/PO/SD 給規格後加以實作出來），並能夠藉由 模仿 來學習。這是剛進入軟體產業的學習階段。 2). 此階段代表已懂得透過重構來讓程式碼有基本的可維護性 、已能熟用 DRY (Don't Repeat Yourself)，進入這個階段代表已經有基本的程式語言的基礎， 應付 Programming/Developer 日常 工作 上的需求基本上沒什麼太大的問題。 3). 這裡的專案收尾代表對於專案開發已經有某些程度的認知、掌握度。我所提的掌握度在於了解『技術債』的產生緣由 與 危害，在 Programming/Devloper 層面懂得透過 S.O.L.I.D./Design Patterns 解決問題 並 開始能夠 自我學習 + 自我成長 。 4). 我這裡用『紀錄』 代表能運用所學 + 將使用者需求運用 〔邏輯思考〕 與 〔抽象化〕 轉化為程式碼 + 並能 自我成長 將經驗保存下來。我認為這是跨越只是（寫程式／實作）進入另一個門檻的重要經驗與歷練。 這個階段花費的時間會較長一點，時間長短取決於個人歷練、經歷、學習的環境與工作內容。 5). 此階段含括上面所有技能，並能夠與〔團隊〕和〔客戶〕 溝通 與 協作 、並產生出〔產品〕。而所謂的協作代表，不只自身技術所長能應付本身開發工作工作所需，亦能帶領團隊解決軟體專案的大小事務、也能夠替...
閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當...
閱讀完整內容

什麼是 gRPC ？

圖片
圖片取自： https://grpc.io/docs/guides/ gRPC 是什麼？能吃嗎？ 在安裝了 .NET Core 3.0 之後，眼尖的朋友應該會發現，在新增 ASP.NET Core 網頁類型專案裡，會看見一個 gRPC Service 類型的專案，其實它也不是什麼很新的東西，早在十多年前 Google 就使用這樣的 RPC 協定進行一些大量的可靠性微服務的存取，聽到這，難道現有的 Web API 不可靠嗎？其實不是的，它主要用在移動設備等提供高效簡單且跨平台的通訊與熱插拔的驗證機制。 gRPC 的運作原理 gRPC 顧名思義，是種基於 RPC 的通訊協定，不同於 Web API 走的傳統 HTTP 基礎協定，它有點像是 Socket ，但應該說是基於 Socket， 或精確地來說它是基於 HTTP/2 的協定 ，gRPC 是種協議緩衝協定，它必須事先定義 IDL (Interface Definition Language) 描述檔，看到 IDL 對於一些熟悉 COM／DCOM 的朋友一定非常的熟悉，對！沒錯！就是類似的東西！但，這邊的 IDL 是用一種副檔名為 .proto 檔案來是先定義在分散式環境中，要傳輸的序列化結構資訊，當然它也可以跟 JSON 一起使用。 也就是說，要使用 gRPC 您必須先定義 .proto 協議，然後透過 Compile 的支援，編譯成特定語言框架。而很高興的是，C# 也支援了，然而其實根據官方的資料顯示，C# 應該在 .NET Core 2.1 開始就支援了，只是到了 .NET Core 3.0 才有樣版的支援。 而使用 gRPC 的協議緩衝區的服務可以做到 Stub 的機制，也就是說，它就像是許多 RPC 一樣，Client 在呼叫 Server 端時，其實是對 Stub 進行叫用，Stub 在這就像個緩衝區一般，但更細部的說，應該是一個遠程服務的替身，這應該又讓許多熟悉 COM／RPC 通訊的朋友覺得熟悉了起來，是的！沒有錯。 在 .NET Core 3.0 裡使用 gRPC 目前支援 .proto 擴展為 gRPC 協議緩衝區的編譯器只有 .NET Core 了 ， 根據 Github 上的說明 .NET Framework 4.5+ 以上或 Mono 4+ 以上也可支援，而 gRPC 也完全的跨平台。要在 ....
閱讀完整內容