微服务框架

SpringBoot和SpringCloud简介

简要概述

1、SpringBoot：是一个快速开发框架，通过用MAVEN依赖的继承方式，帮助我们快速整合第三方常用框架，完全采用注解化（使用注解方式启动SpringMVC），简化XML配置，内置HTTP服务器（Tomcat，Jetty），最终以Java应用程序进行执行。

2、SpringCloud： 是一套目前完整的微服务框架，它是是一系列框架的有序集合。它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。

基础概念

1. 注册中心（Service Registry）

概念： 注册中心就像一个“通讯录”。每个微服务（比如订单服务、库存服务）启动后，都会将自己的地址（IP地址和端口号）注册到这里。当一个服务需要调用另一个服务时，它会先去注册中心查询目标服务的地址，然后才能发起调用。

为什么重要： 在微服务架构中，服务的数量非常多，而且它们的地址可能会频繁变动（比如服务重启、扩容）。如果没有注册中心，服务之间就无法找到对方，整个系统会瘫痪。注册中心解决了服务发现的问题。开发者通常只需要在应用启动类上添加一个 @EnableDiscoveryClient注解，框架就会自动处理服务的注册和发现。

2. 负载均衡（Load Balancing）

概念： 负载均衡器是一种策略，它负责将来自客户端的请求，公平、高效地分配到后端多个提供相同服务的实例上。

为什么重要： 在高并发场景下，为了分担压力，我们通常会部署多个相同的服务实例。负载均衡可以防止某个服务实例因压力过大而崩溃，同时提高整个系统的吞吐量和可用性。常见的负载均衡策略有轮询、随机、加权等。调用服务时，只需使用服务名（而不是硬编码的IP地址），框架内置的负载均衡器（如Ribbon）就会自动从注册中心获取多个实例地址，并选择一个进行调用。

3. 熔断（Circuit Breaking）

概念： 熔断器是一种 自我保护机制 。当一个服务调用另一个服务时，如果目标服务因为某种原因（如过载或宕机）连续多次失败，熔断器会像电路开关一样“熔断”这次调用，直接返回错误，而不是让请求一直等待或重试。

为什么重要： 它能防止“雪崩效应”。想象一下，服务A调用服务B，如果服务B很慢或已经失败，服务A的请求就会堆积，最终导致服务A也崩溃。熔断机制可以保护调用方，让它快速失败并返回，避免整个调用链条因一个节点的故障而连锁崩溃。使用Hystrix或Resilience4j等组件，只需要在调用的方法上添加一个注解，就可以轻松实现熔断功能。

4. 链路追踪（Distributed Tracing）

概念： 链路追踪工具负责记录一个用户请求从进入系统开始，经过所有微服务调用的完整路径和每个服务调用的耗时。它就像一个“探险家”，沿着请求的足迹，记录下每一步的细节。

为什么重要： 在复杂的微服务架构中，一个简单的请求可能要经过十几个甚至几十个服务的协作才能完成。当请求失败或响应变慢时，我们很难知道是哪一个环节出了问题。链路追踪可以帮助开发者快速定位问题，分析性能瓶颈，极大地简化了调试和排查故障的难度。

什么是微服务

1. 以前的模式是 所有的代码在同一个工程中 部署在同一个服务器中 同一个项目的不同模块不同功能互相抢占资源
2. 微服务 将工程根据不同的业务规则拆分成微服务 微服务部署在不同的机器上 服务之间进行相互调用
3. Java微服务的框架有 dubbo（只能用来做微服务），spring cloud（提供了服务的发现，断路器等）

SpringBoot和SpringCloud的关系

1、SpringBoot只是一个快速开发框架，使用注解简化了xml配置，内置了Servlet容器，以Java应用程序进行执行。
2、SpringCloud是一系列框架的集合，可以包含SpringBoot。

SpringBoot使用了默认大于配置的理念，集成了快速开发的Spring多个插件，同时自动过滤不需要配置的多余的插件，简化了项目的开发配置流程，一定程度上取消xml配置，是一套快速配置开发的脚手架，能快速开发单个微服务；

