首页 > 网站建设 >

网站建设高可用性经验之代码控制(下篇)

发布时间:2018-11-06 作者:深圳网站建设

网站建设高可用性经验之代码控制(下篇)
  对于大型网站,核心应用系统和公用业务模块涉及许多团队和工程师,需要对相同的代码库进行共同开发和维护。而这些团队对同一个应用的开发维护(开发周期和发布时间点各不相同),如果代码控制环节出了问题,可能将有问题的代码发布上线,将问题带入生产环境,导致系统故障。网站代码控制的核心问题是如何进行代码管理,既能保证代码发布版本的稳定正确,同时又能保证不同团队的开发互不影响,深圳网站建设公司发现目前大部分网站使用的源代码版本控制工具是SVN,SVN代码控制和版本发布方式假有以下两种。
1.主干开发、分支发布
  代码修改部在工干(truuk)上进行,,需要发布的时候,从主干上拉一个分支(branch)发布,该分支即成为一个发布版本,如果该版本发现Bug,继续在该分支上修改发布,并将修改合并(merge)回主干,直到下次主干发布。
2.分支开发,主干发布
  任何修改都不得在主干上直接进行,需要开发个新功能或者修复个Bug时,从主干拉个分支进行开发,开发完成且测试通过后合并回主干,然后从主干进行发布,主干上的代码永远是最新发布的版本。
  这两种方式各有优缺点。主干开发、分支发布方式,主干代码反应目前整个应用的状态,一目了然,便于管理和控制,也利于持续集成分支开发,主干发布方式,各个分支独立进行,互不干扰,可以使不同发布周期的开发在同应用中进行。目前网站应用开发中主要使用的是分支开发、王干发布的方式,如图5-16所示。
大型你网站建设高可用经验之网站分支开发主干发布示意图-5-16
  可以想象,如果使用主干开发、分支发布,那么在同一个应用上,对于不同开发周期,不同发布时间的项目,有可能A项目发布的时候B项目只开发了一半,这时候的主干代码是半成品,根本不能发布。而使用分支开发、主干发布的方式,只需要将A项目的分支合并回主干即可发布,不受B项目发布时间的影响。
  目前在开源技术社区,Git作为版本控制工具,正逐步取代SVN的地位。Git对分布式开发,分支开发等有更好的支持,也更容易在各个开发分支上及时反映主干的最新更新,避免SVN在最后提交分支代码时发现和主干代码差别太大难以merge成功。但是Git的学习成本较高。如何和网站开发流程相结合还缺乏最佳实践和使用规范。不过相信Git成为网站的标准版本控制工具是迟早的事。
3.自动化发布
  网站的版本发布频繁,整个发布过程需要许多团队通力合作,发布前,多个代码分支合并回主干可能会发生冲突(conflict),预发布验证也会带来风险,每次发布又相当于次宕机事故。因此网站发布过程荆棘丛生,一不小心就会踩到雷。对于有间定发布日期的网站(很多网站选择周四作为发布,这样一周前面有三天时间可以准备发布,后面还有一天时间可以挽回错误。如果选择周五发布,发现问题就必须要周末加班了。)一到发布日,整个技术部门甚至运营部门就如临大敌,也话声此起彼伏,工程师步履匆匆,连空气中的温度部仿佛升而了几度。即便如此,发布过程还是常常出错,发布日工程师加班到凌晨是常有的事。而且容易忙中出错,因发布引发的故障也居高不下。
  据说国外某知名互联网公间的CTO就因为没有有效手段控制发布故障、减少发布日的加班而引咎辞职。其继任者提出了个火车发布模型:将每个应用的发布过程看作次火车旅程,火车定点运行,期间有若干站点,每站都进行例行检查,不通过的项目下车,剩下的项目继续坐着火车旅行,直到火车到达终点(应用发布成功)。但实际中,有可能所有项目都下车了,开着空车前进是没有意义的,火车不得不回到起点,等待解决了问题再重来次。还有可能是车上有达官贵人(重点项目,CEO跟投资人拍胸脯的项目),他不上车,谁也别想走,他出了错,大家都跟着回去重来。简化的火车发布模型如图5-17所示。
大型网站建设高可用性经验示意图5-17网站火车发布模型
  由于火车发布模型是基于规则驱动的流程,所以这个流程可以自动化。采用火车发布模型的网站会开发个自动化发布的工具实现发布过程的自动化。根据响应驱动流程,自动构造代码分支,进行代码合并,执行发布脚本等。正常流程下,可以做到发布过程无人值守,无需SCM(网站配置管理员)参与,每个项目相关人员基于流程执行相应的操作,即可完成应用自动发布。人的干预越少,自动化程度越高,引入故障的可能性就越小,火车准点到达,大家按时下班的可能性就越大。
4.灰度发布
  应用发布成功后,仍然可能发现因为软件问题而引入的故障,这时候就需要撤发布回滚,即卸载刚刚发布的软件,将上个版本的软件包重新发布,使系统复原,消除故障。
  大型网站的主要业务服务器集群规模非常庞大,比如某大型应用集群服务器数量超过一万台。一旦发现故障,即使想要发布回滚也需要很长时间才能完成,只能眼睁睁看着故障时间不断增加却干着急。为了应付这种局面,大型网站会使用灰度发布模式,将集群服务器分成若干部分,每天只发布部分服务器,观蔡运行稳定没有故障,第二天继续发布部分服务器,持续几天才把整个集群全部发布完毕,期间如果发现问题,只需要回滚己发布的部分服务器即可。如图5-18所示。
大型网站建设高可用性经验示意图之图5-18网站灰度友布模型
  灰度发布也常用于用户测试,即在部分服务器上发布新版本,其余服务器保持老版本(或者发布另一个版本).然后监控用户操作行为,收集用户体验报告,比较用户对两个版本的满意度,以确定最终的发布版本。这种手段也被称作AB测试。网站建设公司关于大型网站设计高可用性的经验知识分享本文就全部分享结束,如果您喜欢本站的这类型的文章,请持续关注本站。谢谢,博纳网络编辑整理。
文章标题:网站建设高可用性经验之代码控制(下篇)
本文地址:https://www.198bona.com/news/1654.html
如果您觉得案例还不错请帮忙分享:

网站建设

网络推广

解决方案

域名主机

建站行业资讯