RPC理解,Dubbo和Feign的对比
RPC
随着公司规模的扩大,以及业务量的激增,单体应用逐步演化为服务/微服务的架构模式,因此便会产生不同服务之间相互调用的情况,而 服务之间的调用大多采用rpc的方式调用。
概述
- RPC(Remote Procedure Call)远程过程调用。网上更多的说法RPC是一种协议,需要满足一定的规范,因为不是说一个服务调了另一个服务就算是RPC,比如我可以通过restTemplate调用另一个服务的rest接口,这也算是一个服务调用了另一个服务,但是这不能叫RPC。
- 举例:在微服务的设计中,一个服务A如果访问另一个Module下的服务B,可以采用HTTP REST传输数据,并在两个服务之间进行序列化和反序列化操作,服务B把执行结果返回过来。(后端请求微信接口)
- RPC需要达到的是:客户端在不知道调用细节的情况下,调用存在于远程计算机上的某个对象,就像调用本地应用程序中的对象一样。
- RPC需要满足三个条件:
- 网络协议和网络IO模型对其透明
- 信息格式对其透明
- 应该有跨语言能力
Dubbo
- Dubbo是阿里巴巴开源的基于Java的高性能RPC分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。
//dubbo里的@Service注解
import org.apache.dubbo.config.annotation.Service;
@Service
public class AppServiceImpl implements IAppService {
@Autowired
AppMapper appMapper;
@Override
public AppDTO createApp(AppDTO appDTO) throws BizException {
return null;
}
@Slf4j
@RestController
public class AppController {
//远程调用
@Reference
IAppService appService;
public AppDTO createApp(@RequestBody AppVo appVo){
return appService.createApp(appDTO);
}
- 传输层
- 利用
Netty
,TCP
传输,单一、异步、长连接,适合数据量小、高并发和服务提供者远远少于消费者的场景。
Feign
- Feign是Spring Cloud提供的一个声明式的伪Http客户端,封装了Http调用流程,更适合面向接口化的变成习惯,它使得调用远程服务就像调用本地服务一样简单,只需要创建一个接口并添加一个注解即可。
- Nacos注册中心很好的兼容了Feign,Feign默认集成了Ribbon(Ribbon 是 Netflix开源的 基于HTTP和TCP等协议负载均衡组件),所以在Nacos下使用Fegin默认就实现了负载均衡的效果。
- 应用层
- Feign本身不支持Spring MVC的注解,它有一套自己的注解(@RequestLine),OpenFeign是Spring Cloud 在Feign的基础上支持了Spring MVC的注解,如
@RequesMapping
等等。OpenFeign的@FeignClient
可以解析SpringMVC的@RequestMapping
注解下的接口,并通过动态代理的方式产生实现类,将请求调用委托到动态代理实现类。 - Feign 整体框架非常小巧,在处理请求转换和消息解析的过程中,基本上没什么时间消耗。真正影响性能的,是处理Http请求的环节。
通过短连接的方式进行通信,不适合高并发的访问。
总结
- 功能上Dubbo > Feign
- Dubbo除了注册中心需要进行整合,负载均衡、服务治理、容错机制等都自己实现了,而Feign大部分功能都是依赖全家桶的组件来实现的。
- SpringCloud全家桶里面(Feign、Ribbon、Hystrix),特点是非常方便。Ribbon、Hystrix、Feign在服务治理中,配合Spring Cloud做微服务,使用上有很多优势。
- 如果项目对性能要求不是很严格,可以选择使用Feign,它使用起来更方便。如果需要提高性能,避开基于Http方式的性能瓶颈,可以使用Dubbo。
- 射击项目选用Dubbo比Feign好
问题 Feign算不算RPC框架?
- 有人认为是,因为Feign达到了RPC的要求。
- 有人认为不是,认为RPC主要依赖于客户端和服务端之间建立Socket链接进行,通过TCP协议传输数据而不是HTTP。
新生电子报道
点赞
@Service
@Slf4j
@RequiredArgsConstructor
public class StudentPraiseServiceImpl extends ServiceImpl<StudentPraiseMapper, StudentPraise> implements IStudentPraiseService {
private final StudentPraiseMapper studentPraiseMapper;
private final IStudentsService studentsService;
private final IOpenIdService openIdService;
@Override
@GlobalTransactional
public Boolean clickWish( String cartId, String openId ) {
log.info("【学生身份证为:】" + cartId + "【当前用户的openid为】" + openId);
Integer openIdCount = openIdService.selectCount(openId);
if (openIdCount != 0) {
Students students = studentsService.getByCartId(cartId);
Integer id = students.getId();
//将openid和考生id插入
QueryWrapper<StudentPraise> studentPraiseWrapper = new QueryWrapper<>();
studentPraiseWrapper.lambda().eq(StudentPraise::getStudentId, id).eq(StudentPraise::getOpenid, openId);
Integer count = studentPraiseMapper.selectCount(studentPraiseWrapper);
if (count == 0) {
StudentPraise studentPraise = new StudentPraise();
studentPraise.setStudentId(id);
studentPraise.setOpenid(openId);
studentPraiseMapper.insert(studentPraise);
log.info("【插入数据成功】");
//查询当前的祝福数量
Students selectOne = studentsService.getById(id);
int wishes = 0;
if (ObjectUtil.isNotNull(selectOne)) {
if (ObjectUtil.isNotNull(selectOne.getWishes())) {
wishes = selectOne.getWishes();
}
}
log.info("【当前的祝福数量为:】" + wishes);
//更新库中的祝福数量
return studentsService.updateWishesById(id, wishes+1);
} else {
return false;
}
} else {
return null;
}
}
}
大屏展示
问题 公网ip与内网ip
- 在服务注册到nacos上的时候默认使用的是内网ip,这就导致了一台服务器上的服务访问不到另一台服务器上的服务,需要服务在配置文件里声明公网ip。
- 那我们在真正部署的时候什么情况注册内网ip,什么时候注册公网ip?