作者回复: Bingo!同学在extends的时候加上@FeignClients的方式很好,规避了bean override的问题
作者回复: bingo,我也推荐这种做法
作者回复: 讲真loadbalancer的功能相比ribbon是差一截的,奈何spring cloud不愿意带ribbon玩了,也没辙。ribbon规避懒加载的原因是RibbonClient在调用期才进行初始化,不过ribbon在这个过程花费的时间并不多,只会在网络环境不好的情况下超时概率有所增加。对于loadbalancer来说,实际场景下大多数公司的做法是设置connection timeout + retry的方式来解决。如果对于一致性要求高的接口,底层要注意实现幂等性以防多次调用
作者回复: feign自带的重试策略比较初级,可以结合openfeign+resilience4j的方式做复杂重试规则,https://resilience4j.readme.io/docs/retry
作者回复: 同学这个建议很好,专栏整体偏入门,没有加入太多线上案例分析,后面会分享一些线上的使用场景
作者回复: 如果是外部对接,其实用feign就没啥好处了,因为feign的服务发现负载均衡都用不上,外部对接直接用最土的resttemplate或者webclient就可以。我们不用考虑它背后的负载均衡,咱调用的应该是对方给提暴露出来的一个vip url,负载均衡都在对向端管理
作者回复: 其实在三高应用中同一个微服务库我们也不推荐使用join这类操作,如果是实时性要求不高的场景,把各个微服务表里的数据做一层数据异构,异构到非结构化数据库里,比如opensearch, ES里面,然后再做查找。 如果是实时性要求很高的数据必须查DB,三高服务我推荐你把join逻辑放到代码层来实现,给到DB的尽可能都走主键索引计划。如果非要用join,一定确保调出sql执行计划确保每一步都走索引并且复杂度尽可能低
作者回复: 方法有很多,RequestMapping里有注解属性可以支持header,也可以使用Headers注解,还可以在Feign的拦截器里加header
作者回复: 就像rpc接口调用,其实微服务之间的request大多不需要把业务参数放到header里,但openfeign依然提供了一种定制header的方式,在后面的章节里我们会结合Sentinel了解到
作者回复: FeignClient注解的目的是为了不写实现,通过接口完成远程调用,所以底层的动态代理注册流程里有一个Assert断言,限定了是从接口读取 Assert.isTrue(annotationMetadata.isInterface(), "@FeignClient can only be specified on an interface");