.net進行高效率互聯網敏捷開發的思考

不知從什麼時候開始，創業變得很廉價，談什麼都是互聯網，動輒融資千萬。這陣風好像也刮向了程式設計師中，有那麼一大批開發者，資料結構不好好學習、資料庫原理不紮實掌握，在github上發布幾個項目，用nodejs創建一些服務，再用H5寫出APP ，就自以為邁入了高級程式設計師的隊伍，能夠運籌帷幄互聯網項目，難道學習新技術、新理念就是快速成長嗎，顯然不完全是，在這浮躁的氛圍中，各種粗製濫造的互聯網網站、APP接踵而至，很多看似漂亮的APP，連簡單的http介面安全都沒有措施應對，很多美麗的響應式網站，目錄結構隨意堆疊，這實在是一股歪風邪氣，我覺得程式設計師還是應當踏實實的多學理論，多寫程式碼，重複實踐。

　　那麼另外一個問題就來了，新技術、新理念難道就沒有用了嗎，顯然也不是，新技術新理念是無數的技術大牛在長期的實踐中反復重構的勝利果實，而作為一個.NET老司機，眼看著這些年微軟擁抱開源，擁抱社區帶來的改變和進步，也是深感欣慰，於是今天，我想和大家分享一下這些年我以及我的公司對於使用.NET進行Web開發乃至於互聯網應用開發的一些經驗和技術總結。

最新上線的典型案例，其中用到了諸如HTML5、Bootstrap、EF6 For MySql、阿里雲RDS，阿里雲CDN等新技術和新理念，然而卻並沒有脫離採用.NET進行開發以及採用. NET生態環境（IIS、Windows Server）進行部署這項基礎，但整個開發流程，已經完全擺脫了WebForm甚至MVC，我們實踐了一套全新的.NET開發模式，在開發效率和團隊協作上大大提升，在開發時間上也大幅縮短，在這個案例裡面，整個網站的前台和後台管理，從構思到設計、開發、調試、部署，1個人3天完成。以下就開發模式的細節詳細描述，也聽聽大家的意見，持續改進與改進。

　　對於ASP.NET WebForm的評價，我想以下的話是客觀的：ASP.NET WebForm托拉拽以及事件驅動的Web開發模式的創新，雖然方便了一大批.NET入門者的學習和理解，但最終嚴重阻礙了的.NET的普及和商業化使用，而且在很長一段時間內，.NET優秀的語言特性得不到重視，反而一直被扣著低效率、難擴展、不適合商業開發的帽子，ASP.NET WebForm在這其中有著不可推卸的責任。

　　遙想06、07年的時候，我還在驚嘆於UpdatePanel的強大和方便，現在回想來看，這樣的開發模式讓開發人員對HTTP和Web本質的認識無疑是罩上了一層迷霧，從長遠看是一種倒退，再往後來，到了ASP.NET MVC時代，微軟高階程式設計師的陋習依舊沒有改善，雖然MVC開源了，但仍然充斥著各種自以為是的為開發人員提前想好的特性、綁定、快捷方法等等，這些東西初級開發人員可能會覺得很方便，但我想，任何從事過商業專案架構和開發的技術經理都會深有感觸，在真正需要穩定的紮實專案中，這些小聰明，不僅毫無用處，而且難以擴展，更容易導致難以掌控的Bug和漏洞。

　　令人慶幸的是，在Nadella的帶領下，在比爾蓋茨重新擔任技術顧問的指引下，.NET不斷修正方向，除了在語言上大步向前，更在生態建設上愈加清晰可見。我一直在懷疑公司所創造的.NET敏捷開發模式是否是先進性的體現，直到vNext（MVC6.0）的出現，我豁然開朗，原來殊途同歸，微軟終於走對路了。

　　在談開發模式之前，我想先談一談：

一、目前的互聯網項目或者是傳統Web項目的一些新趨勢和特點

　　1、不再使用WebService，而是大量使用HTTP作為數據通訊的方式

　　2、資料載體不再使用XML，轉而使用JSON

　　3、Web前端會使用Bootstrap、JQueryUI、EasyUI等第三方HTML5框架

🀜APP　　4、有優先的需求的需求， ，APP需要對接各類第三方外掛程式

　　5、為了追求APP快速上線，有時候會採用HTML5的APP開發模式，例如PhoneGap、AppCan、HBuilder等

