項目開發從來就不是一個簡單的問題。更難的問題是維護其他人開發的項目,並且要修改bug。如果原系統有重大問題還需要重構。 怎麼重構系統不是本文探討的問題,但是重構後如何上線部署和本文關係密切。這個大家可能剛興趣。 言歸正傳,現在演示一下如果做到部分版本和部分模塊更新。 Asp.net Mvc模塊化開發
項目開發從來就不是一個簡單的問題。更難的問題是維護其他人開發的項目,並且要修改bug。如果原系統有重大問題還需要重構。
怎麼重構系統不是本文探討的問題,但是重構後如何上線部署和本文關係密切。這個大家可能剛興趣。
言歸正傳,現在演示一下如果做到部分版本和部分模塊更新。
1、 Asp.net MVc模塊化開發之分區擴展框架(送源碼)
2、 Asp.net Mvc模塊化開發之“開啟分模塊開發簡單愉快之旅”
3、 Asp.net Mvc模塊化開發之“邏輯(項目)復用”
3.1、 不同角色或者許可權的邏輯(項目)復用(分區過濾器的應用)
3.2、 不同業務的邏輯(項目)復用(DI(依賴註入)的應用)
4、 Asp.net Mvc模塊化開發之“項目(分區)拆分”
5、 Asp.net Mvc模塊化開發之“部分版本部分模塊更新(上線)”
一、現在假設一個系統架構
以上是一個簡單站點的架構圖
實際開發的是三個項目,blog(博客)、新聞(news)及評論(Coment)
其中評論這個項目(分區)部署了兩個,/Blog/Coment/和/News/Coment/
二、現在我們有新的需求要對評論功能升級
1、我們對評論功能拆分版本
原版本: \Branchs\Coment_V1.0
新版本: \Branchs\Coment_V1.1
2、好在我們偉大的程式員效率就是高,三下五除二,新版本完成了，要部署了
但是由於種種原因,領導更新blog評論(/blog/Coment/),待blog評論上線一段時間穩定後再更新News評論,那我們怎麼辦呢?
並且要我們給出如果新評論功能出現問題需要快速回退(要制定回退方案啊)
三、好吧,雖然需求有點"變態",我們總不能說辦不到吧
這裡說個題外話,程式員這個偏執狂的群體是最不能忍受別人質疑自己的能力的。其實程式員也是人,也不是萬能的。適當的說辦不到或者No也不是不可以。
直接上圖:
1、後端增加一個一個站點(tmp.xxx.com)
裡面部署了一個分區/blog/Coment/
2、前端(Ngnix)配置一個一條rewrite規則指向了新站點的這個分區
這樣新的功能就順利上線了,皆大歡喜,而且訪問路徑也沒有變化,其他相關模塊直接連接過來的也不需要修改。對度娘等搜索引擎更是沒有任何影響。
舊的站點(IIS)我們沒有做任何修改,原來是正常的現在不正常的可能性非常小,減小了上線的風險。
有人可能會說,新評論功能修改了表結構,就算不更新源IIS站點,老的評論站點也可能掛掉。我只能說,你要這樣蠻幹我也沒辦法。
這就要求寫好的模塊化代碼,升級前考慮相容原數據結構,不同業務儘量拆表。如果可以,升級時不要修改原表結構,而是新建一個表,上線前把歷史數據導入到新表,完全上線後再追一次增量數據。按自己團隊的技術實力和產品需求,能做多少是多少。
3、回退怎麼辦？(回退方案)
哈哈,這個更簡單。只要從ngnix上刪除新加的那條rewrite規則
4、有人可能會說,你這個不科學,修改博客評論很可能博客模塊也需求修改
確實,修改博客評論博客模塊也可能需要修改上線
繼續上圖:
本圖是局部圖,原IIS站點部署還是不變
5、有人說,我們公司不用Ngnix,你這個要求太高了
其實其他前端都有rewrite功能,Apache等。
有些沒有前端就不太好辦。但是前端真的是Web站點的標配,在前端上做日誌、緩存、壓縮、防護等。要想讓web站點更好更快的運行,就需要讓他做儘量少(必不可少的業務處理)的事情。
6、有人說你這個還是不夠科學,我們可以拆分為4個獨立的IIS站點
拆分為4個IIS站點是一個方案,可以更好的隔離減少相互影響
但這個前提是值得拆,比如性能達到瓶頸,單個業務(分區)流量太大,多個不同團隊維護不同的業務(分區)。
要知道維護一個人維護一個站點和4個站點還是不一樣的,相同的代碼你需要部署到4個不同的地方。現實中,我們會開發無數可以產品(業務),有些產品的訪問量非常小,但是卻不能下線。為什麼小流量的產品不能下線不是本文探討的範圍,這裡就不展開了。
7、有人會說你這增加的tmp站點是什麼鬼,是要永久存在嗎？
這裡叫tmp只是舉例用,現實中用其他名字也是可以的,臨時版本全部合併後可以把所有最新版本更新到這個站點或者和回到原站點都可以。
這種用法可以叫做“AB版”,有的時候用的是A版,有的時候用的是B版,有的時候是AB版本共存(需要在維護文檔中備註哪些功能在哪個版本站點上)。
如果需求衝突特別嚴重,再來個C版本或者D版本的臨時站點又有什麼不可以的呢？能解決現實問題才是最重要的。不能總等著大家來合併版本再一起上線。有的時候存在多個版本會更加高效呢？
