当前位置 : 首页 » 文章分类 :  开发  »  面试准备09-微服务与dubbo

面试准备09-微服务与dubbo

Java面试准备之微服务与dubbo


常见容错策略

周志明的软件架构课
https://time.geekbang.org/opencourse/intro/100064201

故障转移(FailOver):当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。这种策略要求服务调用的操作必须是幂等的,也就是说无论调用多少次,只要是同一个调用,返回的结果都是相同的,一般适合服务调用是读请求的场景。
快速失败(FailFast):只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。实际在业务执行时,一般非核心业务的调用,会采用快速失败策略,调用失败后一般就记录下失败日志就返回了。
安全失败(Failsafe):出现异常时,直接忽略。通常用于写入审计日志等操作。
静默失败(Failsilent):如果大量的请求需要等到超时(或者长时间处理后)才宣告失败,很容易由于某个远程服务的请求堆积而消耗大量的线程、内存、网络等资源,进而影响到整个系统的稳定。面对这种情况,一种合理的失败策略是当请求失败后,就默认服务提供者一定时间内无法再对外提供服务,不再向它分配请求流量,将错误隔离开来,避免对系统其他部分产生影响,此即为沉默失败策略。
故障恢复(FailBack):就是服务消费者调用失败或者超时后,不再重试,而是根据失败的详细信息,来决定后续的执行策略。比如对于非幂等的调用场景,如果调用失败后,不能简单地重试,而是应该查询服务端的状态,看调用到底是否实际生效,如果已经生效了就不能再重试了;如果没有生效可以再发起一次调用。通常用于消息通知操作。
并行调用(Forking):并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。
广播调用(Broadcast):广播调用所有提供者,逐个调用,任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。


BFF架构演进

BFF 全称是 Backends For Frontends(服务于前端的后端)

在微服务架构中,BFF(Backend for Frontend) 也称聚合层或者适配层,它主要承接一个适配角色:将内部复杂的微服务,适配成对各种不同用户体验(无线/Web/H5/第三方等)友好和统一的API。

BFF 就是服务器设计 API 时会考虑到不同设备的需求,也就是为不同的设备提供不同的API接口,虽然它们可能是实现相同的功能,但因为不同设备的特殊性,它们对服务端的API访问也各有其特点,需要区别处理。

聚合、裁剪、适配是BFF的主要职责

一、没有 BFF 之前的微服务架构如下:
端 -> 微服务
这种架构的问题是:
1、微服务需要适配端,处理各个不同端的登录鉴权认证。
2、端上实现一个功能可能要调用多个微服务,端上逻辑太复杂,对于每次更新都需要在App商店发版的移动端来说,更新成本很高,要尽量简化。

二、加了 BFF 聚合层之后的微服务架构:
Android端 -> 安卓BFF -> 微服务
Web端 -> Web BFF -> 微服务

BFF 聚合层来适配多个微服务,端只需要调用一次聚合层。

三、再将聚合层中的认证、限流、统计、监控抽取出 API 网关层后,架构变为:
端用户体验层(端)-> API网关层 -> BFF层 -> 微服务层


部署

蓝绿部署

BlueGreen Deployment
在蓝绿发布过程中,有两套生产环境:蓝环境和绿环境。蓝色是当前版本并拥有实时流量,绿色是包含更新代码的环境。无论任何时候,只有一套环境有实时流量

要发布一个新版本,需要先将代码部署到没有流量的环境中,这是执行最终测试的地方。当IT人员确认应用程序已经准备就绪,就会将所有流量都将路由到绿色环境。那么绿色环境就已经生效,并且执行发布。

蓝绿部署需要在发布过程中,同时运行两套程序。对硬件的要求也是当前所需的2倍,比如当前运行时,需要10台服务器支撑业务,那么使用蓝绿部署,你就需要购置20台服务器。

滚动更新

Rolling update
所谓滚动发布,就是在发布过程中,并不一下子启动所有新版本,而是先启动一台新版本,再停止一台老版本,然后再启动一台新版本,再停止一台老版本,直到全部发布完成,这样的话,如果当前需要10台服务器支撑服务,那么升级过程中一共只需要11台就行了。

滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。

这种方式也有很多缺点:
在开始滚动发布后,流量会直接流向已经启动起来的新版本,但是这个时候,新版本是不一定稳定/符合预期的,可能需要进一步的测试才能确认。那么在滚动发布期间,整个系统就处于较为不稳定的状态,如果发现了问题,也比较难以确定是新版本还是老版本造成的问题。
如果需要回滚,很困难。

金丝雀发布/灰度发布

灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。
金丝雀部署也就是灰度发布的一种方式。

CanaryRelease
金丝雀发布指的是在生产环境中分阶段逐步更新后端应用的版本(需要具备流量控制能力),在小范围验证符合预期之后,再推广至整个生产环境。

滚动发布加上流量控制和验证,也就是金丝雀发布/灰度发布。

在灰度发布开始后,先启动一个新版本应用,但是并不直接将流量切过来,而是测试人员对新版本进行线上测试,启动的这个新版本应用,就是我们的金丝雀。如果没有问题,那么可以将少量的用户流量导入到新版本上,然后再对新版本做运行状态观察,收集各种运行时数据,如果此时对新旧版本做各种数据对比,就是所谓的A/B测试。
当确认新版本运行良好后,再逐步将更多的流量导入到新版本上,在此期间,还可以不断地调整新旧两个版本的运行的服务器副本数量,以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上,最后关闭剩下的老版本服务,完成灰度发布。
如果在灰度发布过程中(灰度期)发现了新版本有问题,就应该立即将流量切回老版本上,这样,就会将负面影响控制在最小范围内。

为什么叫金丝雀发布?

17世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;而当瓦斯含量超过一定限度时,虽然人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”,以便在危险状况下紧急撤离。


AB测试

A/B测试是效果测试(一般用来验证某个想法是否符合预期),同一时间有多个版本的服务对外服务,这些服务都是经过足够测试,达到了上线标准的服务,有差异但是没有新旧之分。它关注的是不同版本的服务的实际效果,譬如说转化率、订单情况等。

A/B测试时,线上同时运行多个版本的服务,这些服务通常会有一些体验上的差异,譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果,以选出效果最好的版本。


服务治理

服务注册与发现Eureka

客服端负载均衡Ribbon

声明式服务调用Feign

熔断降级Hystrix

调用链跟踪APM

pinpoint的实现原理

见笔记 Pinpoint

微服务可观测

1、可观测与监控的区别
可观测性的范围是大于监控的

可观测的数据基础 MTL Metrics, Tracing, Logging
trace链路追踪系统通常都是采样进行,采样比例可配置,一般不会跟踪全部请求,资源消耗过大。

2、监控系统设计
zabbix:采集,中控机,指标配置
1、数据采集:推/拉,有代码侵入/agent无感知采集
2、数据处理:实时、离线、降采样
3、可视化
4、报警:防止报警抖动(超过阈值n时间或m次后再发出)

3、时序数据库
InfluxDB
OpenTSDB,内部基于 hbase 存储


微服务框架

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。

每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。

放弃Dubbo,选择最流行的Spring Cloud微服务架构实践与经验总结
http://developer.51cto.com/art/201710/554633.htm

Spring cloud

spring cloud 为开发人员提供了快速构建分布式系统的一些工具,包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。它运行环境简单,可以在开发人员的电脑上跑。另外说明spring cloud是基于springboot的

史上最简单的 SpringCloud 教程 | 第一篇: 服务的注册与发现(Eureka)
http://blog.csdn.net/forezp/article/details/69696915

微服务架构Spring cloud与dubbo区别

从项目的背景来看,Dubbo 国内用的公司挺多,国内影响力大,Spring Cloud 自然在国外影响力较大,所以这个来看不分伯仲了,毕竟都有大公司在使用。

从社区的活跃度来看,可以看下各自的Github托管项目来区分,Dubbo · GitHub 与 Spring Cloud · GitHub ,从更新频率与更新时间来看 Spring Cloud 优于Dubbo,Dubbo基本不维护了。