　　6、 有微信公眾帳號的需求，要求對接公眾帳號，進行微信瀏覽器中的行動Web開發

　　7、開發週期短、迭代頻繁

　　8、資料量成長迅速，對報表展示、資料分析有較多的需求

　　9、專案組人員需求由Web開發工程師，細分為HTML5前端工程師、JAVA（.NET）工程師、資料庫工程師等

　　10、單元測試減少，功能測試越來越多，甚至用互聯網工具（worktile等）取代專業測試工具

　　基於以上情況，我們考慮，如果仍然使用.NET進行系統開發，那麼在用戶量

　　二、一些傳統的.NET Web開發模式和方法就應該被拋棄

1、ASP.NET WebForm以及MVC模式不再合適，他們均存在前後端耦合嚴重，簡單流程複雜化的問題，而且前端始終無法脫離.NET架構。

　　2、SQL Server資料庫不再合適，雖然SQL Server 2014的特性讓人激動，但隨著公有雲的使用越來越普遍，同時相比其他資料庫來說，大小、價格、可擴充性甚至效能方面，SQL Server都顯劣勢。

　　3、傳統三層架構不再合適，很多互聯網項目，從設計之初就要求能夠支援多服務節點，不同應用場景使用不同資料庫。再加上三層架構大量使用反射犧牲效能增加程式碼，也不再適合敏捷開發。

　　4、Server 2003的IT架構應當被拋棄，無論是IIS6.0落後於IIS7的HTTP請求處理模型，或是Server 2003落後於Server 2008、2012的穩定與擴展，都不應再考慮基於Server 20033和IIS6的.NET部署。

　　雖然被拋棄了一些東西，但微軟畢竟是微軟：

　　　三、一些.NET特性應當被強化

　　1、深入使用Visual Studio 2015，VS2015是宇宙級甚至在工具前端編碼（CSS、JS、HTML）上也愈加純熟，配合適合工程師自己的自訂設定以及第三方插件，將會如虎添翼

　　2、TFS原始碼管理的使用，無論是內部安裝TFS Express版本還是在tfs.visualstudio.com上申請免費空間，都能夠很好的進行團隊協作，以我們實踐來看，切勿被Git模式沖昏頭腦，事實上TFS管理模式才是最適合.NET開發的

　　3 、.NET高階語言特性應加強使用，在理解的基礎上，如果能熟練使用Linq、Lamda表達式、反射、Task並行程式設計等.NET特有的優質語言特性和方法，將會大大提升開發效率，縮短開發時間。

　　4、IIS的高階功能與動態管理應加強使用，IIS7以後，IIS伺服器就是高效能Web中介軟體的代名詞，加上Server 2008、2012的Core模式，加強對IIS的動態管理與配置能夠大幅提升Web處理效率。

　　5、Server 2012 R2作業系統應該加強使用，雖然跨平台是.NET的方向，也在mono上實踐的很好，但在PC伺服器和雲端伺服器越來越便宜的今天，還是多用Windows最新的伺服器作業系統吧。

　　有了以上這些認識，經過總結，我們現行的.NET開發模式，可以簡單概括為如下：

　　一、前後端高度解耦

　　棄ASP.NET WebForm ，前後端高度解耦，前端的所有邏輯處理均使用JS進行處理，包括Dom元素佈局與繪製以及資料請求，而後端為純粹的業務邏輯處理，包括邏輯處理以及資料處理。目前我們的專案由於使用了ASP.NET中的Routing特性，依然Host在ASP.NET模型以及IIS中，在理論中以及不久的將來，替換為Core IIS或Linux下的Nginx來Host純HTML5以及HTMl5緩存也將非常容易。

　　二、前端使用純HTML5

　　前端拋棄傳統HTML，盡量全部使用HTML5技術，其中做出的犧牲有，拋棄IE11以下的瀏覽器，但在互聯網思路的今天，這樣的思路也未嘗不可，當在前端全部使用HTML5技術後， 檔案、圖形影像、音訊視訊、地理位置等各種處理將變得非常簡單，而且扁平化、資料化。

　　三、前端充分利用成熟框架

