Asp.net Mvc模块化开发之“部分版本部分模块更新(上线)”

项目开发从来就不是一个简单的问题。更难的问题是维护其他人开发的项目,并且要修改bug。如果原系统有重大问题还需要重构。

怎么重构系统不是本文探讨的问题,但是重构后如何上线部署和本文关系密切。这个大家可能刚兴趣。

言归正传,现在演示一下如果做到部分版本和部分模块更新。

---

Asp.net Mvc模块化开发系列目录

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规则

如果新版本程序和原来不是一个表,还需要追一下增量数据,当然提前要写好sql脚本,复杂一点的做一个控制台程序,一般就够了

4、有人可能会说,你这个不科学,修改博客评论很可能博客模块也需求修改

确实,修改博客评论博客模块也可能需要修改上线

继续上图:

本图是局部图,原IIS站点部署还是不变

5、有人说,我们公司不用Ngnix,你这个要求太高了

其实其他前端也都有rewrite功能,Apache等。

有些没有前端就不太好办。但是前端真的是Web站点的标配。在前端上做日志、缓存、压缩、防护等。要想让web站点更好更快的运行,就需要让他做尽量少(必不可少的业务处理)的事情。

6、有人说你这个还是不够科学,我们可以拆分为4个独立的IIS站点

　　拆分为4个IIS站点是一个方案,也可以更好的隔离减少相互影响

但这个前提是值得拆,比如性能达到瓶颈,单个业务(分区)流量太大,多个不同团队交叉维护不同的业务(分区)。

要知道一个人维护一个站点和4个站点还是不一样的,相同的代码你需要部署到4个不同的地方。现实中,我们会开发无数可以产品(业务),有些产品的访问量非常小,但是却不能下线。为什么小流量的产品不能下线不是本文探讨的范围,这里就不展开了。

而且就算你拆分4个站点,升级版本直接覆盖原站风险还是太大,要做平滑上线(方便回退)你还需要一倍的站点。

7、有人会说你这增加的tmp站点是什么鬼,是要永久存在吗？

这里叫tmp只是举例用,现实中用其他名字也是可以的,升级版本全部上线后可以以这个站点为主站点(原站点成备用站点)或者切回到原站点都可以。

这种用法可以叫做“AB版”,有的时候用的是A版,有的时候用的是B版,有的时候是AB版本共存(在维护文档中备注哪些功能在哪个版本站点上)。

如果需求冲突特别严重,再来个C版本或者D版本的临时站点又有什么不可以的呢？能解决现实问题才是最重要的。不能总等着大家来合并版本再一起上线。有的时候存在多个版本岂不是更加高效？