基于SpringMVC的API灰度方案

  一、配景

  在微服务重构时，我们常碰到这个业务场景：同样是/api/test，我们实现了新逻辑和老逻辑，然后根据定制的灰度计谋，通常灰度API和老API两者都必要支持用户使用。
  那么是否有比力好解决方案，帮忙我们完成同名同方法同参数列表的API灰度动态路由的方案呢？
  我们就基于SpringMVC，通过对底层RequestMappingInfo的参数定制化，实现了methodHandler的动态路由决策，从而到达API灰度动态路由目标。
  

  二、实现原理

  我们总的来说，干了两件事情：
  

  

• 第一件事
  服务启动时，在initMethodHandler实行时，对RequestMappingInfo初始化时，就将灰度决策器RouterDecisionMaker，以@PathRouterDecisionMaker决策器注解的情势，预加载到customInfo里
  
• 第二件事
  服务运行期，在路由匹配器PathMatcher里，会剖析RequestMappingInfo，最终实行灰度决策器RouterDecisionMaker，并挑选最符合的RequestMappingInfo映射的methodHandler去实行响应逻辑
  

  三、实现方案

  1、界说决策器注解：@PathRouterDecisionMaker

1. @Target({ElementType.TYPE, ElementType.PACKAGE, ElementType.METHOD})
2. @Retention(RetentionPolicy.RUNTIME)
3. public @interface PathRouterDecisionMaker {
4.     Class<? extends RouterDecisionMaker> decision();
5.     String resourceCondition() default "";
6.     int order() default 0;
7. }

复制代码

分析：
  

• decision()：决策属性，指向路由决策器类，即RouterDecisionMaker接口
  

     注解（Annotation）：仅提供附加元数据支持，并 不能实现任何操作，必要另外的 Scanner 根据元数据实行相应操作。
    2、路由决策器：RouterDecisionMaker接口

  RouterDecisionMaker接口，界说了决策器的匹配计谋方法

1. public interface RouterDecisionMaker {
4.     /**
5.      * 路由决策器的最终决策方法
6.      * @param pathPartRequest
7.      * @return 匹配返回的资源类型
8.      */
9.     boolean matches(PathPartRequest pathPartRequest);
10. }

复制代码

  2.1 灰度决策器-ApiGrayDecisionMaker（返回true）

1. @Component(value = "ApiGrayDecisionMaker")
2. public class ApiGrayDecisionMaker implements RouterDecisionMaker {
5.     @Override
6.     public boolean matches(PathPartRequest pathPartRequest) {
7.         return Boolean.TRUE;
8.     }
11. }

复制代码

代码分析：
  

• 为了方便实践，我们写死一个决策匹配计谋为TRUE
  

  2.2 灰度决策器-ApiNotGrayDecisionMaker（返回false）

1. @Component("ApiNotGrayDecisionMaker")
2. public class ApiNotGrayDecisionMaker implements RouterDecisionMaker {
5.     /**
6.      * 取反，跟 ApiGrayDecision#matches 互斥
7.      * @param pathPartRequest
8.      * @return
9.      */
10.     @Override
11.     public boolean matches(PathPartRequest pathPartRequest) {
12.         return Boolean.FALSE;
13.     }
14. }

复制代码

代码分析：
  

• 为了方便实践，我们写死一个决策匹配计谋为FALSE
  

  2.3 决策信息

  RouterPathRequest，提供数据给决策器

