前言
车队管理类似的SaaS平台，从0到1，咱继续..
上一篇咱撸到域名解析来识别不同租户的支持，现在咱在分析下如何升级如何做灰度发布！
（我是后半夜Java，在掘金这分享下经验，那些靠copy的搬运作者，不要随意copy到其他平台了，哪天闲的就去投诉）
灰度发布
做SaaS平台，就要提前考虑好灰度发布的方案，当然这个需要看整个平台设计的方案，从操作层面上看，一般就是从运营侧会提这块，或他们来操作模块。
灰度发布，目的：
及早获得用户的意见反馈，完善产品功能，提升产品质量 让用户参与产品测试，加强与用户互动 降低产品升级所影响的用户范围。
那么给运营操作上，那就需要2个需求场景：
需要一个放量配置，给产品/运营等工作人员配置放量策略；
需要做到同一个用户始终访问的是同一个版本的代码，如果同个用户上个请求访问的是V1.0版本，下个请求访问的是V2.0版本，就可能会出问题。
灰度发布的需求还没下来，这个优先级没那么高，业务功能优先原则，这个排后哈。
（图画的好不好不重要，明白意思就可以，毕竟不是汇报的PPT）
好的做法
好的解决方案，就是上一篇所讲述的，通过域名解析来处理。如果运营侧可以选出那些租户要来做灰度升级，那么这些租户的三级域名请求进来的就是会请求到V2.0的接口版本。
这篇没法给啥代码了~
总结
灰度发布是每个SaaS都要考虑的， 作为优秀的程序猿，在设计架构的时候，就要考虑到后面的灰度发布需要。
在我的设计里还有另外个方案，就是AOP，处理下不同有灰度发布的场景时，去调用灰度服务接口。 还有啥好的解决方案么？
SaaS系统从0到1搭建，下篇继续....
