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版本的临时站点又有什么不能够的呢？能解决现实问题才是最重要的。不能总等着你们来合并版本再一块儿上线。有的时候存在多个版本岂不是更加高效？