SpringCloud大部分的功能插件都是基于SpringBoot去实现的，SpringCloud关注于全局的微服务整合和管理，将多个SpringBoot单体微服务进行整合以及管理；SpringCloud依赖于SpringBoot开发，而SpringBoot可以独立开发；

SpringBoot是微服务框架吗

1、SpringBoot只是一个快速开发框架，算不上微服务框架。

2、SpringCloud+SpringBoot 实现微服务开发。具体的来说是，SpringCloud具备微服务开发的核心技术：RPC远程调用技术；SpringBoot的web组件默认集成了SpringMVC，可以实现HTTP+JSON的轻量级传输，编写微服务接口，所以SpringCloud依赖SpringBoot框架实现微服务开发。

Springboot:
简介：
1.	简化spring应用开发的一个框架
2.	整个spring技术栈的一个大整合
3.	J2EE开发的一站式解决方案
优点：
1、	快速创建独立运行的spring项目以及主流框架集成
2、	使用嵌入式的Servlet容器，应用无需打成war包
3、	Starters自动依赖与版本控制
4、	大量的自动配置，简化开发，也可以修改默认值
5、	无需配置xml，无代码生成，开箱即用
6、	准生产环境的运行时应用监控
SpringBoot与Spring的区别：
Spring Boot可以建立独立的Spring应用程序；
1.	内嵌了Tomcat，Jetty等容器，直接热部署后就可以直接跑起来，不用再做部署工作了；
2.	无需配置一堆繁琐的xml文件；
3.	可以自动配置Spring。SpringBoot将原有的XML配置改为Java配置，将bean注入改为使用注解注入的方式(@Autowire)，并将多个xml、properties配置浓缩在一个appliaction.yml配置文件中。
4.	提供了一些现有的功能，如量度工具，表单数据验证以及一些外部配置这样的一些第三方功能；
5.	整合常用依赖（开发库，例如spring-webmvc、jackson-json、validation-api和tomcat等），提供的POM可以简化Maven的配置。当我们引入核心依赖时，SpringBoot会自引入其他依赖。

Springboot中的配置解释：
启动器：
spring-boot-starter;场景启动器：帮我们导入了web模块正常运行所依赖的组件

springBoot将所有的功能场景都抽取出来，做成一个个的starter(启动器),只需要在项目里面引入这个starter相关场景的所有依赖都会导入进来。要用什么功能就导入什么场景的启动器。

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
springboot自动配置的原理：
        在spring程序main方法中 添加@SpringBootApplication或者@EnableAutoConfiguration

会自动去maven中读取每个starter中的spring.factories文件  该文件里配置了所有需要被创建spring容器中的bean

Spring Boot视频学习记录

视频地址：https://www.bilibili.com/video/av38657363?p=1

Spring Boot介绍

利用springboot可以自动配置spring的各种组件，简化配置，同时提供了常见场景的推荐组件配置。其设计的目的是用来简化新spring应用的初始搭建以及开发过程，创建出独立运行和产品级别的基于spring框架的应用。该框架使用了特定的方式来配置，从而使开发人员不再需要定义样板化的配置。通过这种方式，大大提升使用spring框架时的开发效率。
Spring包含如下特性
1.可以将应用打包成独立可运行的JAR或WAR，使用java-jar命令来启动应用
2.内嵌Tomcat或者Jetty服务器，无需独立的应用服务器
3.提供基础的POM文件来简化Apache Maven配置
4.根据项目依赖自动配置
5.没有Java Config代码和XML配置文件

创建Spring Boot项目

1有两种方式：
1.1spring官网：http://start.Spring.io站点，在线生成压缩包下载解压导入STS后进行开发。
1.2直接使用STS创建Spring Boot项目

2.项目结构分析：
    .mvn目录是maven包装器，是一个小脚本，它能够确保其它人使用相同版本的maven来构建这个应用
    Src/main/java存放的是java源代码
    Src/main/resources存放的是应用配置，静态文件（css,js,图片）和模板文件（HTML模板）
    Src/test/java存放测试用例java代码
