本文探讨了为何在已有Spring Cloud的情况下还要学习Dubbo，强调Dubbo的RPC协议优势。详细介绍了Dubbo的架构，包括服务提供者、消费者、注册中心的角色。讨论了使用Zookeeper作为服务注册中心的配置思考，以及在配置中遇到的接口管理和远程调用问题。还提到了Dubbo的事务控制与服务发布的冲突，并给出了解决方案。
Dubbo & Zookeeper
为什么要学习Dubbo？
有人说微服务已经有Spring Cloud可以实现，那么我们为什么要学习Dubbo呢？为了卷，啊不，dubbo框架使用了RPC传输协议，相比于Spring Cloud的HTTP传输协议，不会造成消息封装的臃肿。从而使得dubbo的网络消耗小于Spring Cloud，从而节约一些成本。(其实好像造成不了什么影响，但多学一点总是好的😁。)
dubbo的架构
通过查阅官方文档，我们对Dubbo的架构有了初步的了解。其中虚线都是异步访问，实线都是同步访问蓝色虚线:在启动时完成的功能红色虚线(实线)都是程序运行过程中执行的功能。
| 节点 | 角色名称 |
|---|---|
| Provider | 暴露服务的服务提供方 |
| Consumer | 调用远程服务的服务消费方 |
| Registry | 服务注册与发现的注册中心 |
| Monitor | 统计服务的调用次数和调用时间的监控中心 |
| Container |
最低0.47元/天 解锁文章
519
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
