一、简介
由于现阶段微服务项目升级频繁，且前台和后台代码的修改会覆盖掉现有版本，回滚不方便 ，为了在微服务架构中做到服务无缝升级和回滚，并做到服务实时升级和回滚，所以在此基础上在网关层做了版本切换的功能(其实也是服务治理的一小部分)。
#下述的案例是通过 springcloud-zuul 过滤器(https://spring.io/projects/spring-cloud)以及分布式配置中心 Apollo(https://github.com/ctripcorp/apollo)处理。
推荐看我近期写的第二版,因为已经大面积改造和优化.( 微服务版本切换初始设计思路(第二版))
二、简单流程
三、流程概要
3、1 项目启动
在项目启动上下文中加载 apollo 的配置，并开启监听各个 apollo 配置的监听器。
3、2 加载 apollo 实际请求与实际项目的关系 S1(单独项目部署，比如不同项目的网关层)
3、2、1apollo 配置
设计初衷：
1)多域名转发不同项目而项目名称一致的情况(比如，nginx 重定向与 SpringCloud 网关层映射)
2)多域名转发相同项目的情况
3)项目名称可以自定义映射。
4)Apollo 在建立新项目时，项目名称的字符长度最多 26，避免个别项目名称过长而不能建立映射关系的情况。
3、2、2java 处理方式
Map<String,String> map = new ConcurrentHashMap<>();
map.put("http://域名a/项目a/","P1");
map.put("http://域名b/项目a/","P2");
#这个 map 中的值不用维护到 db 中
3、3 加载 apollo 实际项目与项目中链接的关系 S2(单独项目部署，只做监听所有项目这一件事)
3、3、1apollo 配置
#一个 namespace 就是一个项目的配置。
#这里的前端版本号指从 http-head 中获取的值。
#这里的链接不仅要考虑上述图中的请求方式，还要考虑 RESTFul 结构与 get 传参的结构。
3、3、2java 处理方式
存入 redis,hash 类型(如果只有一套 Redis 环境，那么可以在 hashkey 中把环境标示加上)
3、4 监听 apollo 对应关系 S1
直接更新 3、2、2 中的 map 即可
3、5 监听 apollo 对应关系 S2
获取某个项目的某个 key：(apollo 中的 key 是不能修改的，只能修改 value)
新增监听 ADDED 状态，先删除所有，再插入所有。
更新监听 MODIFIED 状态，先删除所有，再插入所有。
删除监听 DELETED 状态，直接删除，但不删除监听对象项目名称。
#这里要注意多机部署时，Redis 中数据的更新顺序和最终一致性问题。
#这里为避免项目删除的情况，可以在 Apollo 中加入所有项目的配置列表，在这个监听项目启动时，加载监听所有项目列表的功能，可对应的设置项目的监听新增和删减。
四、Web 请求访问
4、1 网关层过滤器处理
4、1、1 获取请求链接与项目的关系
根据 request.getRequestURL()获取请求链接在 3、2 中获取到实际项目名称
获取前台传入的版本号 web_version
4、1、2 获取真正的请求链接
根据实际项目名称、版本号、请求链接在 3、3 中获取真正的请求连接之后做转发即可。(个人是在 SpringCloud 的网关层利用 zuul 的过滤器来处理，重定向的链接重新放入 RequestContext 中即可。)