1.为什么需要Dubbo——互联网架构演变
1.1 单体架构
全部功能集中在一个项目内(All in one)
1.2 垂直架构
按照业务进行切割,形成小的单体项目。
优点:技术栈可扩展(不同的系统可以用不同的编程语言编写)
1.3 SOA面向服务架构
它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。
一个服务通常以独立的形式存在于操作系统进程中。
目的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速复用。
1.4 微服务架构
架构优点:
服务拆分粒度更细,有利于提高开发效率。
可以针对不同服务制定对应的优化方案。
适用于互联网时代,产品迭代周期更短。
架构缺点:
粒度太细导致服务太多,维护成本高。
分布式系统开发的技术成本高,对团队的挑战大。
2.Dubbo简介
2.1RPC
全称为remote procedure call,即远程过程调用。
需要注意的是RPC并不是一个具体的技术,而是指整个网络远程调用过程。
各种开发语言都有自己的RPC框架。
Java中的RPC框架比较多,广泛使用的有RMI、Hessian、Dubbo等。
Dubbo提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
2.2 Dubbo架构
虚线都是异步访问,实线都是同步访问 蓝色虚线:在启动时完成的功能 红色虚线(实线)都是程序运行过程中执行的功能。
3.服务注册中心Zookeeper
3.1简介
Registry(服务注册中心)在其中起着至关重要的作用。Dubbo官方推荐使用Zookeeper作为服务注册中心。
Zookeeper 是 Apache Hadoop 的子项目,是一个树型的目录服务,支持变更推送。
3.2实现流程
流程说明:
- 服务提供者(Provider)启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的URL 地址
- 服务消费者(Consumer)启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址
- 监控中心(Monitor)启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者URL 地
4.Dubbo管理控制台
我们在开发时,需要知道Zookeeper注册中心都注册了哪些服务,有哪些消费者来消费这些服务。可以通过部署一个管理中心来实现。
其实管理中心就是一个web应用,部署到tomcat即可。
5.Dubbo相关配置
5.1 包扫描
5.2 协议
5.3 负载均衡
负载均衡(Load Balance):就是将请求分摊到多个操作单元上进行执行,从而共同完成工作任务。
在集群负载均衡时,Dubbo 提供了多种均衡策略(包括随机、轮询、最少活跃调用数、一致性Hash),缺省为random随机调用。
将请求分摊到多个操作单元上进行执行,从而共同完成工作任务。
在集群负载均衡时,Dubbo 提供了多种均衡策略(包括随机、轮询、最少活跃调用数、一致性Hash),缺省为random随机调用。