【MCA】Java互联网高级架构师【马士兵教育】

时间  2021-08-12
标签 html 前端 java git 程序员 web redis spring 数据库 编程 栏目 Java 繁體版
原文   原文链接

 

爱分享 爱生活 加油 2021 

百度网盘html

提取码：qhhv 前端

一、微服务的优缺点分别是什么?说下你在项目开发中碰到的坑。
优势：
1) 每个服务足够内聚,代码容易理解
2) 开发效率提升,一个服务只作一件事
3) 微服务可以被小团队单独开发
4) 微服务是松耦合的,是有功能意义的服务
5) 能够用不一样的语言开发,面向接口编程
6) 易于与第三方集成
7) 微服务只是业务逻辑的代码,不会和HTML,CSS或者其余界面组合
8) 开发中,两种开发模式
9) 先后端分离
10) 全栈工程师
11) 能够灵活搭配,链接公共库/链接独立库
缺点：
1) 分布式系统的负责性
2) 多服务运维难度,随着服务的增长,运维的压力也在增大
3) 系统部署依赖
4) 服务间通讯成本
5) 数据一致性
6) 系统集成测试
7) 性能监控java

二、什么是Spring Cloud？
Spring cloud流应用程序启动器是基于Spring Boot的Spring集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。git

三、SpringBoot和SpringCloud
1) SpringBoot专一于快速方便的开发单个个体的微服务
2) SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,配置管理,服务发现,断路器,路由,事件总线等集成服务
3) SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系
4) SpringBoot专一于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架程序员

四、SpringCloud和Dubbo
1) 区别
a. 服务的调用方式Dubbo使用的是RPC远程调用,而SpringCloud使用的是 Rest API,其实更符合微服务官方的定义
b. 服务的注册中心来看,Dubbo使用了第三方的ZooKeeper做为其底层的注册中心,实现服务的注册和发现,SpringCloud使用Spring Cloud Netflix Eureka实现注册中心,固然SpringCloud也可使用ZooKeeper实现,但通常咱们不会这样作
c. 服务网关,Dubbo并无自己的实现,只能经过其余第三方技术的整合,而SpringCloud有Zuul路由网关,做为路由服务器,进行消费者的请求分发,SpringCloud还支持断路器,与git完美集成分布式配置文件支持版本控制,事务总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素
2) 技术选型
a. 目前国内的分布式系统选型主要仍是Dubbo毕竟国产,并且国内工程师的技术熟练程度高,而且Dubbo在其余维度上的缺陷能够由其余第三方框架进行集成进行弥补
b. 而SpringCloud目前是国外比较流行,固然我以为国内的市场也会慢慢的偏向SpringCloud,就连刘军做为Dubbo重启的负责人也发表过观点,Dubbo的发展方向是积极适应SpringCloud生态,并非起冲突
3) Rest和RPC对比
其实若是仔细阅读过微服务提出者马丁福勒的论文的话能够发现其定义的服务间通讯机制就是Http Rest。
RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强,咱们须要为每个微服务进行接口的定义,并经过持续继承发布,须要严格的版本控制才不会出现服务提供和调用之间由于版本不一样而产生的冲突
而REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合,只是经过一个约定进行规范,但也有可能出现文档和接口不一致而致使的服务集成问题,但能够经过swagger工具整合,是代码和文档一体化解决,因此REST在分布式环境下比RPC更加灵活
这也是为何当当网的DubboX在对Dubbo的加强中增长了对REST的支持的缘由web

  1. 文档质量和社区活跃度
    SpringCloud社区活跃度远高于Dubbo,毕竟因为梁飞团队的缘由致使Dubbo中止更新迭代五年,而中小型公司没法承担技术开发的成本致使Dubbo社区严重低落,而SpringCloud异军突起,迅速占领了微服务的市场,背靠Spring混的风生水起
    Dubbo通过多年的积累文档至关成熟,对于微服务的架构体系各个公司也有稳定的现状

五、你所知道的微服务技术栈有哪些?请列举一二。维度(SpringCloud)
1) 服务开发：SpringBoot、Spring、SpringMVC
2) 服务配置与管理：Netfilx公司的Archaiusm,阿里的Diamond
3) 服务注册与发现：Eureka,ZooKeeper
4) 服务调用：Rest,RPC,gRPC
5) 服务熔断器：Hystrix
6) 服务负载均衡：Ribbon,Nginx
7) 服务接口调用：Feign
8) 消息队列：Kafka,RabbitMq,ActiveMq
9) 服务配置中心管理：SpringCloudConfing
10) 服务路由(API网关)：Zuul
11) 事件消息总线：SpringCloud Busredis

六、负载平衡的意义什么？
在计算中，负载平衡能够改善跨计算机，计算机集群，网络连接，中央处理单元或磁盘驱动器等多种计算资源的工做负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会经过冗余来提升可靠性和可用性。负载平衡一般涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。spring