3.Spring Boot应用启动：
1.Springboot应用可以有多种启动方式来应对不同的使用场景：
1.1 main方法启动
1.2Run as Spring boot APP
1.3使用maven插件运行
1.4 java-jar命令启动
4.Spring Boot自动配置

微服务springCloud

详情传送门：https://blog.csdn.net/qq_35906921/article/details/84032874

互联网发展软件开发的三个阶段

单机版：把要做的所有应用程序放置在一个项目中，最后将之后的war或者jar部署在服务器上。这种模式随着发展终将会被淘汰是因为出现的问题将随之而来并发耦合等问题刻不容缓。
分布式：专业的事情交给专业的人去做，尽量降低耦合度，每个模块不受影响，一个模块你只做一件事。
微服务：微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个微服务，彻底去耦合，每个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看，就是一个小而独立的过程，类似于进程，能够自行单独启动和销毁，拥有自己的独立数据库。

微服务架构是一种架构模式，他提倡将单一应用程序拆分成一组服务，每个服务独立运行在自己的进程中，服务之间相互协调，相互配合，为用户提供最终价值。

对微服务的理解什么是服务熔断?

spring boot 是一个快速整合第三方框架关注的是微观具体关注快速方便的开发单个个体的服务

spring cloud 关注的是宏观具体关注全局的微服务协调整理治理框架将spring boot 开发的一个个单体服务整合并管理起来

它为各个微服务之间提供配置管理服务发现断路器路由微代理全局锁分布式会话等集成服务

服务熔断：指的是由于某些原因使得服务出现过载的现象，为了防止造成整个系统故障，采取的一种保护措施。因此也被称为过载保护。

什么是服务降级微服务的优缺点

服务降级：指的是整体资源不够时，忍痛将某些服务关掉，等度过难关，再将服务开启。

微服务优点：

微服务足够内聚，足够小，代码容易理解。能够聚焦一个指定的业务功能或业务需求。
开发简单，开发效率高，一个微服务专一的只干一件事。
微服务能够被小团队单独开发，这个小团队可以是2-5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是开发阶段或部署阶段都是独立的。
微服务能使用不同语言开发。
微服务易于被开发人员理解，修改和维护。这样小团队更能关注自己的工作成果，无需通过合作才能体现价值。
微服务允许你利用和融合最新技术。
微服务只是业务逻辑的代码，不会和Html、CSS或其他界面组件混合。
每个微服务可以有自己的存储能力，可以有自己的数据库，也可以统一数据库。

微服务缺点：

开发人员要处理分布式系统的复杂性。
多服务运维难度，随着服务的增加，运维的压力也增大。
系统部署依赖。
服务间通信成本。
数据一致性。
系统集成测试。
性能监控。

分布式、集群与微服务

理解：

分布式：多个人在一起做不同的事。
集群：多个人在一起做同样的事。

区别概述：分布式是指将不同的业务分布在多个服务器上。而集群指的是将几台服务器集中在一起，实现同一业务。

微服务：是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

简单的说，微服务是架构设计方式，分布式是系统部署方式

详情参考：传送门

🏛️ 服务架构发展脉络

1. MVC / 单体架构（Monolithic）

代表时期 ：早期互联网、传统企业信息化
特征：
MVC（三层架构：Controller、Service、DAO）
整个系统打成一个 WAR/JAR 部署，所有功能耦合在一起
优点：简单、开发快、部署方便
缺点：规模一大 → 维护困难、发布风险高（改一个模块要重启整个系统）

2. SOA（Service-Oriented Architecture，面向服务架构）

代表时期 ：大型企业系统集成、银行、电信
特征：
系统拆成“服务”（如账户服务、交易服务），通过 ESB（企业服务总线） 或 WebService 通信
有统一的服务注册、治理
优点：服务复用、跨系统集成能力强
缺点：
ESB 成为单点瓶颈
服务依赖 XML、SOAP 协议，臃肿笨重
不够灵活，难以应对互联网高并发

