持续交付 36 讲
王潇俊
携程系统研发部总监
39682 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
开篇词 (1讲)
结束语 (1讲)
持续交付 36 讲
15
15
1.0x
00:00/00:00
登录|注册

23 | 业务及系统架构对发布的影响

总结
业务、系统架构对发布系统的影响
发布系统设计考虑因素

该思维导图由 AI 生成,仅供参考

在分享《发布系统一定要注意用户体验》《发布系统的核心架构和功能设计》这两大主题时,我分别从用户体验和架构设计两个方面,和你分享了携程灰度发布系统的一些经验和实践。但是,要做出一个出色的发布系统,仅仅考虑这两方面还不够。
因为发布系统最终要服务的对象是业务应用,而业务应用又和业务、企业的系统架构有紧密的联系,所以要做好一套发布系统,我们还要考虑其要服务的业务及系统架构的需要,并且要善于利用系统架构的优势为发布系统服务。
那么接下来,我们就一起来看看,业务、企业整体的系统架构会给发布系统带来什么影响,发布系统又可以借用它们的哪些架构能力。

单机单应用还是单机多应用?

众所周知,.NET 应用采用的基本都是 Windows + IIS 的部署模式,这是一种典型的单机、单 Web 容器、多应用的部署模式。
在这种模式下,单机多应用的问题主要体现在两个方面:
一方面,应用划分的颗粒度可以做到非常细小,往往一个单机上可以部署 20~30 个应用,甚至更多,而且应用与应用间的隔离性较差;
另一方面,由于 IIS 的设计问题,不同虚拟目录之间可能存在共用应用程序池的情况,即多个应用运行在同一个进程下,导致任何一个应用的发布都可能对其他的关联应用造成影响。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

这篇文章从业务和系统架构的角度出发,探讨了设计发布系统时需要考虑的关键因素。首先,作者指出了.NET应用采用的典型部署模式存在的问题,并分享了携程解决这一问题的方案。其次,文章讨论了增量发布和全量发布的选择,以及针对服务的Markup和Markdown操作的控制方法。此外,作者还介绍了检查、预热和点火机制的实现,以及如何保证堡垒流量的问题。通过这些讨论,读者可以了解到发布系统设计中需要考虑的关键因素,包括部署模式选择、发布方式、服务操作控制、验证机制和流量控制等方面的技术特点。文章强调了业务和系统架构对发布系统设计的影响,并提出了利用系统架构的能力来完善发布系统设计的建议。通过简单直接的部署架构和利用系统架构的能力,可以使发布系统具有更优的发布能力,带来意想不到的收益。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《持续交付 36 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(2)

  • 最新
  • 精选
  • 九脉一谷
    在携程,我们借助于 VI(Validate Internal)框架中间件,实现了 Verify 过程的自动化,我们把这个过程形象地叫作“点火”。 这个点火过程,主要做了哪方面的检查?VI是携程自研的吗?

    作者回复: 自研中间件,本身没有具体逻辑,只是暴露的接口和协议,具体检查逻辑由各应用自己实现,比如测试一下db联通性等

    2018-08-27
    2
  • soong
    目前发布工作受架构影响多是负面的!拆分不合理,服务间耦合程度高,基本都要全量发布!而且,还会影响线上的服务。
    2020-03-29
收起评论
显示
设置
留言
2
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部