灰度发布,,如果需要快速迭代开发上线,又要保证质量,保证刚上线的系统,一旦出现问题那么可以很快的控制影响面,,可以根据自己的配置,来将用户的流量导到新上线的系统上,来快速验证新的功能修改,而一旦出问题,也可以马上的恢复,简单的说,就是一套A/,应该是类似这样的:其中分为几个部分:接入层,接入客户端请求,,,从协议层来说,需要从一开始就设计是根据哪些参数来进行转发的,而且这些参数最好跟具体的协议体内容分开,,如果客户端的请求是走HTTP协议的,那么将这些参数放在HEADER部分就好了,,放在HEADER中的数据,因为没有了加密性,,最简单粗暴的转发策略,可以根据客户端ip地址来做,,新旧服务器要对新旧客户端的协议兼容,也是能做到灰度发布的根本,如何设计一个扩展性好的应用协议,,还需要满足如果管理后台下发了新的转发策略,,使用者只是在上面写了自己的Nginx模块来实现策略的转发,那么可能还需要在每台接入服务器上部署一个Agent的服务,主要用于:接收管理后台下发的策略,更新Nginx配置,,,那么也可以做一个pub-sub模型的订阅者,用ZK或者Redis都可以,,有朋友表示灰度系统的实现太过简单了,因为我目前接触的系统确实比较简单,很多复杂的东西没有考虑周全,如果更大型的业务系统,涉及到的服务更多,还有如果掺杂着数据的迁移,,,假设对外提供了服务A给客户端访问,服务A后面会调用服务B,C,D,此时需要上线一个功能,这个功能涉及到了服务A,C的修改,但是服务B,D不需要变动,换言之,我们的意图是,如果一个客户端请求,走到了新的灰度服务A,,可以给客户端请求进行tag打标记的方式,比如经由新版本服务A处理的请求,全部打上tagA,而在服务C上,也有接入层进行转发,它转发的策略之一就是根据根据这个tag来进行转发,这个系统如下图所示:上图中,请求首先走到了旧版本的服务A上,该服务没有对请求打上tag,,请求首先走到了新版本需要灰度的服务A上,在经过该服务处理后,给请求打上了tag A,由于带上了tag,,涉及到一个调用链路上某几个服务需
灰度发版资料 来自淘豆网m.daumloan.com转载请标明出处.
