面试 － 必知必会的微服务面试题
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了面试 － 必知必会的微服务面试题相关的知识，希望对你有一定的参考价值。
参考技术A
SOA与微服务的区别？
SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。
基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。
当然企业还需要对服务治理，比如服务注册库，监控管理等。
我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。
而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，如果像企业计算那样的系统，伸缩就需要多个容纳续续多多的服务的系统实例，前面通过负载均衡使得多个系统成为一个集群。但这是很不方便的，互联网企业迭代的周期很短，一周可能发布一个版本，甚至可能每天一个版本，而不同的子系统的发布周期是不一样的。而且，不同的子系统也不像原来企业计算那样采用集中式的存储，使用昂贵的Oracle存储整个系统的数据，二是使用MongoDB，HBase，Cassandra等NOSQL数据库和Redis，memcache等分布式缓存。那么就倾向采用以子系统为分割，不同的子系统采用自己的架构，那么各个服务运行自己的Web容器中，当需要增加计算能力的时候，只需要增加这个子系统或服务的实例就好了，当升级的时候，可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。
微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。
Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。
如何拆分服务？
要围绕业务模块进行拆分，拆分粒度应该保证微服务具有业务的独立性与完整性，尽可能少的存在服务依赖，链式调用。但是，在实际开发过程中，有的时候单体架构更加适合当前的项目。实际上，微服务的设计并不是一蹴而就的，它是一个设计与反馈过程。因此，我们在设计之初可以将服务的粒度设计的大一些，并考虑其可扩展性，随着业务的发展，进行动态地拆分也是一个不错的选择。
REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
实际上呢，不是所有的东西都是“资源”，尤其是在业务系统中，缺点如下：
有个接口是更新订单状态，你是用上面的GET POST PUT DELETE 哪个呢，看样子应该是PUT，但是路径呢PUT /tickets/12
我有时候多个接口 ，更新订单收款状态，更新订单支款状态，更新订单结算状态；
Restful 的路径明显不友好不够用；
再比如，批量删除，DELETE还好用么，DELETE /tickets/12 #删除ticekt 12 这种形式如果要传数组怎么办，url是不是不够友好？
再比如，Resuful要求 GET /tickets # 获取ticket列表 。我们曾经有个需求，对方会把不超过1000个订单id传给我们，我们系统过滤其中一部分特殊订单；这也是个查询服务，用GET /tickets # 获取ticket列表的形式，1000个订单id显然是超过GET url长度的，这里也不合适；再者，我想开发多个条件查询列表服务，路径这么浅显然不合适；
实际业务中，我们webapi的路径是这样的：systemAlias/controller/action
总结下规则：
简单查询尽量用GET，好处是可以直接带查询参数copy api路径；
复杂查询和更新用POST，用的最多；
不用PUT和DELETE，原因是增加复杂度，并没有带来什么好处
看看BAT的很多openapi，也是写着restful，实际没有严格遵守，都是get和post，这是也很多人不知道put和delete的原因
如：
//根据订单id获取订单
GET oms/order/queryOrderById?id=value1¶m2=value2
//根据订单id List获取订单
POST oms/order/queryOrderByIdList
//根据条件查询订单，带分页参数
POST oms/order/queryOrderByCondition
//更新订单收款状态
POST oms/order/updateOrderCollectionStatus
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
//批量删除订单，带操作来源
POST oms/order/deleteOrderInBatch
微服务如何进行数据库管理？
CAP 原理(CAP Theorem)
在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP 原理中，有三个要素：
CAP 原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求 ，否则就失去了价值，因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。
对于大多数 WEB 应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。
当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。
牺牲一致性，只是不再要求关系型数 据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。
通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则 取决于数据复制到一致状态的时间。
最终一致性(eventually consistent)
对于一致性，可以分为从客户端和服务端两个不同的视角。
从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。
从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。
对于关系型数据库，要求更新过的数据能被后续的 访问都能看到，这是强一致性 ;如果能容忍后续的部分或者全部访问不到，则是弱一致性 ; 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。
那么问题来了，如何实现数据的最终一致性呢?答案就在事件驱动架构。
最佳解决办法是采用事件驱动架构。其中碰到的一个挑战是如何原子性的更新状态和发布事件。有几种方法可以解决此问题，包括将数据库视为消息队列和事件源等。
从目前技术应用范围和成熟度看，推荐使用第一种方式(本地事务发布事件)，来实现事件投递原子化，即可靠事件投递。
SpringCloud和Dubbo有哪些区别？
总体来说，两者各有优势。虽说后者服务调用的功能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的依赖，这在强调快速演化的微服务环境下，显得更加合适。
品牌机与组装机的区别：很明显SpringCloud比dubbo的功能更强大，覆盖面更广，而且能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合，这些对于微服务至关重要。使用Dubbo构建的微服务架构就像组装电脑、各环节我们选择自由度高，但是最总可能会因为内存质量而影响整体，但对于高手这也就不是问题。而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性。
在面临微服务基础框架选型时Dubbo与SpringCloud只能二选一。
Dubbo35个必知必会的点，面试总问到！
回复“资源”获取独家整理的学习资料！
链接:https://blog.csdn.net/qq_14958051/article/details/106516664
1.什么是Dubbo?
Dubbo是基于Java的高性能轻量级的RPC分布式服务框架，现已成为 Apache 基金会孵化项目。
官网：http://dubbo.apache.org/en-us/
2.为什么要使用Dubbo?
背景:
随着互联网的快速发展，Web应用程序的规模不断扩大，最后我们发现传统的垂直体系结构（整体式）已无法解决。分布式服务体系结构和流计算体系结构势在必行，迫切需要一个治理系统来确保体系结构的有序发展。
-
开源免费 -
一些核心业务被提取并作为独立的服务提供服务，逐渐形成一个稳定的服务中心，这样前端应用程序就可以更好地响应变化多端的市场需求 -
分布式框架能承受更大规模的流量 -
内部基于netty性能高
3.Dubbo提供了哪3个关键功能？
基于接口的远程调用
容错和负载均衡
自动服务注册和发现
4.你知道哪些机构在用Dubbo吗？
5.Dubbo服务的关键节点有哪些?
6.说一下Dubbo服务注册流程?
-
服务容器负责启动，加载，运行服务提供者。 -
服务提供者在启动时，向注册中心注册自己提供的服务。 -
服务消费者在启动时，向注册中心订阅自己所需的服务。 -
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 -
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 -
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
7.能画一下服务注册流程图吗？
8.Dubbo架构的特点？
连通性、健壮性、伸缩性、以及向未来架构的升级性。
9.对jdk的最小版本需求？
jdk1.6+
10.注册中心的选择？
一般来说选中Zookeeper更稳定更合适。
除了Zookeeper还有Redis注册中心、Multicast注册中心、Simple注册中心。
11.Dubbo的核心配置？用途？
12.配置优先级规则？
优先级从高到低：
-
JVM -D参数，当你部署或者启动应用时，它可以轻易地重写配置，比如，改变dubbo协议端口； -
XML, XML中的当前配置会重写dubbo.properties中的； -
Properties，默认配置，仅仅作用于以上两者没有配置时。
13.如何用代码方式绕过注册中心点对点直连？
…
ReferenceConfig<XxxService> reference = new ReferenceConfig<XxxService>(); // 此实例很重，封装了与注册中心的连接以及与提供者的连接，请自行缓存，否则可能造成内存和连接泄漏
// 如果点对点直连，可以用reference.setUrl()指定目标地址，设置url后将绕过注册中心，
// 其中，协议对应provider.setProtocol()的值，端口对应provider.setPort()的值，
// 路径对应service.setPath()的值，如果未设置path，缺省path为接口名
reference.setUrl("dubbo://10.20.130.230:20880/com.xxx.XxxService");
…
14.Dubbo配置来源有几种？分别是？
4种
-
JVM System Properties，-D参数 -
Externalized Configuration，外部化配置 -
ServiceConfig、ReferenceConfig等编程接口采集的配置 -
本地配置文件dubbo.properties
15.如何禁用某个服务的启动检查？
<dubbo:reference interface = "com.foo.BarService" check = "false" />
16.Dubbo 负载均衡策略？默认是？
-
随机负载平衡(默认)
-
RoundRobin负载平衡
-
最小活动负载平衡
-
一致的哈希负载平衡
17.上线兼容老版本？
多版本号(version)
18.开发测试环境，想绕过注册中心如何配置？
-
xml
<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890" />
-
-D
java -Dcom.alibaba.xxx.XxxService=dubbo://localhost:20890 -
.properties
java -Ddubbo.resolve.file=xxx.properties
com.alibaba.xxx.XxxService=dubbo://localhost:20890
19.集群容错几种方法？
20.Dubbo有几种配置方式？
-
Spring -
Java API
21.Dubbo有哪些协议？推荐？
-
dubbo://(推荐) -
rmi:// -
hessian:// -
http:// -
webservice:// -
thrift:// -
memcached:// -
redis:// -
rest://
22.Dubbo使用什么通信框架?
dubbo使用netty。
23.dubbo协议默认端口号？http协议默认端口？hessian?rmi?
-
dubbo:20880 -
http:80 -
hessian:80 -
rmi:80
24.Dubbo默认序列化框架?其他的你还知道？
-
dubbo协议缺省为hessian2 -
rmi协议缺省为java -
http协议缺省为json
25.一个服务有多重实现时，如何处理？
可以用group分组，服务提供方和消费放都指定同一个group。
26.Dubbo服务调用默认是阻塞的？还有其他的？
默认是同步等待结果阻塞的，同时也支持异步调用。
Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个 Future 对象。
27.Dubbo服务追踪解决方案?
-
Zipkin -
Pinpoint -
SkyWalking
28.Dubbo不维护了吗？Dubbo和Dubbox有什么区别？
现在进入了Apache,由apache维护。
Dubbox是当当的扩展项目。
29.Dubbox有什么新功能？
-
支持REST风格远程调用（HTTP + JSON/XML)
-
支持基于Kryo和FST的Java高效序列化实现
-
支持基于嵌入式Tomcat的HTTP remoting体系
-
升级Spring
-
升级ZooKeeper客户端
30.io线程池大小默认？
cpu个数 + 1
31.dubbo://协议适合什么样的服务调用？
采用单一长链接和NIO异步通讯，适用于小数量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
32.自动剔除服务什么原理？
zookeeper临时节点，会话保持原理。
33.从 2.0.5 版本开始，dubbo支持通过x命令来进行服务治理?
telnet
34.如何用命令查看服务列表？
telnet localhost 20880
进入命令行。然后执行 ls相关命令:
-
ls: 显示服务列表 -
ls -l: 显示服务详细信息列表 -
ls XxxService: 显示服务的方法列表 -
ls -l XxxService: 显示服务的方法详细信息列表
35.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
END
有热门推荐以上是关于面试 － 必知必会的微服务面试题的主要内容，如果未能解决你的问题，请参考以下文章