七、微服务之间是如何独立通信的
1) 远程过程调用（Remote Procedure Invocation）
也就是咱们常说的服务的注册与发现，直接经过远程过程调用来访问别的service。
优势：
简单，常见,由于没有中间件代理，系统更简单
缺点：
a. 只支持请求/响应的模式，不支持别的，好比通知、请求/异步响应、发布/订阅、发布/异步响应；
b. 下降了可用性，由于客户端和服务端在请求过程当中必须都是可用的
2) 消息
使用异步消息来作服务间通讯。服务间经过消息管道来交换消息，从而通讯。
优势:
a. 把客户端和服务端解耦，更松耦合
b. 提升可用性，由于消息中间件缓存了消息，直到消费者能够消费
c. 支持不少通讯机制好比通知、请求/异步响应、发布/订阅、发布/异步响应
缺点:
消息中间件有额外的复杂性数据库

八、springcloud如何实现服务的注册和发现
服务在发布时 指定对应的服务名（服务名包括了IP地址和端口） 将服务注册到注册中心（eureka或者zookeeper）
这一过程是springcloud自动实现 只须要在main方法添加@EnableDisscoveryClient 同一个服务修改端口就能够启动多个实例
调用方法：传递服务名称经过注册中心获取全部的可用实例 经过负载均衡策略调用（ribbon和feign）对应的服务编程

九、Eureka和ZooKeeper均可以提供服务注册与发现的功能,请说说两个的区别。
1) Eureka取CAP中的AP，注重可用性。Zookepper取CAP理论中的CP强调高的一致性。
ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,可是选举期间不可用的
Eureka各个节点是平等关系,只要有一台Eureka就能够保证服务可用,而查询到的数据并非最新的自我保护机制会致使
Eureka再也不从注册列表移除因长时间没收到心跳而应该过时的服务
Eureka仍然可以接受新服务的注册和查询请求,可是不会被同步到其余节点(高可用)
当网络稳定时,当前实例新的注册信息会被同步到其余节点中(最终一致性)
Eureka能够很好的应对因网络故障致使部分节点失去联系的状况,而不会像ZooKeeper同样使得整个注册系统瘫痪
2) ZooKeeper有Leader和Follower角色,Eureka各个节点平等
3) ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
4) Eureka本质上是一个工程,而ZooKeeper只是一个进程

十、eureka自我保护机制
当 Eureka Server 节点在短期内丢失了过多实例的链接时（好比网络故障或频繁的启动关闭客户端），那么这个节点就会进入自我保护模式，一旦进入到该模式，Eureka server 就会保护服务注册表中的信息，再也不删除服务注册表中的数据（即不会注销任何微服务），当网络故障恢复后，该 Ereaka Server 节点就会自动退出自我保护模式（个人 Eureka Server 已经几个月了，至今未自动退出该模式）

十一、什么是服务熔断?什么是服务降级
在复杂的分布式系统中,微服务之间的相互调用,有可能出现各类各样的缘由致使服务的阻塞,在高并发场景下,服务的阻塞意味着线程的阻塞,致使当前线程不可用,服务器的线程所有阻塞,致使服务器崩溃,因为服务之间的调用关系是同步的,会对整个微服务系统形成服务雪崩
为了解决某个微服务的调用响应时间过长或者不可用进而占用愈来愈多的系统资源引发雪崩效应就须要进行服务熔断和服务降级处理。
所谓的服务熔断指的是某个服务故障或异常一块儿相似显示世界中的“保险丝"当某个异常条件被触发就直接熔断整个服务，而不是一直等到此服务超时。
服务熔断就是至关于咱们电闸的保险丝,一旦发生服务雪崩的,就会熔断整个服务,经过维护一个本身的线程池,当线程达到阈值的时候就启动服务降级,若是其余请求继续访问就直接返回fallback的默认值

十二、如何使用Eureka
1) 添加pom依赖
2) 配置文件添加相关配置
3) 启动类添加注解@EnableDiscoveryClient

1三、什么是Ribbon?
ribbon是一个负载均衡客户端，能够很好的控制htt和tcp的一些行为。Feign默认集成了ribbon。
使用：
1) 添加pom依赖
2) 配置文件添加相关配置
3) 启动类添加注解@EnableEurekaServer
4) 向程序的ioc注入一个bean: restTemplate;并经过@LoadBalanced注解代表这个restRemplate开启负载均衡的功能
5) 写一个测试类HelloService，经过以前注入ioc容器的restTemplate来消费service-hi服务的“/hi”接口
源码：
Ribbon的负载均衡，主要经过LoadBalancerClient来实现的，而LoadBalancerClient具体交给了ILoadBalancer来处理，ILoadBalancer经过配置IRule、IPing等信息，并向EurekaClient获取注册列表的信息，并默认10秒一次向EurekaClient发送“ping”,进而检查是否更新服务列表，最后，获得注册列表后，ILoadBalancer根据IRule的策略进行负载均衡。
而RestTemplate 被@LoadBalance注解后，能过用负载均衡，主要是维护了一个被@LoadBalance注解的RestTemplate列表，并给列表中的RestTemplate添加拦截器，进而交给负载均衡器去处理。

1四、什么是Feign？它的优势是什么？
Feign是一个声明式的伪Http客户端，它使得写Http客户端变得更简单。使用Feign，只须要建立一个接口并注解。它具备可插拔的注解特性，可以使用Feign 注解和JAX-RS注解。Feign支持可插拔的编码器和解码器。Feign默认集成了Ribbon，并和Eureka结合，默认实现了负载均衡的效果。
简而言之：
Feign 采用的是基于接口的注解
Feign 整合了ribbon，具备负载均衡的能力
整合了Hystrix，具备熔断的能力
使用：
1) 添加pom依赖
2) 配置文件添加相关配置
3) 启动类添加注解@EnableFeignClients
4) 定义一个接口，使用注解@ FeignClient（“服务名”），来指定调用哪一个服务