　　使用新的開發模式後，很明顯的一個改變​​就是，公司的美工不再或很少進行前端切圖，而對於技術美工的需求（會CSS開發和JS開發、也懂設計）則日漸增加，帶來這項改變的根源就是那些不斷湧現先進的、優秀的前端框架，我們目前正在使用的有JQuery、Zepto、JQueryUI、JQueryMobile、Bootstrap、Amaze UI、inoic、 Framework7、SUI、MUI等等，以及伴隨著這些優秀框架的第三方外掛程式。客觀的說，透過優秀框架的使用，不僅沒有增加前端的系統風險，反而由於框架的開源、架構清晰、穩定等特性，實現了更穩定、可擴展的前端。簡單的舉個例子，在解決困擾許多Web工程師的全相容性的佈局以及響應式佈局問題上，Bootstrap就功不可沒。

　　四、前端開發面向對象化

　　將前端開發，透過JS面向對象特性進行簡單封裝，在Dom元素操作以及業務邏輯數據請求的處理上，與後端數據類型、實體結構以及處理邏輯上保持一致，不僅拉近了前後端開發人員對業務需求的理解，也是大幅降低的技術培訓的門檻，提升了團隊合作的效率。

　　五、使用CDN服務

　　CDN服務在幾年前還是大企業、大公司的專屬，現在已經完全普及化、平民化，Web前端越來越重是不爭的事實，但真正的業務邏輯往往只有幾十K甚至幾K， 1個幾百K的頁面，90%是JQuery等第三方框架，因此，合理的使用CDN加速，不僅提升用戶端的體驗，更直接將基於HTTP架構Web服務的負載能力提升5-10倍以上。

　　六、業務邏輯HTTP服務化

　　這句話的描述可能不是很恰當，但這也是我們全新的.NET開發模式中最重要的環節，經過對阿里開放平台等先進互聯網架構的學習，最終我們形成了結構化但鬆散的業務邏處理模式，即每個業務邏輯行為均有1個唯一的路由名稱，業務邏輯只對路由名稱負責，而路由名稱對流向、性能、權限、安全等上層需求負責。這樣做的好處是，能夠充分利用3-5年左右經驗的開發人員（這也是大部分公司的開發主力軍），讓他們專注於業務邏輯的編寫，而業務邏輯之外的事情，在架構層面由其餘的控制器去解決，而一個大的.NET專案工程，也可以靈活以不同的方式拆分為各個子模組。對於HTTP服務的實現，我們嘗試過ASP.NET ASHX處理器、Windows Service HOST WCF服務、ASP.NET Web API，目前較為穩定版本是Web API，當然針對HTTP服務化這項需求，Wen API也顯略重，以後會繼續改進。總之這個改變過程，在實務上提升了至少3倍以上的開發效率與測試效率。在後一章節中，將會進行詳述。

　　七、分散式與熱加載HTTP服務建設

　　互聯網應用要求的是敏捷開發和反復迭代，同一個邏輯架構下的不同請求會使用不同的服務器和數據庫已經是家常便飯的事情，因此項目設計初期，分散式HTTP服務的建設至關重要，而業務更新更是需要能夠進行熱加載，在.NET體系裡面，就是DLL託管程式碼的動態加載使用，可惜的是，由於公司現有專案並未出現大規模分佈式場景，因此尚未研發出較穩定的DLL動態載入架構，在後一章節中，將會詳細討論。

　　八、使用阿里雲解決大數據問題

　　我想任何一個使用過阿里雲以及其他雲服務的IT架構師，都能深深的感覺到，阿里雲已經領先其他雲不止一個身位。事實上，特別是阿里雲的資料庫相關功能，例如RDS、DRDS、KVStore等，都已經在實踐環節真實的解決了很多傳統需求裡的複雜點和困難點，具體細節後面詳細討論，但真心的說一句，趕快使用阿里雲吧，至少在現階段，不是阿里雲在綁架你，而是在幫助你。

　　今天寫了很多，總的來說，就是告訴大家，.NET的春天已經來了，.NET不僅可以進行互聯網化的敏捷開發，更能處理大型專案大型數據大型邏輯，這一點我在實踐中已經嚐到甜頭，而作為一個寫Pascal資料結構出身的程式設計師，也至今十五年有餘，我也對各類新技術非常感興趣，都有涉獵甚至嘗試，不怕被別的語言噴，我甚至可以大膽的說一句，其他語言，從綜合（語言、開發環境、開發效率、技術社區、團隊協作、應用能力）上來看，在應用級開發領域，已經落後.NET太多太多，只是. NET程式設計師自己還沒察覺，所以從這一點來看，需要大家的共同努力，不斷鑽研和探索。