分布式、微服务相关精华面试题

1.微服务和 SOA 的区别，优劣势？

区分
1）.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

2）.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

优劣势
1.引入微服务就会牵扯到分布式的各种问题：数据一致性、分布式事务、服务发现、容错、负载，
部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相对比，一个微服务应用一般由大批服务构成。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分，除此之外，你还需要完成一个服务发现机制等，以用来发现与它通讯服务的地址（包括服务器地址和端口）。传统的解决问题办法不能用于解决这么复杂的问题。接续而来，成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化

2.画一下dubbo（SOA）的角色调用关系图，并简述一下？

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

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

3.分布式系统原理-CAP、BASE？

CAP
C - Consistent ，一致性。具体是指，操作成功以后，所有的节点，在同一时间，看到的数据都是完全一致的。所以，一致性，说的就是数据一致性。
A - Availability ，可用性。指服务一致可用，在规定的时间内完成响应。
P - Partition tolerance ，分区容错性。指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供服务。
CAP原理指出，这3个指标不能同时满足，最多只能满足其中的两个 分布式中P必须满足，所有只有两种选择：CP、AP

BASE
BASE是Basically Available（基本可用）, Soft-state（软状态）, Eventually consistent（最终一致）的缩写。
Basically Available，基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
软状态（ Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有两到三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
最终一致性（ Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

4.RPC（如：dubbo）包含哪些组件，RPC协议的组成？

5.分布式事务了解吗？你们是如何解决分布式事务问题的？

五种解决方案：
分为两个大类：

1. CAP理论的事务方案：
   两阶段提交方案/XA方案
2. BAS柔性事务方案：
   *TCC（两阶段型、补偿型）
   本地消息表
   *可靠消息最终一致性（异步确保型）
   最大努力通知（非可靠消息、定期校对）

可靠消息最终一致性（异步确保型）RocketMQ事务消息方案：
执行流程

　　为方便理解我们还以注册送积分的例子来描述 整个流程。

Producer 即MQ发送方，本例中是用户服务，负责新增用户。MQ订阅方即消息消费方，本例中是积分服务，负责新增积分。

1）、Producer 发送事务消息

　　Producer （MQ发送方）发送事务消息至MQ Server，MQ Server将消息状态标记为Prepared（预备状态），注意此时这条消息消费者（MQ订阅方）是无法消费到的。本例中，Producer 发送 ”增加积分消息“ 到MQ Server。

2）、MQ Server回应消息发送成功

　　MQ Server接收到Producer 发送给的消息则回应发送成功表示MQ已接收到消息。

3）、Producer 执行本地事务

　　Producer 端执行业务代码逻辑，通过本地数据库事务控制。本例中，Producer 执行添加用户操作。

4）、消息投递

　　若Producer 本地事务执行成功则自动向MQServer发送commit消息，MQ Server接收到commit消息后将”增加积分消息“ 状态标记为可消费，此时MQ订阅方（积分服务）即正常消费消息；

　　若Producer 本地事务执行失败则自动向MQServer发送rollback消息，MQ Server接收到rollback消息后 将删除”增加积分消息“ 。

MQ订阅方（积分服务）消费消息，消费成功则向MQ回应ack，否则将重复接收消息。这里ack默认自动回应，即程序执行正常则自动回应ack。

5）、事务回查

　　如果执行Producer端本地事务过程中，执行端挂掉，或者超时，MQ Server将会不停的询问同组的其他 Producer 来获取事务执行状态，这个过程叫事务回查。MQ Server会根据事务回查结果来决定是否投递消息。

　　以上主干流程已由RocketMQ实现，对用户侧来说，用户需要分别实现本地事务执行以及本地事务回查方法，因此只需关注本地事务的执行状态即可。

你们公司是如何处理分布式事务的？
如果你真的被问到，可以这么说，我们某某特别严格的场景，用的是 TCC 来保证强一致性；然后其他的一些场景基于阿里的 RocketMQ 来实现分布式事务。

你找一个严格资金要求绝对不能错的场景，你可以说你是用的 TCC 方案；如果是一般的分布式事务场景，订单插入之后要调用库存服务更新库存，库存数据没有资金那么的敏感，可以用可靠消息最终一致性方案。

6.谈谈你对IO 、NIO、AIO的理解？

IO（同步阻塞）

NIO（同步非阻塞）

AIO（异步非阻塞）
基于NIO实现，采用事件机制调用（通过指定CompletionHandler回调接口）实现异步io操作
说说对多路复用的理解？
基于selector 监听多个chanel就绪事件，达到一个线程处理多个chanel读写数据，相比同步阻塞io的一个线程处理一个socekt连接性能更高，而且解决高并发场景下大量线程造成的资源浪费