1. public class RouterPathRequest {
4.     private final String pattern;
5.     private final String url;
6.     private final Map<String, String> pathVariables;
7.     private final RouterPatternKey routerPatternKey;
8.     private final String routeCondition;
9.     private final HttpServletRequest request;
12.     public RouterPathRequest(HttpServletRequest request, String pattern, String url, Map<String, String> pathVariables,
13.             RouterPatternKey routerPatternKey, String routeCondition) {
14.         this.request = request;
15.         this.pattern = pattern;
16.         this.pathVariables = pathVariables;
17.         this.url = url;
18.         this.routerPatternKey = routerPatternKey;
19.         this.routeCondition = routeCondition;
20.     }
23.     public static RouterPathRequest build(HttpServletRequest request, String pattern, String url,
24.             Map<String, String> pathVariables, RouterPatternKey routerPatternKey, String routeCondition) {
25.         return new RouterPathRequest(request, pattern, url, pathVariables, routerPatternKey, routeCondition);
26.     }
27.     //...getter&setter
28. }

复制代码

代码分析：
  

• 实际是对HttpServletRequest的二次封装，并提取了一些常用上下文数据到属性
  

  2.4 决策注解探测器

  WebRouterDecisionMakerDetection

1. /**
2. *  PathRouterDecisionMaker注解提取器
3. *   - 从方法注释提取注解
4. */
5. public class WebRouterDecisionMakerDetection {
6.     public PathRouterDecisionMaker detect(Method handlerMethod) {
7.         if (Objects.isNull(handlerMethod)) {
8.             return null;
9.         }
10.         return AnnotatedElementUtils.findMergedAnnotation(handlerMethod, PathRouterDecisionMaker.class);
11.     }
12. }

复制代码

2.5 自界说-路由匹配计谋

  WebRouterDecisionCondition 
  继续了 AbstractRequestCondition，会在创建RequestMappingInfo的填入customCondition条件时，被回调使用。
  

• 抽象类AbstractRequestCondition实现了 RequestCondition 接口，最终回调业务的getMatchingCondition实现
  
• RequestCondition具体实现类都继续自AbstractRequestCondition抽象基类，都是针对请求匹配的某一个方面：请求路径，请求头部，请求方法，请求参数，可消费MIME,可生成MIME等等。
  

     1、AbstractRequestCondition：这是一个抽象类，实现了 RequestCondition 接口，并提供了一1些默认实现。它简化了自界说条件的实现过程。 
   2、RequestCondition：这是一个接口，界说了用于匹配请求的条件。它包罗两个主要方法： 
   - getMatchingCondition(HttpServletRequest request)：返回与给定请求匹配的条件。
   - combine(RequestCondition<?> other)：将当前条件与其他条件组合。
   

