11. Interview-SpringCloud/SpringBoot

微服務(wù)治理

1 Eureka與ZooKeeper的區(qū)別？各自優(yōu)缺點？

  • Zoopkeeper保證CP：

    • ZooKeeper是分布式協(xié)調(diào)服務(wù)，核心算法是ZAB，它的職責(zé)是保證數(shù)據(jù)（配置數(shù)據(jù)，狀態(tài)數(shù)據(jù)）在其管轄下的所有服務(wù)之間保持同步、一致；所以被設(shè)計成CP而不是AP。
    • zk的寫操作都靠leader節(jié)點，leader節(jié)點掛了要先leader選舉出新的leader才能對外寫服務(wù)。
    • 選舉leader的時間可能很長，30~120s，且選舉期間整個zk集群是都是不可用的。

  • Eureka保證AP：

    • Eureka各個節(jié)點都是平等的，只要有一臺Eureka還在，就能保證可用性，只不過查到的信息可能不是最新的（不保證一致性）。
    • Eureka還有一種自我保護機制，如果在15分鐘內(nèi)超過85%的節(jié)點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現(xiàn)了網(wǎng)絡(luò)故障，此時會出現(xiàn)以下幾種情況：
      • Eureka不再從注冊列表中移除因為長時間沒有收到心跳而應(yīng)該過期的服務(wù)
      • Eureka仍然能夠接受新服務(wù)的注冊和查詢請求，但是不會被同步到其它節(jié)點上（即保證當(dāng)前節(jié)點依然可用）
      • 當(dāng)前網(wǎng)絡(luò)穩(wěn)定時，當(dāng)前實例新的注冊信息會被同步到其它節(jié)點中

  • ZooKeeper缺陷

    • 保證CP，忽略A，leader選舉過程中不能保證高可用
    • 其實也是最終一致性
    • leader選舉速度慢，官方說的200ms內(nèi)完成leader選舉，通常需要30~120s
    • ZooKeeper性能有限，典型的ZooKeeper的寫操作TPS大概是一萬多
    • ZooKeeper客戶端使用較復(fù)雜，沒有針對服務(wù)發(fā)現(xiàn)的模型設(shè)計和API封裝，需要調(diào)用方自己處理。
    • 多語言支持不夠友好
    • 沒有比較好用的控制臺進行運維管理

  • Eureka缺陷

    • 保證AP，舍棄C，節(jié)點間同步復(fù)制是基于http的，由于網(wǎng)絡(luò)的不可靠性，可能會出現(xiàn)節(jié)點注冊信息不同步的情況。
    • 不支持事件通知機制

2 使用了springcloud什么組件？

  • Eureka：服務(wù)治理組件。包含服務(wù)注冊中心、服務(wù)注冊與發(fā)現(xiàn)機制實現(xiàn)。
  • Hystrix：容錯管理組件。實現(xiàn)斷路器等。
  • Ribbon：客戶端負載均衡組件。
  • Feign：基于Ribbon和Hystrix的聲明式服務(wù)調(diào)用組件。
  • Zuul：服務(wù)網(wǎng)關(guān)組件。提供智能路由、訪問過濾等功能。
  • Apollo：攜程，分布式配置中心
  • Skywalking：分布式鏈路追蹤
  • Swagger：分布式文檔管理

3 springcloud和springboot版本號多少？

  • springcloud：Dalston.SR1
  • springboot：1.5.9.RELEASE
springcloud&springboot版本對應(yīng)

4 服務(wù)注冊與發(fā)現(xiàn)機制

  • ZooKeeper
    • 沒有內(nèi)置負載均衡器，需要調(diào)用者自己實現(xiàn)
    • 寫操作TPS一萬，存儲節(jié)點數(shù)可達到百萬級別
  • Eureka
    • 負載均衡由Ribbon完成
    • 服務(wù)注冊實例達到5000就會出現(xiàn)服務(wù)不可用
  • Consul
    • 負載均衡由Fabio完成
  • Nacos
    • 一致性協(xié)議
      • AP，Distro協(xié)議
      • CP，Raft協(xié)議
    • 負載均衡機制
      • 基于健康檢查和權(quán)重的負載均衡
      • 基于CMDB的標(biāo)簽負載均衡器
    • 健康檢查機制
      • 客戶端上報，TTL機制
      • 服務(wù)端檢測
    • Nacos開源版本支持服務(wù)實例注冊100萬，服務(wù)的數(shù)量10萬以上。
