容器云之灰度发布设计.docx

《容器云之灰度发布设计.docx》由会员分享，可在线阅读，更多相关《容器云之灰度发布设计.docx（7页珍藏版）》请在优知文库上搜索。

1、灰度发布是应用服务从O到1完全发布的过程.在容器云平台上，一个服务往往部署有很多个实例以根据业务流量实现弹性伸缩.为了的证某个服务或应用的某一特性，或者验证某一服务的功能，在发布一个新的服务版本时，先发布1个或少最实例，通过对新特性的反域分析或新功能的验证分析来决定是否继续发布实例（或替换实例）或回滚.灰度发布和A/B测试、发布新版本和版本替换有相同点也有区别.软件版本控制要说清楚灰度发布和A/B测试、发布新版本、版本替换等概念差别，先说下软件版本控制问题.软件产品对外发布版本号有Alpha、Beta、Released版本等.Alpha、Beta是对外发布的测试版本，Released指的是对外

2、发布的正式版本.每个发布的版本号中通常包括为Major（主版本号）、Minor（小版本号）、Patch（补丁版本号）、Hotfix（热修复版本号）、internal（内部版本号）版本号等.,比如Released版本vl.2.3.4.10,其中1为主版本号，通常软件架构蚕构或升级才会调整主版本号；2为小版本号，通常重要特性发布需要调整小版本号；3为补丁版本号，通常是为了修豆已发布的版本中的系列漏洞而发的一个补丁版本或补丁包；4为热修复版本号，通常用于紧急修宜一些有更大影响的问题，多个的hotfixes可以打包成一个patch补丁包；10为内部控制版本号，通常可用于内部代码或功能进度控制等.我们智

3、借用软件版本控制来说明下服务版本的灰度发布问题。灰度发布和A/B测试灰度发布的目的和A/B测试的目的类似，但并不等同.A/B测试的目的是为了选择A或B而迸行的调研性;则试：灰度发布的FI的是验证某版本中某项功能能否满足需求，比如某功能做了优化可能没有时间进行详细深入的测试,需要部署到生产环境进行实际生产验证,但乂不能全部替换掉原来的版本服务多实例部署，灰度发布是在服务实例级别，同一服务版本，不同实例版本），就可以发布一个灰度版本的实例，引部分流量进行验证。如果没有问题，则一步步替换掉原来全部实例（只有一个实例无法做灰度发布），如果有问题则回退.区分灰度发布和AZB测试，通常需要区分面向前端用户

4、的特性测试还是后端功能的脸证。A/B测试通常是面向前端用户的特性的调研选择性测试，B测试通常有两个入口（如下图A/B测试）:后端功能的验证对用户不可见，面向用户的是一个入口（如下图灰度发布），通过流凝的分发策略来分发制分流仪进行脸证。如果用户的请求在使用灰度版本功能时出现异常或错误就需要立刻回浪。如果没有问题,则可以逐步扩展实例数,直到全部杯换.IDDA/B测试灰度发布A/B测试的版本相当于两个Alpha或Beta版本，等调研测试之后选择两个中的一个正式发布为Released版本。灰度发布的版本相当于发hotfix版本，或者也可以是patch版本，主要用于敏捷修宜和的证功能.灰度发布和发布新版

5、本发布新版本是全新发布一个新的服务版本或应用版本或系统版本。它跟灰度没有关系.是一个全新的发布.不管是否存在一个旧服务版本，也不管新版本和旧版本之间是否存在功能或（和）性能等之间的差别,所以可以看作是两个独立的版本.比如住部署了一个通用版本基础上，为“大客户甲”单独发布部署了一个版本“V甲”。或者如RPP可能同时有很多个版本并行运行，举个最容易理解的例子,比如微软在维护Windows7操作系统版本时，又开发发布了WindorslO。你用WindowslO,我可能还在用Windows7.两个版本同时都需要支持.发布新版本的目的并不是为了验证版本中功能或性能,也不是为了测试两个版本的受欢迎或受认可