1. /**
2. * 自定义的路由匹配条件
3. */
4. public class WebRouterDecisionCondition extends AbstractRequestCondition<WebRouterDecisionCondition> {
7.     private final PathRouterDecisionMaker pathRouterDecisionMaker;
10.      // getter/setter/constructor...
13.     /**
14.      * 创建 RequestMappingInfo 的时候，会进行两件事情：
15.      * 1. 查看 method 上的 @RequestMapping 信息，同时根据 method 类型，创建 condition。
16.      * WebRequestMappingHandlerMapping#getCustomMethodCondition(Method)
17.      * - 创建相应的 condition
18.      * 2. 查看 Controller 上的 @RequestMapping 信息，同时根据 Controller 类型，创建 condition。
19.      * WebRequestMappingHandlerMapping#getCustomTypeCondition(Class)
20.      * - 创建相应的 condition
21.      *
22.      * 查看：org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping#createRequestMappingInfo(AnnotatedElement)
23.      *
24.      * @param other
25.      * @return
26.      */
27.     @Override
28.     public WebRouterDecisionCondition combine(WebRouterDecisionCondition other) {
29.         return other;
30.     }
33.     @Override
34.     public WebRouterDecisionCondition getMatchingCondition(HttpServletRequest request) {
35.         // 【1】
36.         boolean isDirectUrlMatched = this.checkRequestMappingInfo(request);
37.             // 【2】
38.         if (!isDirectUrlMatched) {
39.             return this;
40.         }
41.         // 【3】
42.         return checkPathRouterDecisionMaker(request, this.pathRouterDecisionMaker) ? this : null;
43.     }
46.     /**
47.     * 分析RequestMappingInfo是否有定制化信息customCondition
48.     */
49.     public static boolean checkRequestMappingInfo(HttpServletRequest request) {
50.         // 【1.1】
51.         String lookupUrl = getLookupUrl(request);
52.          // 【1.2】   
53.         Object requestMappingInfoObject = request.getAttribute(REQUEST_MAPPING_MATCHING);
54.         if (!(requestMappingInfoObject instanceof RequestMappingInfo)) {
55.             return false;
56.         }
57.        //【1.3】   
58.         RequestMappingInfo requestMappingInfo = (RequestMappingInfo) requestMappingInfoObject;
59.         PatternsRequestCondition patternsRequestCondition = requestMappingInfo.getPatternsCondition();
60.         if (ObjectUtils.isEmpty(patternsRequestCondition)) {
61.             return false;
62.         }
63.         Set<String> patterns = patternsRequestCondition.getPatterns();
64.         if (CollectionUtils.isEmpty(patterns)) {
65.             return false;
66.         }
67.         for (String pattern : patterns) {
68.             // 【1.4】
69.             if (StringUtils.equals(pattern, lookupUrl)) {
70.                 return true;
71.             }
72.         }
73.         return false;
74.     }
77.     /**
78.     * 检查决策器注解
79.     */
80.     public static boolean checkPathRouterDecisionMaker(HttpServletRequest request, PathRouterDecisionMaker pathRouterDecisionMaker) {
81.         String lookupUrl = DirectPathRouterMatchCondition.getLookupUrl(request);
84.         // 【3.1】
85.         if (ObjectUtils.isEmpty(pathRouterDecisionMaker)) {
86.             return true;
87.         }
90.         RouterDecisionMaker routerDecisionMaker = RouterConstraintsUtils.getRouterConstraint(pathRouterDecisionMaker.decision());
91.         // 【3.2】
92.         if (ObjectUtils.isEmpty(routerDecisionMaker)) {
93.             return true;
94.         }
95.         // 【3.3】
96.         RouterPathRequest routerPathRequest =
97.                 RouterPathRequest.build(request, lookupUrl, lookupUrl, new HashMap<>(),
98.                     new RouterPatternKey(lookupUrl, pathRouterDecisionMaker), null);
101.         // 【3.4】
102.         return routerDecisionMaker.matches(routerPathRequest);
103.     }
106.     public static String getLookupUrl(HttpServletRequest request) {
107.         Object lookupUrl = request.getAttribute(HandlerMapping.LOOKUP_PATH);
108.         return ObjectUtils.isEmpty(lookupUrl) ? "" : lookupUrl.toString();
109.     }
112. }

复制代码

代码分析：
  服务运行时，获取methodHandler，会回调 WebRouterDecisionCondition#getMatchingCondition
  

• 【1】checkRequestMappingInfo 路由匹配分析：分析RequestMappingInfo是否和url相匹配
  
  
  
  • 【1.1】getLookupUrl获取url
    
  • 【1.2】获取RequestMappingInfo
    
  • 【1.3】获取RequestMappingInfo对象中的PatternsRequestCondition对象，然后获取其中的URL模式聚集
    
  • 【1.4】遍历URL模式聚集，如果找到与当前请求URL相匹配的模式，则返回true
    
  
  
• 【2】如果不满足路径匹配，也没有RequestMappingInfo没有特别的customCondition要填充，就直接返回把
  
• 【3】如果满足路径匹配，checkPathRouterDecisionMaker：检查是否包罗灰度路由器，即：判断有没有@PathRouterDecisionMaker注解元信息
  
  
  
  • 【3.1】路由 Controller 方法没有被 @PathRouterDecisionMaker注解修饰
    
  • 【3.2】@PathRouterDecisionMaker 注解中没有 RouterDecisionMaker 决策器，默认视为 true
    
  • 【3.3】直接路径匹配，则 lookupUrl 和 pattern 相匹配
    
  • 【3.4】实行决策器matches方法
    
  
  

  3、界说Controller：灰度和非灰度API

