Java入门系列-后端前世今生（-2019）

静态时代（原始时代）

这个时代需要求很简单，希望输入一个网址（URL），服务端可返回指定页面：

静态页面（指同一页面，每个网民在某段时间内看到的内容是相同）时代，web服务端编程复杂度低，业务处理模块相对较简单：想办法根据请求地址(url)找到对于的Html即可

动态时代

随着web用户量暴增，用户希望和服务端有更多交互（动态页面），如注册，登录，留言，发个交友信息等等。业务处理模块就复杂很多，不止存取html数据，还需存取数据库数据；返回浏览器的数据需根据每次请求不同，组装成不同的网页内容。为提高开发效率，业界做了2件事情：

1. 设计动态web端语言（注：html是静态web语言），更容易编写动态页面数据，如：asp，php等

2. 提供通用的网络处理模块，并提供可以解析动态web语言的环境。此时，业界有人将这提供这两个功能的模块合起叫web容器。如IIS，Apache等。为简单起见，如下示意图未把asp/php解析器部分画出了。

asp和php语言设计初衷是快速开发动态web服务端，因此采用的思路是将语言是嵌入html页面的（如下<?php和?>之间是是动态部分），此类设计的优点是简单快速，缺点是展示内容和业务逻辑揉在一起，而展示和业务逻辑处理一般是多个工种（页面设计者及后端码农）的同事一起完成，当展示和业务逻辑非常复杂时，维护起来就很困难。

Servlet时代（Java web）

Servlet是服务端(Server)小程序(Applet)的意思，可以理解为实现某些接口的类。Servlet可以简单对应到上面的业务处理模块。Servlet规范定义了一些标准接口，Java程序猿只需要实现这些接口即可。

而网络处理、Servlet调用和维护等事情，Java也定义了一套规范，按照这套规范实现的软件，叫Servlet容器，大家也叫web容器，其中优秀成员有：tomcat，jetty，jboss等。规范中要求容器有一个配置文件，叫web.xml，里面可配置哪个url请求对交给哪个Servlet处理

看到上面代码，你就知道java程序猿只开心了一秒钟，虽然php是业务逻辑嵌入展示内容，但上面代码也半斤八两，展示内容嵌入业务逻辑代码。

Servlet时代（JSP）

Java官方当然不会这么傻，用了一招解决此问题，就是设计一个专门用于展示动态页面的Servlet（解决思路如此简单，小白你肯定也能想到），这个Servlet有个别名，叫JSP。JSP被设计成PHP/ASP，在HTML页面内嵌入少量Java代码以支持动态网页内容，而业务逻辑处理部分，最好也设计成和网络无关的，于是Java学霸用JavaBean（也叫Plain Old Java Object (POJO) ）处理业务逻辑部分，于是架构变成这样：

这就是有名的JSP Model 1架构（即页面驱动方式）。在该架构中JSP负责3重要件事：

 

1）动态页面展示

 

2）路由请求到具体的JavaBean并对其发起调用

 

3）解析JavaBean返回的数据，并跳转到相应的页面。

Model1开发模式

Model1的开发模式是：JSP+JavaBean的模式，它的核心是Jsp页面，在这个页面中，Jsp页面负责整合页面和JavaBean（业务逻辑），而且渲染页面，它的基本流程如下：

Model2开发模式

Model2的开发模式是：Jsp+Servlet+JavaBean的模式，它和Model1不同的是，增加了Servlet，将调用页面数据，调用业务逻辑等工作放到了Servlet中处理，从而减轻了Jsp的工作负担！它的基本流程如下：

Model2 问题

1.控制器的逻辑可能比较复杂：每个模块基本需要一个控制器，如登录模块对接LoginServlet，新增用户模块对AddUserServlet等；

2.请求参数到模型的封装比较麻烦：http协议传输都是文本形式，到Servlet后需要手工将它们转到一个有不同类型的javabean(如上篇练习题的AccountBean)，繁琐且无技术含量;

3.视图的选择严重依赖于Servlet API：如resp.sendRedirect("success.jsp"), 很难更换视图，比如我要支持Excel、PDF视图等等;