微服務(wù)注冊與發(fā)現(xiàn)方案對比

5 服務(wù)治理怎么做？

  • 阿里-Dubbo
  • 當(dāng)當(dāng)-DubboX
  • Netflix-Eureka
  • Apache-Consul

6 服務(wù)網(wǎng)關(guān)怎么做？

服務(wù)網(wǎng)關(guān)

服務(wù)網(wǎng)關(guān)功能

  • 請求路由轉(zhuǎn)發(fā)
  • 協(xié)議/格式適配
    • http、HTTPS
    • xml、json
  • 公共模塊
    • 業(yè)務(wù)隔離
    • 安全校驗/攻擊
    • 橫切功能：日志、公共校驗...
  • 限流
    • zuul限流由ratelimit實現(xiàn)

服務(wù)網(wǎng)關(guān)選型

  • OpenResty，基于NGINX+lua
  • kong，基于OpenResty，2015開源
  • zuul，核心功能使用filter實現(xiàn)
    • springcloud全家桶一部分，zuul1.x是同步IO
    • zuul2.x是基于Netty的異步IO，開源不久，可用性較差
  • Spring Cloud Gateway
    • springcloud全家桶一部分，zuul1.x的升級版，基于異步IO
    • 區(qū)分了Router和filter
四大開源服務(wù)網(wǎng)關(guān)

服務(wù)網(wǎng)關(guān)性能

  • 直連 > kong(直連的70%) > OpenResty(直連的60%) > zuul 約等于Spring Cloud Gateway(直連的40%)

7 鏈路追蹤實現(xiàn)原理

7.1 鏈路追蹤實現(xiàn)方案

  • 谷歌的dapper
  • 阿里的鷹眼
  • 大眾點評的CAT
  • Twitter的zipkin
  • naver(社交軟件LINE的母公司)的pinpoint
  • skywalking
  • Spring Cloud Sleuth

7.2 鏈路追蹤實現(xiàn)原理

  • trace架構(gòu)
  • agent代理
trace架構(gòu)
四種時間
計算

8 微服務(wù)限流

8.1 合法性驗證限流

  • 驗證碼
  • IP黑名單

8.2 容器限流

  • Tomcat
    • maxThreads，在conf/server.xml中設(shè)置，默認值為150(tomcat8.5)
    • windows每個進程中最大線程數(shù)為2000，Linux每個進程中最大線程數(shù)為1000
    • 每開啟一個線程需要好用1MB的JVM內(nèi)存空間用作線程棧，線程越多GC負擔(dān)越重。
  • Nginx
    • 控制速率
      • 精確控制：limit_req_zone，限制單位時間內(nèi)(毫秒級)的請求數(shù)
      • 模糊控制：limit_req_zone+burst ，限制單位時間內(nèi)總訪問次數(shù)
    • 控制并發(fā)連接數(shù)：limit_conn_zone+limit_conn
      • limit_conn perip 10，限制單個IP最多持有10個連接
      • limit_conn perserver 100，限制服務(wù)器最大并發(fā)連接數(shù)是100

8.3 服務(wù)端限流

  • 時間窗口算法/計數(shù)器算法

    • Redis的zset實現(xiàn)，key存儲限流的ID，score存儲請求的時間，每次請求來了后先清空之前時間窗口訪問量，統(tǒng)計現(xiàn)在計數(shù)器是否超過最大允許訪問量，超過了則執(zhí)行限流操作；沒超過也允許執(zhí)行業(yè)務(wù)邏輯并在zset中添加一條有效的訪問記錄。
    • 臨界值問題可以結(jié)合滑動時間窗口解決。計數(shù)器是滑動窗口的低精度實現(xiàn)，滑動窗口每個格子都需要存儲一份數(shù)據(jù)，如果精度越高，需要的存儲空間就越大。

  • 漏桶算法(leaky bucket)

    • 漏桶算法解決了時間窗口算法限流不均勻的問題，使用隊列保存請求。
    • Nginx的控制速率就是漏桶算法
    • Redis4.0提供了Redis-Cell模塊支持分布式限流，提供原子指令限流，cl.throttle

  • 令牌桶算法(token bucket)

    • 令牌桶算法在漏桶算法基礎(chǔ)上還允許一定程度的突發(fā)調(diào)用。
    • 一定速率往桶中放令牌，每次請求調(diào)用先要獲取令牌，只有拿到令牌才能才能繼續(xù)執(zhí)行，否則繼續(xù)等待或放棄。
    • Google的guava實現(xiàn)的令牌算法屬于單機限流方案。