1. @RestController
2. public class ConstraintController {
5.     @PathRouterDecisionMaker(decision = ApiNotGrayDecisionMaker.class)
6.     @GetMapping("/test_constraint")
7.     public String test() {
8.         return "非灰度：老API..";
9.     }
12.     @PathRouterDecisionMaker(decision = ApiGrayDecisionMaker.class)
13.     @GetMapping("/test_constraint")
14.     public String test2() {
15.         return "灰度：新API..";
16.     }
17. }

复制代码

代码分析：
  

• 可见上面界说了两个同为GET方法，参数列表相同，RequestMapping的Url也一样，只是方法名不同的一组灰度和非灰度API。
  
• 同时两个API，都用了@PathRouterDecisionMaker注解修饰，但指定了不同的决策器（非灰度API是ApiNotGrayDecisionMaker，灰度API是ApiGrayDecisionMaker）
  

  4、MVC框架定制化工作

  4.1 MVC设置器裁剪：WebMvcRegistrations

     WebMvcRegistrations 是 Spring MVC 框架中的一个接口，用于自界说 Spring MVC 的设置。通过实现这个接口，你可以注册自界说的 RequestMappingHandlerMapping、RequestMappingHandlerAdapter 和其他与 Spring MVC 相关的组件。
    WebRequestMappingRegistrationsConfig 是一个设置类

1. @Configuration
2. public class WebRequestMappingRegistrationsConfig implements WebMvcRegistrations {
3.     /**
4.      * 返回一个自定义的 RequestMappingHandlerMapping 实例，用于处理 HTTP 请求映射。
5.      *
6.      * 具体怎么对请求进行映射呢？，参考 WebRequestMappingHandlerMapping
7.      * - WebRequestMappingHandlerMapping 有路径匹配器：WebRouterPathConstraintMatcher
8.      *    - WebRouterPathConstraintMatcher 有路径匹配器：PathMatcher#match
9.      */
10.     @Override
11.     public RequestMappingHandlerMapping getRequestMappingHandlerMapping() {
12.         WebRequestMappingHandlerMapping requestMappingHandlerMapping = new WebRequestMappingHandlerMapping();
13.         requestMappingHandlerMapping.setPathMatcher(routerPathConstraintMatcher());
14.         return requestMappingHandlerMapping;
15.     }
18.     @Bean
19.     public WebRouterPathConstraintMatcher routerPathConstraintMatcher() {
20.         return new WebRouterPathConstraintMatcher();
21.     }
22. }

复制代码

代码分析：
  

• 界说了一个WebRequestMappingHandlerMapping，它负责：请求定制化映射处置处罚工作
  
  
  
  • 具体的处置处罚逻辑，交给手下的WebRouterPathConstraintMatcher来办
    
  • 且看4.2教学WebRequestMappingHandlerMapping
    
  • 且看4.3教学WebRouterPathConstraintMatcher
    
  
  

  4.2 路由映射器裁剪：

  AbstractRequestMappingHandlerMapping

  WebRequestMappingHandlerMapping
  

• 继续了抽象类，抽象类AbstractRequestMappingHandlerMapping实现了InitializingBean接口，最终会回调业务的initHandlerMethods实现
  

     在Spring MVC中，请求条件用于决定一个特定的HTTP请求是否应该被一个控制器方法处置处罚。
   