源码实现过程：
首先经过@EnableFeignCleints注解开启FeignCleint
根据Feign的规则实现接口，并加@FeignCleint注解
程序启动后，会进行包扫描，扫描全部的@ FeignCleint的注解的类，并将这些信息注入到ioc容器中。
当接口的方法被调用，经过jdk的代理，来生成具体的RequesTemplate
RequesTemplate在生成Request
Request交给Client去处理，其中Client能够是HttpUrlConnection、HttpClient也能够是Okhttp
最后Client被封装到LoadBalanceClient类，这个类结合类Ribbon作到了负载均衡。

1五、Ribbon和Feign的区别：
Ribbon和Feign都是用于调用其余服务的，不过方式不一样。
1.启动类使用的注解不一样，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
2.服务的指定位置不一样，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
3.调用方式不一样，Ribbon须要本身构建http请求，模拟http请求而后使用RestTemplate发送给其余服务，步骤至关繁琐。
Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将须要调用的其余服务的方法定义成抽象方法便可，
不须要本身构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法彻底一致。

1六、什么是Spring Cloud Bus？
Spring Cloud Bus 将分布式的节点用轻量的消息代理链接起来。它能够用于广播配置文件的更改或者服务之间的通信，也能够用于监控。
若是修改了配置文件，发送一次请求，全部的客户端便会从新读取配置文件
使用：
一、添加依赖
二、配置rabbitmq

1七、什么是zuul?
Zuul的主要功能是路由转发和过滤器。路由功能是微服务的一部分，好比／api/user转发到到user服务，/api/shop转发到到shop服务。zuul默认和Ribbon结合实现了负载均衡的功能。
使用：
一、添加pom依赖
二、配置文件添加相关配置
三、启动类添加注解@EnableZuulProxy

在zuul中， 整个请求的过程是这样的，首先将请求给zuulservlet处理，zuulservlet中有一个zuulRunner对象，该对象中初始化了RequestContext：做为存储整个请求的一些数据，并被全部的zuulfilter共享。zuulRunner中还有 FilterProcessor，FilterProcessor做为执行全部的zuulfilter的管理器。FilterProcessor从filterloader 中获取zuulfilter，而zuulfilter是被filterFileManager所加载，并支持groovy热加载，采用了轮询的方式热加载。有了这些filter以后，zuulservelet首先执行的Pre类型的过滤器，再执行route类型的过滤器，最后执行的是post 类型的过滤器，若是在执行这些过滤器有错误的时候则会执行error类型的过滤器。执行完这些过滤器，最终将请求的结果返回给客户端。

1八、什么是Hystrix？它如何实现容错？
Hystrix是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，中止级联故障并在复杂的分布式系统中实现弹性。
一般对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协做。
使用：
一、添加pom依赖
二、启动类使用注解@EnableHystrix
三、在Service方法上加上@HystrixCommand注解。该注解对该方法建立了熔断器的功能，并指定了fallbackMethod熔断方法

** 1九、springcloud断路器的做用**
当一个服务调用另外一个服务因为网络缘由或者自身缘由出现问题时 调用者就会等待被调用者的响应 当更多的服务请求到这些资源时，致使更多的请求等待 这样就会发生连锁效应（雪崩效应） 断路器就是解决这一问题。
断路器有彻底打开状态：必定时间内 达到必定的次数没法调用 而且屡次检测没有恢复的迹象 断路器彻底打开，那么下次请求就不会请求到该服务
半开：短期内 有恢复迹象 断路器会将部分请求发给该服务 当能正常调用时 断路器关闭
关闭：当服务一直处于正常状态 能正常调用 断路器关闭

20、Spring Cloud Config
在分布式系统中，因为服务数量巨多，为了方便服务配置文件统一管理，实时更新，因此须要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。
使用：
一、添加pom依赖
二、配置文件添加相关配置
三、启动类添加注解@EnableConfigServer

2一、Spring Cloud Gateway
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关做为流量的，在微服务系统中有着很是做用，网关常见的功能有路由转发、权限校验、限流控制等做用。
使用了一个RouteLocatorBuilder的bean去建立路由，除了建立路由RouteLocatorBuilder可让你添加各类predicates和filters，predicates断言的意思，顾名思义就是根据具体的请求的规则，由具体的route去处理，filters是各类过滤器，用来对请求作各类判断和修改。

2二、架构：
在微服务架构中，须要几个基础的服务治理组件，包括服务注册与发现、服务消费、负载均衡、断路器、智能路由、配置管理等，由这几个基础组件相互协做，共同组建了一个简单的微服务系统
在Spring Cloud微服务系统中，一种常见的负载均衡方式是，客户端的请求首先通过负载均衡（zuul、Ngnix），再到达服务网关（zuul集群），而后再到具体的服。，服务统一注册到高可用的服务注册中心集群，服务的全部的配置文件由配置服务管理，配置服务的配置文件放在git仓库，方便开发人员随时改配置。



