一、引文最近在项目中频繁使用到OpenFeign和异步消息通知我发现这俩哥们都是托人办事确切地说都是在当前微服务中某项业务一部分功能的实现必须由其他微服务代为完成这个时候往往在项目中都会使用上述两项技术那他们的区别又是什么呢对此我决定对黑马头条项目中二者的使用场景进行深挖以下内容将包括它们的最佳实践细节以及技术场景对比。二、OpenFeign——微服务架构下不可或缺的远程调用在初学微服务时我记得它区别于单体项目一大特点就是服务之间相隔离这个时候如果一个服务的实现需要依托另一个服务时就再也不能像之前那样简单注入Service就完事了因为每个服务都有各自独立的Service层。幸好SpringCloud中整合了OpenFeign技术方便我们允许程序像调用本地方法一样调用远程服务器上方法也就是跨服务调用。接下来我们就介绍一下OpenFign在项目中的最佳实践1.创建独立的Feign模块微服务架构下每一个服务都有自己独立的模块远程调用服务也不例外其目的就在于实现业务功能的解耦和自治。黑马头条的Feign模块目录结构如下heima-leadnews-feign-api/ ├── pom.xml # 只依赖 model 和 common 模块 ├── src/main/java/com/heima/apis/ │ ├── article/ # 文章服务接口 │ │ ├── IArticleClient.java # Feign 接口定义 │ │ └── fallback/ # 降级处理 │ │ └── IArticleClientFallback.java │ ├── user/ # 用户服务接口 │ │ └── IUserClient.java │ ├── wemedia/ # 自媒体服务接口 │ │ └── IWemediaClient.java │ └── schedule/ # 调度服务接口 │ └── IScheduleClient.java我们可以看到它们都在com.heima.apis这个包下该目录下存放的时不同业务模块对应的Client接口你也可以在这里定义fallback后面都会提到作降级处理。同时Feign模块的依赖配置也有讲究为了避免循环依赖问题依赖必须尽可能轻量案例如下dependencies !-- 只依赖必要的模块避免循环依赖 -- dependency groupIdcom.heima/groupId artifactIdheima-leadnews-model/artifactId /dependency dependency groupIdcom.heima/groupId artifactIdheima-leadnews-common/artifactId /dependency !-- OpenFeign 依赖 -- dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-openfeign/artifactId /dependency /dependencies可以看到除了SpringCloud提供的openfeign依赖以及项目中的model模块和common模块依赖就没有依赖别的了。2.定义FeignClient接口我们知道接口只是用来定义它有什么功能而不包含任何业务实现。FeignClient也不例外但是除此之外它跟普通接口依旧存在着较大差异本项目中的接口规范如下FeignClient( value leadnews-article, // 服务名注册到Nacos的服务名 fallback IArticleClientFallback.class // Fallback降级处理类 ) public interface IArticleClient { /** * 保存文章 * param dto 文章DTO对象必须序列化 * return 统一响应结果 */ PostMapping(/api/v1/article/save) ResponseResult saveArticle(RequestBody ArticleDto dto); /** * 获取频道列表GET请求示例 */ GetMapping(/api/v1/channel/list) ResponseResult getChannels(); }我们可以看到接口上面都添加了一个FeignClient注解里面的value是指明该接口对应的实现类在项目中的哪个模块示例中说明提供IArticleClient接口实现类的位置是在项目的文章模块后面在”实现服务提供者“小节会提到fallback则是指明该接口对应的服务降级实现类同在Feign模块。此外Client接口中定义的每个方法上面都有PostMapping或者GetMapping此类的注解该项目的地址规范为(/api/v1/{模块名}/{方法名})。3.配置服务降级同在Feign模块下每个业务目录下除了它对应的Client其实还应该像article一样有它对应服务降级实现类这个实现类实现的是Client接口在实现的方法中编写服务降级逻辑即可。目的在于提高系统的容错能力。示例如下Component public class IArticleClientFallback implements IArticleClient { Override public ResponseResult saveArticle(ArticleDto dto) { log.error(文章服务调用失败降级处理); return ResponseResult.errorResult( AppHttpCodeEnum.SERVER_ERROR, 服务暂时不可用请稍后重试 ); } }需要加上Component注解将它加入到Spring容器之内。上述降级方式问题显而易见一旦远程调用出问题了不论什么问题都会进入fallback逻辑但是却无法定位具体的原因究竟是请求超时、还是服务繁忙又或是没权限访问呢一概不清楚。因此如果你觉得你的某个项目或者某个服务模块足够核心那不妨采取下面的工厂降级模式。需要简单修改一下FeignClient接口把fallback属性改为fallbackFactory。/** * 文章服务远程调用接口 * * fallbackFactory vs fallback: * - fallback: 简单降级无法获取异常信息 * - fallbackFactory: 工厂模式可以获取 Throwable 异常原因 */ FeignClient( value leadnews-article, fallbackFactory ArticleClientFallbackFactory.class // 改用 FallbackFactory ) public interface IArticleClient { PostMapping(/api/v1/article/save) public ResponseResult saveArticle(RequestBody ArticleDto dto); }然后编写降级实现类可以看到它的好处就在于其实现方法create可以拿到具体的异常原因cause这样一来我们就可以编写根据异常原因给出不同降级策略的逻辑了。/** * 文章服务降级处理工厂高级降级 * * 特点 * 1. 实现 FallbackFactoryIArticleClient 接口 * 2. 必须使用 Component 注解 * 3. create(Throwable cause) 方法可以获取具体异常 * 4. 可以根据异常类型返回不同的降级结果 * 5. 可以记录详细的异常日志 */ Slf4j Component public class ArticleClientFallbackFactory implements FallbackFactoryIArticleClient { Override public IArticleClient create(Throwable cause) { // 可以记录详细的异常日志 log.error(文章服务调用失败, cause); log.error(异常类型: {}, cause.getClass().getSimpleName()); log.error(异常消息: {}, cause.getMessage()); return new IArticleClient() { Override public ResponseResult saveArticle(ArticleDto dto) { // 根据不同异常类型返回不同信息 return analyzeAndRespond(cause); } }; } private ResponseResult analyzeAndRespond(Throwable cause) { // 场景1超时异常 - 给用户友好的提示 if (cause instanceof java.net.SocketTimeoutException) { log.warn(文章服务响应超时); return ResponseResult.errorResult( AppHttpCodeEnum.SERVER_ERROR, 请求超时请稍后重试 ); } // 场景2连接异常 - 服务可能挂了 if (cause instanceof java.net.ConnectException) { log.warn(无法连接到文章服务); return ResponseResult.errorResult( AppHttpCodeEnum.SERVER_ERROR, 服务暂时不可用 ); } // 场景3Hystrix 超时 if (cause instanceof com.netflix.hystrix.exception.HystrixTimeoutException) { log.warn(Hystrix 超时熔断); return ResponseResult.errorResult( AppHttpCodeEnum.SERVER_ERROR, 服务繁忙请稍后重试 ); } // 场景4Feign 内部错误如 404, 500 等 HTTP 状态码 if (cause instanceof feign.FeignException) { feign.FeignException fe (feign.FeignException) cause; int status fe.status(); if (status 404) { return ResponseResult.errorResult( AppHttpCodeEnum.DATA_NOT_EXIST, 请求的资源不存在 ); } if (status 401 || status 403) { return ResponseResult.errorResult( AppHttpCodeEnum.NEED_LOGIN, 无权限访问 ); } log.error(Feign 错误, status{}, status); return ResponseResult.errorResult( AppHttpCodeEnum.SERVER_ERROR, 远程服务异常 ); } // 默认降级处理 return ResponseResult.errorResult( AppHttpCodeEnum.SERVER_ERROR, 服务暂时不可用请稍后重试 ); } }4.实现服务提供者在服务提供者模块中实现 Feign 接口保持接口与实现的分离。示例如下RestController // 注意必须是 RestController public class ArticleClient implements IArticleClient { Autowired private ApArticleService apArticleService; PostMapping(/api/v1/article/save) // 必须与接口路径一致 Override public ResponseResult saveArticle(RequestBody ArticleDto dto) { return apArticleService.saveArticle(dto); } }所谓的服务提供者模块就是指之前定义接口时FeignClient注解里面的value值为该服务在Nacos的注册名同时也是项目中这个业务模块的名称。示例中就是在文章模块专门创建一个feign目录里面就可以编写ArticleClient实现IArticleClient接口。这个服务提供者更像是Controller层因为这个实现类必须加上RestController注解而且具体业务也要靠注入本服务模块的Service层ApArticleService来实现还有一个关键点就是方法上面必须加类似于PostMapping、GetMapping注解里面的地址也必须跟先前定义FeignClient接口时对应方法的地址一样Feign接口定义: PostMapping(/api/v1/article/save) 服务提供者实现: PostMapping(/api/v1/article/save) 推荐路径结构: /api/v1/{模块}/{操作} 例如: - /api/v1/article/save 文章保存 - /api/v1/article/{id} 文章查询 - /api/v1/user/{id} 用户查询 - /api/v1/task/add 任务添加5.配置服务消费者在实现跨服务调用前我们需要在消费者服务的启动类中启用 Feign Client 扫描并正确注入使用。示例如下SpringBootApplication EnableDiscoveryClient // 启用服务发现 EnableFeignClients( basePackages com.heima.apis // 指定Feign接口所在包 ) public class ArticleApplication { public static void main(String[] args) { SpringApplication.run(ArticleApplication.class, args); } }EnableDiscoveryClient注解的主要作用是开启服务的自动注册与发现功能。它作为一个“开关”使得当前的微服务实例能够与配置的服务注册中心如 Nacos、Eureka、Consul 或 Zookeeper进行交互。还记得我们定义FeignClient接口时那个value属性吗它就是服务提供者模块注册到Nacos的服务名称所以我们需要启用服务发现在调用Client接口完成远程调用时帮助Client接口找到它的实现类。如果是前者是为了帮Client接口找到实现类那么EnableFeignClients就是为了帮助我们找到Client接口basePackages是帮我们显示指定Feign接口所在包。与此同时因为我们要跨服务调用所以避免不了在服务消费者模块引入Feign模块这个中转站的依赖。dependency groupIdcom.heima/groupId artifactIdheima-leadnews-feign-api/artifactId /dependency前置工作做完了终于可以实现远程调用了让我们看看它是如何实现的Service public class WmNewsAutoScanServiceImpl implements WmNewsAutoScanService { Autowired private IArticleClient articleClient; // 注入Feign客户端 public void publishArticle(WmNews wmNews) { // 构建请求参数 ArticleDto dto new ArticleDto(); BeanUtils.copyProperties(wmNews, dto); dto.setChannelName(wmNews.getChannelName()); // 调用远程服务 ResponseResult result articleClient.saveArticle(dto); // 处理响应 if (result.getCode().equals(200)) { log.info(文章发布成功); } else { log.error(文章发布失败: {}, result.getErrorMessage()); } } }代码好清爽有没有在业务层我们发现这跟单体项目调用其他Service不就一模一样了吗这就是OpenFeign远程调用的强大之处在消费者模块我们还可以进阶一步先前配置服务降级一定程度上提高了系统的容错性但是依旧存在着不足如果请求超时了呢要知道OpenFeign调用是同步阻塞的那要不要重试呢这些配置都可以在消费者模块的yml文件实现Nacos中也可以完成配置。feign: client: config: default: # 全局默认配置 connectTimeout: 5000 # 连接超时 5秒 readTimeout: 5000 # 读取超时 5秒 leadnews-article: # 针对特定服务的配置 connectTimeout: 3000 # 连接超时 3秒 readTimeout: 3000 # 读取超时 3秒 # 启用重试默认启用这里明确配置 retryer: feign.Retryer.Default6.配置日志在调式中日志通常扮演着重要角色那我们能不能配置一下OpenFeign的配置呢答案是可以的。通常我们会在common模块下配置package com.heima.common.config; import feign.Logger; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; /** * Feign 日志配置 * 用于调试 Feign 调用输出完整的请求和响应信息 */ Configuration public class FeignLogConfig { /** * 配置 Feign 日志级别 * * NONE: 不记录日志默认 * BASIC: 只记录请求方法、URL、响应状态码 * HEADERS: 记录请求和响应的头信息 * FULL: 记录全部信息请求、响应体、渲染后的请求/响应 */ Bean public Logger.Level feignLoggerLevel() { return Logger.Level.FULL; } }同时也需要在该模块的yml文件设置日志级别。logging: level: # Feign 接口包的日志级别 com.heima.apis: DEBUG # Feign 核心包的日志 feign: DEBUG7.传递用户认证信息的拦截器大家可以想象一个场景用户登录自媒体端发布文章时需要调用文章微服务的功能此时远程调用确实是没问题但是它所调用的文章微服务的功能又需要知道用户的信息这个时候应该怎么办呢有的同学会说诶我最开始用户登录的时候SpringMVC的拦截器不是就把用户信息存入到ThreadLocal里面了吗从ThreadLocal里面取不就完事了但可惜无法奏效原因在于文章微服务和自媒体微服务是两个微服务它们不一定在一个线程中运行而ThreadLocal又只允许同一线程数据共享。此外OpenFeign远程调用是一次新的Http请求会创建新的线程并不会携带原来的请求头存有用户信息。还是那句话遇事不决、先加一层没有什么事情是加一层不能解决的我们可以专门加一层Feign拦截器在发起新的请求前把旧请求里面的用户信息放到新的请求中/** * Feign 请求拦截器 * 在 Feign 发起请求前自动将需要的 header 信息传递下去 */ Component public class FeignRequestInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { // 1. 从当前线程获取 HTTP 请求上下文 ServletRequestAttributes attributes (ServletRequestAttributes) RequestContextHolder.getRequestAttributes(); if (attributes ! null) { // 2. 从原请求中获取 userId HttpServletRequest request attributes.getRequest(); String userId request.getHeader(userId); // 3. 传递到 Feign 请求头中 template.header(userId, userId); } } }Feign 拦截器在 Feign 请求层面帮我们把 userId 从原请求头传递到目标服务目标服务的 MVC 拦截器再把它存入 ThreadLocal这样一来跨服务的用户信息传递就完成了。三、OpenFeign与异步消息通知区别本项目中采用的Kafka进行异步消息通知使用场景如下// 场景1用户点赞后异步更新文章分数 Autowired private KafkaTemplateString, String kafkaTemplate; public void likeArticle(Long articleId) { // 点赞逻辑立即完成 saveLikeRecord(articleId); // 发送异步消息更新文章热度分数 UpdateArticleMess mess new UpdateArticleMess(); mess.setArticleId(articleId); mess.setType(UpdateArticleMess.UpdateArticleType.LIKES); mess.setAdd(1); // 发送即可返回不等待处理 kafkaTemplate.send(HotArticleConstants.HOT_ARTICLE_SCORE_TOPIC, JSON.toJSONString(mess)); } // 场景2文章发布后同步到ES索引 public void publishArticle(ApArticle article, String content) { // 1. 保存文章到数据库 saveArticle(article); // 2. 生成静态页面 generateStaticPage(article, content); // 3. 发送消息通知ES创建索引异步 kafkaTemplate.send(ArticleConstants.ARTICLE_ES_SYNC_TOPIC, JSON.toJSONString(searchArticleVo)); // 文章发布立即返回ES同步异步进行 } // 场景3自媒体文章上下架通知 public void downOrUpArticle(WmNews wmNews, Integer enable) { // 1. 更新自媒体文章状态 updateWmNewsEnable(wmNews.getId(), enable); // 2. 如果有关联的文章发送消息通知文章服务 if (wmNews.getArticleId() ! null) { MapString, Object map new HashMap(); map.put(articleId, wmNews.getArticleId()); map.put(enable, enable); kafkaTemplate.send(WmNewsMessageConstants.WM_NEWS_UP_OR_DOWN_TOPIC, JSON.toJSONString(map)); } }可以发现这些业务都有一个最大的特点那就是不需要立即获得响应无论是点赞计算评分、还是同步到ES索引又或是上下架不追求强一致性且都不会给用户体验带来太大影响。异步消息通知是非阻塞的而OpenFeign是阻塞远程调用前者可以一次性拜托多个人办事后者只能一对一总结如下场景推荐方案原因获取用户信息/配置等OpenFeign实时查询需要返回值强一致性操作转账、下单OpenFeign Seata需要分布式事务异步日志/行为统计Kafka高并发场景削峰填谷系统间解耦通知Kafka一对多无需等待响应延迟任务调度Kafka Streams定时处理离线计算配置变更通知Kafka / Nacos实时推送配置