1. @ScanPackagePathConstraint(basePackageNames = {"com.bryant"})
2. public class WebRequestMappingHandlerMapping extends AbstractRequestMappingHandlerMapping {
5.     private WebRouterDecisionMakerDetection webRouterDecisionMakerDetection;
8.     public WebRouterDecisionMakerDetection getPathConstraintDetection() {
9.         return this.webRouterDecisionMakerDetection;
10.     }
13.     public void setPathConstraintDetection(WebRouterDecisionMakerDetection webRouterDecisionMakerDetection) {
14.         this.webRouterDecisionMakerDetection = webRouterDecisionMakerDetection;
15.     }
18.     @Override
19.     protected void initHandlerMethods() {
20.         // 加入决策探测器
21.         this.setPathConstraintDetection(new WebRouterDecisionMakerDetection(this.packageRouterConstraintRegistry));
22.         // 初始化HandlerMethods
23.         super.initHandlerMethods();
24.     }
27.     /**
28.      * 循环遍历所有的 @RequestMapping 对一个的路由元信息，进行匹配，匹配到最佳 RequestMappingInfo
29.      * ```
30.      * for (RequestMappingInfo mapping : mappings) {
31.      * // 依次匹配 method\produces\consumes\header\...\patterns\customCondition
32.      * }
33.      * ```
34.      */
35.     @Override
36.     protected RequestMappingInfo getMatchingMapping(RequestMappingInfo info, HttpServletRequest request) {
37.         // 这里步骤是必须的（参考【4.3】步骤的），用来填充HttpServletRequest的上下文，将RequestMappingInfo数据透传往下，key = REQUEST_MAPPING_MATCHING
38.         request.setAttribute(REQUEST_MAPPING_MATCHING, info);
39.         RequestMappingInfo requestMappingInfo = super.getMatchingMapping(info, request);
40.         // 获取结束后，记得移除上下文数据
41.         request.removeAttribute(REQUEST_MAPPING_MATCHING);
42.         return requestMappingInfo;
43.     }
46.     /**
47.      * 直接调用 AbstractHandlerMethodMapping#lookupHandlerMethod(java.lang.String, javax.servlet.http.HttpServletRequest) 即可，没有做特殊处理
48.      * @param lookupPath 请求路径，通过 {@link org.springframework.web.util.UrlPathHelper} 获取
49.      * @param request
50.      * @return
51.      * @throws Exception
52.      */
53.     @Override
54.     public HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {
55.         return super.lookupHandlerMethod(lookupPath, request);
56.     }
59.     /**
60.      * 为每一个请求方法对应的 RequestMappingInfo 路由元信息，创建一个 RequestCondition
61.      *
62.      * @param method
63.      * @return
64.      */
65.     @Override
66.     protected RequestCondition<?> getCustomMethodCondition(Method method) {
69.         // 非灰度接口
70.         PathConstraintDetection pathConstraintDetection = this.getPathConstraintDetection();
71.         if (ObjectUtils.isEmpty(pathConstraintDetection)) {
72.             return new WebRouterDecisionMakerDetection(null);
73.         }
76.         // 灰度接口处理
77.         PathRouterDecisionMaker pathRouterDecisionMaker = pathConstraintDetection.detect(method);
78.         if (ObjectUtils.isNotEmpty(pathRouterDecisionMaker)) {
79.             return new WebRouterDecisionMakerDetection(pathRouterDecisionMaker);
80.         }
83.         // 兜底处理
84.         return new WebRouterDecisionMakerDetection(null);
85.     }
88.     @Override
89.     protected HandlerMethod handleNoMatch(Set<RequestMappingInfo> infos, String lookupPath, HttpServletRequest request) throws ServletException {
90.         return super.handleNoMatch(infos, lookupPath, request);
91.     }
92. }

复制代码

代码分析：
  

• setPathConstraintDetection：加入决策探测器，由于后续会用到
  
