.NET進行高效率互聯網敏捷開發的思考和探索

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

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

  先看一個最新上線的典型案例,http://muban.printhelloworld.com,其中用到了諸如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框架

  4、有APP的需求,甚至APP優先的需求,APP需要對接各類第三方插件

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

  6、 有微信的需求,要求對接微信公衆賬號,進行微信瀏覽器中的移動Web開發

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

  8、數據量增長迅速,對報表展示、數據分析有較多的需求

  9、項目組人員需求由Web開發工程師,細分爲HTML5前端工程師、JAVA(.NET)工程師、數據庫工程師等

  10、單元測試減少,功能測試越來越多,甚至用互聯網工具(worktile等)替代專業測試工具

  基於以上情況,我們考慮,如果仍然使用.NET進行系統開發,那麼在用戶量<=50萬的敏捷項目裏:

  二、一些傳統的.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 2003和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和MVC模型,前後端高度解耦,前端的所有邏輯處理均使用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等,都已經在實踐環節真實的解決了很多傳統需求裏的複雜點和困難點,具體細節後面詳細討論,但真心的說一句,趕快使用阿里雲吧,至少在現階段,不是阿里雲在綁架你,而是在幫助你。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章