令牌桶算法

9 zuul網(wǎng)關(guān)限流

zuul網(wǎng)關(guān)限流實現(xiàn)原理

  • zuul網(wǎng)關(guān)限流是由spring-cloud-zuul-ratelimit包實現(xiàn)的

zuul網(wǎng)關(guān)限流配置

zuul網(wǎng)關(guān)限流參數(shù)
通用配置
Policy屬性

  • zuul.ratelimit.repository 存儲方式

    • InMemoryRateLimiter - 使用 ConcurrentHashMap作為數(shù)據(jù)存儲
    • ConsulRateLimiter - 使用 Consul 作為數(shù)據(jù)存儲
    • RedisRateLimiter - 使用 Redis 作為數(shù)據(jù)存儲
    • SpringDataRateLimiter - 使用 數(shù)據(jù)庫 作為數(shù)據(jù)存儲

  • zuul.ratelimit.policies 限流策略

    • limit：每個周期內(nèi)請求次數(shù)
    • quota：單位時間內(nèi)允許訪問的總時間
    • refresh-interval：周期時間
    • type：限流方式
      • USER 根據(jù)用戶，認證用戶(Authenticated User)，使用已認證的用戶名或匿名
      • ORIGIN 原始請求，原始請求(Request Origin)，使用用戶的原始請求
      • URL 請求地址，使用上游請求的地址
      • 不設(shè)置type，全局限流

zuul網(wǎng)關(guān)限流實現(xiàn)步驟

  • pom.xml配置
 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>
<dependency>
     <groupId>com.marcosbarbero.cloud</groupId>
     <artifactId>spring-cloud-zuul-ratelimit</artifactId>
     <version>2.0.0.RELEASE</version>
</dependency>
  • application.yml配置
spring:
  application:
    name: gateway-server #服務(wù)名稱
  cloud:
    # 設(shè)置偏好網(wǎng)段
    inetutils:
      preferred-networks: 127.0.0.
    loadbalancer:
      retry:
        enabled: true
  jackson:
    date-format: yyyy-MM-dd
    joda-date-time-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8
  redis:
    host: 127.0.0.1
    port: 6379
    timeout: 1000ms
    database: 0
    lettuce:
      pool:
        max-active: 8
        max-wait: -1ms
        max-idle: 8
        min-idle: 0
  zipkin:
    enabled: true
    base-url: http://zipkin-dashboard/


