标签：概念 定义 依赖关系 博文 需要 线程池 post tor dubbo
Spring Boot 有哪些优点？
答：Spring Boot 的优点有：
减少开发，测试时间和努力。
使用 JavaConfig 有助于避免使用 XML。
避免大量的 Maven 导入和各种版本冲突。
提供意见发展方法。
通过提供默认值快速开始开发。
没有单独的 Web 服务器需要。这意味着你不再需要启动 Tomcat，Glassfish 或其
他任何东西。
需要更少的配置 因为没有web.xml文件。只需添加用@ Configuration注释的类，
然后添加用@Bean 注释的方法，Spring 将自动加载对象并像以前一样对其进行管理。
您甚至可以将@Autowired 添加到 bean 方法中，以使 Spring 自动装入需要的依赖关系
中。
基于环境的配置 使用这些属性，您可以将您正在使用的环境传递到应用程序：
-Dspring.profiles.active = {enviornment}。在加载主应用程序属性文件后，Spring 将
在（application{environment} .properties）中加载后续的应用程序属性文件。
如何重新加载 Spring Boot 上的更改，而无需重新启动服务器？
答：
这可以使用 DEV 工具来实现。通过这种依赖关系，您可以节省任何更改，嵌入式
tomcat 将重新启动。Spring Boot 有一个开发工具（DevTools）模块，它有助于提高
开发人员的生产力。Java 开发人员面临的一个主要挑战是将文件更改自动部署到服务器
并自动重启服务器。开发人员可以重新加载 Spring Boot 上的更改，而无需重新启动服
务器。这将消除每次手动部署更改的需要。Spring Boot 在发布它的第一个版本时没有
这个功能。这是开发人员最需要的功能。DevTools 模块完全满足开发人员的需求。该模
块将在生产环境中被禁用。它还提供 H2 数据库控制台以更好地测试应用程序。
常见的系统架构风格有哪些？各有什么优缺点？
1、单体架构
单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦
合在一个应用中的架构方式。
单体架构特点：打包成一个独立的单元(导成一个唯一的 jar 包或者是 war 包)，会一个进
程的方式来运行。
单体架构的优点、缺点
优点：
项目易于管理
部署简单
缺点：
测试成本高
可伸缩性差
可靠性差
迭代困难
跨语言程度差
团队协作难
2、MVC 架构
MVC 架构特点：
MVC 是模型(Model)、视图(View)、控制器(Controller)3 个单词的缩写。 下面我们从
这 3 个方面来讲解 MVC 中的三个要素。
Model 是指数据模型，是对客观事物的抽象。如一篇博客文章，我们可能会以一个 Post
类来表示，那么，这个 Post 类就是数据对象。 同时，博客文章还有一些业务逻辑，如
发布、回收、评论等，这一般表现为类的方法，这也是 model 的内容和范畴。 对于
Model，主要是数据、业务逻辑和业务规则。相对而言，这是 MVC 中比较稳定的部分，
一般成品后不会改变。 开发初期的最重要任务，主要也是实现 Model 的部分。这一部
分写得好，后面就可以改得少，开发起来就快。
View 是指视图，也就是呈现给用户的一个界面，是 model 的具体表现形式，也是收集
用户输入的地方。如你在某个博客上看到的某一篇文章，就是某个 Post 类的表现形式。
View 的目的在于提供与用户交互的界面。换句话说，对于用户而言，只有 View 是可见
的、可操作的。事实上也是如此，你不会让用户看到 Model，更不会让他直接操作 Model。
你只会让用户看到你想让他看的内容。 这就是 View 要做的事，他往往是 MVC 中变化
频繁的部分，也是客户经常要求改来改去的地方。 今天你可能会以一种形式来展示你的
博文，明天可能就变成别的表现形式了。
Contorller 指的是控制器，主要负责与 model 和 view 打交道。 换句话说，model 和
view 之间一般不直接打交道，他们老死不相往来。view 中不会对 model 作任何操作，
model 不会输出任何用于表现的东西，如 HTML 代码等。这俩甩手不干了，那总得有人
来干吧，只能 Controller 上了。 Contorller 用于决定使用哪些 Model，对 Model 执
行什么操作，为视图准备哪些数据，是 MVC 中沟通的桥梁。
MVC 架构优缺点
优点：
各施其职，互不干涉。
在 MVC 模式中，三个层各施其职，所以如果一旦哪一层的需求发生了变化，就只需
要更改相应的层中的代码而不会影响到其它层中的代码。
有利于开发中的分工。
在 MVC 模式中，由于按层把系统分开，那么就能更好的实现开发中的分工。网页设
计人员可以进行开发视图层中的 JSP，对业务熟悉的开发人员可开发业务层，而其它开
发人员可开发控制层。
有利于组件的重用。
分层后更有利于组件的重用。如控制层可独立成一个能用的组件，视图层也可做成通
用的操作界面。
缺点：
增加了系统结构和实现的复杂性。
视图与控制器间的过于紧密的连接。
视图对模型数据的低效率访问。
3、面向服务架构(SOA)
面向服务的架构（SOA）是一个组件模型，它将应用程序拆分成不同功能单元（称
为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进
行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各
种各样的系统中的服务可以以一种统一和通用的方式进行交互。
面向服务架构特点：
系统是由多个服务构成
每个服务可以单独独立部署
每个服务之间是松耦合的。服务内部是高内聚的，外部是低耦合的。高内聚就是每个
服务只关注完成一个功能。
服务的优点、缺点
优点：
测试容易
可伸缩性强
可靠性强
跨语言程度会更加灵活
团队协作容易
系统迭代容易
缺点：
运维成本过高，部署数量较多
接口兼容多版本
分布式系统的复杂性
分布式事务
什么是 AKF 拆分原则？
业界对于可扩展的系统架构设计有一个朴素的理念,就是：通过加机器就可以解决容
量和可用性问题。(如果一台不行那就两台)。
我是个段子：（世界上没有什么事是一顿烧烤不能解决的。如果有，那就两顿。）
这一理念在“云计算”概念疯狂流行的今天，得到了广泛的认可！对于一个规模迅速
增长的系统而言，容量和性能问题当然是首当其冲的。但是随着时间的向前，系统规模
的增长，除了面对性能与容量的问题外，还需要面对功能与模块数量上的增长带来的系
统复杂性问题以及业务的变化带来的提供差异化服务问题。而许多系统，在架构设计时
并未充分考虑到这些问题，导致系统的重构成为常态，从而影响业务交付能力，还浪费
人力财力！对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF 可
扩展立方（Scalability Cube） 。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。 Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能，如订
单管理、客户管理等。在工程上常见的方案是 服务化架构(SOA) 。比如对于一个电子商
务平台，我们可以拆分成不同的服务
X 轴扩展与我们前面朴素理念是一致的，通过绝对平等地复制服务与数据，以解决容量
和可用性的问题。其实就是将微服务运行多个实例，做集群加负载均衡的模式。
Z 轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的
子系统是相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司为了发展在中国
的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，
负责完整的汽车生产。这就是一种 Z 轴扩展。
什么是 Spring Cloud？
Spring Cloud 是一个微服务框架，相比 Dubbo 等 RPC 框架, Spring Cloud 提供的全套
的分布式系统解决方案。
Spring Cloud 对微服务基础框架 Netflix 的多个开源组件进行了封装，同时又实现了和
云端平台以及和 Spring Boot 开发框架的集成。
Spring Cloud 为微服务架构开发涉及的配置管理，服务治理，熔断机制，智能路由，微
代理，控制总线，一次性 token，全局一致性锁，leader 选举，分布式 session，集群状态
管理等操作提供了一种简单的开发方式。
Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者可以快速的启动服务
或构建应用、同时能够快速和云平台资源进行对接
Spring Cloud 与 Dubbo 的区别是什么？
什么是 Eureka 注册中心？
Eureka 是 Netflix 开发的服务发现组件，本身是一个基于 REST 的服务。Spring Cloud
将它集成在其子项目 spring-cloud-netflix 中，以实现 Spring Cloud 的服务注册于发现，
同时还提供了负载均衡、故障转移等能力。
简单谈一下 Eureka 中的三种角色分别是什么？
1、Eureka Server
通过 Register、Get、Renew 等接口提供服务的注册和发现。
2、Application Service (Service Provider)
服务提供方
把自身的服务实例注册到 Eureka Server 中 3、Application Client (Service Consumer)
服务调用方
通过 Eureka Server 获取服务列表，消费服务。
什么是 Ribbon
1.Ribbon 是一个基于 Http 和 TCP 的客服端负载均衡工具，它是基于 Netflix Ribbon
实现的。
2.它不像 spring cloud 服务注册中心、配置中心、API 网关那样独立部署，但是它几乎
存在于每个 spring cloud 微服务中。包括 feign 提供的声明式服务调用也是基于该 Ribbon
实现的。
3.ribbon 默认提供很多种负载均衡算法，例如 轮询、随机 等等。甚至包含自定义的负
载均衡算法。
集中式与进程内负载均衡的区别
目前业界主流的负载均衡方案可分成两类：
第一类：集中式负载均衡, 即在 consumer 和 provider 之间使用独立的负载均衡设施(可
以是硬件，如 F5, 也可以是软件，如 nginx), 由该设施负责把 访问请求 通过某种策略转发
至 provider；
第二类：进程内负载均衡，将负载均衡逻辑集成到 consumer，consumer 从服务注册
中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的 provider。
Ribbon 就属于后者，它只是一个类库，集成于 consumer 进程，consumer 通过它来
获取到 provider 的地址。
Ribbon 的常见负载均衡策略有哪些？
id 策略名称 策略对应的类名 实现原理
1 轮询策略（默认） RoundRobinRule
轮询策略表示每次都顺序取下一个
provider，比如一共有 5 个 provider， 第 1 次取第 1 个，第 2 次取第 2 个，第
3 次取第 3 个，以此类推
2 权重轮询策略
WeightedResponseTime
Rule
1.根据每个 provider 的响应时间分配
一个权重，响应时间越长，权重越小，
被选中的可能性越低。
2.原理：一开始为轮询策略，并开启一
个计时器，每 30 秒收集一次每个
provider 的平均响应时间，当信息足够
时，给每个 provider 附上一个权重，
并按权重随机选择 provider，高权越重
的 provider 会被高概率选中。
3 随机策略 RandomRule
从 provider 列表中随机选择一个
provider
4 最少并发数策略 BestAvailableRule
选择正在请求中的并发数最小的
provider，除非这个 provider 在熔断
中。
5
在“选定的负载均
衡策略”基础上进
行重试机制
RetryRule
1.“选定的负载均衡策略”这个策略是
轮询策略 RoundRobinRule
2.该重试策略先设定一个阈值时间段，
如果在这个阈值时间段内当选择
provider 不成功，则一直尝试采用“选
定的负载均衡策略：轮询策略”最后选
择一个可用的 provider
过滤性能差的 provider,有 2 种：
第一种：过滤掉在 eureka 中处于一直
6 可用性敏感策略 AvailabilityFilteringRule
连接失败 provider
第二种：过滤掉高并发的 provider
1.以一个区域为单位考察可用性，对于
不可用的区域整个丢弃，从剩下区域中
选可用的 provider
7 区域敏感性策略 ZoneAvoidanceRule
2.如果这个ip区域内有一个或多个实例
不可达或响应变慢，都会降低该 ip 区域
内其他 ip 被选中的权重。
简单说说什么是 Feign？
Feign 是一种声明式、模板化的 HTTP 客户端技术(仅在 consumer 中使用)。
什么是声明式，有什么作用，解决什么问题？
声明式调用就像调用本地方法一样调用远程方法;无感知远程 http 请求。
1、Spring Cloud 的声明式调用, 可以做到使用 HTTP 请求远程服务时能就像调用本地
方法一样的体验，开发者完全感知不到这是远程方法，更感知不到这是个 HTTP 请求。
2、它像 Dubbo 一样，consumer 直接调用接口方法调用 provider，而不需要通过常规
的 Http Client 构造请求再解析返回数据。
3、它解决了让开发者调用远程接口就跟调用本地方法一样，无需关注与远程的交互细节，
更无需关注分布式环境开发。
什么是服务的灾难性的雪崩效应？
在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问 A 服务，
而 A 服务需要调用 B 服务，B 服务需要调用 C 服务，由于网络原因或者自身的原因，如
果 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。
此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之
间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，
这就是服务故障的“雪崩”效应
如何解决灾难性雪崩效应？
降级
超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。
实现一个 fallback 方法, 当请求后端服务出现异常的时候, 可以使用 fallback 方法返回的
值.
隔离（线程池隔离和信号量隔离）
限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
熔断
当失败率(如因网络故障/超时造成的失败率高)达到阀值自动触发降级，熔断器触发
的快速失败会进行快速恢复。
缓存
提供了请求缓存。
请求合并
提供请求合并。
线程池隔离和信号量隔离的区别
请回答微服务架构的六种常用设计模式是什么？
答：如下这六种
代理设计模式
聚合设计模式
链条设计模式
聚合链条设计模式
数据共享设计模式
异步消息设计模式
什么是网关服务？
答：网关服务，通常是外部访问服务的唯一接口，访问内部的所有服务都必须先经过网
关服务。网关服务的主要功能是消息解析过滤，路由，转发等。
网关服务中，路由器的 4 种路由规则方法是什么？
答：
采用 URL 指定路由方式
采用服务名称指定路由方式
路由的排除方法
路由的添加前缀方法
为什么要使用 spring cloud config 配置中心？它解决了什么问题？
什么是 Spring Cloud Bus
消息驱动 Stream 解决了什么问题？
为什么要使用微服务跟踪？它解决了什么问题？
什么是 ELK（ElasticSearch, Logstash, Kibana）
ELK 是三个工具的集合，Elasticsearch + Logstash + Kibana，这三个工具组合形成了
一套实用、易用的监控架构，很多公司利用它来搭建可视化的海量日志分析平台。
ElasticSearch
ElasticSearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全
文搜索引擎，基于 RESTful web 接口。Elasticsearch 是用 Java 开发的，并作为 Apache 许
可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实
时搜索，稳定，可靠，快速，安装使用方便。
Logstash
Logstash 是一个用于管理日志和事件的工具，你可以用它去收集日志、转换日志、解析
日志并将他们作为数据提供给其它模块调用，例如搜索、存储等。
Kibana
Kibana 是一个优秀的前端日志展示框架，它可以非常详细的将日志转化为各种图表，为
用户提供强大的数据可视化支持。
为什么要用 ELK，它解决了什么问题？
什么是分布式跟踪 : Zipki？
