微服务拆分治理最佳实践( 四 ) _微服务

接口抓取&归类

路由filter是根据接口路径将请求分发到各个新系统的，所以需要抓取一份接口和新系统的映射关系。我们这边自定义了一个注解@TargetSystem，用注解标识接口应该路由到的目标系统域名，

@TargetSystem(value = https://www.isolves.com/it/cxkf/jiagou/2022-12-20/"http://order.demo.com") @GetMapping("/order/info") public ApiResponse orderInfo(String orderId) { return ApiResponse.success(); }

然后遍历获取所有controller根据接口地址和注解生成路由映射关系map

/** * 生成路由映射关系MAP * key：接口地址 ，value：路由到目标新系统的域名 */ public Map generateRouteMap() { Map handlerMethods = requestMappingHandlerMapping.getHandlerMethods(); Set> entries = handlerMethods.entrySet(); Map map = new HashMap<>(); for (Map.Entry entry : entries) { RequestMappingInfo key = entry.getKey(); HandlerMethod value = https://www.isolves.com/it/cxkf/jiagou/2022-12-20/entry.getValue(); Class declaringClass = value.getMethod().getDeclaringClass(); TargetSystem targetSystem = (TargetSystem) declaringClass.getAnnotation(TargetSystem.class); String targetUrl = targetSystem.value(); String s1 = key.getPatternsCondition().toString(); String url = s1.substring(1, s1.length() - 1); map.put(url, targetUrl); } return map; }

文章插图

路由映射关系MAP

测试流量识别

测试可以用利用抓包工具charles，为每个请求都添加固定的请求头，也就是测试流量标识，路由器拦截请求后判断请求头内是否包含测试流量标，包含就路由到新系统，不包含就是线上流量留在老系统执行。

文章插图

路由流程

需求代码合并

执行系统拆分的过程中，还是有需求正在并行开发，并且需求代码是写在老系统的，系统拆分完成上线后，需要将这部分需求的代码合并到新系统，同时要保证git版本记录不能丢失，那应该怎么做呢？
我们利用了git可以添加多个多个远程仓库来解决需求合并的痛点，命令：git remote add origin 仓库地址，把新系统的git仓库地址添加为老系统git的远程仓库，老系统的git变动就可以同时push到所有新系统的仓库内，新系统pull下代码后进行合并。

文章插图

需求代码合并方案

上线风险

风险一：JOB在新老系统并行执行。新系统是复制的老系统，JOB也会复制过来，导致新老系统有相同的JOB，如果这时候上线新系统，新系统的JOB就会执行，老系统的JOB也一直在run，这样一个JOB就会执行2次。新系统刚上线还没经过测试验证，这时候执行JOB是有可能失败的。以上2种情况都会引起线上Bug，影响系统稳定性。
风险二：新系统提前消费MQ 。和风险一一样，新系统监听和老系统一样的topic，如果新系统直接上线，消息是有可能被新系统消费的，新系统刚上线还没经过测试验证，消费消息有可能会出异常，造成消息丢失或其他问题，影响系统稳定性。
如何解决以上2个上线风险呢？
我们用“动态开关”解决了上述风险，为新老系统的JOB和MQ都加了开关，用开关控制JOB和MQ在新/老系统执行。上线后新系统的JOB和MQ都是关掉的，待QA测试通过后，把老系统的JOB和MQ关掉，把新系统的JOB和MQ打开就可以了。