1.保障應用程式埠的連通性 通常情況下伺服器的防火牆通常都是開啟的狀態，所以我們需要保證我們部署應用程式的埠是開啟了相應的訪問許可權，否則我們的應用程式將無法被外界進行訪問。這裡為了快速測試應用程式的埠連通性，我們使用比較方便的Telnet工具進行測試，該工具的安裝包內置在Windows操作系統 ...
1.保障應用程式埠的連通性
通常情況下伺服器的防火牆通常都是開啟的狀態，所以我們需要保證我們部署應用程式的埠是開啟了相應的訪問許可權，否則我們的應用程式將無法被外界進行訪問。這裡為了快速測試應用程式的埠連通性，我們使用比較方便的Telnet工具進行測試，該工具的安裝包內置在Windows操作系統中，所以使用起來比較方便。
1.1.Telnet客戶端安裝說明
打開“控制面板”，在“程式和功能”部分，單擊“打開或關閉 Windows 功能”。然後在“Windows 功能”列表中，選擇“Telnet 客戶端”，然後單擊“確定”。
1.2.Telnet測試埠連通性
在電腦中打開CMD命令視窗，然後輸入該格式的命令：“Telnet IP 埠號”。在輸入完命令後進行回車後，如果能夠跳轉到“全黑無內容”的視窗則表示該埠可以正常訪問。
1.3.開啟埠訪問許可權
如果Telnet提示連接失敗，我們則需要為伺服器開通指定埠的訪問許可權，開啟的步驟如下：
1.我們進入到“控制面板”找到“Windows防火牆”單擊打開，然後在Windows防火牆視窗左側找到“高級設置”，單擊後進入“入站規則”界面；
2.右擊左側欄的“入站規則”節點，點擊“新建規則”進入到“新建入站規則嚮導”界面，創建規則類型選擇“埠”單擊下一步；
3. 規則應用選擇TCP，規則應用的埠勾選“特定本地埠”，然後在輸入框中填寫我們要開通的埠，然後單擊下一步；
4.在操作步驟中選擇“允許連接”，在配置文件步驟中勾選所有選項（域、專用、公用）；
5.輸入自定義規則名稱，單擊【完成】，即可完成創建；
1.4.Telnet測試埠註意事項
埠只有在指定分配相應的“服務或站點”後，電腦偵聽埠列表才會包含相應的埠，telnet才能夠測試相應埠的連通性。可以使用：“netstat -na”命令查看電腦偵聽的網路信息。
如果我們在開通埠許可權之前，我們的應用程式沒有部署在指定埠上，那麼我們在命令視窗使用telnet測試埠連通性的時候也是無法連接的。這是因為telnet的功能主要是連接到“服務或站點”的埠，所以前提條件是你開通的埠有指定相應的“服務或站點”。
2.排查-應用程式未啟動前出現的異常
對於部署之後的ASP.NET Core應用而言，如果是程式在為啟動之前發生的異常，通常可能是因為環境配置等原因導致應用程式無法啟動，並且我們無法通過程式日誌獲取到詳細的異常信息，導致我們很難排查解決問題的原因。
2.1.實際案例
應用程式在啟動之前首先會載入Startup.cs類的ConfigureServices方法以便配置相關的服務，在生產環境中，ConfigureServices方法中使用到了配置文件(appsettings.json)中的某個參數，並且該參數我們忘記配置到伺服器環境中的配置文件(appsettings.json)，這個時候我們訪問站點就會發現，瀏覽器顯示500的狀態碼且沒有詳細的錯誤信息，由於是啟動時候的發生的異常，我們日誌程式也沒有相應的記錄。
該案例是我實際工作中遇到的一個比較典型的案例，這種異常的情況也比較好復現出來。在排查問題原因的時候，為此投入了很多的時間和精力。當然可以在本地開發環境中進行調式查看開發異常信息，但是對於項目上線場景的重要性和緊急程度而言，對於這種情況我們的項目必須要採取相應的應對措施，以便快速定位問題原因進行解決。
2.2.Opw.HttpExceptions.AspNetCore
在排查問題的過程中發現了一個“一勞永逸”的方法，就是“Opw.HttpExceptions.AspNetCore”這個第三方組件。該組件可以幫助我們在應用程式無法啟動的時候，以JSON格式返回詳細的異常原因。下麵介紹使用該組件的步驟：
A.安裝 nuget 包 Opw.HttpExceptions.AspNetCore
<PackageReference Include="Opw.HttpExceptions.AspNetCore" Version="2.3.0" />
B.在Startup類的ConfigureServices方法中找到註冊MVC服務的代碼，在後面新增調用方法AddHttpExceptions。註冊MVC服務的方式每個項目可能各有不同，找到相應的位置新增調用方法即可。
C.在Startup類中的Configure方法塊的首行添加 UseHttpExceptions方法。
至此在加入Opw.HttpExceptions.AspNetCore組件後，項目已經具備了在應用程式未啟動出現異常反饋錯誤信息的能力，反饋的錯誤信息格式如下圖：
通過返回的JSON格式錯誤信息，我們可以清楚知道程式配置啟動缺失一個“ClientId”參數，有關Opw.HttpExceptions.AspNetCore組件更多的使用方式請詳見官方文檔：https://libraries.io/nuget/Opw.HttpExceptions.AspNetCore
3.排查-應用程式在啟動後出現異常
我們常常在項目上線的過程中，在完成站點的發佈和部署之後，訪問進入應用程式時，往往會發生一些意料之外的程式功能的異常，如點擊頁面操作某個功能或者進行登錄時。如果部署後的應用程式無法正常運行項目的業務功能，那麼這意味著我們的部署工作是不成功的，我們必須要快速解決在上線過程中出現的任何程式異常。
對於生產環境上的ASP.NET Core應用在產生程式異常時，預設情況下我們是無法看到詳細的異常信息的，頁面只是返回一個500的狀態碼，這樣情況顯然對於我們排查問題和用戶體驗都是不利的，所以我們需要一種應對方式，既能捕獲詳細的異常信息又能展示出友好的界面提示用戶。
3.1實際案例
在完成ASP.NET Core應用站點的上線部署後，通過指定的URL訪問站點，站點能夠成功響應請求並返回登錄頁面。然而在執行登錄操作的時候，由於之前資料庫賬號的密碼發生了改變，而配置文件的連接字元串沒有做出相應的調整，導致登錄時出現異常。然後應用程式並沒有在代碼中做出相應的異常處理，導致伺服器返回狀態碼500，並且頁面沒有任何的異常信息，我們也並不知道是因為錯誤的資料庫連接字元串導致的。
為了應對這種情況，我們將使用一種在ASP.NET Core中實現全局異常處理的方式來解決這種問題，該方式能夠捕獲到詳細的異常信息，並且能夠將錯誤信息友好的呈現到視圖中。
3.2UseExceptionHandler
在項目創建之初Startup.cs類的Configure方法中就存在了一個“UseDeveloperExceptionPage”的中間件，雖然它也可以捕獲異常信息，但是只能用在非生產環境中，而對於生產環境中的異常處理我們這可以選擇“UseExceptionHandler”中間件進行處理。
具體的實現方式如下：
A.在Startup.cs類的Configure方法中添加UseExceptionHandler方法的調用，UseExceptionHandler方法需要傳入一個路由規則參數，該方法捕獲到異常時會跳轉到對應參數的控制器中，在控制器中我們可以針對異常做出相應的處理，比如進行日誌的記錄、跳轉到呈現錯誤的視圖。
B.根據UseExceptionHandler方法傳入的參數(路由規則)，創建對應的控制器和Action，併在Action中定義處理異常的具體措施，本文的措施是將異常信息呈現到視圖頁面並記錄到日誌。
C.創建呈現程式異常信息的視圖頁面。
在配置好“UseExceptionHandler”的使用方式後，我們再次復現本段落中出現的案例情況（上線部署後站點能夠正常訪問，但是登錄時出現異常），看看能否呈現出詳細的異常信息。
上圖已經通過UseExceptionHandler中間件的作用，成功反饋了異常信息，很明顯一條關於資料庫連接的錯誤，這樣一來我們就可以有針對性的去排查異常的原因，從而避免“無的放矢”的局面。
結語
Web應用的部署看似流程標準化，但是部署人員經常會在這項工作中出現不可預知的風險，嚴重程度直接影響到客戶對項目的驗收。所以我們需要儘可能的去規避上線部署的風險，這其中規避風險的方式包括：網路的連通性檢查、程式的異常日誌處理、上線演練等方式。
知識改變命運
