向ASP.NET Core遷移
我們首先來看看http://ASP.NET Core有哪些優勢?
- 跨平臺:可以部署到Linux伺服器上
- 內置一套對雲和部署環境非常友好的配置模塊
- 內置依賴注入
- IIS或者Kestrel(或者其它自定義)
- 輕量級、高性能、模塊化的Http處理管線
- .NET Core 是開源的,並且基於nuget發布。 這讓我們有了更大的空間去改造和擴展它
- 更易於現代化的項目開發,比如面向容器,微服務架構,對DevOps更友好
公司的決策層為什麼要做這樣的選擇?
- 降低成本,提升效率
- 提升公司的技術品牌
- 更好的留住和培養現有的開發團隊,以及招募到更好的開發者
在同等用戶規模的情況下,選擇 Linux的伺服器比Windows Server的性價比更高。在一個產品的整個實現與運營生命週期當中,編碼只佔了很小的一部分,還有開發與測試環境的初始化與維護,測試與集成,線上環境部署與運維這都會佔用不少的時間,通過自動化可以大幅度的減少這些時間。而在.NET Core實現跨平臺之後,讓自動化的門檻降到最低。你不再需要一個資深的架構師或者專業的DevOps纔可以實現,一個有經驗肯學習的開發者足以應付。
如何來做升級和改造 ?
說到真實產品的技術升級和改造,不傷筋動骨,不可能完成。
- 老系統是 http://asp.net Web Form
- 老系統用的是WCF之類的項目
- 老系統是http://asp.net MVC或者WEB API
由於對system.web的重依懶,將Web Form遷移到http://ASP.NET Core幾乎是不可能。如果Web Form項目使用了伺服器端控制項,那已經可以放棄往下走,可以嘗試開始一個新的項目逐步替換老的項目。如果沒有使用伺服器端控制項,用handller在返回數據,則可以考慮先將Web Form的項目進行前後端分離或者API 分離,在視圖層邏輯不變的情況下重寫後端邏輯部分。當然這個代價也不小,所以轉型和升級需要準備的事情有很多。
WCF暫時還不能支持.NET Core,雖然微軟已經啟動WCF的開源和併入.NET基金會,但短時間內WCF遷移到.NET Core還有一段時間。所以如果對WCF依懶比較重,最好暫時不要考慮升級。一些複雜的MVC和WEB API的項目如果依懶比較多,要升級起來也不是一件容易的事情 。目前比較可行的方案,還是在新項目上使用.NET Core來實現 。
最合適的步驟是先在一些新的項目上採用http://ASP.NET Core來開發。就語言特性本身來說http://ASP.NET Core的變化不大,學習成本也不高。但是生產環境不是隨便玩的,要從無到有,過程比較艱難,這也是很多小公司到現在還沒有在生產上用上.NET Core人原因之一。只有開發人員幹著急,我們什麼用.NET Core 呢?
與其等待你的總監做這個決定,不如自己先幹起來。如果不能從無到有,那麼我們可以在原來的系統上換部件:也就是我們的最小升級方案,將.NET Core部署在IIS上。
最小升級方案:將http://ASP.NET Core部署在IIS上
關於如何把http://ASP.NET Core的網站或者API部署到IIS上,網上已經有比較多的介紹,可以參考這裡。主要是需要先下載一個ASP.NET Core的模塊安裝之後再進行簡單的配置,新手比較容易忽略。如果你的IIS模塊裡面沒有AspNetCoreModule,說明沒有安裝這個ASP.NET Core模塊,需要進行下載安裝。
http://ASP.NET Core所有的項目都必須運行在Kestrel或者一個自定義的Web Server上。
在http://asp.net core 2.0時,採用默認的 WebHost.CreateDefaultBuilder().Builder() 得到的Host已將將 Kestrel和IISIntegration都添加進來。
public static void Main(string[] args){ BuildWebHost(args).Run();}public static IWebHost BuildWebHost(string[] args){ return WebHost.CreateDefaultBuilder(args) .UseStartup<Startup>() .UseKestrel(options => { options.Listen(IPAddress.Loopback, 5000); options.Listen(IPAddress.Loopback, 5001, listenOptions => { listenOptions.UseHttps("testCert.pfx", "testPassword"); }); }).UseIISIntegration().Build()}
IISIntegration其實是將IIS做一個反向代理,AspNetCoreModule的任務就是將請求轉發給Kestrel。
當然你也可以選擇用Nginx或者 Apache來做反向代理,來實現http://ASP.NET Core在Linux上的部署。這裡有一篇不錯的實踐貼(將ASP.NET Core應用程序部署至生產環境中(CentOS7)
在我們的最小升級方案裡面,部署到IIS是在生產環境中使用http://ASP.NET Core是最易實現和成本最低的一種。剩下的,等開發人員對http://ASP.NET Core掌握的比較牢固,對Linux的運維也有一些經驗之後可以再嘗試往Linux上遷移。
新老項目交互的問題
除了剛起步沒有任何歷史負擔的公司,我們大多數所在的公司都處於老系統維護和新系統開發並行的情況。在新系統的開發過程當中,少不了要與老系統打交道。比如最常用的一些其它系統的數據訪問,就會面臨是重寫好,還是調用老系統中的代碼比較好的問題。
這裡沒有明確的答案,取絕於當前業務的發展和我們所擁有的時間來決定 。人和時間夠整個系統重寫都可以,不夠的話我們也只能採用系統嫁接的方式。
根據老系統的結構主要分兩種:
- 前後端未分離,就是一個大的網站
- 前後端已分離,前端和移動端直接調用http://ASP.NET Web API
第一種情況會給系統以及開發增加的複雜度是: 本地代碼訪問變成API訪問之後的引發的問題,這也是多數團隊在做服務化時首先遇到的問題。
- 增加額外的API訪問代碼
- 增加Debug的複雜度,不好找原因
第二種情況,已經API化只是沒有做拆分。那我們新寫的http://ASP.NET Core API 可以直接被訪問。這裡的問題是要解決認證授權的問題包括(從客戶端到Core API,以及從Core API到原來的Web API)
註:這種方案應該禁止從老的http://ASP.NET Web API訪問 http://ASP.NET Core的項目。最後應該是停止維護老項目,所有代碼在新的http://ASP.NET Core上進行開發。 Proxy的設計應該按照新的框架來設計,實現可以嫁接老的API,做好被新代碼替換掉的準備。
關於http://ASP.NET Core認證與授權相關可以參考我寫的另外一篇文章 http://ASP.NET Core集成現有系統授權 : ASP.NET Core集成老系統認證
http://weixin.qq.com/r/qTrP1x3EKkBVrVm092_7 (二維碼自動識別)
推薦閱讀: