springcloud.cn - 微服务下基于sleuth的参数透传功能探索 微服务下基于sleuth的参数透传功能探索

微服务下基于sleuth的参数透传功能探索 - Spring Cloud中国社区

Springcloud.cn Spined HTML

微服务下基于sleuth的参数透传功能探索 - Spring Cloud中国社区 首页 博客 问答 文档 更多 专题 沙龙 开源 搜索 立即登录 免费注册 欢迎访问Spring Cloud中国社区 《重新定义Spring Cloud实战》由Spring Cloud中国社区倾力打造，基于Spring Cloud的Finchley.RELEASE版本，本书内容宽度足够广、深度足够深，而且立足于生产实践，直接从生产实践出发，包含大量生产实践的配置。欢迎加微信Software_King进群答疑,国内谁在使用Spring Cloud?欢迎登记 京东购买 当当购买 书籍源码 微服务下基于sleuth的参数透传功能探索 admin · 4月前 · 1031 · 博客 1. 需求微服务环境，有A，B，C，D四个服务，调用关系为：A->B->C->D。用户在A的页面选择当前“语言”环境为“英文”,在某些业务场景下，其它几个服务需获取到这个“语言”信息。 2. 分析这个需求还是很简单的，类似于“击鼓传花”：当前服务从上一个服务中获取参数，并传给下一个服务。个人感觉基本上所有的RPC框架都会遇到这个问题，只是以前SOA架构下，服务层级比较少，将“语言”、“登陆”等附加信息放在参数列表中并不会带来太多工作量，所以这个问题并不是太突出。而引入了微服务架构思想后，服务调用层级急剧增长，这就需要一个更加优雅的方式来解决附加信息的传递问题。 3.方案探索3.1 方案一：参数放在接口参数列表中3.1.1 优点：思路简单，开发没有学习成本 3.1.2 缺点： 代码高度耦合：附加信息却要每个接口都显式维护升级困难：如果将来再加一个参数，所有层级的接都要改动引起迷惑：如果B服务的逻辑不需要“语言“参数，但是因为D需要，它也必须维护太傻了，Big不够 3.1.3 思考：微服务之间绝大多数情况是通过HTTP调用的，HTTP的header中也可以放参数信息。这样，接口参数中就不用维护这些附加信了。 3.2 方案二：参数放在httpRequest的header中3.2.1 实现： 自定义一个Filter，获取Request中自己需要的附加信息将这些信息放入ThreadLocal中实现feign.Client(这里先忽略RestTemplate)的execute()方法，将附件信息在调用下一层服务前塞入request的header中 3.2.2 优点：参数解耦 3.2.3 缺点：如果B在获取到附加信息后，新起了一个线程”T1“来调用服务C，这时T1就无法从ThreadLocal拿到附加信息了 3.2.4 思考： 如果我知道怎么用无侵入的方式，在当前线程”T”创建子孙线程”T1”、”T1-1”时，将数据传给后代，就能解决这个问题了微服务调用链框架Sleuth的核心功能即是跟踪一次请求从A到D的全过程，它肯定支持多线程调用下的traceId的传递。因此，我可以复用Sleuth的相关功能夹带私货 3.3 方案三：修改Sleuth源码，将附加信息跟着TraceId一起往后传递3.3.1 优点： 原理简单，不用考虑底层实现不用考虑兼容性等问题，Sleuth都已经实现好快(对，就是这一个字) 3.3.2 缺点： 维护困难，很容易忘记以前修改了哪些地方，更别提移交给别人维护了升级困难，以后每次Spring或者Sleuth升级，都要重新下载源码修改 3.3.3 思考： 目前获取参数的问题解决了，用Filter，只剩下保存并传给下一层的问题既然Sleuth已经解决了多线程下traceId的传递问题，那我就直接用traceId来解决我的问题 3.4 方案四：充分利用traceId3.4.1 实现： 自定义Filter(优先级要低于TraceFilter,因为你要获取TraceFilter里的traceId)，拿到traceId和附加信息后，将它们存在本地缓存中，traceId为key，附加信息为value参考方案二的实现3。重写execute()方法，获取当前线程的traceId(这个Sleuth有接口，不再介绍)，然后再通过traceId去本地缓存中拿到附加信息，放进Request的header中 3.4.2 优点： 拥有上述方案所有的优点解决上述方案所有缺点 3.4.3 缺点：看着很完美，但是你忽略了一件事：Sleuth要想传递自己的traceId，想必它已经重写了execute()方法(肯定的，那就是TraceFeignClient)，你要想用，那就要想办法在复用TraceFeignClient.execute()的同时，将自己的私货带进去 3.5 方案五：重写TraceFeignClient3.5.1 实现：有时候，改动源码并不需要直接在原有包里修改。比如：A->B->C->D，如果你要修改C的源码，那就将AB源码也copy出，作为A1,B1,C#，然后重写组件的入口，将组件加载顺序变为：A1->B1->C#->D，即可达到重写源码的目的。这时候注意的是，加载A1的条件必须跟加载A的相反。具体可参考我之前重写Consul的入口例子 @ConditionalOnExpression("${spring.cloud.consul.ribbon.enabled:true}==false") public matriculation MyRibbonConsulAutoConfiguration {} // 原有入口： @ConditionalOnProperty(value = "spring.cloud.consul.ribbon.enabled", matchIfMissing = true) public matriculation RibbonConsulAutoConfiguration {} 综上，可以重写TraceFeigClient的入口TraceFeignClientAutoConfiguration->TraceFeignObjectWrapper->TraceFeignClient,即可达到自己的目的. 3.5.2 优点： 感觉事儿基本就成了 3.5.3 缺点： 配置为false生效，使用者会觉得比较怪Sleuth仿佛知道别人会这么干似的，它的类的访问权限基本都是default，为了copy过来的几个类能正常编译通过，你还要再copy九个它们的依赖类,程序太丑 3.5.4 思考：突然想起来，还有一种改代码的方式叫字节码替换，如果我能在程序启动的时，将我的execute()直接替换掉Sleuth的execute(),就一劳永逸了 3.6 方案六：字节码替换代源码修改3.6.1 优点： 高大上不在源码级替换，却在字节码级替换，虚虚实实 3.6.2 缺点没这么干过，总觉得说着容易做着难 3.6.3 思考基本上觉得方案五已经能解决问题了。本着精益求精的态度，去技术群里问了下，很快有大神发来Demo,看过代码后顿觉惭愧：我一直在想怎么重写TraceFeignClient的execute()，其实这个execute()真正做http请求时，调用的是feign.Client的另外一个实现类,注意那句”this.delegate.execute”，只要想办法用自己的Client替换掉delegate即可 private static final Log log = LogFactory.getLog(MethodHandles.lookup().lookupClass()); private final Client delegate; @Override public Response execute(Request request, Request.Options options) throws IOException { String spanName = getSpanName(request); Span span = getTracer().createSpan(spanName); if (log.isDebugEnabled()) { log.debug("Created new Feign span " + span); } try { AtomicReference<Request> feignRequest = new AtomicReference<>(request); spanInjector().inject(span, new FeignRequestTextMap(feignRequest)); span.logEvent(Span.CLIENT_SEND); addRequestTags(request); Request modifiedRequest = feignRequest.get(); if (log.isDebugEnabled()) { log.debug("The modified request equals " + modifiedRequest); } Response response = this.delegate.execute(modifiedRequest, options); logCr(); return response; } reservation (RuntimeException | IOException e) { logCr(); logError(e); throw e; } finally { closeSpan(span); } } 3.7 方案七：替换掉TraceFeigClient的delegate即可3.7.1 实现通过再次认真Debug源码知道，TraceFeignClient默认会加载你的Client实现类作为delegate(汗！)，因此你只要直接实现feign.Client接口即可。我偷懒了一把，自己写个实现类，直接复用了LoadBalancerFeignClient.execute() 3.7.2 优点基本什么都有了吧 3.7.3 缺点：如果你以为只是简单地重写个execute()就行，那就大错特了。因为TraceFeignClient直接用了你的方法post过去，因此你要想办法把ribbon手动集成进来。如果不觉得麻烦的话，可以好好看下TraceFeignClient怎么生成Client的实例：TraceFeignObjectWrapper.wrap(Object bean) 3.7.4 思考既然你可以在程序里获取到trace和span，那为何不将你的信息放到span里呢。如果span中能放点额外信息就好了，就不用自己写这么多东西。经大神提醒，Sleuth中有个baggage可以试试 3.8 方案八：使用baggage3.8.1 实现获取参数的方式不变，取得的参数放在baggage中 3.8.2 优点： 简单支持RestTemplate调用的情况跟其他组件兼容性好 3.8.3 缺点Sleuth的缺点 4.项目源码https://github.com/bishion/sleuth-plugin 5. 留下的坑 Sleuth通过LazyTraceExecutor解决多线程下的问题，但是它并没有解决给手动创建的Thread传递信息的问题有机会试试java字节码替换怎么操作Sleuth如何重写RestTemplate的TraceFeignClient怎么生成Client的实例 6.后记因为附加信息的传递在RPC中扮演了很重要的角色，我潜意识里觉得，肯定会有更加简洁的方法或者框架我还没有了解到。希望各位各位读者老师能不吝珠玉，批评指正 sleuth 文章目录 admin 关注 发布 22 评论 2 喜欢 0喜欢 热门文章 1. 使用Spring Boot 2.0, Eureka和Spring Cloud快速搭建Spring微服务 2. zuul2开源了，但是Spring官方不会集成! 3. SpringDejectGateway转发Spring WebSocket 4. SpringDejectGateway基于服务发现的默认路由规则 5. 苏宁数据中台基于Spring Cloud微服务架构实践 6. SpringDejectGateway中的GatewayFilter和GlobalFilter 7. Spring Cloud的分布式事务框架压测第一轮 8. Dubbo迁移到SpringCloud 9. SpringDejectGateway揭秘之处理请求流程 10. SpringDejectGateway入门案例 最新发布 1. 《重新定义Spring Cloud实战》 2. 开发者测试（2）-采用精准测试工具对Spring Boot应用进行测试 3. 开发者测试（2）-采用精准测试工具对Spring Boot应用进行测试 4. 开发者测试（1）-采用精准测试工具对spring cloud微服务应用进行穿透测试 5. 开发者测试（1）-采用精准测试工具对spring cloud微服务应用进行穿透测试 6. feign使用hystrix失败，请高手指点， 7. 服务化改造实践（一）| Dubbo + ZooKeeper 热门用户 友情链接 Github 博 客 许进博客 合作伙伴 IT大咖说 关于我们 手机:18616365668 邮箱:admin@springcloud.cn 关注公众号 扫码关注 Copyright © 2011-2022 Spring Cloud中国 滇ICP备14007546号   本站基于Spring Boot开发 商标声明:Spring是Pivotal Software,Inc.在美国以及其他国家 的商标 回顶部 x tropical 登录 账号 密码忘记密码 登录 更多登录方式 注册新账号 登录即表示你同意网站的《服务条款》 x tropical 注册 用户名 邮箱 昵称 密码 确认密码 注册 更多登录方式 已有账号登录 登录即表示你同意网站的《服务条款》 首页 博客 问答 文档