《Spring源码解析（一）》Spring框架的前世今生以及对Spring的宏观认识
通过对本章内容的学习，你将得到：
1、掌握 Spring 的基本架构及各子模块之间的依赖关系。
2、了解 Spirng 的发展历史，启发思维。
3、对 Spring 形成一个整体的认识，为之后的深入学习做铺垫。
4、了解 Spring 版本升级的规律，从而应用到自己的系统升级版本命名
Spring 的设计初衷
BOP 编程伊始
Spring 是面向 Bean 的编程（Bean Oriented Programming, BOP），Bean 在 Spring 中才是真正的主角。Bean 在 Spring 中作用就像 Object 对 OOP 的意义一样，Spring 中没有 Bean 也就没有 Spring存在的意义。
Spring 提供了 IOC 容器通过配置文件或者注解的方式来管理对象之间的依赖关系。
控制反转(其中最常见的实现方式叫做依赖注入（Dependency Injection，DI），还有一种方式叫“依赖查找”（Dependency Lookup，DL），她在 C++、Java、PHP 以及.NET 中都运用。
在最早的Spring 中是包含有依赖注入方法和依赖查询的，但因为依赖查询使用频率过低，不久就被 Spring 移除 了，所以在 Spring 中控制反转也被直接称作依赖注入)，她的基本概念是：不创建对象，但是描述创建 它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。
容器 （在 Spring 框架中是 IOC 容器）负责将这些联系在一起。
在典型的 IOC 场景中，容器创建了所有对象，并设置必要的属性将它们连接在一起，决定什么时间调用方法。
依赖注入的基本概念
BeanFactory 最底层支持两个对象模型。
AOP 编程理念
Spring5 系统架构
Spring 总共大约有 20 个模块，由 1300 多个不同的文件构成。而这些组件被分别整合在核心容器（Core Container）、AOP（Aspect Oriented Programming）和设备支持（Instrmentation）、数据访问及集成（Data Access/Integeration）、Web、报文发送（Messaging）、Test，6 个模块集合中。
以下是 Spring 5 的模块结构图：
组成 Spring 框架的每个模块集合或者模块都可以单独存在，也可以一个或多个模块联合实现。每个模块的组成和功能如下：
核心容器
由spring-beans、spring-core、spring-context和spring-expression（Spring Expression Language, SpEL） 4 个模块组成。
spring-core 和 spring-beans 模块是 Spring 框架的核心模块，包含了控制反转（Inversion of Control, IOC）和依赖注入（Dependency Injection, DI）。
BeanFactory 接口是 Spring 框架中的核心接口，它是工厂模式的具体实现。BeanFactory 使用控制反转对应用程序的配置和依赖性规范与实际的应用程序代码进行了分离。但BeanFactory 容器实例化后并不会自动实例化 Bean，只有当 Bean 被使用时 BeanFactory 容器才会对该 Bean 进行实例化与依赖关系的装配。
spring-context 模块构架于核心模块之上，他扩展了 BeanFactory，为她添加了 Bean 生命周期控制、框架事件体系以及资源加载透明化等功能。
此外该模块还提供了许多企业级支持，如邮件访问、远程访问、任务调度等ApplicationContext 是该模块的核心接口，她的超类是 BeanFactory。
与BeanFactory 不同，ApplicationContext 容器实例化后会自动对所有的单实例 Bean 进行实例化与依赖关系的装配，使之处于待用状态。
spring-context-support 模块是对 Spring IOC 容器的扩展支持，以及 IOC 子容器。
spring-context-indexer 模块是 Spring 的类管理组件和 Classpath 扫描。
spring-expression 模块是统一表达式语言（EL）的扩展模块，可以查询、管理运行中的对象，同时也方便的可以调用对象方法、操作数组、集合等。
它的语法类似于传统 EL，但提供了额外的功能，最出色的要数函数调用和简单字符串的模板函数。这种语言的特性是基于 Spring 产品的需求而设计，他可以非常方便地同 Spring IOC 进行交互。
AOP 和设备支持
数据访问与集成
Web 组件
通信报文
集成测试
集成兼容
各模块之间的依赖关系
Spring 官网对 Spring5 各模块之间的关系也做了详细说明：
我本人也对 Spring5 各模块做了一次系统的总结，描述模块之间的依赖关系，希望能对小伙伴们有所帮助。
接下来的《深入Spring5源码系列》中，我们将深入了解 Spring 的核心模块功能。
基本学习顺序为：从 spring-core 入手， 其次是 spring-beans 和 spring-aop，随后是 spring-context，再其次是 spring-tx 和 spring-orm， 最后是 spring-web 和其他部分。
Spring 版本命名规则
常见软件的版本号命名
从上可以看出，不同的软件版本号风格各异，随着系统的规模越大，依赖的软件越多，如果这些软件没有遵循一套规范的命名风格，容易造成 Dependency Hell。
所以当我们发布版本时，版本号的命名需要遵循某种规则，其中 Semantic Versioning 2.0.0 定义了一套简单的规则及条件来约束版本号的配置 和增长。
本文根据 Semantic Versionning 2.0.0 和 Semantic Versioning 3.0.0 选择性的整理出版本 号命名规则指南。
语义化版本命名通行规则
该规则对版本的迭代顺序命名做了很好的规范，其版本号的格式为 X.Y.Z(又称Major.Minor.Patch)，
递增的规则为：
详细的使用规则如下：
X, Y, Z 必须为非负整数，且不得包含前导零，必须按数值递增，如 1.9.0 -> 1.10.0 -> 1.11.0 0.Y.Z 的版本号表明软件处于初始开发阶段，意味着 API 可能不稳定；1.0.0 表明版本已有稳定的API。
当 API 的兼容性变化时，X 必须递增，Y 和 Z 同时设置为 0；当新增功能(不影响 API 的兼容 性)或者 API 被标记为 Deprecated 时，Y 必须递增，同时 Z 设置为 0；当进行 bug fix 时，Z 必须递增。
先行版本号(Pre-release)意味该版本不稳定，可能存在兼容性问题，其格式为：X.Y.Z.[a-c][正整数]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。
开发版本号常用于 CI-CD，格式为 X.Y.Z.dev[正整数]，如 1.0.1.dev4。
版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如 1.0.0 < 1.0.1 < 1.1.1 <2.0.0；对于先行版本号和开发版本号，有：1.0.0.a100 < 1.0.0，2.1.0.dev3 < 2.1.0；当存在字母时， 以 ASCII 的排序来比较，如 1.0.0.a1 < 1.0.0.b1。
注意：版本一经发布，不得修改其内容，任何修改必须在新版本发布！
软件版本号使用限定
为了方便理解,版本限定的语法简述为为 [范围描述]<版本号描述> 范围描述可选,必须配和版本描述确定范围,无法独立存在
< 小于某一版本号
<= 小于等于某一版本号
> 大于某一版本号
>= 大于等于某一版本号
= 等于某一版本号,没有意义和直接写该版本号一样
~ 基于版本号描述的最新补丁版本
^ 基于版本号描述的最新兼容版本
- 某个范围,他应该出现在两个版本描述中间,实际上语法应为 <版本描述>-<版本描述>,写在此处为了统一。
严格来讲对 ~,^ 的表述需要结合具体的包管理工具和版本号规则来确定.但是对于一般使用记住如下原则：
^ 是确保版本兼容性时,默认对次版本号的限定约束
~ 是确保版本兼容性时,默认对补丁号的约束
Spring 版本命名规则
扫码关注公众号，精彩万元VIP视频免费获取！！
长按二维码识别