• initHandlerMethods：初始化入口，实际走了AbstractRequestMappingHandlerMapping抽象类的initHandlerMethods
  
  
  
  • 步骤一：创建HandlerMethod
    
  • 步骤二：校验validateMethodMapping
    
  • 步骤三：放入mappingLookup
    
  • 预加载RequestMappingInfo：通过MappingRegistry，将原API和灰度API的RequestMappingInfo信息，注册到mappingLookup这个Map里（key是RequestMappingInfo，value是HandlerMethod）
    
  • 本质是：RequestMappingInfo里面包罗了路由计谋，我们通过在handlerMethod方法上打注解，如此透传到RequestMappingInfo#customConditionHolder；解决了SpringBoot启动服务，规避了RequestMappingHandler重复异常
    
  • 核心是：AbstractHandlerMethodMapping.MappingRegistry#register，分为三个步骤（受限篇幅）
    
  
  
• getMatchingMapping：循环遍历所有的 @RequestMapping 聚集，根据路由注解元信息，进行匹配，匹配到最佳 RequestMappingInfo
  
  
  
  • for (RequestMappingInfo mapping : mappings)
    
  
  
• lookupHandlerMethod：将HTTP请求映射到相应的methodHandler处置处罚器方法上；这里直接调用了父类AbstractHandlerMethodMapping的同名方法，没有进行任何额外的处置处罚（但真实业务可以按需裁剪功能）
  
• getCustomMethodCondition：我们通过 WebRouterDecisionMakerDetection 完成自界说RequestMappingInfo#CustomCondition的注入和判断
  
  
  
  • 返回：一个WebRouterDecisionMakerDetection对象，里面包装了 @PathRouterDecisionMaker注解元信息，而注解则包罗了决策器对象PathRouterDecisionMaker，即该方法返回的Condition包罗了灰度决策器
    
  • WebRouterDecisionMakerDetection剖析见：【2.4】-决策注解探测器
    
  
  
• handleNoMatch：兜底处置处罚：在处置处罚HTTP请求时，如果找不到完全匹配的RequestMappingInfo（即URL和HTTP方法等都不匹配），则根据不同的不匹配类型抛出相应的异常。
  

  4.3 路由匹配器裁剪：PathMatcher

  WebRouterPathConstraintMatcher，实现了PathMatcher接口，实现了从 HttpServletRequest 提取 @PathRouterDecisionMaker注解元信息，灰度决策器PathRouterDecisionMaker