从框架的完整度来看,Dubbo只是实现了服务治理(注册 发现等),而Spring Cloud下面有很多个子项目覆盖了微服务架构下的方方面面,服务治理只是其中的一个方面,一定程度来说,Dubbo只是Spring Cloud Netflix中的一个子集。如果选择Spring Cloud,基本上每个环节都已经有了对应的组件支持,可能有些也不一定能满足你所有的需求,但是其活跃的社区与快速的迭代更新也会让你没有后顾之忧。

放弃Dubbo,选择最流行的Spring Cloud微服务架构实践与经验总结
http://developer.51cto.com/art/201710/554633.htm

请问哪位大神比较过spring cloud和dubbo,各自的优缺点是什么?
https://www.zhihu.com/question/45413135


webservice(SOAP)

WebService是一种跨编程语言和跨操作系统平台的远程调用技术。
WSDL: 服务描述协议。用来描述如何访问具体的服务。包括方法,参数
SOAP: 基于HTTP协议,采用XML格式,用来传递信息的格式

Apache cxf原理

基于CXF可以非常简单地以WebService的方式来实现Java甚至是跨语言的远程调用

cxf的实现原理是代理:
在服务端,提供一个JaxWsProxyFactoryBean工厂类,内部采用java原生发布webservice的方式(定义接口、实现类、Endpoint发布)对服务进行包装并发布。此外还提供Interceptor拦截器对服务进行扩展,可以在服务被调用前或调用后增加一些额外的处理,比如安全验证等。
在客户端,提供一个JaxWsProxyFactoryBean工厂类,能够直接以接口的方式来调用远程的WebService,不需要手动通过wsimport工具生成客户端代码,简化了调用WebService调用的复杂性。

CXF的大体原理
http://blog.sina.com.cn/s/blog_4adc4b090102v2wy.html

hessian

Hessian是一个轻量级的RPC框架。它基于HTTP协议传输,使用Hessian二进制序列化,对于数据包比较大的情况比较友好。
Hessian是一个轻量级的remoting onhttp工具,使用简单的方法提供了RMI的功能。 相比WebService,Hessian更简单、快捷。采用的是二进制RPC协议,因为采用的是二进制协议,所以它很适合于发送二进制数据。

Hessian序列化

Hessian原理分析
https://www.cnblogs.com/happyday56/p/4268249.html

hessian序列化区别
https://blog.csdn.net/bohu83/article/details/51210468

java RMI

只能基于JAVA语言,客户机与服务器紧耦合。


restful api

详见rest笔记


rpc框架

rpc原理

一次完整的RPC调用流程(同步调用,异步另说)如下:
1)服务消费方(client)调用以本地调用方式调用服务;
2)client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;
3)client stub找到服务地址,并将消息发送到服务端;
4)server stub收到消息后进行解码;
5)server stub根据解码结果调用本地的服务;
6)本地服务执行并将结果返回给server stub;
7)server stub将返回结果打包成消息并发送至消费方;
8)client stub接收到消息,并进行解码;
9)服务消费方得到最终结果。
RPC框架的目标就是要2~8这些步骤都封装起来,让用户对这些细节透明。

服务注册和发现

服务提供者启动后主动向注册中心注册机器ip、port以及提供的服务列表;
服务消费者启动时向注册中心获取服务提供方地址列表,可实现软负载均衡和Failover;

stub存根和动态代理

生成 client stub和server stub需要用到 Java 动态代理技术 ,我们可以使用JDK原生的动态代理机制,可以使用一些开源字节码工具框架 如:CgLib、Javassist等。

序列化

为了能在网络上传输和接收 Java对象,我们需要对它进行 序列化和反序列化操作。

序列化:将Java对象转换成byte[]的过程,也就是编码的过程;
反序列化:将byte[]转换成Java对象的过程;

可以使用Java原生的序列化机制,但是效率非常低,推荐使用一些开源的、成熟的序列化技术,例如:protobuf、Thrift、hessian、Kryo、Msgpack
关于序列化工具性能比较可以参考:jvm-serializers