6、等的程陡从而选择一个更好的版本。所以发布新版本和灰度发布以及VB测试都是不一样的。,1、CzZl1发布新版本发布新版本相当于发布一个新的Relased版本.这通常是“应用-服务-实例“分层中的”应用系统层，至少是组件服务”层级，而不能是“实例”层次.灰度发布和版本替换灰度发布在灰度状态下，是两个版本的实例并存（多实例状态）。版本替换功能的目的是用新的版本来替换IH的版本，并不需要存在灰度状态的脸证。虽然说灰度发布完成.也是实现了版本哲我，最终结果版本致（也存在回退可能），不过版本称换相时要简单一组，可以是单实例服务的替换，也可以是多实例服务的替换，其实就相当于是服务版本的替换，屈于服务层的操作

7、，它不关心服务有多少实例，一次性全部替换.有人说，应用也可以做版本替换，没错,不过需要考虑的是，是否影响到终端用户.很多人对应用和服务的定义是不一样的，所以可以用是否影里终端用户来判断。如果影响到终端用户，财用户来说就是版本升级,如果对用户透明,只是做后端服务的版本咨推,比如服芬的实现方法或连接配置等发生r改变，简圆的如数据库地址迁移上服务配设.而要更新，服务版本就发生了变化，就需要用新的服务版本替换旧的服务版本RR版本替换版本替换和灰度发布的区别在于是否有一个持续灰度的过程.如果没有持续灰度的过程，就是版本替换；如果有则是灰度发布.最终目的都会实现版本的替换。灰度发布设计闻清楚r上面的几个叔

8、念，我们讨论下在以应用管理为核心的容涔云平台或容器化PaaS平台如何设计灰度发布功能。灰度发布是对服务的实例的替换过程，因此首先灰度发布是服务的一项功施，在应用服务的列表或详情页面需要有灰度发布的入口.服务列表中灰度发布入口在应用服务列表中，可以选择列衣中的个服分进行灰度发布操作。在灰度发布过程中的服务,其状态应该显示“灰度”。非灰度的服务,正常的服务显示“正常”，如果实例有异常，则显示“异常”.点服务名则进入服务详情页面.在服务操作栏，则可以选择：负载配置、灰度发布（灰度状态则显示“回滚”按钮）、弹性配置、治理配置、标签、告警、搜索等操作.全造、反选、K.停止!三SI状态WltilIft版本