3. MSA（MicroService Architecture，微服务架构）

代表时期 ：移动互联网、云原生
特征：
系统进一步拆分为更小的“微服务”，每个微服务独立部署、独立数据库
通过 RESTful API / gRPC / MQ 通信
有服务注册发现、配置中心、链路追踪、容错限流等治理机制
优点：高可扩展、独立部署、适应敏捷迭代
缺点：分布式复杂度高（网络、数据一致性、运维要求）

🚀 发展趋势

单体 → SOA → 微服务 → 云原生（Kubernetes、Service Mesh）

微服务现在也在往 Serverless / Mesh 化 发展，比如 Istio、Knative，把服务治理抽象化，开发者更专注业务逻辑。

📌 一句话总结：

MVC 单体 = 小作坊（快，但不耐用）
SOA 服务化 = 工厂化生产（标准，但笨重）
MSA 微服务 = 智能工厂（灵活，但复杂）

消息队列

RocketMQ

它是阿里巴巴开源的一款非常优秀的 分布式消息中间件 ，后来捐赠给了 Apache 基金会，成为了顶级的开源项目，现在被广泛应用在公司的AFA5这类微服务架构中，来处理你之前提到的削峰填谷、异步解耦和发布订阅等场景。

主流消息队列中间件

主流消息队列中间件的核心特点与差异：

特性对比	RocketMQ	Kafka	RabbitMQ	ActiveMQ	Pulsar
主要特点	高吞吐、高可靠、金融级	超高吞吐、分布式流平台	高可靠性、灵活路由、低延迟	功能丰富、多协议支持	云原生、存算分离、多租户
单机吞吐量	10万级	10万级（极高）	万级	万级	100万+
典型应用场景	交易系统、订单处理、日志	实时日志、流处理、大数据领域	支付、订单管理、低延迟场景	传统企业应用、低并发系统	云原生环境、多租户场景
消息延迟	毫秒级	毫秒以内	微秒级	毫秒级	毫秒级
消息顺序	支持	分区内有序	支持	支持	支持
事务消息	支持	不支持（可通过其他方式模拟）	支持	支持	支持
协议支持	自定义协议	自定义协议	AMQP、MQTT、STOMP等多种协议	OpenWire, STOMP, AMQP等	自定义协议
开发语言	Java	Scala & Java	Erlang	Java	Java
优势	阿里系、经过双十一考验	生态丰富、吞吐量极高	灵活的路由、高可靠性、低延迟	协议支持全面	计算存储分离、扩展性极佳、支持百万级Topic
缺点	社区相对Kafka较小	运维复杂、消息顺序仅保证在分区内	吞吐量相对较低、Erlang学习曲线稍陡	吞吐量和性能相对较低	相对较新，社区和生态仍在发展中

🧐 如何选择消息队列

选择哪款消息队列并没有绝对的答案，关键在于匹配你的业务场景和技术需求：

金融、电商等对事务一致性要求极高的场景：RocketMQ 是很好的选择，它源自阿里，经历了双十一的严苛考验。
大数据、日志采集、实时流处理（如用户行为分析、监控数据）：Kafka 几乎是业界标配，其超高的吞吐量和丰富的生态（与 Flink、Spark 等集成）非常适合这类场景。
对消息可靠性、复杂路由有较高要求的业务系统（如支付、订单）：RabbitMQ 凭借其灵活的交换机和路由规则、丰富的特性（如消息确认、持久化），以及微秒级的延迟，在这些场景中表现出色。
传统企业应用、需要支持多种协议集成：ActiveMQ 是一个成熟的选择，但其在吞吐量和性能上相对较弱。
云原生环境、需要极强扩展性和多租户支持：可以关注 Pulsar，其存算分离的架构设计使其在扩展性方面具有独特优势。

许多大型公司并不会只采用一种消息队列，而是会根据不同的业务线和技术需求，组建包含多种消息队列的“混合舰队”。例如，核心交易用 RocketMQ，日志收集用 Kafka，业务通知用 RabbitMQ。