4.给视图传入用于展示的模型数据也依赖于Servlet API.

Spring MVC解决问题

1.控制器过于复杂问题：那就将其分为多个子控制器呗，各负责一部分控制逻辑

2.请求参数转成模型麻烦：那就单独设计一个模块，专门将http文本型参数转为javabean内部属性对应的类型，暂叫DataBinder

3.控制和视图强耦合问题：那就让这两者用一个通用的数据结构进行交互，比如用字符串来表示一个视图逻辑名，用jsp还是其他视图模板，控制器不关心，而是由一个单独的模块处理，暂叫它ViewResolver。ViewResolver根据视图逻辑名找到相应具体视图模板并结合模型数据进行解析。如控制器给视图模块传“success”字符串，ViewResolver根据配置及工程目录下文件名，找到success.jsp，并用jsp视图解析器解析success.jsp此模板。

Spring MVC架构图

上图只有橙色需自己实现，其他组件框架都实现好了

为什么要有Spring

可以看出，每一个方法中都需要进行实例化我们需要用到的接口的实现类，这就会存在大量的实例化对象，并且他们的生命周期可能就是从方法的调用开始到方法的调用结束为止，加大了GC回收的压力！

单利模式

可以看出，这种方式有两个问题：

 

（1）业务代码与单利模式的模板代码放在一个类里，耦合性较高； 

（2）大量重复的单利模式的模板代码；

 

从上述可以看出，使用的单利模式虽然从性能上有所提高，但是却加重了我们的开发成本。因此只会小规模的使用，例如我们操作JDBC的Utils对象等。

Spring 容器

IoC（控制反转，英文含义：Inverse of Control）是Spring容器的内核，AOP、事务等功能都是建立在此基础上的。从字面意思上可以把IoC拆分为两层含义：控制和反转。控制可以理解为是接口实现类的选择权，反转可以理解为这个选择权交给第三方进行管理；总的来说就是某一接口具体实现类的选择控制权从调用类中移除，转交给第三方进行决定，即由Spring容器通过Bean配置来进行控制，这样的话应用程序本身就不用负责依赖对象的创建和维护，而由Spring容器进行管理。

依赖注入的概念和控制反转的概念从本质上是一样的，只是从不同的侧面描述了这个功能。依赖注入的概念描述的是让调用类对某一接口实现类的依赖关系有第三方容器或其他东西注入，以此来移除对某一接口实现类的依赖。

Spring 构造方法注入

Spring Set注入

Spring 基于注解的注入

四种注解可以注册bean，每种注解可以任意使用，只是语义上有所差异：

@Component：可以用于注册所有bean

@Repository：主要用于注册dao层的bean

@Controller：主要用于注册控制层的bean

@Service：主要用于注册服务层的bean

@Resource：java的注解，默认以byName的方式去匹配与属性名相同的bean的id，如果没有找到就会以byType的方式查找，如果byType查找到多个的话，使用@Qualifier注解（spring注解）指定某个具体名称的bean。

@Autowired：spring注解，默认是以byType的方式去匹配与属性名相同的bean的id，如果没有找到，就通过byName的方式去查找，如果byName查找到多个的话，使用@Qualifier注解（spring注解）指定某个具体名称的bean。

Spring

容器核心组件：

Beans :表示的是spring对所有Bean对象的管理，主要是包含了对象间的关系配置以及一些对象的实例化操作。

Core：包含了最底层的开发支持，例如：依赖的注入关系、资源文件的访问，数据类型的转换；

Context:提供的是一个完整的容器上下文，在这个上下文可以处理对象生命周期或者是事务；

SPEL：表达式语言模块，利用SPEL实现表达式语言的操作，以增强String的功能；

Spring 的问题

随着使用 Spring 进行开发的个人和企业越来越多，Spring 也慢慢从一个单一简洁的小框架变成一个大而全的开源软件，Spring 的边界不断的进行扩充，到了后来 Spring 几乎可以做任何事情了，市面上主流的开源软件、中间件都有 Spring 对应组件支持，人们在享用 Spring 的这种便利之后，也遇到了一些问题。

