Asp.net Mvc模塊化開發之「部分版本部分模塊更新(上線)」

項目開發歷來就不是一個簡單的問題。更難的問題是維護其餘人開發的項目,而且要修改bug。若是原系統有重大問題還須要重構。

怎麼重構系統不是本文探討的問題,可是重構後如何上線部署和本文關係密切。這個你們可能剛興趣。

言歸正傳,如今演示一下若是作到部分版本和部分模塊更新。

 

---

 Asp.net Mvc模塊化開發系列目錄

 一、 Asp.net MVc模塊化開發之分區擴展框架(送源碼)

 二、 Asp.net Mvc模塊化開發之「開啓模塊開發、調試的簡單愉快之旅」

 三、 Asp.net Mvc模塊化開發之「邏輯(項目)複用」

   3.一、 不一樣角色或者權限的邏輯(項目)複用(分區過濾器的應用)

   3.二、 不一樣業務的邏輯(項目)複用(DI(依賴注入)的應用)

 四、 Asp.net Mvc模塊化開發之「項目(分區)拆分」

 五、  Asp.net Mvc模塊化開發之「部分版本部分模塊更新(上線)」

 

---

 1、如今假設一個系統架構

以上是一個簡單站點的架構圖
實際開發的是三個項目,blog(博客)、新聞(news)及評論(Coment)
    其中評論這個項目(分區)部署了兩個,/Blog/Coment/和/News/Coment/

 

2、如今咱們有新的需求要對評論功能升級

一、咱們對評論功能拆分版本

     原版本: \Branchs\Coment_V1.0

     新版本: \Branchs\Coment_V1.1

二、好在咱們偉大的程序員效率就是高,三下五除二,新版本完成了，要部署了

　　可是因爲種種緣由,領導要求更新blog評論(/blog/Coment/),待blog評論上線一段時間穩定後再更新News評論,那咱們怎麼辦呢?

      而且要求若是新評論功能出現問題快速回退(要制定回退方案啊)

 

3、好吧,雖然需求有點"變態",咱們總不能說辦不到吧

這裏說個題外話,程序員這個偏執狂的羣體是最不能忍受別人質疑本身能力的。其實程序員也是人,也不是萬能的。適當的說辦不到或者No也不是不能夠。

直接上圖:

 一、後端增長了一個站點(tmp.xxx.com)

      裏面部署了一個分區/blog/Coment/

     注:這個站點是服務器內網站點,域名是沒法外網直接訪問的

 二、前端(Ngnix)配置一條rewrite規則並指向新站點的這個分區

　　這樣新的功能就順利上線了,皆大歡喜,並且訪問路徑也沒有變化,其餘相關模塊直接鏈接過來的也不須要修改。對度娘等搜索引擎更是沒有任何影響。

     舊的站點(IIS)咱們沒有作任何修改,原來是正常的如今不正常的可能性很是小,減少了上線的風險。

     有人可能會說,新評論功能修改了表結構,就算不更新源IIS站點,老的評論站點也可能掛掉。我只能說,你要這樣蠻幹我也沒辦法。

      這就要求寫好的模塊化代碼,升級前考慮兼容原數據結構,不一樣業務儘可能拆表。若是能夠,升級時不要修改原表結構,而是新建一個表,上線前把歷史數據導入到新表,徹底上線後再追一次增量數據。按本身團隊的技術實力和產品需求,能作多少是多少。

三、回退怎麼辦？(回退方案)

     哈哈,這個更簡單。只要從ngnix上刪除新加的那條rewrite規則

     若是新版本程序和原來不是一個表,還須要追一下增量數據,固然提早要寫好sql腳本,複雜一點的作一個控制檯程序,通常就夠了

四、有人可能會說,你這個不科學,修改博客評論極可能博客模塊也需求修改

     確實,修改博客評論博客模塊也可能須要修改上線

    繼續上圖:

    

   本圖是局部圖,原IIS站點部署仍是不變

五、有人說,咱們公司不用Ngnix,你這個要求過高了

     其實其餘前端也都有rewrite功能,Apache等。

     有些沒有前端就不太好辦。可是前端真的是Web站點的標配。在前端上作日誌、緩存、壓縮、防禦等。要想讓web站點更好更快的運行,就須要讓他作儘可能少(必不可少的業務處理)的事情。

六、有人說你這個仍是不夠科學,咱們能夠拆分爲4個獨立的IIS站點

　　拆分爲4個IIS站點是一個方案,也能夠更好的隔離減小相互影響

     但這個前提是值得拆,好比性能達到瓶頸,單個業務(分區)流量太大,多個不一樣團隊交叉維護不一樣的業務(分區)。

     要知道一我的維護一個站點和4個站點仍是不同的,相同的代碼你須要部署到4個不一樣的地方。現實中,咱們會開發無數能夠產品(業務),有些產品的訪問量很是小,可是卻不能下線。爲何小流量的產品不能下線不是本文探討的範圍,這裏就不展開了。

     並且就算你拆分4個站點,升級版本直接覆蓋原站風險仍是太大,要作平滑上線(方便回退)你還須要一倍的站點。

七、有人會說你這增長的tmp站點是什麼鬼,是要永久存在嗎？

     這裏叫tmp只是舉例用,現實中用其餘名字也是能夠的,升級版本所有上線後能夠以這個站點爲主站點(原站點成備用站點)或者切回到原站點均可以。

     這種用法能夠叫作「AB版」,有的時候用的是A版,有的時候用的是B版,有的時候是AB版本共存(在維護文檔中備註哪些功能在哪一個版本站點上)。

     若是需求衝突特別嚴重,再來個C版本或者D版本的臨時站點又有什麼不能夠的呢？能解決現實問題纔是最重要的。不能總等着你們來合併版本再一塊兒上線。有的時候存在多個版本豈不是更加高效？