k8s集群与vm集群

“租毛坯房” vs “租精装公寓”

VM集群（租毛坯房）：
- 你租下了一整套完整的毛坯房（VM）。你需要自己装修（安装操作系统）、通水电煤气（配置环境）、买家具家电（部署运行时依赖），最后才能入住（部署应用）。
- 每个毛坯房都是完全独立的，有一套完整的基础设施。
K8s集群（租精装公寓）：
- 你租的是一套精装公寓（Pod），家具家电齐全，拎包即可入住（只需提供应用本身）。
- 公寓大楼（K8s集群）由统一的物业（K8s Master）管理，负责安保、维修、扩容（调度、运维、自愈）。
- 你不需要关心水管怎么接、电线怎么走，物业都搞定了。

详细对比

为了更直观地展示两者的核心区别，请看下表：

特性	VM 集群 (传统方式)	K8s 集群 (云原生方式)
虚拟化对象	硬件资源	操作系统
核心单元	虚拟机 (VM)	容器 (Container) / Pod
隔离级别	完全隔离（每个VM有独立OS内核）	进程级别隔离（所有容器共享主机OS内核）
启动速度	慢（分钟级，需启动完整OS）	极快（秒级，只需启动进程）
资源消耗	重（每个VM需占用完整OS的开销）	轻（几乎无额外开销，共享OS内核）
部署单位	整个应用和环境打包成VM镜像	应用本身打包成容器镜像
伸缩性	慢，需要创建新的VM	快速弹性伸缩（秒级扩缩容Pod实例数）
高可用/自愈	通常需要额外软件和复杂配置	内置（自动重启失败的容器、调度到健康节点）
发布与回滚	复杂，可能需要蓝绿部署	原生支持（滚动更新、一键回滚）
典型管理工具	OpenStack, vSphere, 自定义脚本	Kubernetes (K8s) 本身
适用场景	传统应用、需要强隔离的应用、对OS有特殊需求	微服务、云原生应用、CI/CD、快速迭代的业务

工作流程对比

在VM集群中部署一个服务：

申请VM资源：从VM池中申请一台虚拟机（CPU、内存、磁盘）。
初始化环境：在VM中安装操作系统、配置网络、安装运行时（如JDK、Tomcat）。
部署应用：上传应用包（如WAR/JAR），配置启动脚本。
服务上线：启动应用，配置负载均衡，将流量引入此VM。
扩缩容：需要扩容时，重复以上所有步骤，非常缓慢。

在K8s集群中部署一个服务：

制作镜像：将应用及其所有依赖打包成一个Docker镜像（一次构建，随处运行）。
定义配置：编写一个YAML文件，告诉K8s：“请帮我运行这个镜像的3个实例，端口是8080，CPU给1核，内存给2G。”
部署：执行 kubectl apply -f your-config.yaml。
自动完成：K8s会自动在集群中找到有资源的节点，拉取镜像，启动容器（Pod），并挂载负载均衡。
扩缩容：修改YAML文件中的副本数（replicas）从3到5，再次执行 apply命令，K8s会自动秒级扩容2个新实例。

为什么现代企业更倾向于K8s

虽然VM提供了最强的隔离性，但K8s在效率、敏捷性和运维成本上具有压倒性优势，尤其适合微服务架构：

极高的资源利用率：容器几乎无额外开销，可以在同样硬件上运行比VM多出数倍的服务实例。
** DevOps 与 CI/CD：容器镜像是不可变的，实现了开发、测试、生产环境的绝对一致**，打通了CI/CD的最后一公里。
天生的微服务伴侣：微服务强调快速迭代、独立部署、弹性伸缩，K8s的每一项特性都为此而生。
声明式API与自动化：你只需要“声明”你想要的状态（如“我要5个实例”），K8s会自动地、持续地调整当前状态以达到目标状态。运维实现了自动化。

总结与关系