9、号胤务0A方式I：贲量占用；女傲傲Wft口SecMsAgseer*MZ-.ic(g*V23M99口%ceBawkeI*aswe三12*1.Micaaiek2Cg点灰度发布则打开服务灰度发布.页面,遂行灰度发布的策略配置，这里要说明的是.灰度发布的愤像名是不变的，所以可以自动获取：版本号会变化，需要选择一个新的版本号，默认可以自动埴入必新的版本号。如果服务只有一个实例，则不可用灰度发布。固定ip方式也可以有多实例，也可以执行灰度发布，只不过其前面往往需要加一层负栽分发能力，比如说用Nginx或F5来实现分发。灰度策跑配置灰度策略配置主要设置灰度发布的策略.发布的策略可以定义很多种,最常用可以使用

10、灰度发布的服务个数或灰废发布白.分比.如果用灰度发布百分比，这里可能有个问题.就是百分比分数可能不合适，比如3个实例设置灰度替换策略50%,那灰度应该是发布几个实例呢？这种情况卜建议卜取整3的5（%是1.5,向卜取整为1，在实例数较少的情况下，尽破用具体的实例个数来电设，实例数比较多时，用百分比比较合适。灰度策略可以很简单，也可以很经杂,比如再引入时间变量，等时区间或不等时区间灰度设置、定时策略和不定时策略等就可能乂带来很多灰度发布选项.比如前24小时发布5%,第2个24小时发布10%,第三个24小时发布40%等。还有异常回滚策略等会使灰度发布策略配四复杂化。在实际的服务灰欧发布中可能需要支持

11、不同的策略选择组合.欢度发布时，不改变服务实例数.调整服务实例数用弹性伸缩功能.灰度发布负毂分发策BS服务运行在灰度状态时，也需要考虑服务的诂求分发策略。服务不同的分发策略会使灰度服务实例接收处理不同量的请求.服务分发策略可能是轮泡、权电、最小连接、响应时间、Hash法等。灰度通常可以使用hash方法，选择些特定的请求来验证。在实现Ingress时候，就可以扩展来支持不同的分发策略.这是平台层的功粕.就不M户k8s调度管理层的能力了，所以需要额外的能力扩展，灰度发布实例列表处于灰度状态的服务,进入服务详情页面,在服务实例列表中需要体现灰度实例和原实例之间的区别。可以通过实例的版本号和背景色等来

12、体现。灰度状态的服务实例版本是不一样的，镜像版本也不一样，但灰度结束后果终版本会统一（无论回滚或滚动发布完成）.实例详情页面需要在表之上显示服务的基本信息，包括服务名、应用名、命名空间、创建人、创建时间、状态、服务暴露方式、服芬地址，资源分配和使用、负莪策略、灰度策略、调度标签、答注等信息，这样一目了然当前服务的信息，也方便到服务、应用等的跳转，从而形成操作闭环.其实应用、服务、实例、Pod,容器、集群、分区、节点、命名空间等各时阪之间都褥要通过其关系关联起来，实现便利地跳转和排序，方便查询和统计.全送、反选、重启.停止CwncelJ1sEInMM23”MinuiVUMMWinMitScMSM

13、lInstame3cmttkMtn*灰度发布设计原则针对当前容器云平台灰度发布的一些不足，从笔者使用体脸用度提出一些想法.灰度发布设计首先不能把多个功能糅合在一起,否则搞不清处要做什么，也使功能设计发杂化：另外也不能把一个操作流程分为几个部分，否则操作体验会很差，做完一步不知道下一步在哪里。其实不只是灰度发布，容器云平台设计是为J用户使用的，而不是开发人员想当然的自以为是，基于经检和体会总结,建议灰欧发布可以遵循以卜原则：原则1:功能设计清Ir矢度发布功能设计需要先厘清概念，不俄把多种概念混在一起,单一功能不能又能发布新版本又能做版本替换等等。不同的概念往往意味希不同的功能，在设计时需要明确区

14、分理解单一功能边界和区别，原JIl2,功能流程完整灰度发布功能施要有完整的流程，能终形成闭环。从灰度发布入口，到策略配价，到自动执行灰度、异常回浪、提醒等.然后返M服务列表，显示服务状态（是否灰度状态）.灰度发布从服务列表回到服务列衣，一个完成闭环流程结束，原则3以用户体疆为最高原则无欧发布设计是为了方便用户完成自己的工作.在设计时需要从用户的角度来思考问题.不能仅仅从开发人员自身的角度为f完成开发功能而应付.所以福要换位思考下，把自己当作用户去设计和实现，才能做好并搬得客户。容器公平台灰度发布在容器公平台上并不是一个核心的功能,不过如果能够支持，住某些场景下会便利很多.本文也只是表面的一些思考，具体设计实现时，还有很多细节的考虑，比如没有新版本的镜像，则不能去做灰度发布：单个实例的服务无法做灰度：服务的历史版本管理和版本回退问题等等.从一个产品功能的设计，也基本上可以看出该产品公司的产品设计能力和相关人员的态度。灰度发布设计不应该成为一个问Sg,如果它依然成为一个问巡，那么一定是人的问题.容器云也发展了好几年了,产品功能不能只解决有无问题,而是需要考虑好不好用问SS了。