2024年6月1日发(作者：)
1. Dubbo推荐使用哪种协议(A)
://
://
://
vice://
解析： Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，但是Dubbo官网是推荐我们使用Dubbo协议的。
1、dubbo 协议 采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
2、不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
针对每种协议的取舍，可以参考/xiaojin21cen/article/details/79834222。
2. Dubbo里面的非必备的节点角色是(D)
er(服务提供者)
er(服务消费者)
ry(注册中心)
r(监控中心)
解析： 一个微服务中，必备的角色是Provider,Consumer,Registry
3. Dubbo默认使用哪个注册中心(A)
per
ast
解析： Dubbo推荐使用 Zookeeper 作为注册中心，还有 Redis、Multicast、Simple 注册中心，但不推荐。
4. Dubbo中，在Provider(提供者)上可以配置Consumer(消费者)的属性有哪些(D)
t：方法调用超时
s：失败重试次数，默认重试 2 次
lance：负载均衡算法，默认随机
D.上述全部
解析： 在 Provider 上可以配置的 Consumer 端的属性有以下四种：
(1）timeout：方法调用超时
(2）retries：失败重试次数，默认重试 2 次
(3）loadbalance：负载均衡算法，默认随机
(4）actives 消费者端，最大并发调用限制
5. Dubbo默认使用哪个容错方案(A)
er Cluster (失败自动切换，自动重试其他服务器)
st Cluster （快速失败，立即报错，只发起一次调用）
fe Cluster （失败安全，出现异常时，直接忽略）
ck Cluster （失败自动恢复，记录失败请求，定时重发）
解析：
6. Dubbo默认用哪种负载均衡策略(A)
LoadBalance (随机)
obin LoadBalance （轮询）
ctice LoadBalance （最少活跃）
tenHash LoadBalance （一致性Hash）
解析： dubbo有以下四种负载均衡策略，默认使用随机策略。
7. 下面对Dubbo的主要应用场景描述错误的是(D)
A.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单
配置，没有任何API侵入。
B.软负载均衡及容错机制，降低成本，减少单点。
C.服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务
提供者的IP地址，并且能够平滑添加或删除服务提供者。
D.任何时候都能采用dubbo
解析： 略。
8. Dubbo中，为什么需要服务治理(D)
A.过多的服务URL配置困难
B.负均衡分配节点压力过大的情况下也需要部署集群
C.服务依赖混乱，启动顺序不清晰
D.上述所有原因
解析：
1.
2.
3.
过多的服务 URL 配置困难
负载均衡分配节点压力过大的情况下也需要部署集群
服务依赖混乱，启动顺序不清晰
4.
过多服务导致性能指标分析难度较大，需要监控
9. Dubbo默认使用什么方式进行序列化(A)
n 序列化
on
自带序列化。
解析： 默认使用
Hessian 序列化，还有 Duddo、 FastJson、 Java 自带序列化。
10. Dubbo内置了哪几种服务容器(D)
Container
Container
4j Container
D.上述三种容器都有
解析： Dubbo内置了以下几种服务容器：Spring Container、Jetty Container、Log4j Container
Dubbo 的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。
11. Dubbo必须依赖的包有哪些(A)
per
on
解析： dubbo中，必须依赖JDK，其他依赖为可选。
12. 下列关于Dubbo服务注册与发现的流程，正确的是(D)
A.服务容器Container负责启动，加载，运行服务提供者。
B.服务提供者Provider在启动时，向注册中心注册自己提供的服务。
C.服务消费者Consumer在启动时，向注册中心订阅自己所需的服务。
D.上述三个选项都是正确的。
解析： dubbo的服务注册与发现流程如下：
1.
2.
3.
4.
5.
6.
服务容器Container负责启动，加载，运行服务提供者。
服务提供者Provider在启动时，向注册中心注册自己提供的服务。
服务消费者Consumer在启动时，向注册中心订阅自己所需的服务。
注册中心Registry返回服务提供者地址列表给消费者。
服务消费者Consumer，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者Consumer和提供者Provider，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心Monitor。
13. 以下选项中，对zookeeper描述正确的是(D)
A. ZooKeeper 是一个开源的分布式协调服务。
B. 是一个为分布式应用提供一致性服务的软件。
C. 分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服
务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
D. ZooKeeper 的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高
效、功能稳定的系统提供给用户。
E.上面全部选项
解析：
1. ZooKeeper 是一个开源的分布式协调服务。它是一个为分布式应用提供一致性服务的软件，分布式应用程序可以基于 Zookeeper 实
现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
2.
ZooKeeper 的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
14. zookeeper宕机对dubbo中的服务提供者、消费者有什么影响(A)
A. zookeeper注册中心宕机，还可以消费dubbo暴露的服务。
B. 消费者无法使用
C. 提供者无法使用
D. dubbo无法使用
解析：
zookeeper注册中心宕机后，还可以消费dubbo暴露的服务。
原因：
1.监控中心宕掉不影响使用，只是丢失部分采样数据
2.数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
3.注册中心对等集群，任意一台宕掉后，将自动切换到另一台
4.注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
5.服务提供者无状态，任意一台宕掉后，不影响使用
6.服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
15. 关于dubbo服务之间的调用，下面描述错误的是（D）
A. 可以使用reference调用
B. 可以指定dubbo服务端口进行调用
C. 可以采用zkClient从zookeeper服务中获取服务提供者信息，再进行调用。
D. 不支持异步调用
解析：
1.
2.
dubbo服务之间的调用默认是同步等待结果阻塞，支持异步调用。
dubbo的三种调用方式：1：reference； 2:指定dubbo服务端；3：采用zkClient从zookeeper中获取提供者信息再调用
16. dubbo中，带上传下载文件的服务推荐采用什么协议（C）
A. dubbo协议
B. HTTP协议
C. Hessian协议
D. RMI协议
解析：
在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的
创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议
或者Hessian协议。
Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务。适用场景：传入传出参数数据包较大，
提供者比消费者个数多，提供者压力较大，可传文件。因此比较高效的做法是带上传下载文件的服务使用hessian协议，去普通的服务使用dubbo
协议
。
17. 下列关于对服务降级描述正确的有（D）
A. 降级：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面
有策略的不处理或简单处理，从而释放服务器资源以保证核心业务正常运作或高效运
作。
B. 降级可以分为自动降级和人工降级
C. Dubbo的服务降级采用的是mock机制。其具有两种降级处理方式：Mock Null降
级处理，与Mock Class降级处理。
D. 上述所有选项
解析：
略
18. 服务上线怎么不影响旧版本（B）
A. 直接统一更新到最新版本
B. 用版本号过渡，版本号不同的服务相互间不引用，在低压力时间段，先升级一半提
供者为新版本，再将所有消费者升级为新版本，然后将剩下的一半提供者升级为新版本。
C. 不用理会
D. 只升级消费者版本
解析：dubbo中，采用多版本并不影响旧版本，版本号不同的服务相互间不引用。而由于服务已经上线，所以采用版本号过度，进行灰度发布。
19. Dubbo中，服务配置，引用配置，协议配置，应用配置分别是哪些(A)
A. dubbo:service dubbo:reference dubbo:protocol dubbo:application
B. dubbo:application dubbo:reference dubbo:protocol dubbo:service
C. dubbo:service dubbo:protocol dubbo:reference dubbo:application
D. dubbo:reference dubbo:service dubbo:protocol dubbo:application
解析：
dubbo核心配置如下：
20. Dubbo核心服务有哪些(D)
A. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列
化，以及“请求-响应”模式的信息交换方式。
B. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均
衡，失败容错，地址路由，动态配置等集群支持。
C. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地
址透明，使服务提供方可以平滑增加或减少机器。
D. 上述所有选项
解析：
略
1. 下列关于SpringCloud的说法错误的是(D)
Cloud是基于SpringBoot的一整套实现微服务的框架
B.提供了微服务开发所需的配置管理、服务发现、断路器、智能路由等组件
C.基于SpringBoot，会让开发微服务架构非常方便
Cloud等同于SpringBoot
解析：SpringCloud是基于SpringBoot的一整套实现微服务的框架。它提供了微服务开发所需的配置管理、服务发现、断路
器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。最重要的是，基于SpringBoot，
会让开发微服务架构非常方便。SpringBoot专注于快速，方便集成的单个个体，SpringCloud是关注全局的服务治理框架；
2. 下列关于SpringCloud和SpringBoot的区别说法正确的是(ABCD)
A. SpringBoot是Spring的一套快速配置脚手架，可以基于spring boot快速开发单个微
服务
B. SpringBoot专注于快速，方便集成的单个个体，SpringCloud是关注全局的服务治
理框架；
C. SpringCloud很大一部分是基于SpringBoot来实现的；
D. SpringBoot可以离开SpringCoud独立开发项目，但是SpringCloud离不开
SpringBoot,属于依赖的关系。
解析：略
3. 下列关于SpringCloud和Dubbo的关系说法错误的是(D)
A.两者都是现在主流的微服务框架
Cloud注册中心一般用Eureka，而Dubbo用的是Zookeeper
Cloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，
更像是组装机。
Cloud有的组件Dubbo的一定会有
解析：Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一
个方面。二者的组件区别如下：（Dubbo 提供了各种 Filter，对于下表中“无”的要素，可以通过扩展 Filter 来完善。）
4. 下列关于SpringCloud的核心组件有哪些(F)
A. Eureka
B. Feign
C. Ribbon
D. Hystrix
F.上述全部
解析：SpringCloud核心组件有
Eureka：服务注册于发现。
Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。
Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。
Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。
Zuul：网关管理，由 Zuul 网关转发请求给对应的服务。
5. 下列关于SpringCloud和Dubbo的区别的说法错误的是(D)
的服务调用方式是RPC，SpringCloud的是RestApi
的注册中心 是zookeeper，Spring Cloud可以是eureka或其他。
本身没有实现服务网关，需要和第三方整合，SpringCloud有zuul路由网关。
完整度比SpringCloud高
解析：SpringCloud和Dubbo的主要区别如下：
（1）服务调用方式：dubbo是RPC，Spring Cloud是Rest Api。
（2）注册中心：dubbo 是zookeeper，Spring Cloud可以是zookeeper或其他。
（3）服务网关：dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由
服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文
件的更新与服务自动装配等等一系列的微服务架构要素。
（4）架构完整度：Spring Cloud包含诸多微服务组件要素，完整度上比Dubbo高。
6. 下列关于Eureka和Zookeeper说法错误的是(D)
A.都可以提供服务注册与发现的功能
per保证的是C（一致性）P（分区容错性）
保证的是A（ 可用性）P（分区容错性）
per保证的是A（ 可用性）P（分区容错性）
解析：Eureka和Zookeeper都可以提供服务注册与发现的功能，著名的CAP理论指出，一个分布式系统不可能同时满足C (一
致性) 、A (可用性) 、P (容错性)，由于分区容错性P再分布式系统中是必须要保证的，因此我们只能再A和C之间进行权衡。
Zookeeper保证的是CP（网络问题导致master节点宕机，选举时间长，集群无法使用，无法保证可用性）
Eureka保证的是AP（网络有问题时触发自我保护机制，不会移除过期服务，同时能接受新服务，保证可用性，而不会同步到其
他节点，无法保证一致性）
7. 下列关于微服务描述错误的是(D)
A.松耦合，聚焦单一业务功能
B.无关开发语言，团队规模降低
C.微服务一个功能受损，对其他功能影响并不是太大，可以快速定位问题
D.任何系统都能用微服务
解析：微服务并非任何系统都能使用，需要具体情况具体分析。
优点：
1.松耦合，聚焦单一业务功能，无关开发语言，团队规模降低。
2.在开发中，不需要了解多有业务，只专注于当前功能，便利集中，功能小而精。
3.微服务一个功能受损，对其他功能影响并不是太大，可以快速定位问题。
4.微服务只专注于当前业务逻辑代码，不会和 html、css 或其他界面进行混合。可以灵活搭配技术，独立性比较舒服。
8. 下列关于CAP原则的说法错误的是(A)
解析：著名的CAP理论指出，一个分布式系统不可能同时满足C (一致性) 、A (可用性) 、P (容错性)，由于分区容错性P再
分布式系统中是必须要保证的，因此我们只能再A和C之间进行权衡。
A. C (一致性)
B.A (可用性)
C.P（分区容错性）
D.C（分区容错性）
9. 下列关于SpringCloud和dubbo的说法错误的是(D)
A.都是分布式管理框架
是二进制传输，占用带宽会少一点。
Cloud是http 传输，带宽会多一点，同时使用http协议一般会使用JSON报文，
消耗会更大。
对第三方的继承可以一键式生成，天然集成。
解析：
首先，SpringCloud和dubbo都是分布式管理框架。
是二进制传输，占用带宽会少一点。SpringCloud是http 传输，带宽会多一点，同时使用http协议一般
会使用JSON报文，消耗会更大。
开发难度较大，所依赖的 jar 包有很多问题大型工程无法解决。SpringCloud 对第三方的继承可以一键式
生成，天然集成。
Cloud 接口协议约定比较松散，需要强有力的行政措施来限制接口无序升级。
10. 下列关于Eureka的说法正确的是(D)
是基于REST的服务，用于定位服务
cloud 封装了Netflix公司开发的Eureka模块来实现服务注册与发现
包含两个组件：Eureka Server 和 Eureka Client
D.上述全部
解析：略
11. 下列关于Eureka的自我保护机制的说法错误的是(C)
A.当eureka server在一定时间内没有收到实例的心跳，便会把该实例从注册表中删除
B.如果短时间内丢失大量的实例心跳，便会触发eureka server的自我保护机制
的自我保护机制认为虽然收不到实例的心跳，会把它们从注册表中删掉
D.自我保护模式下，eureka会保护注册表中的信息，不在注销任何微服务，当网络故障
恢复后，eureka会自动退出保护模式。
解析：一句话总结就是：某时刻某一个微服务不可用，eureka不会立即清理，依旧会对该微服务的信息进行保存！
eureka server在一定时间内没有收到实例的心跳，便会把该实例从注册表中删除（默认是90秒），但是，如果短时间内丢失大
量的实例心跳，便会触发eureka server的自我保护机制，比如在开发测试时，需要频繁地重启微服务实例，但是我们很少会把
eureka server一起重启。所以当一分钟内收到的心跳数大量减少时，会触发该保护机制，会出现红色的警告：EMERGENCY!EUREKA
MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE LS ARE LESSER THAN THRESHOLD AND
HENCE THE INSTANCES ARE NOT BEGING EXPIRED JUST TO BE SAFE.从警告中可以看到，eureka认为虽然收不到实例的心跳，
但它认为实例还是健康的，eureka会保护这些实例，不会把它们从注册表中删掉。
12. 下列关于Ribbon的说法错误的是(D)
是基于Netflix Ribbon 实现的一套客户端负载均衡的工具
B.主要功能是提供客户端的软件负载均衡算法，提供一系列完整的配置项，如：连接超
时、重试等。
C.容易使用 Ribbon 实现自定义的负载均衡算法
D.负载均衡算法不能自定义。
解析：Ribbon 是 Netflix 发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将 Netflix 的中间层服务连接在一
起。Ribbon 的客户端组件提供一系列完整的配置项，如：连接超时、重试等。简单的说，就是在配置文件中列出 LoadBalancer
(简称LB：负载均衡) 后面所有的及其，Ribbon 会自动的帮助你基于某种规则 (如简单轮询，随机连接等等) 去连接这些机器。
我们也容易使用 Ribbon 实现自定义的负载均衡算法
13. 下列关于Hystrix描述正确是(D)
x是一个应用于处理分布式系统的延迟和容错的开源库
x 能够保证在一个依赖出问题的情况下，不会导致整个体系服务失败，避免级
联故障，以提高分布式系统的弹性
x能实现服务降级、服务熔断、服务限流、接近实时的监控
D.上述所有选项
解析：略
14. 下列关于服务降级的说法错误的是(D)
A.服务降级是指 当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务
和页面有策略的不处理，或换种简单的方式处理，从而释放服务器资源以保证核心业务正常
运作或高效运作。
B.当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超
过预设的阈值时，为了保证重要或基本的服务能正常运行，可以将一些 不重要 或 不紧急
的服务或任务进行服务的 延迟使用 或 暂停使用。
C.降级的方式可以根据业务来，可以延迟服务，比如延迟给用户增加积分，只是放到一
个缓存中，等服务平稳之后再执行 ；或者在粒度范围内关闭服务，比如关闭相关文章的推
荐。
D.上述所有选项
解析：略
15. 下列哪些是服务降级需要关注的点(D)
A.哪些服务是核心服务，哪些服务是非核心服务
B.哪些服务可以支持降级，哪些服务不能支持降级，降级策略是什么
C.除服务降级之外是否存在更复杂的业务放通场景，策略是什么
D.上述所有选项
解析：略
1. 下面关于对微服务的描述正确的是(D)
A. 微服务是一种将单个应用程序开发为一组小服务的方法
B. 每个服务都在自己的进程中运行，并通过轻量级机制（通常是HTTP资源API）进行
服务之间交互
C. 服务可以用不同的编程语言编写，并使用不同的数据存储技术。
D. 上述全部
解析： 微服务是一种将单个应用程序开发为一组小服务的方法，每个服务都在自己的进程中运行，并通过轻量级机制
（通常是HTTP资源API）进行服务之间交互。这些服务基于业务能力构建的，可以通过全自动部署机制独立部署。通
常情况下我们很少去集中化去管理这些服务，而且这些服务可以用不同的编程语言编写，并使用不同的数据存储技术
。
2. 下面关于微服务的优点的说法错误的是(D)
A.每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求；
B.微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
C.微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成
果，无需通过合作才能体现价值；
D.运维要求较高；
解析：微服务优点有：
1.每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求；
2.微服务能够被小团队单独开发；
3.微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
4.微服务能使用不同的语言开发；
5.微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值；
6.微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合；
3. 下面关于微服务的缺点的说法错误的是(D)
A. 运维要求较高
B. 分布式的复杂性
C. 接口调整成本高
D. 每个微服务都很小
解析：微服务的缺点有：1.运维要求较高；2.分布式的复杂性；3.接口调整成本高；D选项是微服务的优点，每个微服务都很小,，这样能聚焦一个
指定的业务功能或业务需求,是一个优点。
4. 下面哪个不是微服务必备的组件(D)
A. 注册中心
B. 消费者
C. 提供者
D. 熔断
解析：微服务种，必备的三个组件：1.注册中心；2.消费者；3.提供者；其他常用组件有：熔断、路由、限流、链路跟踪...等
5. 什么情况下可以考虑使用微服务是(D)
A. 模块间严重耦合，互相依赖，每次变动需要牵扯多个团队，单次上线需求太多，风
险大。
B. 主要业务和次要业务耦合，横向扩展流程复杂。
C. 多人开发一个模块/项目，提交代码频繁出现大量冲突
D. 上述情况都可以考虑
解析： 四个可以考虑上微服务的情况：
1.多人开发一个模块/项目，提交代码频繁出现大量冲突。
2.模块间严重耦合，互相依赖，每次变动需要牵扯多个团队，单次上线需求 太多，风险大。
3.主要业务和次要业务耦合，横向扩展流程复杂。
4. 熔断降级全靠 if-else。
（熔断：某个服务异常后直接熔断整个服务,相当于及时割肉的概念；
降级： 服务器当压力剧增的时候，根据当前业务情况及流量，对一些服务和页面进行有策略的降级，比如因为访问量太大而导致系统崩溃，会
使用限流，到达阈值之后，可以进行降级，比如排队页面、无货、错误页等等。）
6. 下面关于使用微服务说法错误的是(A)
A. 微服务适用在任何地方
B. 是否使用微服务取决于系统的复杂度
C. 使用微服务仍然有不小的成本，需要解决其他一系列问题。
D. 项目过大，模块之间耦合度高，可以考虑上微服务
解析：微服务并不是什么灵丹妙药，在现代架构中，它有自己的位置，但并不适用于任何的地方。 是否选择微服务取决于你要设计的系统的复杂
度。微服务是用来把控复杂系统的，但是随之而来的就是引入了微服务本身的复杂度，需要解决包括自动化部署、监控、容错处理、最终一致性等
其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案，但是仍然是有不小的成本的。
7. 下面关于微服务的说法错误的是(D)
A. 微服务是一种架构思想
B. 可以把微服务理解为把一个应用分解成一组小的服务
C. 微服务中每个服务都可以单独部署，可以用自己的语言编写，使用自己的数据库。
D. 微服务在任何情况下都可以考虑使用
解析：
1. 微服务架构是一种架构模式，或者说是一种架构风格，它提倡将单一的应用程序划分成一组小的服务。
2.
3.
4.
可以把微服务理解为把一个应用分解成一组小的服务，每个服务运行在自己的进程中。
每个服务都可以单独部署，可以用自己的语言编写，使用自己的数据库。
微服务并不是什么灵丹妙药，在现代架构中，它有自己的位置，但并不适用于任何的地方。 是否选择微服务取决于你要设计的系统的复杂度。
8. 下面关于微服务设计原则说法正确的是(E)
A. 单一职责原则
B. 服务自治原则
C. 轻量级通信原则
D. 接口明确原则
E. 上述全部
解析：
1.单一职责原则：每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考
虑。
2.服务自治原则：每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把
它当成一个项目来对待。不必依赖于其它模块。
3.轻量级通信原则：首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服
务都有足够的独立性，可以不受技术的钳制。
4.接口明确原则：由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初
就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
9. 目前微服务的开发框架，最常用的有(D)
A. SpringCloud
B. Dubbo
C. gRPC
D. 上述全部
解析：
Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅支持 Java 语言。
Spring Cloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，仅支持 Java 语言
gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，支持多种语言。
10. 下面跟语言平台绑定的微服务开源框架的是(A)
A. SpringCloud
B. gRPC
C. Thrift
D. 上述全部
解析：
Spring Cloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，仅支持 Java 语言（跟语言平台绑定）
gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，支持多种语言。
Thrift：最初是由 Facebook 开发的内部系统跨语言的 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一，支持多种语言。
11. 微服务中，服务挂了可以怎么处理(F)
A. 限流
B. 熔断机制
C. 负载均衡
D. 降级
E. 重试机制
F. 上述全部
解析：
由于微服务架构的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。
相应的手段有很多：重试机制、限流、熔断机制、负载均衡、降级。
12. 关于RPC描述错误的是(D)
A. 全称Remote Procedure Call，远程过程调用
B. 是一种架构性上的设计思想，或者是一种解决方案。
C. RPC框架的职责是：让调用方感觉就像调用本地函数一样调用远端函数、让服务提供
方感觉就像实现一个本地函数一样来实现服务
D. RPC框架是架构微服务化的首要基础组件，但是会提高架构微服务化的成本
解析：
全称Remote Procedure Call，中文译为远程过程调用，其实你可以把它理解为是一种架构性上的设计思想，或者是一种解决方案。
是架构微服务化的首要基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）
的各类复杂细节。
框架的职责是：让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。
4.通过RPC 框架提供的一种透明调用机制，使用者可以像调用本地方法一样调用别的服务上的方法，不必显式的区分本地调用和远程调用。
13. 关于RPC和微服务的关系描述错误的是(C)
A. RPC是架构微服务化的首要基础组件
B. 微服务中，服务之间的通过RPC进行通信
C. 微服务就是RPC
D. RPC 能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率。
解析：
略
发布评论