zuul:
  routes:
    user-service:
      path: /user/**
      serviceId: user-service
  add-host-header: true
  sensitive-headers: Access-Control-Allow-Origin,Access-Control-Allow-Methods
  strip-prefix: true
  ratelimit:
    # 開啟限流
    enabled: true
    # 存儲方式
    repository: REDIS
    # 限流策略
    policies:
      # 指定限流服務(wù)
      user-service:
        # 每個周期內(nèi)請求次數(shù)
        limit: 3
        # 單位時間內(nèi)允許訪問的總時間
        quota: 30
        # 周期時間
        refresh-interval: 60
        # 限流方式 USER 根據(jù)用戶；ORIGIN 原始請求；URL 請求地址；
        type: ORIGIN
server:
  port: 9001    # 端口號

eureka:
  client:
    serviceUrl:
      # 服務(wù)器注冊/獲取服務(wù)器的zone
      defaultZone: http://127.0.0.1:9000/eureka/
    healthcheck:
      enabled: true
  instance:
    prefer-ip-address: true

10 服務(wù)熔斷機制

10.1 微服務(wù)熔斷實現(xiàn)方案

  • hystrix
  • Service Mesh
    • lstio
    • Linkerd
  • Glasnostic

10.2 熔斷器實現(xiàn)原理

  • 熔斷機制是應(yīng)對微服務(wù)雪崩效應(yīng)的一種微服務(wù)鏈路保護機制。當(dāng)扇出鏈路的某個微服務(wù)不可用或響應(yīng)時間太長時，會進行服務(wù)降級，進而熔斷該節(jié)點微服務(wù)的調(diào)用，快速響應(yīng)。
  • springcloud是通過hystrix實現(xiàn)熔斷機制，默認5s內(nèi)20次調(diào)用失敗就會啟用熔斷機制，熔斷機制的注解是@HystrixCommand

10.3 Spring Cloud熔斷機制

  1. 添加pom.xml依賴
<dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
 </dependency>
<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
</dependency>
  1. 啟動類注解開啟熔斷器@EnableCircuitBreaker
@EnableDiscoveryClient
@EnableCircuitBreaker
@SpringBootApplication
@EnableFeignClients(basePackageClasses = {PaymentClient.class})
@EnableScheduling
public class Goods {
 
    public static void main(String[] args) {
        SpringApplication.run(Goods.class, args);
    }
}
  1. FeignClient開啟hystrix
feign:
  hystrix:
    enabled: true
  1. 啟動類開啟hystrix監(jiān)控@EnableHystrixDashboard
@EnableHystrixDashboard
@EnableDiscoveryClient
@EnableCircuitBreaker
@SpringBootApplication
@EnableFeignClients
public class GoodsApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(GoodsApplication.class, args);
    }
}
  1. 服務(wù)熔斷
  2. 服務(wù)降級

10.4 dubbo熔斷機制

  • Dubbo的熔斷降級需要自己實現(xiàn)，也可以集成hystrix
  • @EnableHystrix，@HystrixCommand，fallbackMethod

11 微服務(wù)降級

  • Feign整合Hystrix的降級
  • Hystrix本身的降級
    • 隔離（線程池隔離和信號量隔離）：限制調(diào)用分布式服務(wù)的資源使用，某一個調(diào)用的服務(wù)出現(xiàn)問題不會影響其他服務(wù)調(diào)用。
    • 優(yōu)雅的降級機制：超時降級、資源不足時(線程或信號量)降級，降級后可以配合降級接口返回托底數(shù)據(jù)。
    • 融斷：當(dāng)失敗率達到閥值自動觸發(fā)降級(如因網(wǎng)絡(luò)故障/超時造成的失敗率高)，熔斷器觸發(fā)的快速失敗會進行快速恢復(fù)。

12 springcloud超時設(shè)置和重試機制

##timeout config
hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: true
        isolation:
          thread:
            timeoutInMilliseconds: 60000
ribbon:
  ReadTimeout: 60000
  ConnectTimeout: 60000
  MaxAutoRetries: 0
  MaxAutoRetriesNextServer: 1
  eureka:
    enabled: false

zuul:
  max:
    host:
      connections: 500
  host:
    socket-timeout-millis: 60000
    connect-timeout-millis: 60000

12.1 zuul超時設(shè)置

  • zuul使用服務(wù)發(fā)現(xiàn)(serviceId，使用ribbon輪詢機制，取ribbon和hystrix配置最小值)
    • ribbon.ReadTimeout
    • ribbon.SocketTimeout
  • zuul指定URL路由(url，基于httpclient發(fā)送請求)
    • zuul.host.connect-timeout-millis
    • zuul.host.socket-timeout-millis

12.2 ribbon超時設(shè)置

  • ribbon總超時=(1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout
    • ribbon.ConnectTimeout，請求連接超時，會自動重試，重試失敗zuul異常，默認值2000ms
    • ribbon.ReadTimeout，請求處理超時，會自動重試，重試失敗zuul異常，默認值5000ms
    • MaxAutoRetries：當(dāng)前實例最大自動重試次數(shù)，默認值0
    • MaxAutoRetriesNextServer：最大自動重試下一個服務(wù)的次數(shù)，默認值1
  • ribbon設(shè)置的超時應(yīng)該要小于hystrix的超時

12.3 hystrix超時設(shè)置

hystrix超時設(shè)置

  • 設(shè)置隔離方式
    execution.isolation.strategy= THREAD|SEMAPHORE

  • zuul.semaphore.max-semaphores
    是一個絕對值，無時間窗口，相當(dāng)于亞毫秒級的。當(dāng)請求達到或超過該設(shè)置值后，其余請求會被拒絕。默認100，這個值最好是根據(jù)每個后端服務(wù)的訪問情況，單獨設(shè)置。

  • execution.isolation.thread.timeoutInMilliseconds

    • 用來設(shè)置thread和semaphore兩種隔離策略的超時時間，默認值1000ms，可以針對service-id單獨設(shè)置。
    • 單獨設(shè)置時，要根據(jù)所對應(yīng)的業(yè)務(wù)和服務(wù)器所能承受的負載來設(shè)置，一般是大于平均響應(yīng)時間的20%~100%,最好是根據(jù)壓力測試結(jié)果來評估，這個值設(shè)置太大，會導(dǎo)致線程不夠用而會導(dǎo)致太多的任務(wù)被fallback；設(shè)置太小，一些特殊的慢業(yè)務(wù)失敗率提升，甚至?xí)斐蛇@個業(yè)務(wù)一直無法成功，在重試機制存在的情況下，反而會加重后端服務(wù)壓力。

  • execution.isolation.semaphore.maxConcurrentRequests
    指任意時間點允許的并發(fā)數(shù)。當(dāng)請求達到或超過該設(shè)置值后，其余就會被拒絕。默認值是100。

  • execution.timeout.enabled
    要使用hystrix的超時fallback，必須設(shè)置，默認開啟

  • execution.isolation.thread.interruptOnTimeout
    發(fā)生超時是是否中斷線程，默認是true。

  • execution.isolation.thread.interruptOnCancel
    取消時是否中斷線程，默認是false。

  • hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests
    設(shè)置fallback的線程數(shù)，默認是10，這個值在大量觸發(fā)fallback邏輯時要注意調(diào)整。

13 springcloud hystrix隔離策略

  • hystrix線程有兩種隔離策略：
    • 線程隔離
    • 信號量隔離
  • 隔離策略都是控制線程數(shù)量的，hystrix默認的隔離策略是thread，zuul中默認的hystrix隔離策略是semaphore，可通過zuul.ribbon-isolation-strategy=THREAD 修改為線程隔離方式。
  • thread和semaphore隔離策略默認超時時間都是1000ms
  • zuul隔離策略為Semaphore時，max-semaphores默認是100

14 重啟zuul后為啥第一次訪問經(jīng)常會超時？怎么解決？

  • zuul是懶加載機制，第一次訪問才會加載類，而不是啟動時候加載，由于默認時間本來很短，加載類也需要時間，就造成了超時。
  • zuul依賴hystrix，通過處理hystrix超時來解決zuul首次訪問超時問題。
hystrix超時設(shè)置

15 Spring Boot 的核心配置文件有哪幾個？它們的區(qū)別是什么？

Spring Boot 的核心配置文件是 application 和 bootstrap 配置文件。

  • application 配置文件這個容易理解，主要用于 Spring Boot 項目的自動化配置。
  • bootstrap 配置文件有以下幾個應(yīng)用場景。
    • 使用 Spring Cloud Config 配置中心時，這時需要在 bootstrap 配置文件中添加連接到配置中心的配置屬性來加載外部配置中心的配置信息；
    • 一些固定的不能被覆蓋的屬性；
    • 一些加密/解密的場景；

16 Spring Boot 的配置文件有哪幾種格式？它們有什么區(qū)別？

  • .properties 和 .yml。
  • 它們的區(qū)別主要是書寫格式不同。.yml 格式不支持 @PropertySource 注解導(dǎo)入配置

17 Spring Boot 的核心注解是哪個？它主要由哪幾個注解組成的？

啟動類上面的注解是@SpringBootApplication，它也是 Spring Boot 的核心注解，主要組合包含了以下 3 個注解：

  • @SpringBootConfiguration：組合了 @Configuration 注解，實現(xiàn)配置文件的功能。
  • @EnableAutoConfiguration：打開自動配置的功能，也可以關(guān)閉某個自動配置的選項，如關(guān)閉數(shù)據(jù)源自動配置功能： @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })。
  • @ComponentScan：Spring組件掃描。

18 SpringBoot開啟的兩種方式？

  • 繼承spring-boot-starter-parent項目
  • 導(dǎo)入spring-boot-dependencies項目依賴

19 Spring Boot 自動配置原理是什么？

注解 @EnableAutoConfiguration, @Configuration, @ConditionalOnClass 就是自動配置的核心，首先它得是一個配置文件，其次根據(jù)類路徑下是否有這個類去自動配置。META-INF/spring.factories

20 Spring Boot 有哪幾種讀取配置的方式？

  • @PropertySource
  • @Value
  • @Environment,
  • @ConfigurationProperties

21 SpringBoot 實現(xiàn)熱部署有哪幾種方式？

  • Spring Loaded
  • Spring-boot-devtools

22 SpringBoot配置加載順序？

1、開發(fā)者工具 `Devtools` 全局配置參數(shù)；

2、單元測試上的 `@TestPropertySource` 注解指定的參數(shù)；

3、單元測試上的 `@SpringBootTest` 注解指定的參數(shù)；

4、命令行指定的參數(shù)，如 `java -jar springboot.jar --name="Java技術(shù)棧"`；

5、命令行中的 `SPRING_APPLICATION_JSONJSON` 指定參數(shù), 如 `java -Dspring.application.json='{"name":"Java技術(shù)棧"}' -jar springboot.jar`

6、`ServletConfig` 初始化參數(shù)；

7、`ServletContext` 初始化參數(shù)；

8、JNDI參數(shù)（如 `java:comp/env/spring.application.json`）；

9、Java系統(tǒng)參數(shù)（來源：`System.getProperties()`）；

10、操作系統(tǒng)環(huán)境變量參數(shù)；

11、`RandomValuePropertySource` 隨機數(shù)，僅匹配：`ramdom.*`；

12、JAR包外面的配置文件參數(shù)（`application-{profile}.properties（YAML）`）

13、JAR包里面的配置文件參數(shù)（`application-{profile}.properties（YAML）`）

14、JAR包外面的配置文件參數(shù)（`application.properties（YAML）`）

15、JAR包里面的配置文件參數(shù)（`application.properties（YAML）`）

16、`@Configuration`配置文件上 `@PropertySource` 注解加載的參數(shù)；

17、默認參數(shù)（通過 `SpringApplication.setDefaultProperties` 指定）；

23 保護 Spring Boot 應(yīng)用有哪些方法？

  • 在生產(chǎn)中使用HTTPS
  • 使用Snyk檢查你的依賴關(guān)系
  • 升級到最新版本
  • 啟用CSRF保護
  • 使用內(nèi)容安全策略防止XSS攻擊

https://mp.weixin.qq.com/s/HG4_StZyNCoWx02mUVCs1g

24 Spring Boot 2.X 有什么新特性？與 1.X 有什么區(qū)別？

  • 配置變更
  • JDK 版本升級
  • 第三方類庫升級
  • 響應(yīng)式 Spring 編程支持
  • HTTP/2 支持
  • 配置屬性綁定

25 Spring Boot中的監(jiān)視器是什么？

  • Spring boot actuator是spring啟動框架中的重要功能之一。Spring boot監(jiān)視器可幫助您訪問生產(chǎn)環(huán)境中正在運行的應(yīng)用程序的當(dāng)前狀態(tài)。
  • 有幾個指標(biāo)必須在生產(chǎn)環(huán)境中進行檢查和監(jiān)控。即使一些外部應(yīng)用程序可能正在使用這些服務(wù)來向相關(guān)人員觸發(fā)警報消息。監(jiān)視器模塊公開了一組可直接作為HTTP URL訪問的REST端點來檢查狀態(tài)。

26 springboot常用的starter有哪些？

  • spring-boot-starter-web 嵌入tomcat和web開發(fā)需要servlet與jsp支持
  • spring-boot-starter-data-jpa 數(shù)據(jù)庫支持
  • spring-boot-starter-data-redis redis數(shù)據(jù)庫支持
  • spring-boot-starter-data-solr solr支持
  • mybatis-spring-boot-starter 第三方的mybatis集成starter

27 如何在不使用BasePACKAGE過濾器的情況下排除程序包？

過濾程序包的方法不盡相同。但是彈簧啟動提供了一個更復(fù)雜的選項，可以在不接觸組件掃描的情況下實現(xiàn)這一點。在使用注釋@ SpringBootApplication時，可以使用排除屬性。請參閱下面的代碼片段：

@SpringBootApplication(exclude= {Employee.class})

public class FooAppConfiguration {}

28 如何禁用特定的自動配置類？

  • 若發(fā)現(xiàn)任何不愿使用的特定自動配置類，可以使用@EnableAutoConfiguration的排除屬性。

//By using "exclude"

@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})

  • 另一方面，如果類別不在類路徑上，則可以使用excludeName類注解，并且指定完全限定名。

//By using "excludeName"

@EnableAutoConfiguration(excludeName={Foo.class})

  • 此外，Spring Boot還具有控制排除自動配置類列表的功能，可以通過使用spring.autoconfigure.exclude property來實現(xiàn)?？梢詫⑵涮砑拥?propertie應(yīng)用程序中，并且可以添加逗號分隔的多個類。

//By using property file

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAuto

29 springboot優(yōu)缺點

30 springboot修改過哪些配置

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容