1. public class WebRouterPathConstraintMatcher implements PathMatcher {
4.     /**
5.      * 自定义了一个key到request的attribute，如此通过HttpServletRequest的上下文透传数据
6.      */
7.     String REQUEST_MAPPING_MATCHING = PathMatchedConstant.class.getName() + ".requestMappingMatching";
10.     @Override
11.     public boolean match(String pattern, String path) {
14.         // 【0】从上下文获取请求，本质上是Spring内置的工具类实现的
15.         HttpServletRequest request = ServletRequestUtil.getCurrentRequest();
18.         // 【1】提取 @PathRouterDecisionMaker注解元信息
19.         PathRouterDecisionMaker pathRouterDecisionMaker = getRouterConstraintTypeByMatchingRequestMappingInfo(request);
20.         Class<? extends RouterDecisionMaker> routerConstraintClass = ObjectUtils.isEmpty(pathRouterDecisionMaker) ? null : pathRouterDecisionMaker.decision();
23.         // 【2】 封装了一层 RouterPatternKey
24.         RouterPatternKey routerPatternKey = new RouterPatternKey(pattern, pathRouterDecisionMaker);
27.         // 【3】有约束条件处理
28.         if (!ObjectUtils.isEmpty(routerConstraintClass)) {
29.             // 【3.1】提取 RouterDecisionMaker决策器（灰度决策器-可能是ApiNotGrayDecisionMaker，也可能是ApiGrayDecisionMaker）
30.             RouterDecisionMaker routerDecisionMaker = RouterConstraintsUtils.getRouterConstraint(routerConstraintClass);
31.             // 【3.2】构造决策信息 RouterPathRequest
32.             RouterPathRequest routerPathRequest = RouterPathRequest.build(request, pattern, path, null, routerPatternKey, pathRouterDecisionMaker.resourceCondition());
33.             // 【3.3】路由决策器执行
34.             if (!routerDecisionMaker.matches(routerPathRequest)) {
35.                 return false;
36.             }
37.         }
38.         // 不存在约束条件
39.         return true;
40.     }
43.     /**
44.      * 每次在匹配的时候，当前匹配的 RequestMappingInfo 存储在 request 上下文中：
45.      * ```
46.      * for (RequestMappingInfo mapping : mappings) {
47.      *     request.setAttribute(REQUEST_MAPPING_MATCHING, mapping);
48.      *     // 依次匹配 method\produces\consumes\header\...\patterns\customCondition
49.      *     request.removeAttribute(REQUEST_MAPPING_MATCHING, mapping);
50.      * }
51.      * ```
52.      * 以下方法获取每一个正在匹配的 RequestMappingInfo 中 customCondition 对应的 RouterConstraint 约束条件
53.      * @param request
54.      * @return
55.      */
56.     private PathRouterDecisionMaker getRouterConstraintTypeByMatchingRequestMappingInfo(HttpServletRequest request) {
57.         Object requestMappingInfoObject = request.getAttribute(REQUEST_MAPPING_MATCHING);
58.         // 【1.1】取出 RequestMappingInfo 对象
59.         if (!(requestMappingInfoObject instanceof RequestMappingInfo)) {
60.             return null;
61.         }
64.         RequestMappingInfo requestMappingInfo = (RequestMappingInfo) requestMappingInfoObject;
67.         // 【1.2】RequestMappingInfo对象的customCondition不为空，说明有灰度决策器or非灰度决策器，
68.         // 通过【4.2】步骤之后，自定义的路由匹配条件，会塞到一个新的WebRouterDecisionCondition对象，
69.         // 因此要读出，自然是从 WebRouterDecisionCondition 提取出来 PathRouterDecisionMaker注解元信息
70.         RequestCondition<?> requestCondition = requestMappingInfo.getCustomCondition();
71.         if (!(requestCondition instanceof WebRouterDecisionCondition)) {
72.             return null;
73.         }
76.         // 【1.3】从 WebRouterDecisionCondition 提取出来 PathRouterDecisionMaker注解元信息
77.         WebRouterDecisionCondition condition = (WebRouterDecisionCondition) requestCondition;
78.         Collection<PathRouterDecisionMaker> pathRouterDecisionMakers = condition.getContent();
79.         return CollectionUtils.isEmpty(pathRouterDecisionMakers) ? null : new ArrayList<>(pathRouterDecisionMakers).get(0);
80.     }
81. }

复制代码

代码分析：
  

• WebRouterPathConstraintMatcher#match：
  
  
  
  • 【0】从上下文获取请求，本质上是Spring内置的工具类实现的
    
  • 【1】提取 PathRouterDecisionMaker 决策器
    
    
    
    • 【1.1】取出 RequestMappingInfo 对象
      
    • 【1.2】从RequestMappingInfo 对象拿customCondition数据，即WebRouterDecisionCondition
      
    • 【1.3】从 WebRouterDecisionCondition 提取出来 PathRouterDecisionMaker注解元信息并返回
      
    
    
  • 【2】 在@PathRouterDecisionMaker注解元信息，封装了一层 RouterPatternKey对象
    
  • 【3】有束缚条件处置处罚
    
    
    
    • 【3.1】提取 RouterDecisionMaker决策器（灰度决策器-可能是ApiNotGrayDecisionMaker，也可能是ApiGrayDecisionMaker）
      
    • 【3.2】构造决策信息 RouterPathRequest
      
    • 【3.3】路由决策器实行，也是我们最核心灰度逻辑的实现了，现在我们是写死为true or false的返回值，但其实我们可以通过注入RestTemplate实现更复杂的灰度计谋。
      
    
    
  
  

  4.4 总结

  通过以上的设置，我们实现了MVC框架的定制化工作，通过ServeltHttpRequest，将@PathRouterDecisionMaker注解元信息透传给了路由映射器，再通过灰度决策器确认是否返回RequestMappingInfo。
  5、测试

  访问：http://localhost:8853/test_constraint，实现路由的动态匹配，请求抵达新API灰度的MethodHandler并被处置处罚完成。
  

  四、源码剖析

  上面分析了实现原理和实现方案，下面则从MVC初始化的角度来分析。
  1、预加载：RequestMappingInfo

  初始化入口是：AbstractRequestMappingHandlerMapping抽象类的initHandlerMethods
  预加载是：通过MappingRegistry，将原API和灰度API的RequestMappingInfo信息，注册到mappingLookup这个Map里（key是RequestMappingInfo，value是HandlerMethod）
  本质是：RequestMappingInfo里面包罗了路由计谋，我们通过在handlerMethod方法上打注解，如此透传到RequestMappingInfo#customConditionHolder；解决了SpringBoot启动服务，规避了RequestMappingHandler重复异常
  核心是：AbstractHandlerMethodMapping.MappingRegistry#register
  