Spring 每集成一个开源软件，就需要增加一些基础配置，慢慢的随着人们开发的项目越来越庞大，往往需要集成很多开源软件，因此后期使用 Spirng 开发大型项目需要引入很多配置文件，太多的配置非常难以理解，并容易配置出错，到了后来人们甚至称 Spring 为配置地狱。

Spring Boot 的诞生

Spring 似乎也意识到了这些问题，急需有这么一套软件可以解决这些问题。

Spring Boot 是由 Pivotal 团队提供的全新框架，其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。用我的话来理解，就是 Spring Boot 其实不是什么新的框架，它默认配置了很多框架的使用方式，就像 maven 整合了所有的 jar 包，Spring Boot 整合了所有的框架（不知道这样比喻是否合适）。

Spring Boot 简化了基于 Spring 的应用开发，通过少量的代码就能创建一个独立的、产品级别的 Spring 应用。 Spring Boot 为 Spring 平台及第三方库提供开箱即用的设置，这样你就可以有条不紊地开始。Spring Boot 的核心思想就是约定大于配置，多数 Spring Boot 应用只需要很少的 Spring 配置。采用 Spring Boot 可以大大的简化你的开发模式，所有你想集成的常用框架，它都有对应的组件支持。

Spring Boot 特性

• 使用 Spring 项目引导页面可以在几秒构建一个项目

• 方便对外输出各种形式的服务，如 REST API、WebSocket、Web、Streaming、Tasks

• 非常简洁的安全策略集成

• 支持关系数据库和非关系数据库

• 支持运行期内嵌容器，如 Tomcat、Jetty

• 强大的开发包，支持热启动

• 自动管理依赖

• 自带应用监控

• 支持各种 IED，如 IntelliJ IDEA 、NetBeans

Spring Boot 这些特性会给我们研发带来非常大的优势，下面我们可以分开来介绍：

使用 Spring Boot 的优势

使用 Spring Boot 开发项目，会给我们带来非常美妙的开发体验，可以从以下几个方面展开来说明

Spring Boot 让开发变得更简单

Spring Boot 对开发效率的提升是全方位的，我们可以简单做一下对比：

在没有使用 Spring Boot 之前我们开发一个 web 项目需要做哪些工作：

• 1）配置 web.xml，加载 Spring 和 Spring mvc

• 2）配置数据库连接、配置 Spring 事务

• 3）配置加载配置文件的读取，开启注解

• 4）配置日志文件

• …

• n) 配置完成之后部署 tomcat 调试

可能你还需要考虑各个版本的兼容性，jar 包冲突的各种可行性。

那么使用 Spring Boot 之后我们需要开发一个 web 项目需要哪些操作呢？

• 1）登录网址 http://start.spring.io/ 选择对应的组件直接下载

• 2）导入项目，直接开发

上面的 N 步和下面的2步形成巨大的反差，这仅仅只是在开发环境搭建的这个方面。

微服务

1 什么是微服务

1. 使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且他们可以通过自动化方式部署。
2. 如何拆分最小服务单元（不是固定的量化，是一种设计思路）
3. 微服务特征:单一职责，轻量级通讯，隔离性，业务数据独立，技术多样性。
4. 微服务诞生背景:互联网的快速发展，敏捷开发，精益方法，容器技术的成熟

2.微服务架构图

1. 业务场景：登录注册，发送邮件或者短信，获取课程列表
2. 单体架构图： 

    

3.  微服务架构图：

         

3.微服务架构优势，劣势

1. 优势：独立性，敏捷性，技术栈灵活，高效团队。
2. 劣势：额外的工作，数据一致性，沟通成本。

 

参考：

Java Web 开发发展简介 https://www.jianshu.com/p/bec6736dcc3d

Spring Boot 的发展历程和优点 https://blog.csdn.net/adingyb/article/details/80707471

微服务简介 https://www.cnblogs.com/jingtyu/p/8745647.html