面试专题（分布式系统微服务）

架构设计相关

0. 什么是分布式系统，什么是微服务？

集群：多机器作同一件事情；
分布式系统： 一件事情，多系统协同完成；
微服务架构：构建分布式系统的一种架构方式， 核心思路是：去中心化；
http://www.cnblogs.com/liuning8023/p/4493156.html
 

1. RPC和RPC框架

RPC是指远程过程调用，实现远程过程调用的方式有不少中，Dubbo，Rmi，Hessian等等；
RPC的核心过程包括了客户端和服务端的通信协议，寻址，数据序列化/反序列化；
对上述过程进行了封装，不须要开发人员本身去定义通信协议，去实现序列化的细节工做，
这样的组件称为RPC框架；常见RPC框架有 thrift，gRpc，dubbo，motan

2. 序列化方式及做用

序列化：将java对象或者其余内存中的数据，转换为一种特定格式的流，使之能够在网络中传输或者磁盘上存储；
反序列化：将流以特定的格式转为java对象或者内存中其余形式的数据；# json，jdk serializable, Hessian，Dubbo, Protobuf,
做用：压缩；持久化存储；跨网络传输；

3. 分布式系统中事务的处理

参考：https://wenku.baidu.com/view/be946bec0975f46527d3e104.html
          https://segmentfault.com/a/1190000004468442
事务相关必了解的概念：
ACID （Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性）
CAP （一致性Consistency，可用性Availability，分区容错性Partitiontolerance），分布式系统来讲，P是不能放弃的
BASE （Basically Available（基本可用），Soft state（软状态），Eventuallyconsistent（最终一致性））
分布式事务实现方式：
1.  XA （数据库厂商实现）；2. 后台任务按期校对数据；3. 经过消息队列，实现最终一致(确保消息到达MQ，幂等性)；4. TCC机制(Try,Confirm,Cancel)
https://www.cnblogs.com/rainwang/p/7099648.html

 

4. 系统监控

# 链路监控
Spring‐Cloud‐Sleuth + Zipkin
Sleuth收集微服务之间的接口调用信息以及内部方法调用。经过采样以后，将数据传输致
Zipkin，由Zipkin负责存储和可视化查询；
# 核心概念：Trace，Span。公开课有讲过Sleuth；
# 日志监控
ELK
1）ElasticSearch搜索服务器，提供了一个分布式多用户能力的全文搜索引擎，基于
RESTful web接口。
2）Logstash是能够对日志进行收集、过滤、分析，并将其存储供之后使用;
3）Kibana 是Elasticsearch前端展现工具,能够为 Logstash 和 ElasticSearch 提供
的日志分析友好的 Web 界面，能够帮助您汇总、分析和搜索重要数据日志
搭建方式参考资料: https://www.cnblogs.com/kevingrace/p/5919021.html
# 代码性能监控
Metrics：度量；咱们须要为某个系统某个服务作监控、作统计，就须要用到Metrics；
代码执行的吞吐量，响应时间，并发量，瞬时状态值。
# 这个须要经过代码埋点实现，公开课有讲过Metrics+Grafana构建性能监控平台；

5. 高可用

服务的高可用能够经过多实例，自检测，自恢复，快速扩容机制来实现；
多实例：一个服务部署多个实例，经过负载均衡机制下降单实例的负载以及实现容错；
自检测：系统预留健康检查接口，经过docker集群模式的健康检查机制来实现自动重启和预警；
自恢复：对于网络抖动的问题，须要程序有必定的容错性，好比：熔断机制，Eureka的自我保护措施；
快速扩容：互联网应用的特殊性，在特定时候会出现高峰期的海量请求，此时，须要咱们的分布式系统可以快速扩容。docker的服务编排就能够实现已有硬件资源的状况下秒级扩容；对于硬件资源，须要结合云计算技术来实现；

6. 服务调用的负载均衡

# 服务端负载均衡：对客户端屏蔽具体的接口地址，对外仅暴露负载均衡器，全部请求通过统一的负载服务；有硬件负载(f5,radware)和软件负载(nginx,apache,lvs)
优点：统一管理，控制；对外部调用友好，屏蔽了微服务地址多变的复杂性；
劣势：性能要求高，流量大对负载服务自己有很高的要求；管理复杂，大多数服务端负载器
须要手工配置服务实例信息；
# 客户端负载均衡：由客户端本身选择目标服务器，直调对应的地址；dubbo(源码参考com.alibaba.dubbo.rpc.cluster.LoadBalance)，springcloud(ribbon)都是客户端负载均衡；
优点：性能好，能够根据具体应用微调负载策略；易管理，服务实例信息自发现
劣势：服务实例信息在多客户端之间的不一样步；一般是集群内部使用；