一、什么是springboot

  1. 用来简化spring应用的初始搭建以及开发过程 使用特定的方式来进行配置（properties或yml文件）
  2. 建立独立的spring引用程序 main方法运行
  3. 嵌入的Tomcat 无需部署war文件
  4. 简化maven配置

二、什么是 JavaConfig？
Spring JavaConfig 是 Spring 社区的产品，它提供了配置 Spring IoC 容器的纯 Java 方法。所以它有助于避免使用 XML 配置。
使用 JavaConfig 的优势在于：
面向对象的配置。因为配置被定义为 JavaConfig 中的类，所以用户能够充分利用 Java 中的面向对象功能。一个配置类能够继承另外一个，重写它的@Bean 方法等。
减小或消除 XML 配置。基于依赖注入原则的外化配置的好处已被证实。可是，许多开发人员不但愿在 XML 和 Java 之间来回切换。 JavaConfig 为开发人员提供了一种纯 Java 方法来配置与 XML 配置概念类似的 Spring 容器。从技术角度来说，只使用 JavaConfig 配置类来配置容器是可行的，但实际上不少人认为将 JavaConfig 与 XML 混合匹配是理想的。
类型安全和重构友好。 JavaConfig 提供了一种类型安全的方法来配置 Spring 容器。因为Java 5.0 对泛型的支持，如今能够按类型而不是按名称检索 bean，不须要任何强制转换或基于字符串的查找。

三、Spring Boot有哪些优势？
答：

  1. 快速建立独立运行的spring项目与主流框架集成
  2. 使用嵌入式的servlet容器，应用无需打包成war包
  3. starters自动依赖与版本控制
  4. 大量的自动配置，简化开发，也可修改默认值
  5. 准生产环境的运行应用监控
  6. 与云计算的自然集成

四、Spring Boot 提供了哪些核心功能？

  1. 独立运行 Spring 项目
  2. 内嵌 Servlet 容器
    Spring Boot 能够选择内嵌 Tomcat、Jetty 或者 Undertow，这样咱们无须以 war 包形式部署项目。
  3. 提供 Starter 简化 Maven 配置
    例如，当你使用了 spring-boot-starter-web ，会自动加入以下依赖：spring-boot-starter-web 的 pom 文件
  4. 自动配置 Spring Bean
    Spring Boot 检测到特定类的存在，就会针对这个应用作必定的配置，进行自动配置 Bean ，这样会极大地减小咱们要使用的配置。
  5. 准生产的应用监控
    Spring Boot 提供基于 HTTP、JMX、SSH 对运行时的项目进行监控。
  6. 无代码生成和 XML 配置
    Spring Boot 没有引入任何形式的代码生成，它是使用的 Spring 4.0 的条件 @Condition 注解以实现根据条件进行配置。同时使用了 Maven /Gradle 的依赖传递解析机制来实现 Spring 应用里面的自动配置。

五、如何从新加载Spring Boot上的更改，而无需从新启动服务器？
这可使用DEV工具来实现。经过这种依赖关系，您能够节省任何更改，嵌入式tomcat将从新启动。
Spring Boot有一个开发工具（DevTools）模块，它有助于提升开发人员的生产力。Java开发人员面临的一个主要挑战是将文件更改自动部署到服务器并自动重启服务器。
开发人员能够从新加载Spring Boot上的更改，而无需从新启动服务器。这将消除每次手动部署更改的须要。Spring Boot在发布它的第一个版本时没有这个功能。
这是开发人员最须要的功能。DevTools模块彻底知足开发人员的需求。该模块将在生产环境中被禁用。它还提供H2数据库控制台以更好地测试应用程序。

六、建立一个 Spring Boot Project 的最简单的方法是什么？
Spring Initializer 是建立 Spring Boot Projects 的一个很好的工具

七、运行 Spring Boot 有哪几种方式？

  1. 打包成 Fat Jar ，直接使用 java -jar 运行。目前主流的作法，推荐。
  2. 在 IDEA 或 Eclipse 中，直接运行应用的 Spring Boot 启动类的 #main(String[] args) 启动。适用于开发调试场景。
  3. 若是是 Web 项目，能够打包成 War 包，使用外部 Tomcat 或 Jetty 等容器。

八、Spring Boot中的监视器是什么？
Spring boot actuator是spring启动框架中的重要功能之一。Spring boot监视器可帮助您访问生产环境中正在运行的应用程序的当前状态。
有几个指标必须在生产环境中进行检查和监控。即便一些外部应用程序可能正在使用这些服务来向相关人员触发警报消息。监视器模块公开了一组可直接做为HTTP URL访问的REST端点来检查状态。

九、什么是starter?
Starter主要是用来简化maven依赖

十、Spring Boot 经常使用的 Starter 有哪些？
spring-boot-starter-web ：提供 Spring MVC + 内嵌的 Tomcat 。
spring-boot-starter-data-jpa ：提供 Spring JPA + Hibernate 。
spring-boot-starter-data-redis ：提供 Redis 。
mybatis-spring-boot-starter ：提供 MyBatis 。

十一、什么是YAML？
YAML是一种人类可读的数据序列化语言。它一般用于配置文件。
与属性文件相比，若是咱们想要在配置文件中添加复杂的属性，YAML文件就更加结构化，并且更少混淆。能够看出YAML具备分层配置数据。

