分布式简要阐明
Dubbo是用于分布式系统的框架所以咱们要先理解什么是分布式
分布式系统是若干独立 计算机的汇合,这些计算机对于用户来说就像单个相干零碎。
利用架构及倒退演变
Dubbo和SpringCloud比照
倒退演变
繁多利用架构:一个我的项目装到一个服务器当中,也能够运行多个服务器每一个服务器当中都装一个我的项目。
毛病:1.如果要增加某一个性能的话就要把一个我的项目从新打包,在别离部署到每一个服务器当中去。2.如果前期我的项目越来越大的话单台服务器跑一个我的项目压力会很大的。会不利于保护,开发和程序的性能。
MVC
垂直利用架构:将利用切割成几个互不相干的小利用,在将每个小利用独立放到一个服务器上,如果哪一个利用的拜访数量多就多加几台服务器。
分布式服务架构
RPC简介
利用之间交互不可避免,将外围业务抽取进去,作为独立的服务,逐步造成稳固的服务中心,使前端利用能更疾速的响应多变的市场需求。
什么叫RPC
1.RPC是指近程过程调用,是一种过程问通信形式,他是一种技术的思维,它容许程序调用另一个地址空间的办法
- RPC(Remote Procedure Call)—近程过程调用,它是一种通过网络从近程计算机程序上申请服务,而不须要理解底层网络技术的协定。也就是说两台服务器A,B,一个利用部署在A服务器上,想要调用B服务器上利用提供的办法,因为不在一个内存空间,不能间接调用,须要通过网络来表白调用的语义和传播调用的数据。
RPC工作原理
- Client像调用本地服务似的调用近程服务;
- Client stub接管到调用后,将办法、参数序列化
- 客户端通过sockets将音讯发送到服务端
- Server stub 收到音讯后进行解码(将音讯对象反序列化)
- Server stub 依据解码后果调用本地的服务
- 本地服务执行(对于服务端来说是本地执行)并将后果返回给Server stub
- Server stub将返回后果打包成音讯(将后果音讯对象序列化)
- 服务端通过sockets将音讯发送到客户端
- Client stub接管到后果音讯,并进行解码(将后果音讯发序列化)
- 客户端失去最终后果。
RPC 调用分以下两种:
同步调用:客户方期待调用执行实现并返回后果。
异步调用:客户方调用后不必期待执行后果返回,但仍然能够通过回调告诉等形式获取返回后果。若客户方不关怀调用返回后果,则变成单向异步调用,单向调用不必返回后果。
RPC步骤解析
RPC相干材料可拜访博客:
http://blog.csdn.net/smartbetter/article/details/100360835
SOA
流动计算架构:在分布式应用架构的根底上减少了一个调度、治理核心基于拜访压力实时治理集群容量、进步集群的利用率,用于进步机器利用率的 资源调度和治理核心(SOA) 是要害 (不节约计算机资源)
Dubbo外围概念
Dubbo官网: http://dubbo.apache.org/en-us...
Dubbo 是一款高性能、轻量级的开源Java RPC框架,它提供了三大外围能力:面向接口的近程办法调用,智能容错和负载平衡,服务主动注册和发现。分布式系统是将一个零碎拆分为多个不同的服务
Dubbo个性一览
dubbo设计架构
该图来自Dubbo官网,形容了服务注册核心、服务提供方、服务生产方、服务监控核心之间的调用关系。
服务提供者(Provider):裸露服务的服务提供方,服务提供者在启动时,向注册核心注册本人提供的服务。
服务消费者(Consumer): 调用近程服务的服务生产方,服务消费者在启动时,向注册核心订阅本人所需的服务,服务消费者,从提供者地址列表中,基于软负载平衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
注册核心(Registry):注册核心返回服务提供者地址列表给消费者,如果有变更,注册核心将基于长连贯推送变更数据给消费者。
监控核心(Monitor):服务消费者和提供者,在内存中累计调用次数和调用工夫,定时每分钟发送一次统计数据到监控核心。
Dubbo的个性
(1)服务注册核心
- 相比Hessian类RPC框架,Dubbo有本人的服务中心, 写好的服务能够注册到服务中心, 客户端从服务中心寻找服务,而后再到相应的服务提供者机器获取服务。通过服务中心能够实现集群、负载平衡、高可用(容错) 等重要性能。
- 服务中心个别应用zookeeper实现,也有redis和其余一些形式。以应用zookeeper作为服务中心为例,服务提供者启动后会在zookeeper的/dubbo节点下创立提供的服务节点,蕴含服务提供者ip、port等信息。服务提供者敞开时会从zookeeper中移除对应的服务。
- 服务使用者会从注册核心zookeeper中寻找服务,同一个服务可能会有多个提供者,Dubbo会帮咱们找到适合的服务提供者,也就是针对服务提供者的负载平衡。
(2)负载平衡
当同一个服务有多个提供者在提供服务时,客户端如何正确的抉择提供者实 现负载平衡呢?dubbo也给咱们提供了几种计划:
- random
随机
选提供者,并能够给提供者设置权重 - roundrobin
轮询
抉择提供者 - leastactive 起码沉闷调用数,雷同沉闷数的随机,沉闷数:指调用前后计数差。使慢的提供者收到更少申请,因为越慢的提供者的调用前后计数差会越大。
- consistenthash 一致性hash,雷同参数的申请发到同一台机器上。
- random
(3)简化测试,容许直连提供者
在开发阶段为了不便测试,通常零碎客户端能指定调用某个服务提供者,那么能够在援用服务时加一个url参数去指定服务提供者。 配置如下:
`<dubbo:reference id="xxxService"interface="com.alibaba.xxx.XxxService"url="dubbo://localhost:20890"/>` * 1
(4)服务版本,服务分组
在Dubbo配置文件中能够通过制订版本实现连贯制订提供者,也就是通过服务版本能够管制服务的不兼容降级;当同一个服务有多种实现时,能够应用服务分组进行辨别。
dubbo环境搭建 ZooKeeper注册核心
搭建zookeeper注册核心环境
Dubbo官网文档: http://dubbo.apache.org/en-us/docs/user/quick-start.html
在zookeeper官网下载zookeeper
http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.14/
在bin文件下,启动zkServer.cmd会有报错,解决须要在condif文件中将zoo_sample.cfg文件复制一份,将名字改为zoo.cfg。在zookeeper的文件夹下创立data文件夹,关上zoo.cfg,批改datadir,将dataDir数据保留为咱们自定义的文件中
(此步骤可省略)
配置结束后,咱们再次在conf下启动zkServer.cmd,这次能够胜利启动
持续运行zkCli.cmd,能够连贯到zookeeper的服务器。
此时,咱们zookeeper的注册核心及环境以及搭建结束。
zookeeper监控核心的配置
1、下载dubbo-admin
dubbo-admin下载地址 :https://github.com/apache/dubbo-admin/tree/master
2、解压后进入目录批改指定zookeeper地址
进入如下地址:dubbo-admin-masterdubbo-adminsrcmainresourcesapplication.properties"
将zookeeper的监控核心的地址配置为本地端口
`#注册核心的地址dubbo.registry.address=zookeeper://127.0.0.1:2181` * 1* 2
配置结束后,咱们在dubo-zookeeperdubbo-admin-masterdubbo-admin文件夹下cmd打包测试下。
`mvn clean package` * 1
在target文件中打包实现的jar包
cmd命令 java -jar dubbo-admin-0.0.1-SNAPSHOT.jar
运行打包好的jar包
启动胜利后,能够看到一个7001的端口
此时咱们的zookeeper的服务都为启动状态,在浏览器中拜访 localhost:7001,拜访到注册核心,输出账号密码root。
此时,咱们zookeeper监控核心的配置实现。留神,要拜访到监控核心,肯定要启动zookeeper注册核心的启动类
Dubbo环境搭建,创立提供者、消费者我的项目
基于以下图实现服务 提供者、消费者
Dubbo服务提供消费者接口搭建
创立Maven我的项目=> user-service-provider
服务提供者
UserAddress
`public class UserAddress implements Serializable{ private Integer id; private String userAddress; //用户地址 private String userId; //用户id private String consignee; //收货人 private String phoneNum; //电话号码 private String isDefault; //是否为默认地址 Y-是 N-否 //get set //有参结构 无参结构 }` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10
UserService
`//用户服务public interface UserService { /** * 依照用户id返回所有的收货地址 * @param userId * @return */ public List<UserAddress> getUserAddressList(String userId);}` * 1* 2* 3* 4* 5* 6* 7* 8* 9
UserServiceImpl
`public class UserServiceImpl implements UserService { public List<UserAddress> getUserAddressList(String userId) { UserAddress address1 = new UserAddress(1, "河南省郑州巩义市宋陵大厦2F", "1", "坦然", "150360313x", "Y"); UserAddress address2 = new UserAddress(2, "北京市昌平区沙河镇沙阳路", "1", "情话", "1766666395x", "N"); return Arrays.asList(address1,address2); }}` * 1* 2* 3* 4* 5* 6* 7* 8* 9
创立Maven我的项目=> order-service-consumer
服务消费者(订单服务)
OrderService
`public interface OrderService { /** * 初始化订单 * @param userID */ public void initOrder(String userID);}` * 1* 2* 3* 4* 5* 6* 7
OrderServiceImpl
`public class OrderServiceImpl implements OrderService { public void initOrder(String userID) { //查问用户的收货地址 }}` * 1* 2* 3* 4* 5* 6
因服务消费者要拿到提供者的办法
将 服务提供者 中的 实体类 及 UserService 复制到以后消费者同级文件中。
OrderServiceImpl
`public class OrderServiceImpl implements OrderService { public UserService userService; public void initOrder(String userID) { //查问用户的收货地址 List<UserAddress> userAddressList = userService.getUserAddressList(userID); System.out.println(userAddressList); }}` * 1* 2* 3* 4* 5* 6* 7* 8
此时咱们调用userservice必定是要报错的。这种面向接口的形式,咱们这里只是调到了接口,而接口理论是在另外一个我的项目中,如果咱们两个我的项目工程都创立独特的实体类,太过于麻烦了,咱们能够将服务接口,服务模型等独自放在一个我的项目中,更为不便调用。
创立Maven我的项目=> gmail-interface 用于寄存独特的服务接口
将 提供者 和 消费者 我的项目中的所有实体类复制到以后相干的文件包下,删除原有的实体类包及service包,也就是将实体类及service放在了以后公共的我的项目中。
把服务提供者和消费者我的项目中引入以下依赖,引入后我的项目不在报错.
`<dependency> <groupId>com.lemon.gmail</groupId> <artifactId>gmail-interface</artifactId> <version>1.0-SNAPSHOT</version> </dependency>` * 1* 2* 3* 4* 5
服务提供者配置及测试
在 user-service-provider
服务提供者我的项目中引入依赖
`<!--dubbo--> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.6.2</version> </dependency> <!--注册核心是 zookeeper,引入zookeeper客户端--> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>2.12.0</version> </dependency>` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12
在resource
文件中创立provider.xml
`<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd"> <!--1、指定以后服务/利用的名字(同样的服务名字雷同,不要和别的服务同名)--> <dubbo:application name="user-service-provider"></dubbo:application> <!--2、指定注册核心的地位--> <!--<dubbo:registry address="zookeeper://127.0.0.1:2181"></dubbo:registry>--> <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"></dubbo:registry> <!--3、指定通信规定(通信协议? 服务端口)--> <dubbo:protocol name="dubbo" port="20880"></dubbo:protocol> <!--4、裸露服务 让他人调用 ref指向服务的真正实现对象--> <dubbo:service interface="com.lemon.gmail.service.UserService" ref="userServiceImpl"></dubbo:service> <!--服务的实现--> <bean id="userServiceImpl" class="com.lemon.gmail.service.impl.UserServiceImpl"></bean></beans>` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12* 13* 14* 15* 16* 17* 18* 19* 20
编写一个ProviderApplication
启动类程序,运行测试配置
`public class MailApplication { public static void main(String[] args) throws IOException { ClassPathXmlApplicationContext applicationContext= new ClassPathXmlApplicationContext("provider.xml"); applicationContext.start(); System.in.read(); }}` * 1* 2* 3* 4* 5* 6* 7
启动zookeeper注册核心的的zkServer.cmd、和zkCli.cmd服务
在dubbo-admin target中cmd运行 java -jar dubbo-admin-0.0.1-SNAPSHOT.jar
再次启动我的项目,咱们能够看到在zookeeper中曾经发现服务提供者。
服务提供者的配置和测试实现
服务消费者配置及测试
在 order-service-consumer
服务消费者我的项目中引入依赖
`<!--dubbo--> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.6.2</version> </dependency> <!--注册核心是 zookeeper,引入zookeeper客户端--> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>2.12.0</version> </dependency>` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12
创立consumer.xml
`<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd"> <!--包扫描--> <context:component-scan base-package="com.lemon.gmail.service.impl"/> <!--指定以后服务/利用的名字(同样的服务名字雷同,不要和别的服务同名)--> <dubbo:application name="order-service-consumer"></dubbo:application> <!--指定注册核心的地位--> <dubbo:registry address="zookeeper://127.0.0.1:2181"></dubbo:registry> <!--调用近程裸露的服务,生成近程服务代理--> <dubbo:reference interface="com.lemon.gmail.service.UserService" id="userService"></dubbo:reference></beans>` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12* 13* 14* 15* 16* 17* 18* 19* 20
把以后OrderServiceImpl实现类中加上注解
`@Servicepublic class OrderServiceImpl implements OrderService { @Autowired public UserService userService; public void initOrder(String userID) { //查问用户的收货地址 List<UserAddress> userAddressList = userService.getUserAddressList(userID); //为了直观的看到失去的数据,以下内容也可不写 System.out.println("以后接管到的userId=> "+userID); System.out.println("**********"); System.out.println("查问到的所有地址为:"); for (UserAddress userAddress : userAddressList) { //打印近程服务地址的信息 System.out.println(userAddress.getUserAddress()); } }}` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12* 13* 14* 15* 16* 17* 18* 19
编写一个ConsumerApplication
启动类程序,运行测试配置
`public class ConsumerApplication { public static void main(String[] args) { ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("consumer.xml"); OrderService orderService = applicationContext.getBean(OrderService.class); //调用办法查问出数据 orderService.initOrder("1"); System.out.println("调用实现..."); System.in.read(); }}` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11
留神:消费者的运行测试须要先启动提供者。
启动服务提供者、消费者。及zookeeper的和dubbo-admin,查看监控信息。
localhost:7001
此时能够看到一个提供者,一个消费者的信息监控信息。
dubbo-monitor-simple繁难监控核心
进入dubbo-monitor-simple文件,执行cmd命令,mvn package打包成jar包
将 dubbo-monitor-simple-2.0.0-assembly.tar.gz
压缩包解压至以后文件夹,解压后config文件查看properties的配置是否是本地的zookeeper。
关上解压后的 assembly.bin
文件,start.bat
启动dubbo-monitor-simple监控核心
在浏览器 localhost:8080
,能够看到一个监控核心。
在服务提供者和消费者的xml中配置以下内容,再次启动服务提供和消费者启动类。
`<!--dubbo-monitor-simple监控核心发现的配置--> <dubbo:monitor protocol="registry"></dubbo:monitor> <!--<dubbo:monitor address="127.0.0.1:7070"></dubbo:monitor>-->` * 1* 2* 3
能够看到,这个监控核心也捕捉到了服务提供和消费者信息
Dubbo与SpringBoot整合
boot-user-service-provider 服务提供者
创立Maven我的项目 boot-user-service-provider
服务提供者
导入以下依赖
`<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.4.RELEASE</version> <relativePath /> </parent> <dependencies> <dependency> <groupId>com.lemon.gmail</groupId> <artifactId>gmail-interface</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dependency> <groupId>com.alibaba.boot</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>0.2.0</version> </dependency> </dependencies>` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12* 13* 14* 15* 16* 17* 18* 19* 20* 21* 22* 23* 24* 25
把 user-service-provider
中的service拿到此我的项目中。
留神,以此办法为返回的须要更改 interface包中的void为 List
`@Service//dubbo的服务裸露@Componentpublic class UserServiceImpl implements UserService { public List<UserAddress> getUserAddressList(String userId) { UserAddress address1 = new UserAddress(1, "河南省郑州巩义市宋陵大厦2F", "1", "坦然", "150360313x", "Y"); UserAddress address2 = new UserAddress(2, "北京市昌平区沙河镇沙阳路", "1", "情话", "1766666395x", "N"); return Arrays.asList(address1,address2); }}` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11
配置 application.properties
`dubbo.application.name=boot-user-service-providerdubbo.registry.address=127.0.0.1:2181dubbo.registry.protocol=zookeeperdubbo.protocol.name=dubbodubbo.protocol.port=20880#连贯监控核心dubbo.monitor.protocol=registry` * 1* 2* 3* 4* 5* 6* 7* 8* 9
BootProviderApplication 启动类配置
`@EnableDubbo //开启基于注解的dubbo性能@SpringBootApplicationpublic class BootProviderApplication { public static void main(String[] args) { SpringApplication.run(BootProviderApplication.class, args); }}` * 1* 2* 3* 4* 5* 6* 7* 8
启动注册核心,启动以后服务提供者,能够在浏览器看到一个服务提供者。
boot-order-service-consumer 服务消费者
创立Maven我的项目 boot-order-service-consumer
服务消费者
导入以下依赖
`<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.4.RELEASE</version> <relativePath /> <!-- lookup parent from repository --> </parent> <dependencies> <dependency> <groupId>com.lemon.gmail</groupId> <artifactId>gmail-interface</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.alibaba.boot</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>0.2.0</version> </dependency> </dependencies>` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12* 13* 14* 15* 16* 17* 18* 19* 20* 21* 22* 23* 24* 25
把order-service-consumer我的项目中的service复制到以后我的项目。
`@Servicepublic class OrderServiceImpl implements OrderService { @Reference//援用近程提供者服务 UserService userService; public List<UserAddress> initOrder(String userID) { //查问用户的收货地址 List<UserAddress> userAddressList = userService.getUserAddressList(userID); System.out.println("以后接管到的userId=> "+userID); System.out.println("**********"); System.out.println("查问到的所有地址为:"); for (UserAddress userAddress : userAddressList) { //打印近程服务地址的信息 System.out.println(userAddress.getUserAddress()); } return userAddressList; }}` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12* 13* 14* 15* 16* 17* 18* 19* 20
创立 OrderController 控制器
`@Controllerpublic class OrderController { @Autowired OrderService orderService; @RequestMapping("/initOrder") @ResponseBody public List<UserAddress> initOrder(@RequestParam("uid")String userId) { return orderService.initOrder(userId); }}` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11
创立application.properties 配置
`server.port=8081dubbo.application.name=boot-order-service-consumerdubbo.registry.address=zookeeper://127.0.0.1:2181#连贯监控核心 注册核心协定dubbo.monitor.protocol=registry` * 1* 2* 3* 4* 5* 6
BootConsumerApplication 启动类创立
`@EnableDubbo //开启基于注解的dubbo性能@SpringBootApplicationpublic class BootConsumerApplication { public static void main(String[] args){ SpringApplication.run(BootConsumerApplication.class,args); }}` * 1* 2* 3* 4* 5* 6* 7
配置结束,此时启动zookeeper注册核心及监控。
启动springboot配置的服务提供者和消费者
在浏览器输出 localhost:7001 查看后果
http://localhost:8081/initOrder?uid=1 查问到地址信息
duboo的springboot整合配置实现。
Dubbo配置
dubbo配置官网参考:http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-service.html
1、配置准则
JVM 启动 -D 参数优先,这样能够使用户在部署和启动时进行参数重写,比方在启动时需扭转协定的端口。
XML 次之,如果在 XML 中有配置,则 dubbo.properties 中的相应配置项有效。
Properties 最初,相当于缺省值,只有 XML 没有配置时,dubbo.properties 的相应配置项才会失效,通常用于共享公共配置,比方利用名。
2、启动时查看
Dubbo 缺省会在启动时查看依赖的服务是否可用,不可用时会抛出异样,阻止 Spring 初始化实现,以便上线时,能及早发现问题,默认 check=“true”。
能够通过 check=“false” 敞开查看,比方,测试时,有些服务不关怀,或者呈现了循环依赖,必须有一方先启动。
另外,如果你的 Spring 容器是懒加载的,或者通过 API 编程提早援用服务,请敞开 check,否则服务长期不可用时,会抛出异样,拿到 null 援用,如果 check=“false”,总是会返回援用,当服务复原时,能主动连上。
以order-service-consumer
消费者为例,在consumer.xml中增加配置
`<!--配置以后消费者的对立规定,以后所有的服务都不启动时查看--> <dubbo:consumer check="false"></dubbo:consumer>` * 1* 2
增加后,即便服务提供者不启动,启动以后的消费者,也不会呈现谬误。
3、全局超时配置
`全局超时配置<dubbo:provider timeout="5000" />指定接口以及特定办法超时配置<dubbo:provider interface="com.foo.BarService" timeout="2000"> <dubbo:method name="sayHello" timeout="3000" /></dubbo:provider>` * 1* 2* 3* 4* 5* 6* 7
配置准则
dubbo举荐在Provider上尽量多配置Consumer端属性
`1、作服务的提供者,比服务应用方更分明服务性能参数,如调用的超时工夫,正当的重试次数,等等2、在Provider配置后,Consumer不配置则会应用Provider的配置值,即Provider配置能够作为Consumer的缺省值。否则,Consumer会应用Consumer端的全局设置,这对于Provider不可控的,并且往往是不合理的` * 1* 2
配置的笼罩规定:
- 办法级配置别优于接口级别,即小Scope优先
- Consumer端配置 优于 Provider配置 优于 全局配置,
- 最初是Dubbo Hard Code的配置值(见配置文档)
多版本控制
[
http://dubbo.apache.org/zh-cn...](http://dubbo.apache.org/zh-cn...
在服务提供者中复制多个impl。起不同的名字
配置多个文件的门路及信息。
服务消费者调用时,可自在配置版本
dubbo与springboot整合的三种形式
1、将服务提供者注册到注册核心(如何裸露服务)
1.1导入Dubbo的依赖 和 zookeeper 客户端
2、让服务消费者去注册核心订阅服务提供者的服务地址
Springboot与Dubbo整合的三种形式
2.1导入dubbo-starter。在application.properties配置属性,应用@Service【裸露服务】,应用@Reference【援用服务】
2.2保留Dubbo 相干的xml配置文件
导入dubbo-starter,应用@ImportResource导入Dubbo的xml配置文件
3、应用 注解API的形式
将每一个组件手动配置到容器中,让dubbo来扫描其余的组件
高可用
zookeeper宕机与dubbo直连
景象:zookeeper注册核心宕机,还能够生产dubbo裸露的服务。
起因:
健壮性↓
- 监控核心宕掉不影响应用,只是失落局部采样数据
- 数据库宕掉后,注册核心仍能通过缓存提供服务列表查问,但不能注册新服务
- 注册核心对等集群,任意一台宕掉后,将主动切换到另一台
- 注册核心全副宕掉后,服务提供者和服务消费者仍能通过本地缓存通信
- 服务提供者无状态,任意一台宕掉后,不影响应用
- 服务提供者全副宕掉后,服务消费者利用将无奈应用,并有限次重连期待服务提供者复原
高可用:通过设计,缩小零碎不能提供服务的工夫;
集群下dubbo负载平衡配置
在集群负载平衡时,Dubbo 提供了多种平衡策略,缺省为 random 随机调用。
负载平衡策略如下
Random LoadBalance 基于权重的随机负载平衡机制随机,按权重设置随机概率。 在一个截面上碰撞的概率高,但调用量越大散布越平均,而且按概率使用权重后也比拟平均,有利于动静调整提供者权重。
RoundRobin LoadBalance 基于权重的轮询负载平衡机制轮循,按公约后的权重设置轮循比率。 存在慢的提供者累积申请的问题,比方:第二台机器很慢,但没挂,当申请调到第二台时就卡在那,长此以往,所有申请都卡在调到第二台上。
LeastActive LoadBalance起码沉闷数负载平衡机制起码沉闷调用数,雷同沉闷数的随机,沉闷数指调用前后计数差。 使慢的提供者收到更少申请,因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance一致性hash 负载平衡机制一致性 Hash,雷同参数的申请总是发到同一提供者。 当某一台提供者挂时,本来发往该提供者的申请,基于虚构节点,平摊到其它提供者,不会引起激烈变动。算法参见:http://en.wikipedia.org/wiki/Consistent_hashing 缺省只对第一个参数 Hash,如果要批改,请配置 <dubbo:parameter key="hash.arguments" value="0,1" /> 缺省用 160 份虚构节点,如果要批改,请配置 <dubbo:parameter key="hash.nodes" value="320" />
整合hystrix,服务熔断与降级解决
服务降级
当服务器压力剧增的状况下,依据理论业务状况及流量,对一些服务和页面有策略的不解决或换种简略的形式解决,从而开释服务器资源以保障外围交易失常运作或高效运作。
能够通过服务降级性能长期屏蔽某个出错的非关键服务,并定义降级后的返回策略。
向注册核心写入动静配置笼罩规定:
`RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));` * 1* 2* 3
其中:
mock=force:return+null 示意生产方对该服务的办法调用都间接返回 null 值,不发动近程调用。用来屏蔽不重要服务不可用时对调用方的影响。
还能够改为 mock=fail:return+null 示意生产方对该服务的办法调用在失败后,再返回 null 值,不抛异样。用来容忍不重要服务不稳固时对调用方的影响。
集群容错
在集群调用失败时,Dubbo 提供了多种容错计划,缺省为 failover 重试。
集群容错模式
Failover Cluster
失败主动切换,当呈现失败,重试其它服务器。通常用于读操作,但重试会带来更长提早。可通过 retries=“2” 来设置重试次数(不含第一次)。
重试次数配置如下:
<dubbo:service retries=“2” />
或
<dubbo:reference retries=“2” />
或
dubbo:reference
<dubbo:method name=“findFoo” retries=“2” />
</dubbo:reference>
Failfast Cluster
疾速失败,只发动一次调用,失败立刻报错。通常用于非幂等性的写操作,比方新增记录。
Failsafe Cluster
失败平安,出现异常时,间接疏忽。通常用于写入审计日志等操作。
Failback Cluster
失败主动复原,后盾记录失败申请,定时重发。通常用于音讯告诉操作。
Forking Cluster
并行调用多个服务器,只有一个胜利即返回。通常用于实时性要求较高的读操作,但须要节约更多服务资源。可通过 forks=“2” 来设置最大并行数。
Broadcast Cluster
播送调用所有提供者,一一调用,任意一台报错则报错 [2]。通常用于告诉所有提供者更新缓存或日志等本地资源信息。
集群模式配置
依照以下示例在服务提供方和生产方配置集群模式
<dubbo:service cluster=“failsafe” />
或
<dubbo:reference cluster=“failsafe” />
整合hystrix
服务熔断错解决配置参考=> https://www.cnblogs.com/xc-xinxue/p/12459861.html
Hystrix 旨在通过管制那些拜访近程零碎、服务和第三方库的节点,从而对提早和故障提供更弱小的容错能力。Hystrix具备领有回退机制和断路器性能的线程和信号隔离,申请缓存和申请打包,以及监控和配置等性能
配置spring-cloud-starter-netflix-hystrix
spring boot官网提供了对hystrix的集成,间接在pom.xml里退出依赖:
`<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> <version>1.4.4.RELEASE</version></dependency>` * 1* 2* 3* 4* 5
而后在Application类上减少@EnableHystrix来启用hystrix starter:
`@SpringBootApplication@EnableHystrix //开启服务容错性能public class ProviderApplication { ...启动办法}` * 1* 2* 3* 4* 5
配置Provider端
在Dubbo的Provider上减少@HystrixCommand配置,这样子调用就会通过Hystrix代理。
`@Service(version = "1.0.0")public class HelloServiceImpl implements HelloService { @HystrixCommand(commandProperties = { @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"), @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") }) @Override public String sayHello(String name) { // System.out.println("async provider received: " + name); // return "annotation: hello, " + name; throw new RuntimeException("Exception to show hystrix enabled."); }}` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12
配置Consumer端
对于Consumer端,则能够减少一层method调用,并在method上配置@HystrixCommand。当调用出错时,会走到fallbackMethod = "reliable"的调用里。
`@Reference(version = "1.0.0") private HelloService demoService; @HystrixCommand(fallbackMethod = "reliable") public String doSayHello(String name) { return demoService.sayHello(name); } public String reliable(String name) { return "hystrix fallback value"; }` * 1* 2* 3* 4* 5* 6* 7* 8* 9* 10
dubbo原理
RPC原理
一次残缺的RPC调用流程(同步调用,异步另说)如下:
- 服务生产方(client)调用以本地调用形式调用服务;
- client stub接管到调用后负责将办法、参数等组装成可能进行网络传输的音讯体;
- client stub找到服务地址,并将音讯发送到服务端;
- server stub收到音讯后进行解码;
- server stub依据解码后果调用本地的服务;
- 本地服务执行并将后果返回给server stub;
- server stub将返回后果打包成音讯并发送至生产方;
- client stub接管到音讯,并进行解码;
- 服务生产方失去最终后果。
dubbo只用了两步1和8,两头的过程是通明的看不到的。RPC框架的指标就是要2~8这些步骤都封装起来,这些细节对用户来说是通明的,不可见的。
netty通信原理
Netty是一个异步事件驱动的网络应用程序框架, 用于疾速开发可保护的高性能协定服务器和客户端。它极大地简化并简化了TCP和UDP套接字服务器等网络编程。
BIO:(Blocking IO)
NIO (Non-Blocking IO)
Selector 个别称 为选择器 ,也能够翻译为 多路复用器,
Connect(连贯就绪)、Accept(承受就绪)、Read(读就绪)、Write(写就绪)
Netty基本原理:
netty基本原理,可参考https://www.sohu.com/a/272879207_463994
dubbo原理
1.dubbo原理 -框架设计
- config 配置层:对外配置接口,以 ServiceConfig, ReferenceConfig 为核心,能够间接初始化配置类,也能够通过 spring 解析配置生成配置类
- proxy 服务代理层:服务接口通明代理,生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为核心,扩大接口为 ProxyFactory
- registry 注册核心层:封装服务地址的注册与发现,以服务 URL 为核心,扩大接口为 RegistryFactory, Registry, RegistryService
- cluster 路由层:封装多个提供者的路由及负载平衡,并桥接注册核心,以 Invoker 为核心,扩大接口为 Cluster, Directory, Router, LoadBalance
- monitor 监控层:RPC 调用次数和调用工夫监控,以 Statistics 为核心,扩大接口为 MonitorFactory, Monitor, MonitorService
- protocol 近程调用层:封装 RPC 调用,以 Invocation, Result 为核心,扩大接口为 Protocol, Invoker, Exporter
- exchange 信息替换层:封装申请响应模式,同步转异步,以 Request, Response 为核心,扩大接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
- transport 网络传输层:形象 mina 和 netty 为对立接口,以 Message 为核心,扩大接口为 Channel, Transporter, Client, Server, Codec
- serialize 数据序列化层:可复用的一些工具,扩大接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool