项目开发从来就不是一个简单的问题。更难的问题是维护其他人开发的项目,并且要修改bug。如果原系统有重大问题还需要重构。
怎么重构系统不是本文探讨的问题,但是重构后如何上线部署和本文关系密切。这个大家可能刚兴趣。
言归正传,现在演示一下如果做到部分版本和部分模块更新。
Asp.net模块化开发系列目录
1、 Asp.net模块化开发之Mvc分区扩展框架(送源码)
2、 Asp.net模块化开发之“开启分模块开发简单愉快之旅”
3、 Asp.net模块化开发之“逻辑(项目)复用”
3.1、 不同角色或者权限的逻辑(项目)复用(分区过滤器的应用)
3.2、 不同业务的逻辑(项目)复用(DI(依赖注入)的应用)
4、 Asp.net模块化开发之“项目(分区)拆分”
5、 Asp.net模块化开发之“部分版本部分模块更新(上线)”
一、现在假设一个系统架构
以上是一个简单站点的架构图
实际开发的是三个项目,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版本的临时站点又有什么不可以的呢？能解决现实问题才是最重要的。不能总等着大家来合并版本再一起上线。很多更新适当存在多个版本是不是更加高效呢？