十二、如何集成Spring Boot和ActiveMQ？
对于集成Spring Boot和ActiveMQ，咱们使用spring-boot-starter-activemq依赖关系。 它只须要不多的配置，而且不须要样板代码。

1三、springboot经常使用的starter有哪些？
spring-boot-starter-web 嵌入tomcat和web开发须要servlet与jsp支持
spring-boot-starter-data-jpa 数据库支持
spring-boot-starter-data-redis redis数据库支持
spring-boot-starter-data-solr solr支持
mybatis-spring-boot-starter 第三方的mybatis集成starter

1四、springboot自动配置的原理
在spring程序main方法中 添加@SpringBootApplication或者@EnableAutoConfiguration
会自动去maven中读取每一个starter中的spring.factories文件 该文件里配置了全部须要被建立spring容器中的bean

1五、springboot读取配置文件的方式
springboot默认读取配置文件为application.properties或者是application.yml

1六、Spring Boot 须要独立的容器运行吗？
能够不须要，内置了 Tomcat/ Jetty 等容器。

1七、运行 Spring Boot 有哪几种方式？
1）打包用命令或者者放到容器中运行
2）用 Maven/ Gradle 插件运行
3）直接执行 main 方法运行

1八、Spring Boot 的核心配置文件有哪几个？它们的区别是什么？
Spring Boot 的核心配置文件是 application 和 bootstrap 配置文件。
application 配置文件这个容易了解，主要用于 Spring Boot 项目的自动化配置。
bootstrap 配置文件有如下几个应用场景。
使用 Spring Cloud Config 配置中心时，这时须要在 bootstrap 配置文件中增长链接到配置中心的配置属性来加载外部配置中心的配置信息；
少许固定的不能被覆盖的属性；
少许加密/解密的场景；

1九、Spring Boot 的核心注解是哪一个？它主要由哪几个注解组成的？
启动类上面的注解是@SpringBootApplication，它也是 Spring Boot 的核心注解，主要组合包含了如下 3 个注解：
@SpringBootConfiguration：组合了 @Configuration 注解，实现配置文件的功能。
@EnableAutoConfiguration：打开自动配置的功能，也能够关闭某个自动配置的选项，如关闭数据源自动配置功能： @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })。
@ComponentScan：Spring组件扫描

20、为何咱们须要 spring-boot-maven-plugin?
spring-boot-maven-plugin 提供了一些像 jar 同样打包或者运行应用程序的命令。
spring-boot:run 运行你的 SpringBooty 应用程序。
spring-boot：repackage 从新打包你的 jar 包或者是 war 包使其可执行
spring-boot：start 和 spring-boot：stop 管理 Spring Boot 应用程序的生命周期（也能够说是为了集成测试）。
spring-boot:build-info 生成执行器可使用的构造信息。

2一、如何使用Spring Boot实现分页和排序？
使用Spring Boot实现分页很是简单。使用Spring Data-JPA能够实现将可分页的
org.springframework.data.domain.Pageable
传递给存储库方法。

2二、什么是Swagger？你用Spring Boot实现了它吗？
Swagger普遍用于可视化API，使用Swagger UI为前端开发人员提供在线沙箱。Swagger是用于生成RESTful Web服务的可视化表示的工具，规范和完整框架实现。它使文档可以以与服务器相同的速度更新。当经过Swagger正肯定义时，消费者可使用最少许的实现逻辑来理解远程服务并与其进行交互。所以，Swagger消除了调用服务时的猜想。

2三、什么是Spring Profiles？
Spring Profiles容许用户根据配置文件（dev，test，prod等）来注册bean。所以，当应用程序在开发中运行时，只有某些bean能够加载，而在PRODUCTION中，某些其余bean能够加载。假设咱们的要求是Swagger文档仅适用于QA环境，而且禁用全部其余文档。这可使用配置文件来完成。Spring Boot使得使用配置文件很是简单。

2四、什么是Spring Batch？
Spring Boot Batch提供可重用的函数，这些函数在处理大量记录时很是重要，包括日志/跟踪，事务管理，做业处理统计信息，做业从新启动，跳过和资源管理。它还提供了更先进的技术服务和功能，经过优化和分区技术，能够实现极高批量和高性能批处理做业。简单以及复杂的大批量批处理做业能够高度可扩展的方式利用框架处理重要大量的信息。

2五、什么是FreeMarker模板？
FreeMarker是一个基于Java的模板引擎，最初专一于使用MVC软件架构进行动态网页生成。使用Freemarker的主要优势是表示层和业务层的彻底分离。程序员能够处理应用程序代码，而设计人员能够处理html页面设计。最后使用freemarker能够将这些结合起来，给出最终的输出页面。

