为什么spring框架会出现？
为什么spring系列的框架成为后端开发的标准范式？
为什么许多后端开发并没有感觉到spring有何高明之处？
这篇文章来讲述spring是如何闯入并霸占我们的开发工作的。
框架的历史
要知道框架的思想，最好的路径就是顺一遍通用工程框架的历史发展，是如何从野蛮时期，到现在稳定统一的框架的。
第一时代：无框架，原生servlet+jsp
jsp和servlet，除了早期学习java的时候听过，工作之后基本少有见过这两个词了。
但是servlet的确是java web的根基，就算是如今，也是这一套架构。而jsp已经早早被扔进历史的垃圾堆了。
这个时期，没有业务与框架之分，所有的代码都是直接在一团，各种硬编码的new，依赖都塞在一起，没有什么模块化的美感，对象创建、依赖查找、生命周期：全由业务类自己管。写好了servelt，就扔到服务器。
本质是对象的控制权在业务代码手里。
问题：业务代码与对象管理强耦合，不仅不利于代码阅读，修改代码也是灾难级别，更别说重复写许多同质化的代码了
第二时代： 好莱坞原则出现，IOC 控制反转思想
好莱坞原则：时髦的说法是 Don't call me, I'll call you.不要联系我，我会找你的。在工程里的说法就是高层可以调用低层，而低层只管实现业务逻辑，不要试图去寻找，或者new，甚至是调用高层。
之所以提出这个原则，是因为第一时代的手写new，和依赖。导致了各个对象都有错综复杂的依赖关系，以及调用关系，在理解上非常的不流畅。而且一旦修改依赖和逻辑，那么就非常灾难。
而谁都可以调用其他的依赖，带来的是执行顺序的完全混乱。
这样的特性，在工程分层解耦上体现了巨大的困难，根据这些问题，提出了好莱坞原则来缓解。
工程中的业务分为高层和低层。低层不要试图去创建，寻找，调用高层。将业务逻辑顺当地梳理为高层->低层1->低层2
这样一来，业务逻辑分层解耦，工程就好看得多，也方便维护。
IOC控制反转思想：基于好莱坞原则，如果是第一时代的做法，依赖关系和创建对象都由用户负责，那么肯定免不了依赖混乱问题。那么不如写一个专门的对象，用于管理对象的创建，依赖。把对象的管理，从业务代码中解耦出去。这个专门的对象现在我们叫做容器，具体点可以说是你创建项目时第一个写的ApplicationContext。
这样一来，大家都不需要new来new去，或者依赖来依赖去，想要谁的帮助，让容器给你拿来即可。
于是乎，框架开始出现了，对象管理这些功能，开始从业务代码解耦出去。
第三时代：EJB时代
完全贴合好莱坞原则+IOC的主流框架来了，它叫做EJB。
它已经开始用容器来管理对象。然而，没多久就落寞了。
EJB衰落的原因很典型：它太重，侵入性太小强。
如果要使用EJB，那么必须符合一系列的接口定义。代码侵入性极强，如果要修改，那么成本巨大。
并且实现非常复杂，实现一个功能，要符合多个接口的要求。更别说测试困难和配置地狱的问题。
第四时代：spring来了
经历过EJB的教训，spring在容器化的基础之上，改进了EJB的侵入性和复杂程度。
代码层面，普通的bean不需要一系列的接口实现，就可以注册为bean。
配置层面，早期有一些xml（但是比EJB少很多了），后来更是用注解的方式进一步降低配置地狱的难题。
调用流程方面，EJB是JNDI→找 Home 工厂→创建 Bean→调用，步骤巨多。而spring只需要Autowired一步注入。
除了优化EJB的问题，spring还带来了实用的一系列新功能，AOP、灵活事务管理、整合三方中间件、事件发布机制、国际化等等。
第五时代：springboot
在spring之上的又一步升级，极大简化了开发步骤。核心思想是约定大于配置。
自动配置：预制好了一大批常用的工具，只需要引入依赖，那么框架就会自动走流程，创建对应的bean，放到容器管理。而那些服务需要的参数，已经根据行业的最佳实践预设好了，你甚至直接两行启动代码，就能开启一个服务。
内嵌容器：以前还需要打包，扔到tomcat部署一下，现在tomcat都一键引入工程了，表面看起来就是一个jar包，直接启动。
起步依赖starter：这个依赖包关注的是一个场景，它里面已经包含了所有需要的包，只用引入一个，那么就够了，甚至免去了版本冲突问题。
总结
我们发现，很多人就算零计算机基础，也能用几个月开始写后端服务。其中一个巨大的原因，是开发框架封装度已经太高了，隐去了底层细节，甚至连配置都预设好了，留给我们的，很多时候是业务本身。这也是为什么很多人都说自己干了几年还是crud，技术没什么长进，这都是因为前人踩完的坑，给我们留下的财富，而非后端本身是个低门槛的职业。我们觉得简单，是因为前人已经搭好了台阶。
