说明:如果没有分布式的需求,其实是不需要用的,只有在分布式的时候,才有dubbo这样的分布式服务框架的需求
2.Dubbo是一个RPC框架,,提供了SOA服务治理方案
说明:RPC(Remote Procedure Call Protocol),通俗的说,就是两台服务器A、B,应用A部署在A服务器上,应用B部署在B服务器上,A应用想要调用B服务器上B应用提供的函数(方法),由于不在一个内存空间,不能直接调用,需要通过网络通讯、协议、寻址的方式来表达调用的语义和传达调用的数据。RPC的亮点就是将远程调用的细节隐藏起来,使得调用远程服务像调用本地服务一样简单
RPC主要是基于TCP/IP协议的,而HTTP服务主要是基于HTTP协议的,我们都知道HTTP协议是在传输层协议TCP之上的,HTTP是应用层协议,而TCP是传输层协议,所以效率来看的话,RPC当然是要更胜一筹。
本质上,dubbo就是个服务调用的东东。
SOA(Service-Oriented Architecture):面向服务的架构,也可以理解为资源调度和治理中心。所谓服务,拿项目二举个最简单的例子,把商品、订单、搜索等核心业务抽取出来,作为独立的服务。和面向对象来比较,面向对象的程序是由一个一个的类组成的,而面向服务的架构是由一个一个服务组成的。如果有多个系统、多个终端(PC、APP等)都想调用我这个服务,那么就可以通过同一套协议和接口规范来调用。而服务越来越多,容量和资源利用率不相同的时候,我们可以增加一个调度中心基于访问的压力实时的管理集群容量,从而提高集群利用率,因此Dubbo就可以这中间起到的资源(服务)调度和治理中心。
dubbo的架构:
主要有五个角色/核心组件,分为是Container(容器)、Provider(服务的提供方)、Registry(注册中心)、Consumer(服务的消费方)、Monitor(监控中心)。
容器主要负责启动、加载、运行服务提供者;
同时服务提供者在启动时,向注册中心注册自己提供的服务;
消费者向注册中心订阅自己的服务;
注册中心返回服务提供者列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者;
对于服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另外一台调用;
服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心;
Dubbo提供的负载均衡策略有四种:
1、随机均衡算法:按权重设置随机概率,默认的
-
权重轮询均衡算法:按照公约后的权重设置轮询比率,能考虑到每台服务器的性能,所以,在实际应用中比较常见;
-
最少活跃调用数均衡算法
-
一致性hash均衡算法:相同参数的请求总是发到同一台提供者
它有什么特点?它的优点是什么?Dubbo能做什么?
1.它是高性能的
2.它是轻量级的
3.它是开源的
4.它和 Spring框架无缝集成
5.透明化的远程方法调用 或者说 面向接口的远程方法调用
说明:像调用本地方法一样调用远程方法;只需简单配置,没有任何API侵入。
6.软负载均衡及容错机制 或者说 智能容错和负载均衡
说明:可在内网替代nginx lvs等硬件负载均衡器。
7.服务注册中心自动注册和服务发现 & 配置管理
说明:不需要写死服务提供者地址,注册中心基于接口名自动查询提供者ip。
使用类似zookeeper等分布式协调服务作为服务注册中心,可以将绝大部分项目配置移入zookeeper集群。
8.服务接口监控与治理
说明:Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能,针对不同应用的不同接口,可以进行 多版本,多协议,多注册中心管理。
为什么要使用它?
背景:
当网站规模达到了一定的量级的时候,普通的MVC框架已经不能满足我们的需求,于是分布式的服务框架和流动式的架构就凸显出来了。
单一应用架构
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。
在大规模服务化之前,应用可能只是通过 RMI 或 Hessian 等工具,简单的暴露和引用远程服务,通过配置服务的URL地址进行调用,通过 F5 等硬件进行负载均衡。
需求:
当服务越来越多时,服务 URL 配置管理变得非常困难,F5 硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心,动态的注册和发现服务,使服务的位置透明。并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover,降低对 F5 硬件负载均衡器的依赖,也能减少部分成本。
当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。 这时,需要自动画出应用间的依赖关系图,以帮助架构师理清理关系。
接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器? 为了解决这些问题,第一步,要将服务现在每天的调用量,响应时间,都统计出来,作为容量规划的参考指标。其次,要可以动态调整权重,在线上,将某台机器的权重一直加大,并在加大的过程中记录响应时间的变化,直到响应时间到达阈值,记录此时的访问量,再以此访问量乘以机器数反推总容量。
实际场景中的选择:
-
Spring Cloud:Spring全家桶,用起来很舒服,只有你想不到,没有它做不到。可惜因为发布的比较晚,国内还没出现比较成功的案例,大部分都是试水,不过毕竟有Spring作背书,还是比较看好。
-
Dubbox:相对于Dubbo支持了REST,估计是很多公司选择Dubbox的一个重要原因之一,但如果使用Dubbo的RPC调用方式,服务间仍然会存在API强依赖,各有利弊,懂的取舍吧。
-
Thrift:如果你比较高冷,完全可以基于Thrift自己搞一套抽象的自定义框架吧。
-
Montan:可能因为出来的比较晚,目前除了新浪微博16年初发布的,
-
Hessian:如果是初创公司或系统数量还没有超过5个,推荐选择这个,毕竟在开发速度、运维成本、上手难度等都是比较轻量、简单的,即使在以后迁移至SOA,也是无缝迁移。
-
rpcx/gRPC:在服务没有出现严重性能的问题下,或技术栈没有变更的情况下,可能一直不会引入,即使引入也只是小部分模块优化使用。
假设模块A写了一个接口,模块B写了接口的实现类,现在模块A需要查询id为5的user数据,它是怎么工作的?
它的架构是怎么样的呢?
那我们要怎么去使用dubbo呢?
实战案例操作dubbo:
第一步:
准备注册中心:启动Zookeeper服务器。/opt/zookeeper-3.4.9/bin/zkServer.sh start
创建common工程
存放Java实体类:Employee
存放封装远程方法功能的接口:RemoteEmployeeService
创建Provider工程
提供RemoteEmployeeService 接口实现类
基于RemoteEmployeeService 接口暴露服务
在pom.xml中加入依赖
com.alibaba
dubbo
2.5.5
cglib
cglib
2.2
org.aspectj
aspectjweaver
1.6.8
com.github.sgroschupf
zkclient
0.1
com.dubbo
Dubbo_Common
0.0.1-SNAPSHOT
spring-provider.xml
<dubbo:application name=“provider”/>
<dubbo:registry address=“192.168.0.100:2181” protocol=“zookeeper”/>
<dubbo:service interface=“com.api.RemoteEmployeeService” ref=“remoteEmployeeService”/>
<dubbo:protocol name=“dubbo” port=“20880”/>
web.xml
contextConfigLocation
classpath:spring-provider.xml
org.springframework.web.context.ContextLoaderListener
RemoteEmployeeService接口实现类
获取到数据改动就可
创建Consumer工程
pom.xml
javax.servlet
servlet-api
2.5
provided
javax.servlet.jsp
jsp-api
2.1.3-b06
provided
cglib
cglib
2.2
org.aspectj
aspectjweaver
1.6.8
com.alibaba
dubbo
2.5.5
com.github.sgroschupf
zkclient
0.1
org.springframework
spring-webmvc
4.3.10.RELEASE
compile
com.dubbo
Dubbo_Common
0.0.1-SNAPSHOT
form.jsp
表单
ID:
Name:
spring-consumer.xml
<context:component-scan base-package=“com.handler”/>
mvc:annotation-driven/
<dubbo:application name=“consumer”/>
<dubbo:registry address=“192.168.0.100:2181” protocol=“zookeeper”/>
<dubbo:reference id=“RemoteEmployeeService” interface=“com.api.RemoteEmployeeService”/>
handler方法
@Autowired
private RemoteEmployeeService remoteEmployeeService;
@RequestMapping(“/handler”)
public String queryEmployee(Employee employee,Model model) {
Employee queryEmployeeByCondition = remoteEmployeeService.queryEmployeeByCondition(employee);
model.addAttribute(“employee”, queryEmployeeByCondition);
return “target”;
}
web.xml
springDispatcherServlet
org.springframework.web.servlet.DispatcherServlet
contextConfigLocation
classpath:spring-consumer.xml
1
springDispatcherServlet
/
启动运行项目
先运行provider
在运行consumer,改端口号,避免报错