2六、什么是JavaConfig？
Spring JavaConfig是Spring社区的产品，它提供了配置Spring IoC容器的纯Java方法。所以它有助于避免使用XML配置。使用JavaConfig的优势在于：
面向对象的配置。因为配置被定义为JavaConfig中的类，所以用户能够充分利用Java中的面向对象功能。一个配置类能够继承另外一个，重写它的@Bean方法等。
减小或消除XML配置。基于依赖注入原则的外化配置的好处已被证实。可是，许多开发人员不但愿在XML和Java之间来回切换。
JavaConfig为开发人员提供了一种纯Java方法来配置与XML配置概念类似的Spring容器。
从技术角度来说，只使用JavaConfig配置类来配置容器是可行的，但实际上不少人认为将JavaConfig与XML混合匹配是理想的。
类型安全和重构友好。JavaConfig提供了一种类型安全的方法来配置Spring容器。因为Java 5.0对泛型的支持，如今能够按类型而不是按名称检索bean，不须要任何强制转换或基于字符串的查找

2七、启动类注解：
@SpringBootConfiguration:Spring Boot的配置类; 标注在某个类上，表示这是一个Spring Boot的配置类; @Configuration:配置类上来标注这个注解;配置类 ----- 配置文件;配置类也是容器中的一个组件;@Component
@EnableAutoConfiguration:开启自动配置功能;
之前咱们须要配置的东西，Spring Boot帮咱们自动配置;@EnableAutoConfiguration告诉SpringBoot开启自动配置功能;这样自动配置才能生效;
Spring Boot在启动的时候从类路径下的META-INF/spring.factories中获取EnableAutoConfiguration指定的值，将这些值做为自动配置类导入到容器中，自动配置类就失效，帮咱们进行自动配置工做

2八、配置文件的加载顺序
由jar包外向jar包内进行寻找;
优先加载带profile
jar包外部的application-{profile}.properties或application.yml(带spring.profile)配置文件
jar包内部的application-{profile}.properties或application.yml(带spring.profile)配置文件
再来加载不带profile
jar包外部的application.properties或application.yml(不带spring.profile)配置文件
jar包内部的application.properties或application.yml(不带spring.profile)配置文件

2九、自动配置原理
1)、SpringBoot启动的时候加载主配置类，开启了自动配置功能 @EnableAutoConfiguration
2)、@EnableAutoConfiguration 做用:
将类路径下 META-INF/spring.factories 里面配置的全部EnableAutoConfiguration的值加入到了容器中;
每个这样的 xxxAutoConfiguration类都是容器中的一个组件，都加入到容器中;用他们来作自动配置;
3)、每个自动配置类进行自动配置功能;
根据当前不一样的条件判断，决定这个配置类是否生效；
4)、一但这个配置类生效;这个配置类就会给容器中添加各类组件;这些组件的属性是从对应的properties类中获取 的，这些类里面的每个属性又是和配置文件绑定的;
5)、全部在配置文件中能配置的属性都是在xxxxProperties类中封装者‘;配置文件能配置什么就能够参照某个功 能对应的这个属性类

30、怎么用好自动配置，精髓:
1)、SpringBoot启动会加载大量的自动配置类
2)、咱们看咱们须要的功能有没有SpringBoot默认写好的自动配置类;
3)、咱们再来看这个自动配置类中到底配置了哪些组件;(只要咱们要用的组件有，咱们就不须要再来配置了)
4)、给容器中自动配置类添加组件的时候，会从properties类中获取某些属性。咱们就能够在配置文件中指定这 些属性的值;

3一、日志框架：
SpringBoot选用 SLF4j和logback;
如何让系统中全部的日志都统一到slf4j;
一、将系统中其余日志框架先排除出去;
二、用中间包来替换原有的日志框架;
三、咱们导入slf4j其余的实现
SpringBoot能自动适配全部的日志，并且底层使用slf4j+logback的方式记录日志

3二、Spring Boot、Spring MVC 和 Spring 有什么区别
Spring 是一个“引擎”，
Spring MVC是基于Spring的一个 MVC 框架，
Spring Boot是基于 Spring的一套快速开发整合包

3三、咱们如何监视全部 Spring Boot 微服务？
Spring Boot 提供监视器端点以监控各个微服务的度量。这些端点对于获取有关应用程序的信息（如它们是否已启动）以及它们的组件（如数据库等）是否正常运行颇有帮助。可是，使用监视器的一个主要缺点或困难是，咱们必须单独打开应用程序的知识点以了解其状态或健康情况。想象一下涉及 50 个应用程序的微服务，管理员将不得不击中全部 50 个应用程序的执行终端。



1. Dubbo 支持哪些协议，每种协议的应用场景，优缺点？

  • dubbo： 单一长链接和 NIO 异步通信，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步， Hessian 序列化；
  • rmi： 采用 JDK 标准的 rmi 协议实现，传输参数和返回参数对象须要实现Serializable 接口，使用 java 标准序列化机制，使用阻塞式短链接，传输数据包大小混合，消费者和提供者个数差很少，可传文件，传输协议 TCP。多个短链接， TCP 协议传输，同步传输，适用常规的远程服务调用和 rmi 互操做。在依赖低版本的 Common-Collections 包， java 序列化存在安全漏洞；
  • http： 基于 Http 表单提交的远程调用协议，使用 Spring 的 HttpInvoke 实现。多个短链接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，须要给应用程序和浏览器 JS 调用；
  • webservice： 基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生 WebService 的互操做。多个短链接，基于 HTTP 传输，同步传输，适用系统集成和跨语言调用；
  • ** hessian**： 集成 Hessian 服务，基于 HTTP 通信，采用 Servlet 暴露服务，Dubbo 内嵌 Jetty 做为服务器时默认实现，提供与 Hession 服务互操做。多个短链接，同步 HTTP 传输， Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；
  • redis： 基于 redis 实现的 RPC 协议

2. Dubbo 超时时间怎样设置？
Dubbo 超时时间设置有两种方式：

  • 服务提供者端设置超时时间，在 Dubbo 的用户文档中，推荐若是能在服务端多配置就尽可能多配置，由于服务提供者比消费者更清楚本身提供的服务特性。
  • 服务消费者端设置超时时间，若是在消费者端设置了超时时间，以消费者端为主，即优先级更高。由于服务调用方设置超时时间控制性更灵活。若是消费方超时，服务端线程不会定制，会产生警告。

3. Dubbo 有些哪些注册中心？

  • Multicast 注册中心： Multicast 注册中心不须要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现；
  • Zookeeper 注册中心： 基于分布式协调系统 Zookeeper 实现，采用Zookeeper 的 watch 机制实现数据变动；
  • redis 注册中心： 基于 redis 实现，采用 key/Map 存储，住 key 存储服务名和类型， Map 中 key 存储服务 URL， value 服务过时时间。基于 redis 的发布/订阅模式通知数据变动；
  • Simple 注册中心

4. Dubbo 集群的负载均衡有哪些策略?
Dubbo 提供了常见的集群策略实现，并预扩展点予以自行实现。

  • Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀；
  • RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，可是存在请求累积的问题；
  • LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；
  • ConstantHash LoadBalance: 一致性 Hash 策略，使相同参数请求老是发到同一提供者，一台机器宕机，能够基于虚拟节点，分摊至其余提供者，避免引发提供者的剧烈变更；

5. Dubbo 是什么？
Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案， 能够和Spring 框架无缝集成

6. Dubbo 的主要应用场景？

  • 透明化的远程方法调用，就像调用本地方法同样调用远程方法，只需简单配置，没有任何 API 侵入。
  • 软负载均衡及容错机制，可在内网替代 F5 等硬件负载均衡器，下降成本，减小单点。
  • 服务自动注册与发现，再也不须要写死服务提供方地址，注册中心基于接口名查询服务提供者的 IP 地址，而且可以平滑添加或删除服务提供者。

7. Dubbo 的核心功能？
主要就是以下 3 个核心功能：

  • Remoting： 网络通讯框架，提供对多种 NIO 框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。
  • Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
  • Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方能够平滑增长或减小机器。

8. Dubbo 服务注册与发现的流程？

 
watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=
file

