超详细spring boot笔记

1. 微服务架构

Spring 和 Springboot均属于微服务架构，这里有必要先对微服务进行说明。

1.1 传统单体架构应用体系

（一）单体架构体系介绍
在很多项目的业务初期阶段，高速迭代上线是首要考虑的事情，对后期的容量预估、可扩展性和系统健壮性、高可用一般没有那么重视。
随着业务的发展，用户量、请求量的暴增，发现原来的 单体系统 已经远远不满足需求了，特别是随着互联网整体的高速发展，对系统的要求越来越高。
但是物理服务器的CPU、内存、存储器、连接数等资源有限，单体系统能够承受的的QPS也是有限的。
某个时段大量连接同时执行操作，会导致web服务和数据库服务在处理上遇到性能瓶颈。

为了解决这个问题， 分而治之 的思想被提出。该思想对大数据库、大表进行分割，以便实施更好的控制和管理。
同时创建多个服务实例，使用多台服务机进行CPU、内存、存储的分摊，提供更好的性能。

（二）单体系统存在的问题

• 复杂性高（强耦合）：由于是一个单体的系统，所以整个系统的模块是耦合在一起的，模块的边界比较模糊、依赖关系错综复杂。功能的调整，容易带来不可知的影响和潜在的bug风险。
• 服务性能问题：单体系统遇到性能瓶颈问题，只能 横向扩展 ，增加服务实例，进行负载均衡分担压力。无法纵向扩展，做模块拆分。
• 扩缩容能力受限：单体应用只能作为一个整体进行扩展，影响范围大，无法根据业务模块的需要进行单个模块的伸缩。
• 无法做故障隔离：当所有的业务功能模块都聚集在一个程序集当中，如果其中的某一个小的功能模块出现问题（如某个请求堵塞），那么都有可能会造成整个系统的崩溃。
• 发布的影响范围较大：每次发布都是整个系统进行发布，发布会导致整个系统的重启，对于大型的综合系统挑战比较大，如果将各个模块拆分，哪个部分做了修改，只发布哪个部分所在的模块即可。

（三）单体系统的优点

• 系统的简易性：系统语言风格、业务结构，接口格式均具有一致性，服务都是耦合在一起的，不存在各个业务通信问题。
• 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，简化了测试过程，无需额外测试服务间的依赖，测试均可在部署完成后开始。
• 易于部署与升级：相对于微服务架构中的每个服务独立部署，单体系统只需将单个目录下的 服务程序统一部署和升级 。
• 较低的维护成本：只需维护单个系统即可。运维主要包括配置、部署、监控与告警和日志收集四大方面。相对于单体系统，微服务架构中的每个服务都需要独立地配置、部署、监控和日志收集，成本呈指数级增长。

1.2 微服务架构的基本信息

（一）微服务的定义：
微服务是一种架构模式，是面向服务的体系结构（SOA）软件架构模式的一种演变。
它提倡将单一应用程序划分成一组 松散耦合的细粒度小型服务 ，辅助轻量级的协议 ，互相协调、互相配合，为用户提供最终价值。
所以，微服务（或微服务架构）是一种云原生架构方法，其中 **单个应用程序 由许多 松散耦合 且可 独立部署 的 较小组件或服务组成 **。
这些服务通常包含如下特点：

• 单一职责
  微服务架构中的每个节点高度服务化，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，包括数据库和数据模型；
  不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。

• 轻量级通信
  通过REST API模式或者RPC框架，实现服务间互相协作的轻量级通信机制。

• 独立性
  在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试、部署、运维。

• 进程隔离
  在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上，实现高度自治和高度隔离。
  进程的隔离，还能保证服务达到动态扩缩容的能力，业务高峰期自动增加服务资源以提升并发能力，业务低谷期则可自动释放服务资源以节省开销。

• 混合技术栈和混合部署方式
  团队可以为不同的服务组件使用不同的技术栈和不同的部署方式（公有云、私有云、混合云）。

• 简化治理
  组件可以彼此独立地进行扩缩容和治理，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。

• 安全可靠，可维护。
  从架构上对运维提供友好的支撑，在安全、可维护的基础上规范化发布流程，支持数据存储容灾、业务模块隔离、访问权限控制、编码安全检测等

（二）两种架构方式的对比：

1. all in one的架构方式：即在微服务出来之前，将所有的功能单元部署在一个应用里面，然后将整个应用部署在服务器上。
   如果应用负载能力不足，则将整个应用进行水平复制拓展，再均衡负载。
2. 微服务架构：打破之前的all in one架构，把每个功能单元独立出来，再做功能单元的动态组合。
   若应用负载能力不足，则增加对应的功能单元，其余单元数量保持不变。

（三）微服务架构的特点与优点

• 特点：最小单元是功能模块（单元），而all in one的最小单元是应用。
• 这个特点可以理解为装配式的模块化开发。
• 每个功能元素的服务都是一个 可替换/可独立升级 的软件代码。这代表可以在不关闭服务的情况下对部分功能区进行升级/修改。
• 实现了 高内聚，低耦合（即专业化程度高，且模块之间耦合小，靠接口连接）。节省了调用资源。

1.3 微服务架构演变史

1.3.1 第一阶段：简单通讯模块

• 这是最初的模样，开发人员最开始的时候想象的两个服务间简单的通信模式，抽象表示如下，两个服务之间直接进行通信：
• 该阶段的实际运用存在很多问题。

  

1.3.2 第二阶段：原始通信时代

• 上面的原始通讯方式非常简单，但实际情况远比想象的复杂很多。通信需要底层字节码传输和电子信号的物理层来完成。
  在TCP协议