NIO

当前很多RPC框架都直接基于netty这一IO通信框架,比如阿里巴巴的HSF、dubbo,Hadoop Avro,推荐使用Netty 作为底层通信框架。

服务注册中心

可选技术:
Redis
Zookeeper
Consul
Etcd

开源的优秀RPC框架

阿里巴巴 Dubbo:github.com/alibaba/dub…
新浪微博 Motan:github.com/weibocom/mo…
gRPC:github.com/grpc/grpc
rpcx :github.com/smallnest/r…
Apache Thrift :thrift.apache.org/


dubbo

阿里开源的一个分布式服务框架
Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色。

Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次数和调用时间的监控中心。
Container: 服务运行容器。

调用关系说明:
0 服务容器负责启动,加载,运行服务提供者。

  1. 服务提供者在启动时,向注册中心注册自己提供的服务。
  2. 服务消费者在启动时,向注册中心订阅自己所需的服务。
  3. 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
  4. 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
  5. 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。

Dubbo入门—搭建一个最简单的Demo框架(Dubbo+Zookeeper+Spring)
http://blog.csdn.net/noaman_wgs/article/details/70214612

最近项目用到Dubbo框架,临时抱佛脚分享一下共探讨。
https://www.cnblogs.com/Javame/p/3632473.html

长连接和短连接

所谓长连接,指在一个TCP连接上可以连续发送多个数据包,在TCP连接保持期间,如果没有数据包发送,需要双方发检测包以维持此连接,一般需要自己做在线维持。

短连接是指通信双方有数据交互时,就建立一个TCP连接,数据发送完成后,则断开此TCP连接,一般银行都使用短连接。
比如http的,只是连接、请求、关闭,过程时间较短,服务器若是一段时间内没有收到请求即可关闭连接。

其实长连接是相对于通常的短连接而说的,也就是长时间保持客户端与服务端的连接状态。

长连接与短连接的操作过程:
通常的短连接操作步骤是:
连接→数据传输→关闭连接;

而长连接通常就是:
连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接;

这就要求长连接在没有数据通信时,定时发送数据包(心跳),以维持连接状态,短连接在没有数据传输时直接关闭就行了.

什么时候用长连接,短连接
长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况,。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用建立TCP连接。例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费。

dubbo相关知识(三)–socket长连接和短连接
https://blog.csdn.net/guchuanyun111/article/details/52047494

注册中心如何知道Provider挂掉了?(长连接心跳)

ConfigServer(zookeeper)
配置中心和每个Server/Client之间会作一个实时的心跳检测(因为它们都是建立的Socket长连接),比如几秒钟检测一次。收集每个Server提供的服务的信息,每个Client的信息,整理出一个服务列表,如:


当某个Server不可用,那么就更新受影响的服务对应的serverAddressList,即把这个Server从serverAddressList中踢出去(从地址列表中删除),同时将推送serverAddressList给这些受影响的服务的clientAddressList里面的所有Client。如:192.168.0.3挂了,那么UserService和ProductService的serverAddressList都要把192.168.0.3删除掉,同时把新的列表告诉对应的Client 172.16.0.1,172.16.0.2,172.16.0.3;
当某个Client挂了,那么更新受影响的服务对应的clientAddressList
ConfigServer根据服务列表,就能提供一个web管理界面,来查看管理服务的提供者和使用者。
新加一个Server时,由于它会主动与ConfigServer取得联系,而ConfigServer又会将这个信息主动发送给Client,所以新加一个Server时,只需要启动Server,然后几秒钟内,Client就会使用上它提供的服务

Client(Consumer)
调用服务的机器,每个Client启动时,主动与ConfigServer建立Socket长连接,并将自己的IP等相应信息发送给ConfigServer。
Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息(这样ConfigServer就知道某个服务是当前哪几个Client在使用),Client拿到这些服务提供者信息后,与它们都建立连接,后面就可以直接调用服务了,当有多个服务提供者的时候,Client根据一定的规则来进行负载均衡,如轮询,随机,按权重等。
一旦Client使用的服务它对应的服务提供者有变化(服务提供者有新增,删除的情况),ConfigServer就会把最新的服务提供者列表推送给Client,Client就会依据最新的服务提供者列表重新建立连接,新增的提供者建立连接,删除的提供者丢弃连接