不是取代，而是演进：K8s并不是要完全取代VM。实际上，K8s集群本身通常就运行在VM集群或物理机之上。它们是不同层次的抽象。
分工明确：
- VM/IaaS层：负责提供稳定、可靠、安全的计算资源（CPU、内存、网络、存储）。
- K8s/PaaS层：负责在计算资源之上高效、智能、自动化地调度和管理应用。

可以理解为：K8s是新一代的“应用操作系统”，它管理的是应用的生命周期；而VM是传统的“机器操作系统”，它管理的是一台虚拟的电脑。采用K8s意味着能够以更高的效率和更低的成本来管理成千上万个微服务。

企业常见的文件格式

.properties（prop）

格式：key=value 的简单键值对。
特征：轻量、简单，主要存储字符串型配置。
典型场景 ：
Java 传统配置文件（Spring 早期用 application.properties）
国际化资源（messages_zh_CN.properties）
优点：简洁，易读，和 Java Properties 类天然兼容。
缺点：只能表达平面结构，层次化数据不好处理。

.yaml（YAML Ain’t Markup Language）

格式：缩进层级表示结构（类似 Python 语法风格）。
特征：比 .properties 更强大，可以表达复杂的层级数据。
典型场景 ：
Spring Boot 配置文件（application.yml / application.yaml）
Kubernetes 配置文件（部署清单、服务定义）
优点：语法直观、可读性高、天然支持嵌套结构。
缺点：缩进敏感，容易因为空格出错。

.json（JavaScript Object Notation）

格式：基于 {} 和 [] 的对象表示。
特征：轻量数据交换格式，跨语言支持最好。
典型场景 ：
前后端交互（REST API 响应/请求体）
配置文件（如 VSCode、前端项目配置 package.json）
数据持久化（如 MongoDB 文档存储）
优点：语言无关、解析库丰富、标准化。
缺点：可读性比 YAML 稍差，不支持注释。

.xml（eXtensible Markup Language）

格式：基于标签（<tag>）的结构化表示。
特征：层级关系清晰，支持复杂 schema 定义。
典型场景 ：
Java EE 时代配置（web.xml、Spring XML 配置）
银行/政企系统报文交换（ISO20022、SOAP 协议）
配置管理（Maven 的 pom.xml）
优点：表达能力强，可定义约束（XSD/DTD）。
缺点：冗长、开发效率低、读写繁琐。

📌 关联与对比

格式	表达能力	可读性	常见场景	现状趋势
`.properties`	简单键值对	高	Java 早期配置、国际化	渐渐被 YAML 取代
`.yaml`	强（支持层级、集合）	高	Spring Boot、K8s	🔥 主流配置文件
`.json`	强（跨语言标准）	中	前后端交互、NoSQL	🔥 数据交换主流
`.xml`	很强（支持约束）	低	Maven、SOAP、老系统	逐渐被 JSON/YAML 替代

✨ 一句话总结 ：

配置领域 → .properties → .yaml
数据交换领域 → .xml → .json
趋势 → 企业新系统偏爱 YAML + JSON，老系统还大量依赖 XML 。

`application.yaml` 文件

application.yaml（或 application.properties）是 Spring Boot 项目的“心脏”和“控制中心”，几乎所有需要根据环境变化的配置信息都在这里集中管理。它最大的价值在于：实现了“配置”与“代码”的分离。修改配置（比如切换数据库、改变端口）不再需要重新编译和打包代码，只需修改这个文件即可。

它通常配置哪些信息

application.yaml 文件里的配置可以说是“包罗万象”，但主要可以分为以下几大类：

配置类别	作用	典型示例
服务器配置	配置内嵌Web容器的行为	端口号、上下文路径、连接超时时间
数据源配置	连接数据库	数据库URL、用户名、密码、连接池设置
框架特定配置	调整Spring或第三方库的行为	MyBatis的mapper路径、日志级别、MVC视图解析
应用自定义配置	定义自己业务所需的参数	文件上传路径、短信服务的密钥、开关功能标志
Profile配置	区分不同环境的配置	开发、测试、生产环境使用不同的数据库