7. 分布式配置中心

相似产品有不少：360 Qconf，百度 Disconf，淘宝 Diamond
参考：https://www.cnblogs.com/zhangxh20/p/5464103.html
咱们着重讲了springcloudconfig 分布式配置中心，用来解决多配置的问题；
将配置文件统一存储在gitlab，svn，filesystem，并支持敏感信息的加密存储(configserver或者client都可解密)

8. 服务注册与发现机制

这种机制目的是实现：服务提供者的自注册，服务消费者的主动发现服务提供者；
服务注册：服务提供者启动实例时，将信息存储到注册中心；
注册中心：保存服务提供者或者消费者的实例信息(服务名称，IP,端口，方法地址等等)
服务发现：服务消费者，经过服务名在注册中心的信息中查询出具体的服务提供者实例信息。

9. 分布式系统如何拆分？

业务线(订单系统，积分系统，审计系统，支付系统，结算系统，推广系统….)
技术栈（php，java，nodejs，go）

架构分层 (前台，中台，后台； 存储服务，缓存服务，MQ服务，搜索引擎服务….)

 

SpringCloud

1. 微服务是如何保护本身的

http://blueskykong.com/2017/10/19/security1/

信息加密

经过Https实现信息传输的加密(nginx，tomcat均可以配置https)；
对代码侵入性很小。由于微服务集群不直接对外提供服务，由统一的网关来提供业务API(zuul，nginx均可以的)。

权限校验方案

· 单点登陆

# 每一个应用都必须接入单点登陆，大型系统中，须要集成单点登陆带来的复杂工做和性能损耗；

· 分布式session方案

流程： 客户端 ‐> 获取session ‐> 请求微服务 ‐> 查询共享存储中受权信息 ‐> 校验权限 ‐> 提供服务 ‐> 给予响应
分布式session保存方案，根据session去查找共享存储中对应的权限信息来实现权限校验；
# 共享存储的高可用和安全性是个问题，相似直接redis，memcache来作；

· token方案

1. 客户端 ‐> uaa认证 ‐> 获取token
2. 客户端 ‐> 微服务 ‐> 校验token

token包含必要的受权信息，一次获取，屡次使用，相对独立，实现简单，不须要cookie；长度有限，不能撤销，须要设置过时时间；
# 能够在网关层作；也能够构建成通用的组件，放在每一个微服务上面去作；
# 根据不一样的业务场景：token能够发放一次，也能够在每次请求的时候去申请，这样可以实现分控须要的帐户禁用，黑名单等功能

 

2. 微服务网关

zuul是springcloud提供的成熟的路由方案；根据请求的路径不一样，网关会定位到指定的微服务，并代理请求到不一样的微服务接口；对外屏蔽了微服务接口调用的复杂性。
三个重要概念：动态路由表，路由定位，反向代理
反向代理：客户端请求到网关，网关受理后，再对目标服务发起请求，拿到响应以后，再响应给客户端；
动态路由表：zuul支持eureka路由，手动配置的路由，这两种都支持动态更新；
路由定位：根据请求路径，zuul有一套自身的服务定位规则以及路由匹配的表达式；
# 应用场景： 对外暴露，权限校验，服务聚合，日志审计

 

3. 各服务之间如何调用

服务对外以http接口形式暴露，因此调用有多种方式；
Fegin是cloud提供的一种服务调用客户端；
Resttemplate也能够快速的发起服务调用；
同时，也能够手动获取对应接口的具体地址，经过日常的httpclient进行调用；
# Feign和Resttemplate 均可以集成负载均衡，失败重试，熔断的功能；

 

4.如何保证服务健康的状况
1. Spring Boot‐Actuator 能够用来监控咱们的项目，能够经过HealthEndPoint/health来查看应用的健康情况；
SpringBoot在集成不少组件时，都会实现一个健康检查的接口，如ElasticsearchHealthIndicator，RedisHealthIndicator，RabbitHealthIndicator等。
2. 在微服务集群中，咱们一般还会经过sleuth来进行服务调用的链路追踪，能够经过抽样看到服务调用的异常状况；
3. 日志信息也是咱们监控服务监控状况的一个重要手段，经常使用经过ELK实现日志收集，分析和查看；
4. 在经过docker部署微服务时，咱们能够利用docker的健康检查机制，实现服务的自动重启；

 

5. 容错机制

