基础介绍

下文分别从名词解释、灰度升级的作用、灰度升级方案3个方面展开介绍：

1.名词解释

灰度升级：灰度升级是一种升级时候的平滑切换，当有些服务器的客户端要进行升级，可以只对其中一个客户端升级并测试，确保程序无误后再全局升级。也就是说所有服务器可以不同步更新升级，首次只是对一个地区的服务器进行更新升级，待升级完成确保无误后，再对其他地区的服务器进行统一的更新升级。

灰度期：灰度发布从开始到结束的这一段时间，被称为灰度期。

Nginx：Nginx不仅是一个十分轻量级的HTTP服务器，也是一个高性能的HTTP和反向代理服务器，同时还是一个IMAP/POP3/SMTP代理服务器。目前很多国内网站采用Nginx作为Web服务器，如国内知名的新浪、163、腾讯、Discuz、豆瓣等。本次灰度升级就是通过调整Nginx配置文件的方式实现。

2.灰度作用

1.及早获得用户的意见反馈，完善产品功能，提升产品质量；

2.让用户参与产品测试，加强与用户的互动；

3.降低产品升级所影响的用户范围，降低升级风险，避免升级事故。

3.升级方案

实现思路方向可分为两种，一种是在代码中实现，一种是在接入层中实现。灵活的灰度方案一般需要在接入层实现，也就是自定义负载均衡策略实现。本篇文档介绍的就是这种在接入层实现，使用Nginx实现负载均衡的策略。

> > > >实现思路

• 在代码中

一套线上环境，在代码中做开关，对于不同的用户走不同的逻辑。

优点：灵活，粒度细；一套代码(环境)运维成本低；

缺点：灰度逻辑侵入代码。

• 在接入层

多套（隔离的）线上环境，接入层针对不同用户转发到不同的环境中。

优点：无需或少量侵入代码，风险小；

缺点：多套线上环境，运维成本高。

• 接入模式

1.在nginx层实现，例如通过IP地址判断，部分IP段（如办公环境的IP地址段）的请求会引入到灰度环境；

2.在网关层实现（spring-cloud-zuul）；

3.dubbo的灰度，项目中如果使用dubbo，有可能会需要dubbo服务的灰度实现。

2灰度框架

下面介绍灰度升级的整体架构流程，方便大家快速理解。

1.整体框架

灰度发布只升级部分服务，即让一部分用户继续用老版本（下图绿框部分），一部分用户开始用新版本（下图蓝框部分），如果事业用新版本的用户没有意见反馈，接下来就会逐步扩大使用范围，直到将所有用户都迁移到新版本。

 

2.项目架构

在本次项目中，灰度升级包含两个部分，一个是现有环境至云平台正式环境的灰度升级，另一个是云平台发布环境至云平台正式环境的灰度升级，两种情况下升级的主要配置及原理如下：

> > > >现有与云平台正式

 

说明：

1.用户A登录服务，根据ip网段分配到现有环境；

2.用户B登录服务，根据ip网段分配到云平台正式环境。

> > > >云平台发布与正式

 

说明：

1.用户A登录服务，根据ip网段分配到云平台发布环境；

2.用户B登录服务，根据ip网段分配到云平台正式环境。

配置说明

1.现有与云平台正式

现有环境和云平台环境灰度升级实际为调整Nginx配置添加两个upsteamcluster，一套配置为原有CentOS部署的运行环境，另一套配置为云平台部署的运行环境，在Server监听的过程中按照IP段进行配置判断，划分IP区间，实现定义分割IP区间。根据IP区间实现某一段IP访问的为原有CentOS环境，另一端访问的IP区间则为云平台部署环境，运行一段时间后调整为整体IP区间全部访问云平台的模式。

关键配置如下：

定义两个upsteamcluster，一套配置为原有CentOS部署的运行环境，另一套配置为云平台部署的运行环境。

 

在Server监听的过程中按照IP段进行配置判断，划分IP区间，根据IP区间实现某一段IP访问的为原有CentOS环境，另一端访问的IP区间则为云平台部署环境。

 

说明：

1)set $group cluster_classic：设置proxy_pass默认值为“cluster_classic”，现有环境；