Server(Provider)
真正提供服务的机器,每个Server启动时,主动与ConfigServer建立Scoket长连接,并将自己的IP,提供的服务名称,端口等信息直接发送给ConfigServer,ConfigServer就会收集到每个Server提供的服务的信息。

优点:
1,只要在Client和Server启动的时候,ConfigServer是好的,服务就可调用了,如果后面ConfigServer挂了,那只影响ConfigServer挂了以后服务提供者有变化,而Client还无法感知这一变化。
2,Client每次调用服务是不经过ConfigServer的,Client只是与它建立联系,从它那里获取提供服务者列表而已
3,调用服务-负载均衡:Client调用服务时,可以根据规则在多个服务提供者之间轮流调用服务。
4,服务提供者-容灾:某一个Server挂了,Client依然是可以正确的调用服务的,当前提是这个服务有至少2个服务提供者,Client能很快的感知到服务提供者的变化,并作出相应反应。
5,服务提供者-扩展:添加一个服务提供者很容易,而且Client会很快的感知到它的存在并使用它。

分布式服务框架dubbo原理解析
https://blog.csdn.net/zhongbaolin/article/details/50847951

zookeeper注册中心的作用?

Zookeeper到底在Dubbo服务框架体系中起到了一个什么作用?下面介绍一下:
Zookeeper是一个分布式服务框架的协调服务,意思就是说他服务于分布式的服务框架
Zookeeper可以做到集群服务统一管理
Zookeeper、Register、Consumer三者之间使用的都是长连接
如果Zookeeper感知一个Register挂掉了,会及时通知Consumer
如果Zookeeper挂掉了,Consumer会根据本地缓存的Register列表进行调用,不会影响服务间的调用
Dubbo可以完全脱离Zookeeper注册中心,Consumer和Register之间可以直连!

服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互,注册中心不转发请求,服务消费者向注册中心获取服务提供者地址列表,并根据负载算法直接调用提供者,注册中心,服务提供者,服务消费者三者之间均为长连接,监控中心除外,注册中心通过长连接感知服务提供者的存在,服务提供者宕机,注册中心将立即推送事件通知消费者,注册中心和监控中心全部宕机,不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表,注册中心和监控中心都是可选的,服务消费者可以直连服务提供者

Dubbo学习笔记(三)——Zookeeper注册中心
https://blog.csdn.net/keysilence1/article/details/54579914

Dubbo中的一些常见问题?
https://blog.csdn.net/qq_38765404/article/details/78617142

zk挂掉时服务还能调用吗?

Dubbo中zookeeper做注册中心,如果注册中心集群都挂掉,发布者和订阅者之间还能通信么?

可以
1.启动dubbo时,消费者会从zk拉取注册的生产者的地址接口等数据,缓存在本地。每次调用时,按照本地存储的地址进行调用。
2.注册中心对等集群,任意一台宕掉后,会自动切换到另一台 。
3.注册中心全部宕掉,服务提供者和消费者仍可以通过本地缓存通讯 。
4.服务提供者无状态,任一台 宕机后,不影响使用 。
5.服务提供者全部宕机,服务消费者会无法使用,并无限次重连等待服务者恢复 。

可以的,启动dubbo时,消费者会从zk拉取注册的生产者的地址接口等数据,缓存在本地。每次调用时,按照本地存储的地址进行调用

可以的,消费者本地有一个生产者的列表,他会按照列表继续工作,倒是无法从注册中心去同步最新的服务列表,短期的注册中心挂掉是不要紧的,但一定要尽快修复

挂掉是不要紧的,但前提是你没有增加新的服务,如果你要调用新的服务,则是不能办到的


面试题:Dubbo中zookeeper做注册中心,如果注册中心集群全都挂掉,发布者和订阅者之间还能通信么?
https://blog.csdn.net/zh521zh/article/details/77948208

