如何获得讲师PPT：
扫码关注公众号，后台回复「0412」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
Q&A环节答疑：
一、灰度环境是不是单独一套更好还是怎么样？
灰度环境它肯定是单独一套，但这个单独是根据你的隔离性去做的。就比如说我前面讲到一些K8s，包括jk，包括你消息队列，对吧？隔离只要去制定一个隔离策略，然后把它隔离出来，它就可以认为是单独的一套，但是这个单独的一套并不意味着它是单独部署的一套物理集群。如果是单独部署的一套物理集群的话，那它其实就相当于是一个预发布环境了。对吧? 它可能就丧失掉灰度的意义了。完全不同的两套机器的话，我认为这个没有必要，也许它带来的一些好处，但它其实会带来更多的问题。比如跨集群的访问就是一个非常非常难解决的问题。
二、消息队列隔离，为什么没有考虑不同的消费组？
其实不同的消费组在做消费隔离的时候，你就一定使用的是不同的消费组，就我之前提到的一种消费去做过滤的话，你就一定是使用不同的消费组。不同的消费组的话，如果灰度跟生产在同一个消费组里面的话，那一条消息只会被灰度消费，或者是被生产消费，你只有使用两个不同的消费组的话，你才能说一条消息，同时被两个消费组消费。我提到的那个第二种隔离方案其实就是消费做隔离。
三、Redis怎么进行灰度？
之前讲到数据一致性的时候，我没有讲这一块，Redis相当于存储层的一个灰度，对吧？存储层的灰度像Redis 、Mysql这些实施起来和业务数据的相关性很高。以一个场景为例，我们通用的存储就是mysql，你要去对mysql里面存储的数据去做一个灰度方案的设计，你要考虑很多问题，但是这些问题都跟你的数据是强相关的，跟你数据的功能是强相关的。举个账单分期的例子，比如说我现在生成了一笔订单，可能是一个分期购买的订单，那根据这笔订单去生成一些账单，那根据这些账单可能又有一些处理逻辑。那在这种场景下呢，这些账单就比如说我在灰度之前所生成的订单，它是一个账单的生成方案。跟在灰度之后，根据订单去生成了一个账单的逻辑，它其实是需要你对数据，去做一个灰度标识。这是第一个。就是你对数据要有一个灰度跟生产的区分，要根据这个订单是灰度的流量生成的？还是说是生产的流量生成的？去做一个标识。那在有了这个标识之后，要考虑一个问题就是：如何恢复？如果说我认为这个订单是灰度流量生成的，那接下来账单的生成逻辑是否要走灰度？这是要根据当时的一个业务场景去考虑的，如果是从平台侧来做的话，会遵循一个原则，就是灰度所生成的数据要被灰度处理，就比如说我现在这一笔订单，它是生产流量所生成的，那这个时候，我们可能会有两种处理方式。生产的那个数据。它能被灰度处理，它也能被生产处理，也就是说灰度是对那个数据所做兼容的。这是两种方案，但是它核心的就是不管是Mysql还是Redis ，你存进去的数据，都要考虑到要去做一个数据的打标，但这种打标它也有方案，其实又回到那个隔离性的问题，就比如说是用影子库，或者说不做库的隔离，做表的隔离，或者说表的隔离都不做，就是同一张表，然后在表里面对不同的消息去打标，这个都是在实践过程中需要考虑的问题，但是这个其实没有一个通用的解决方案，它更多的是要根据你的业务场景去挂钩的。
四、怎么控制灰度的影响范围？
我们做灰度来说，更多的是去考虑说怎么去控制灰度不去影响生产？所以很重要的一个手段就是灰度的流量应该是逐步放大的。就比如说从实际的一个应用场景来说，我先会一个厂家，商家验证没问题之后，我就把流量一下子全都放掉，把所有的流量都切进来。这就是从流量的那个控制的角度来说。
还有一个就是，本身你做这个灰度方案的时候，你就要去考虑它的隔离性，把它跟生产尽量的去隔离开。但是在这个隔离性的设计里面，你要去考虑成本、考虑稳定性、这个稳定性其实就对应了灰度的影响范围。它的影响范围足够小，那就是它对生产的稳定性的干扰就足够低。所以在实施灰度方案，也就是通过灰度平台去制定灰度发布的节奏的时候，流量应该是逐步放大的。第二个是做灰度平台的时候，要认真的去考虑隔离性的问题，至于怎么去做，我前面已经讲过了，这个我就不再赘述了。
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫 