1, 为什么要使用 Dubbo
2, 本地调用和远程调用
3,RPC 框架
5, 注意事项
为什么使用 Dubbo:
1, 需要进行项目之间的相互调用 (跨域), 以达到某种效果, 所以用到了 Dubbo
eg: 在第一个项目中, 用到了数据源, 在第二个项目中也用到了同样的数据源, 用的甚至可能是同一张表
那我是不是可以在进行第二个项目的编写时, 不去配置数据源了, 去使用第一个项目中配置好的数据源,
这样一来, 代码进行了简化, 这就被称作远程调用.
2, 为了实现远程调用, 但在 restful 风格中, restfule 需要把用户的登录状态暴露在 http 中, 一旦被截获,
可能导致整个项目的运行处事故, 而且 restful 是使用 controller 调用 controller, 这样不符合 MVC 的设计思想.
3, 为了既能远程调用, 还要安全且符合 MVC 的设计思想, 开始使用 RPC(remote preducer call): 远程过程调用.
!!springcloud 依然延续使用 Restful.
本地调用:
在同一个项目 / 同一个域中, 发起调用请求, 最终达到某种目的, 称之为本地调用.
远程调用:
在不同的项目中 / 不同的域中, 发起调用请求, 最终达到某种目的, 称之为远程调用.
RPC 框架:
dubbo 是 RPC 中的一个很优秀的框架, 由阿里巴巴开发, 贡献给了 apache 软件基金会.
当当网使用的 dubbox
京东使用的是 JSF
spring 公司使用的是 springcloud
dubbo:
dubbo 是阿里巴巴开发的一个高性能, 轻量级, 基于 Java 的开源 RPC 框架.
dubbo 的三大核心:
面向接口的风格
容错和负载均衡
自动的服务注册和服务实现
面向接口的风格:
restful 是 controller 调用 controller
dubbo 是 controller 调用 service(只需要在本项目中定义接口即可, 不需要实现类)
容错:
在项目运行中即使出现了错误, 仍然可以继续运行的解决方案就叫做容错
自动的服务注册和服务发现:
是用到了 zookeeper 注册中心, 通过 zookeeper 来实现自动的服务注册和发现.
在 Linux 中配置 dubbo:
1, 配置 zookeeper 集群
2, 配置 jdk
3, 配置 maven
4, 配置 Tomcat
5, 进行 dubbo 的配置:
解压压缩包: tar -zxvf xxxxx
进入 dubbo 的目录进行编译命令: mvn install -Dmaven.test.skip=true
找到 dubbo-admin 目录, 进入 target, 找到 dubbo-admin-2.5.7.war
找到 Tomcat 中的 webapps, 在此下面有个 ROOT 项目, 删掉它
使用 cp -r 将 dubbo-admin-2.5.7.war 复制到 Tomcat 下的 WebApps 中,
将 dubbo-admin-2.5.7.war 改名为 ROOT, 取代原有的 ROOT 项目,
去 bin 目录下执行./startup.sh 命令 启动 Tomcat, 然后可以在 WebApps 下看到 war 包被编译出来了
修改 dubbo 的配置文件 (在 Web-INF 目录下的 dubbo.properties)
dubbo.registry.address=zookeeper://127.0.0.1:2181
将 IP 地址改成自己配置的 zookeeper 集群的其中一台 IP
在该配置文件下还有两行, 分别为: dubbo.admin.root.password=root
dubbo.admin.guest.password=guest
这是在浏览器上启动 dubbo 项目时需要输入的两种用户名以及对应的密码
配置完成, 去浏览器输入该 dubbo 服务器的 IP 加 8080 端口号, 由于原来的 Tomcat 自带的项目已经被删除, 由 dubbo 的项目去取代了,
所以将看到的是 dubbo 的展示页面.
dubbo 所必须要知道的注意事项:
1, 所有的 service 层必须要使用 service 注解 (之前用的 spring 框架的, 现在用 dubbo 框架所提供的 @Service 注解)
@Service(timeout = 单位是秒)
2, 在配置 dubbo 端口号的时候
只是 provider 项目和 consumer 项目直接数据通讯的时候所必需的的要遵循的端口号
也只是说必须要注意无论是 provider 还是 consumer, 所配置的 dubbo 端口号必须要保持一致
端口号随意定制!
3, 无论是在 dubbo 还是在 provider 以及 consumer 的 zookeeper 配置中, 所有的 zookeeper 集群无论是 leader 还是 follower
都可以配:
eg:
zookeeper01 是 leader
dubbo-admin------> 把 zookeeper 的配置改为 --->zookeeper01
zookeeper02 是 leader
dubbo-admin-------> 把 zookeeper 的配置仍可改为 --->zookeeper01
以上, 无论 zookeeper 的 leader 是谁, dubbo-admin 中的 IP 只要是 zookeeper 集群的其中一台就行, 因为最终都会转交给 leader(除非 leader 宕机)
所有的 zookeeper 配置的端口号都应该是 2181, 因为 dubbo 中的端口号就是 2181
4,dubbo 如何判定项目为服务器的生产者还是消费者?
在项目中的配置文件 application.properties 中所配置的 dubbo.scan.base-packages 属性来进行判断该项目时 provider 还是 consumer:
如果是服务生产者的话, 需要配置包扫描, 而消费者不需要.
5. 无论是 provider 还是 consumer,service 包必须要保持一致
- provider-->IUserService:com.aaa.lee.dubbo.service
- consumer-->IUserService:com.aaa.lee.dubbo.service
并且两个接口的名字也必须要保持一致!!!!
接口中方法也必须要保持一致 (返回值名称, 返回值类型, 方法名, 方法参数)
6.consumer 项目中的 controller 需要调用 service 的时候, 不能再使用 @Autowired 注解进行注入 service
因为整个 consumer 项目中只有 service 的接口并没有实现类
需要使用 dubbo 所提供的 @Reference
7.provider 和 consumer 的 application.properties 配置文件中 dubbo.application.name 不能一样!!!!
- provider: dubbo.application.name=user-provider
- consumer: dubbo.application.name=user-consumer
8. 无论是 provider 还是 consumer 项目都必须要把 zookeeper 的地址配置一致!!!
不要求必须配置 leader--->follower 会自动把请求转交给 leader
9. 所有的实体类必须要实现序列化接口
因为实现了序列化接口的实体类都可以把实体类以流的形式进行发送
provider 会把 User 实体类转换为二进制流 -----> 发送给 consumer---->consumer 所接收到的并不是一个 User 对象, 而是一个二进制流
---->consumer 必须要把整个二进制流转换为 User 对象才可以使用!
也就是说无论是 consumer 还是 provider 都必须要实现序列化接口
Dubbo
来源: http://www.bubuko.com/infodetail-3189420.html