dubbo如何序列化?

使用默认dubbo协议的话,序列化使用的是修改过的hessian协议,这是一种高效的二进制与具体语言无关的协议。

Dubbo在安全机制方面是如何解决的?

Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo还提供服务黑白名单,来控制服务所允许的调用方。

Dubbo中的一些常见问题?
https://blog.csdn.net/qq_38765404/article/details/78617142


dubbo集群容错

在集群调用失败时,Dubbo 提供了多种容错方案,缺省为 failover 重试。

Failover Cluster
失败自动切换,当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。可通过 retries=”2” 来设置重试次数(不含第一次)。

Failfast Cluster
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。

Failsafe Cluster
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。

Failback Cluster
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。

Forking Cluster
并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks=”2” 来设置最大并行数。

Broadcast Cluster
广播调用所有提供者,逐个调用,任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

按照以下示例在服务提供方和消费方配置集群模式

<dubbo:service cluster="failsafe" />

<dubbo:reference cluster="failsafe" />

集群容错
http://dubbo.apache.org/books/dubbo-user-book/demos/fault-tolerent-strategy.html


dubbo服务降级

return null

mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值,不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
mock=fail:return+null 表示消费方对该服务的方法调用在失败后,再返回 null 值,不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

在调用方配置:

<dubbo:reference id="iUser" interface="com.dubbosample.iface.IUser"  timeout="10000" check="false" mock="return null">
</dubbo:reference>

测试时,如果服务启动,则程序按照预期的运行正常;如果服务没启动,则此时运行程序,程序并未报错,输出数据为null。

自定义Mock类

配置mock=”true”,同时mock实现接口,接口名要注意命名规范:接口名+Mock后缀。此时如果调用失败会调用Mock实现。mock实现需要保证有无参的构造方法。

比如服务接口为IUser

public interface IUser {
    public void addUser(User u);
    public User getUserById(int id);
}

除了IUser的正常实现类外,在同一个包下添加IUserMock类

public class IUserMock implements IUser {
    @Override
    public void addUser(User u) {
        throw new RuntimeException("add user fail!");
    }

    @Override
    public User getUserById(int id) {
        return null;
    }
}

此时如果对应的方法调用失败,dubbo会自动调用Mock实现类中的方法。

dubbo服务降级
https://www.cnblogs.com/allenwas3/p/8427659.html

服务降级及dubbo中的实现示例
https://blog.csdn.net/whereismatrix/article/details/53354141


dubbo负载均衡

在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用。

Random LoadBalance
随机,按权重设置随机概率。
在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。

RoundRobin LoadBalance
轮循,按公约后的权重设置轮循比率。
存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。

LeastActive LoadBalance
最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance
一致性 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" />

服务端和客户端配置示例:

<dubbo:service interface="..." loadbalance="roundrobin" />

<dubbo:reference interface="..." loadbalance="roundrobin" />

负载均衡
http://dubbo.apache.org/books/dubbo-user-book/demos/loadbalance.html


dubbo管理控制台

下载dubbo-admin-2.8.4.war,解压后放到Tomcat webapps中的ROOT中,也就是部署在根目录中。

zookeeper及账号密码配置:
/opt/app/tomcat/apache-tomcat-7.0.82/webapps/ROOT/WEB-INF/dubbo.properties

dubbo.registry.address=zookeeper://10.220.43.93:2181?backup=10.220.43.94:2181,10.220.43.95:2181
dubbo.admin.root.password=root
dubbo.admin.guest.password=guest

打开dubbo管理控制台
http://localhost:8080

dubbo管理控制台的安装部署
https://blog.csdn.net/u013144287/article/details/77921353


上一篇 面试准备10-消息中间件

下一篇 面试准备08-Web与系统架构

阅读
评论
8.1k
阅读预计29分钟
创建日期 2018-04-26
修改日期 2021-07-28
类别

页面信息

location:
protocol:
host:
hostname:
origin:
pathname:
href:
document:
referrer:
navigator:
platform:
userAgent:

评论