微服务框架

SpringBoot和SpringCloud简介

简要概述

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

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

什么是微服务

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

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

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

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

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

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

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

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

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

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

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

微服务优点：

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

微服务缺点：

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

分布式、集群与微服务

理解：

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

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

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

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

详情参考：传送门

🏛️ 服务架构发展脉络

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 微服务 = 智能工厂（灵活，但复杂）

企业常见的文件格式

.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 。

---