各类配置详解与示例

服务器配置 (Server Settings)

server:
  port: 8088 # 修改内嵌Tomcat端口为8088，默认是8080
  servlet:
    context-path: /api # 为所有API地址添加统一的前缀 `/api`。
                        # 例如，原来的 `/users` 会变成 `/api/users`
  tomcat:
    connection-timeout: 5000 # 连接超时时间（毫秒）

数据源配置 (Data Source Configuration)

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/afa5_db?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai
    username: root
    password: your_password_here
    driver-class-name: com.mysql.cj.jdbc.Driver # 数据库驱动
    hikari: # HikariCP是Spring Boot默认的数据库连接池，性能非常好
      maximum-pool-size: 10 # 连接池最大连接数
      minimum-idle: 5       # 连接池最小空闲连接数

框架特定配置 (Framework Configuration)

a. MyBatis-Plus 配置：

mybatis-plus:
  mapper-locations: classpath*:mapper/**/*.xml  # 告诉MyBatis去哪找SQL映射文件(XML)
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 在控制台打印SQL语句，调试神器

b. 日志配置：

logging:
  level:
    com.example.afa5: debug # 将你公司项目包的日志级别设置为DEBUG，便于调试
    org.springframework.web: info # 将Spring Web的日志级别设置为INFO，减少噪音
  file:
    name: logs/application.log # 将日志输出到项目根目录下的 logs/application.log 文件

应用自定义配置 (Custom Configuration)

你可以定义任何你需要的参数，然后在代码中通过 @Value 注解注入。

# 自定义配置项
afa5:
  system:
    upload-path: /opt/afa5/uploads # 文件上传路径
    sms:
      access-key: YOUR_ACCESS_KEY # 短信服务的密钥
      secret-key: YOUR_SECRET_KEY
    feature:
      enable-cache: true # 一个功能开关，是否启用缓存

在Java代码中这样使用：

@RestController
public class FileController {
  
    @Value("${afa5.system.upload-path}") // 使用 ${} 语法注入配置值
    private String uploadPath;
  
    @PostMapping("/upload")
    public void upload(MultipartFile file) {
        // 使用配置的路径
        File dest = new File(uploadPath + "/" + file.getOriginalFilename());
        file.transferTo(dest);
    }
}

多环境配置 (Profile-specific Configuration)

这是 application.yaml 最强大的功能之一。你可以为不同环境（开发、测试、生产）创建不同的配置文件。

主配置文件：application.yaml（存放所有环境的公共配置）
环境配置文件：application-{profile}.yaml（存放特定环境的配置）

示例：

application-dev.yaml (开发环境)

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/afa5_dev # 开发库
logging:
  level: debug # 开发环境开启debug日志

application-prod.yaml (生产环境)

spring:
  datasource:
    url: jdbc:mysql://192.168.1.100:3306/afa5_prod # 生产库
    password: very_strong_production_password # 生产环境的强密码
logging:
  level: info # 生产环境使用info日志，减少IO消耗

如何激活环境？
在主配置文件 application.yaml 中指定，或者通过启动命令参数指定。

# 在 application.yaml 中指定默认使用开发环境
spring:
  profiles:
    active: dev

1 2	# 或者在启动Jar包时，通过命令行参数指定，这会覆盖文件中的配置 java -jar your-app.jar --spring.profiles.active=prod

总结

application.yaml 文件是 Spring Boot 项目的配置大全，主要负责：

基础服务配置：如端口、路径。
数据源与集成：如数据库、缓存连接。
框架行为调优：如MyBatis、日志。
业务参数管理：如各种密钥、路径、开关。
环境隔离：通过Profile轻松切换开发、测试、生产环境。

它的存在使得应用程序的部署和运维变得极其灵活和简单，是Spring Boot“约定大于配置”理念的完美体现。

文章作者: PanXiaoKang

文章链接: http://example.com/2020/05/02/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%A1%86%E6%9E%B6/

Springboot SpringCloud

打赏

微信
支付宝