# Ribbon 负载均衡&重试
经过服务名获取实例信息，根据负载策略选择合适的实例去访问；
服务调用失败时，能够配置重试次数，以及实例切换的次数；
# Hystrix熔断机制
限流，降级，熔断；
限流：限制接口访问并发量，限制缓冲区大小，超出限制，调用Fallback方法
熔断：出错率超过阈值，必定时间内再也不请求该接口。(超时、run方法抛出异常)
降级：凡是没有正常的从接口中拿到数据，就会调用Fallback方法，获取一个结果
# 经过命令模式的封装，SpringCloud内部自动集成，且可做用于任意JAVA方法上，不关心方法的具体实现。表明着(http、redis、db操做均可以作熔断)；

 

6. SpringCloud中的服务注册与发现机制

两个角色eurekaServer， eurekaClient
server提供httpapi服务，存储服务实例的信息，而且具有主动剔除服务(心跳检测)和server高可用的功能；
client集成在具体的微服务中，在服务启动时，将服务实例信息post到server上；client也会定时同步server上面其余service信息；
# eureka的工做大可能是后台thread在定时工做，任务执行的间隔时间均可以经过配置文件进行配置；

 

7. SpringCloud的实施推广

# 集成SpringMVC项目
微服务改造的过渡期，在传统的SpringMvc项目中，引入部分SpringCloud的特性，便可经过微改造变成微服务；
# 其余语言的项目加入SpringCloud微服务系统
Eureka提供HttpApi，使得非java语言加入到SpringCloud微服务集群成为可能；

 

Dubbo

http://dubbo.io/books/dubbo­user­book/ 
http://dubbo.io/books/dubbo­dev­book 
http://dubbo.io/books/dubbo­admin­book/

1. 若是注册中心集群都挂掉，发布者和订阅者之间还能通讯么？

# 有缓存；
注册中心所有宕掉后，服务提供者和服务消费者仍能经过本地缓存通信
新的服务将没法发现；服务下架后仍旧有被调用的可能；

2. dubbo链接注册中心和直连的区别

注册中心： 消费者动态发现服务提供者，实现软负载均衡和集群容错;
直连：不能动态增减提供者；开发、测试环境可经过指定Url方式绕过注册中心直连指定的服务地址，快速测试

3. dubbo服务的容错机制

# http://dubbo.io/books/dubbo‐user‐book/demos/fault‐tolerent‐strategy.html
Failover Cluster：失败自动切换，当出现失败，重试其它服务器，默认两次；
Failfast Cluster：失败当即报错
Failsafe Cluster：失败安全，出现异常时，直接忽略
Failback Cluster：失败自动恢复，后台记录失败请求，定时重发
Forking Cluster：并行调用多个服务器，只要一个成功即返回。一般用于实时性要求较
高的读操做，但须要浪费更多服务资源
Broadcast Cluster:播调用全部提供者，逐个调用，任意一台报错则报错
# 要注意分布式事务

4. 具体问题示例1：关于服务调用超时
# 超时是针对消费端仍是服务端？
dubbo的超时是争对客户端的，因为是一种NIO模式，消费端发起请求后获得一个ResponseFuture，而后消费端一直轮询这个ResponseFuture直至超时或者收到服务端的返回结果
# 超时在哪设置，优先级是什么？
http://dubbo.io/books/dubbo‐user‐book/configuration/xml.html
# 实现原理
消费端发起远程请求后，线程不会阻塞等待服务端的返回，而是立刻获得一个ResponseFuture（ReponseFuture的实现类：DefaultFuture），消费端经过不断的轮询机制判断结果是否有返回。由于是经过轮询，轮询有个须要特别注要的就是避免死循环，因此为了解决这个问题就引入了超时机制，只在必定时间范围内作轮询，若是超时时间就返回超时异常

5. 服务提供者能实现失效踢出是什么原理

源码参考  RegistryService， 文档参考http://dubbo.io/books/dubbo‐user‐book/references/registry/introduction.html
# redis ‐ 脏数据由监控中心删除
# zookeeper ‐ 的临时节点

6. dubbo通信协议

# 什么是通信协议
客户端服务端之间进行数据流转的一种约定，将数据按照标准格式来组装；
# 协议内容
头部信息（调用控制协议16B) + body(序列化)
head = 魔数(2） + 标识（1） + 响应状态(1) + 消息ID（8） + 内容长度(4)
body = dubbo版本 + 服务接口路径 + 服务版本号 + 服务方法名 + 参数描述符 + 参数值序列化 + 隐式参数

7. 大几率的问题

# dubbo文档，仔细阅读一遍，面试官可能随便抽取一个。
# dubbo配置的方式和属性
http://dubbo.io/books/dubbo‐user‐book/configuration/
# dubbo底层协议
http://dubbo.io/books/dubbo‐user‐book/references/protocol/introduction.html
# dubbo服务注册与发现流程 http://dubbo.io/books/dubbo‐user‐book/references/registry/introduction.html