• 步骤一：创建HandlerMethod
  
• 步骤二：校验validateMethodMapping
  
• 步骤三：放入mappingLookup
  

  2、动态路由：

  AbstractHandlerMethodMapping#lookupHandlerMethod

  

• org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#lookupHandlerMethod
  
• 步骤一：this.mappingRegistry.getMappingsByUrl(lookupPath);
  
  
  
  • 这里将灰度API和原API的RequestMappingInfo都取出来了
    
  
  
• 步骤二：addMatchingMappings();
  

    1、里面会逐个RequestMappingInfo校验是否匹配乐成，这里会回调的WebRequestMappingHandlerMapping.java#getMatchingMapping，即，RequestMappingInfoHandlerMapping#getMatchingMapping，
  很简单，就是遍历request的请求附加参数，融合到RequestMappingInfo里面。
  另外，注意这个步骤：
  RequestConditionHolder custom = this.customConditionHolder.getMatchingCondition(request);
    customConditionHolder 是持有决策器 ApiGrayDecisionMaker的
  ，沿着背面的链路一直debug，会回调到 WebRouterConstraintCondition#getMatchingCondition 方法，
  在这个自界说匹配方法里，可以直接用@PathRouterDecisionMaker
  注解的动态路由方法，对路由匹配规则校验并返回。
  于是，最终RequestConditionHolder custom是得到了生效的决策器[ApiGrayDecisionMaker]
  2、对于匹配乐成的RequestMappingInfo，包装一个Match对象
  步骤三：取出最终匹配到的Match
  步骤四：handleMatch
  1、会回调到WebRequestMappingHandlerMapping#handleMatch，即，RequestMappingInfoHandlerMapping#handleMatch，很简单，
  2、进入到AbstractHandlerMethodMapping#lookupHandlerMethod
  3、返回methodHandler
  

  

• 步骤五：嵌入拦截器，构成实行责任链
  

  

  

• 步骤六：通过署理实行invokeHandlerMethod，最终动态署理实行Controller#test方法，即：灰度逻辑
  

  

  五、总结

  以上是基于SpringMVC的接口动态灰度方案的一些教学，实际工程问题上，还会碰到一些其他问题，好比：
  

• 如果通过缓存，加速动态路由的盘算，让每次请求都快速找到RequestMappingInfo，加速路由匹配
  
• 如果匹配失败的请求，能否缓存起来，下次再有请求到后端，则快速失败
  
• 对于批量接口灰度，是否有更好的办法呢？
  

  上面源码可以参考我的个人github项目：https://github.com/bryantmo/springcloud_test
  六、相关文章

  JDK源码教学：Bean生命周期案例（初始化/销毁）

  Mybatis链路分析：JDK动态署理和责任链模式的应用

  业务上云的容器排障与思考


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。