规范-dubbo服务设计

1、工程架构

    层次设计大致分为:Remote层、Manager层、Service层、Cache层、DAO层、DTO\DO。

    各层次功能描述:

  • Remote层:对外暴露dubbo接口;
  • Manager层:多表业务;
  • Service层:单表业务;
  • Cache层:缓存业务;
  • DAO层:数据库访问操作;
  • DTO:暴露服务操作对象;
  • DO:数据库操作对象;

2、开发规范

  • Remote层:只允许操作Manager层和Service层,命名规范为Remote*Service;
  • Manager层:只允许Service 层,可以使用缓存和事务;
  • Service层:只允许DAO 层和Cache层,一个Service对应一个DAO;
  • Cache层:只允许DAO 层,封装有降级策略的业务;

3、注意事项:

对外暴露的服务(Remote层),不允许抛出异常(异常需要发送堆栈信息),减小网络开销;

消费者获取DubboResult后,必须先判断调用是否成功,成功则进行正常业务处理,失败应该抛出异常或其他处理;

服务端在RemoteService层应该始终返回DubboResult;

内部Service层的业务异常应该使用BusinessException

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
dubbo服务分布式事务是指在使用dubbo框架进行微服务架构设计时,处理跨多个服务节点间的事务一致性问题的方法。 在分布式系统中,每个服务节点都可以独立运行并处理自己的业务逻辑,因此可能存在多个服务节点相互协作完成一个完整的事务。而分布式事务要求所有参与节点在提交或回滚时保持一致性,即要么都提交,要么都回滚,不能出现部分节点提交,部分节点回滚的情况。 为了解决这个问题,dubbo提供了分布式事务解决方案。首先,可以通过编写一致的接口规范事务操作的方法。通过在接口上添加@Transactional注解,可以标识该方法为事务处理方法。在方法执行时,dubbo会根据配置的事务管理器对事务进行管理,保证所有事务操作的一致性。 其次,dubbo可以与各种消息中间件集成,如RocketMQ、Kafka等,通过消息队列的方式实现分布式事务的异步提交。使用这种方式,可以先将事务操作记录到消息队列中,然后由消息队列负责保证所有操作的一致性。 另外,dubbo还提供了基于TCC(Try-Confirm-Cancel)模式的分布式事务解决方案。TCC模式通过在事务的预备阶段、确认阶段和取消阶段执行相应的操作,来确保所有参与节点在最终提交或回滚时保持一致性。在dubbo中,可以通过实现Transaction接口来自定义TCC模式的事务管理器,以满足各种业务场景的需求。 总的来说,dubbo服务框架提供了多种解决方案来处理分布式事务,开发者可以根据具体的业务需求选择合适的方法来保证分布式系统的事务一致性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值