流程说明：

 

  • Provider(提供者)绑定指定端口并启动服务
  • 指供者链接注册中心，并发本机 IP、端口、应用信息和提供服务信息发送至注册中心存储
  • Consumer(消费者），链接注册中心 ，并发送应用信息、所求服务信息至注册中心
  • 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。
  • Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。
  • Provider 状态变动会实时通知注册中心、在由注册中心实时推送至Consumer
    设计的缘由：
  • Consumer 与 Provider 解偶，双方均可以横向增减节点数。
  • 注册中心对自己可作对等集群，可动态增减节点，而且任意一台宕掉后，将自动切换到另外一台
  • 去中心化，双方不直接依懒注册中心，即便注册中心所有宕机短期内也不会影响服务的调用
  • 服务提供者无状态，任意一台宕掉后，不影响使用

9. Dubbo 的架构设计

 
watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=
file

Dubbo 框架设计一共划分了 10 个层：

 

  • 服务接口层（ Service） ：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。
  • 配置层（ Config） ：对外配置接口，以 ServiceConfig 和ReferenceConfig 为中心。
  • 服务代理层（ Proxy）：服务接口透明代理，生成服务的客户端 Stub和服务器端 Skeleton
  • 服务注册层（ Registry） ：封装服务地址的注册与发现，以服务 URL为中心。
  • 集群层（ Cluster） ：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心。
  • 监控层（ Monitor） ： RPC 调用次数和调用时间监控。
  • 远程调用层（ Protocol） ：封将 RPC 调用，以 Invocation 和 Result为中心，扩展接口为 Protocol、 Invoker 和 Exporter。
  • 信息交换层（ Exchange） ：封装请求响应模式，同步转异步，以Request 和 Response 为中心。
  • 网络传输层（ Transport） ：抽象 mina 和 netty 为统一接口，以Message 为中心。

10. Dubbo 的服务调用流程？

 
watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=
file

 

11. Dubbo 的核心组件？

 
watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=
file

 

12. Dubbo 支持哪些协议，每种协议的应用场景，优缺点？

  • dubbo： 单一长链接和 NIO 异步通信，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步， Hessian 序列化；
  • rmi： 采用 JDK 标准的 rmi 协议实现，传输参数和返回参数对象须要实现 Serializable 接口，使用 java 标准序列化机制，使用阻塞式短链接，传输数据包大小混合，消费者和提供者个数差很少，可传文件，传输协议 TCP。 多个短链接， TCP 协议传输，同步传输，适用常规的远程服务调用和rmi 互操做。在依赖低版本的 Common-Collections包， java 序列化存在安全漏洞；
  • webservice： 基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生 WebService 的互操做。多个短链接，基于 HTTP 传输，同步传输，适用系统集成和跨语言调用；
  • http： 基于 Http 表单提交的远程调用协议，使用 Spring 的HttpInvoke 实现。多个短链接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，须要给应用程序和浏览器 JS 调用；
  • hessian： 集成 Hessian 服务，基于 HTTP 通信，采用 Servlet 暴露服务， Dubbo 内嵌 Jetty 做为服务器时默认实现，提供与 Hession 服务互操做。多个短链接，同步 HTTP 传输， Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；
  • memcache： 基于 memcached 实现的 RPC 协议
  • redis： 基于 redis 实现的 RPC 协议

13. dubbo 推荐用什么协议？
默认使用 dubbo 协议

14. Dubbo 有些哪些注册中心？

  • Multicast 注册中心： Multicast 注册中心不须要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现； Zookeeper 注册中心： 基于分布式协调系统 Zookeeper 实现，采用Zookeeper 的 watch 机制实现数据变动；
  • redis 注册中心： 基于 redis 实现，采用 key/Map 存储，住 key 存储服务名和类型， Map 中 key 存储服务 URL， value 服务过时时间。基于 redis 的发布/订阅模式通知数据变动；
  • Simple 注册中心

15. Dubbo 默认采用注册中心？
采用 Zookeeper

16. 为何须要服务治理？

 
watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=
file

 

  • 过多的服务 URL 配置困难
  • 负载均衡分配节点压力过大的状况下也须要部署集群 服务依赖混乱，启动顺序不清晰
  • 过多服务致使性能指标分析难度较大，须要监控

17. Dubbo 的注册中心集群挂掉，发布者和订阅者之间还能通讯么？
能够的，启动 dubbo 时，消费者会从 zookeeper 拉取注册的生产者的地址接口等数据，缓存在本地。
每次调用时，按照本地存储的地址进行调用。

18. Dubbo 与 Spring 的关系？
Dubbo 采用全 Spring 配置方式，透明化接入应用，对应用没有任何API 侵入，只需用 Spring 加载 Dubbo 的配置便可， Dubbo 基于Spring 的 Schema 扩展进行加载。

19. Dubbo 使用的是什么通讯框架?
默认使用 NIO Netty 框架

20. Dubbo 集群提供了哪些负载均衡策略？

  • Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀；
  • RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，可是存在请求累积的问题； LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；
  • ConstantHash LoadBalance: 一致性 Hash 策略，使相同参数请求老是发到同一提供者，一台机器宕机，能够基于虚拟节点，分摊至其余提供者，避免引发提供者的剧烈变更；
  • 缺省时为 Random 随机调用

21. Dubbo 的集群容错方案有哪些？

  • Failover Cluster
  • 失败自动切换，当出现失败，重试其它服务器。一般用于读操做，但重试会带来更长延迟。
  • Failfast Cluster
  • 快速失败，只发起一次调用，失败当即报错。一般用于非幂等性的写操做，好比新增记录。
  • Failsafe Cluster
  • 失败安全，出现异常时，直接忽略。一般用于写入审计日志等操做。
  • Failback Cluster
  • 失败自动恢复，后台记录失败请求，定时重发。一般用于消息通知操做。
  • Forking Cluster
  • 并行调用多个服务器，只要一个成功即返回。一般用于实时性要求较高的读操做，但须要浪费更多服务资源。可经过 forks="2" 来设置最大并行数。
  • Broadcast Cluster
  • 广播调用全部提供者，逐个调用，任意一台报错则报错 。一般用于通知全部提供者更新缓存或日志等本地资源信息

22. Dubbo 的默认集群容错方案？
Failover Cluster

23. Dubbo 支持哪些序列化方式？
默认使用 Hessian 序列化，还有 Duddo、 FastJson、 Java 自带序列化。

24. Dubbo 超时时间怎样设置？
Dubbo 超时时间设置有两种方式：

  • 服务提供者端设置超时时间，在 Dubbo 的用户文档中，推荐若是能在服务端多配置就尽可能多配置，由于服务提供者比消费者更清楚本身提供的服务特性。
  • 服务消费者端设置超时时间，若是在消费者端设置了超时时间，以消费者端为主，即优先级更高。由于服务调用方设置超时时间控制性更灵活。若是消费方超时，服务端线程不会定制，会产生警告。

25. 服务调用超时问题怎么解决？
dubbo 在调用服务不成功时，默认是会重试两次的。

26. Dubbo 在安全机制方面是如何解决？
Dubbo 经过 Token 令牌防止用户绕过注册中心直连，而后在注册中心上管理受权。 Dubbo 还提供服务黑白名单，来控制服务所容许的调用方。

27. Dubbo 和 Dubbox 之间的区别？
dubbox 基于 dubbo 上作了一些扩展，如加了服务可 restful 调用，更新了开源组件等。

28. Dubbo 和 Spring Cloud 的关系？
Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外因为依托了 Spirng、Spirng Boot 的优点之上，两个框架在开始目标就不一致， Dubbo定位服务治理、 Spirng Cloud 是一个生态。

29. Dubbo 和 Spring Cloud 的区别？

 
watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=
file
最大的区别： Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于TCP 协议传输的，配合以 Hession 序列化完成 RPC 通讯。 而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通讯，相对来讲， Http 请求会有更大的报文，占的带宽也会更多。可是REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程