2)set $environmentType "classic：设置环境类型默认值为"classic"，现有环境；

3)set $ingressPath "/"：设置proxy_cookie_path路径默认值为“/”，cookie地址保持不变；

4)if ($remote_addr ~ "18.0.9.*")：根据ip是否在这个网段，如果在就走云平台正式环境；

5)set $group cluster_cloud：proxy_pass重新赋值为“cluster_cloud”，云平台正式环境；

6)set $environmentType "cloud_product"：将环境类型重新设置为"cloud_product"，云平台正式环境；

7)if ($environmentType = "cloud_product")：判断是否是云平台正式环境；

8)set $ingressPath "/S01/Product/ESB/"：设置proxy_cookie_path路径；

9)rewrite (/|$)(.*) $ingressPath$2 break：设置重定向路径；

10)proxy_pass http://$group：proxy_pass引用$group；

11)proxy_cookie_path $ingressPath /：proxy_cookie_path引用$ingressPath。

2.云平台发布与正式

云平台内部发布与生产的回复升级，原理与CentOS升级至云平台模式相同，不同的是云平台内部灰度升级是依据访问路径进行区分，核心配置如下：

 

说明：

1)set $ingressPath "/S01/Release/ESB/"：设置proxy_cookie_path路径默认值发布路径；

2)if ($remote_addr ~ "18.0.8.*")：根据ip是否在这个网段选择访问环境，如果在就走云平台正式环境；

3)set $ingressPath "/S01/Product/ESB/"：proxy_cookie_path路径重新赋值为正式路径；

4)rewrite (/|$)(.*) $ingressPath$2 break：设置重定向路径；

5)proxy_cookie_path $ingressPath /：proxy_cookie_path引用$ingressPath。

3.传统与云区别说明

现有环境和云平台正式环境与云平台正式环境和发布环境灰度升级配置的主要区别如下：

1)定义upstream的访问地址不同，一个是云平台部署地址，云平台地址为动态替换proxy_pass；另一个是现有CentOS部署环境地址，现有部署无需动态替换proxy_pass；

2)云平台与现有部署环境中的proxy_pass引用upstream不同；proxy_cookie_path设置的地址不同，现有部署为“/”，不转换cookie路径，云平台需要转换为内部Ingress路径。

心得总结

灰度升级可以比较有效地解决服务升级对用户的影响，之前一直使用调整nginx配置进行全量更新升级，灰度升级方式并没有被使用，通过本次在项目中使用灰度升级方式学习到了许多新的知识。

1.能力欠缺

在开始配置nginx时，想要使其支持根据IP进行分流，需要设置变量的方式，而其中有一处配置问题一直没有攻克，尝试多种方式依旧没有解决。在尝试过程中感受到了自己在网络层面、代理方面能力的不足，真是有些力不从心，最后还是在公司领导的帮助下解决的，后续不仅要对底层代码加深研究，也要对上层逻辑深入了解。

2.知识收获

在这次使用Nginx实现灰度升级过程中，学习到了许多新的知识，同时也巩固了已经积累的知识。对Nginx中的变量更加熟知，掌握了在Nginx里script的常规用法、变量的使用范围和配置重定向路径的方法。

3.个人总结

升级策略不仅仅只有灰度发布一种，还有滚动发布和蓝绿部署。本次我们选择灰度升级的原因是这种方式的影响用户少、配置简单。后续会继续了解滚动发布和蓝绿部署的优缺点及配置方法，融入到产品项目体系中。

团队作战不仅需要相互协作，自己也要多尝试多思考，不要灰心不要轻言放弃，领导的指点为我提供了解决思路，这些经历也让我不断成熟，在以后处理各种问题时会考虑得更加全面。基于K8S云平台来构建集成开发解决方案、开发集成方案未来是数通畅联的主打方式，K8S云平台管理中心UMC是公司SOA应用集成、数据治理分析套件的管理底座，融入了大量平台产品与集成项目结合的最佳实践和管理思想，也是构建集成中台、数据中台、应用中台的利器，未来考虑陆续输出云平台相关文档。

注意：本文归作者所有，未经作者允许，不得转载