互联网应用主流框架整合【Spring框架】

基于全面文章所讲Web容器、Servlet容器的概念和使用，再来理解Spring框架就水到渠成，Spring框架的广泛应用来自于它的理念而并非技术本身，其两大核心即控制反转(Inversion of Control)和面向切面变成(Aspect Oriented Programming)

Inversion of Control(IOC)

前面的文章详细讲过Web容器和Servlet容器，充分理解并实操之后，再来理解IoC就水到渠成，因为IoC本身也是容器

互联网轻量级框架整合之JavaEE基础I
互联网轻量级框架整合之JavaEE基础II

在Spring世界中，它认为一切Java资源都是JavaBean，这里暂时无需深究Bean实际是个什么东西，语言世界里名词概念无非就是个标签，SpringIoC里装载了各种Bean，IoC容器管理这些Bean的构建、事件、行为及其之间的关系；类比Servlet容器就较容易理解了，在Servlet容器里也存在这诸多Servlet实例，这些实例或通过注解声明或通过web.xml配置，同时有这些实例的初始化、销毁等动作；只是在SpringIoC管理对象和其关系不是人为构建的，而是由SpringIoC通过描述构建的，换句话说SpringIoC通过描述来完成对象及对象之间的关系的构建，而这便是IoC的理念

IoC容器里的对象构建是被动的，而非像以往的对象构建，人为的去new一个出来，在IoC容器里，向其注入描述信息而得到Bean，控制权在IoC容器中，它根据注入的描述信息找到构建对象所需资源给使用者，这边是控制反转的概念

以往的对象构建方式

Socket socket = new Socket1();
user.setSocket(socket);
user.useSocket();

Socket socket= new Socket2();
user.setSocket(socket);
user.useSocket();

SpringIoC构建对象方式

<bean id="socket" class="Socket1">
<bean id="user" class="xxx.User">
	<property name="socket" ref="socket"/>
</bean>

试想第一个问题：如果需要构建1000个同一个接口下的同类对象，如上两个方式哪个更可取
试想第二个问题：创建了1000个同类对象，明天有500个不用了，但又需要构建新增的200个对象，如上两个方式哪个更可取
试想第三个问题：两个方式代码的耦合哪个更好，开发效率哪个更高

这便是SpringIoC的魅力所在

SpringAOP面向切面编程

假设有一个产品订单付费的业务流程，在开发的时候可能需要处理的几个维度包括订单生成—>订单审批—>财务审批等等，然而每一步如果审批通过还好，如果审批未通过，那么为了保证数据一致性之前的操作产生的数据结果就要作废，重新处理，在以往的编程中我们似乎不不得写代码进行处理，而有了SpringAOP之后，它解决了此类问题，在SpringAOP实现的数据库事务管理中，以异常信息作为消息，默认情况下只要Spring接收到了异常信息(可以通过Spring的配置修改)，就会将数据库事务回滚，而取代了人工实现

@Transactional
private void proceed(Order order){
	boolean pflag = productionDept.isPass(order);
	if(pflag){
		if(financialDept.isOverbuget(order)){
			throw new RuntimeException("超出预算")；
		}
	}
}

在此例代码中，对方法proceed()使用了@Transactional注解，有了这个注解，当遇到了异常信息之后，Spring就会自己处理数据库事务的回滚甚至包括数据库的开闭也会自动完成，而无需再去写复杂的try...catch...finally结构体处理异常信息

SSM+Redis架构

Spring MVC

Spring MVC是一种MVC模式，在MVC模式里，把应用程序(输入逻辑、业务逻辑和UI逻辑)分成不同的元素，同时提供这些元素之间的松耦合，主要涉及三个概念：

• Model(模型)：封装了应用程序的数据和它们组成的POJO
• View(视图)：负责把模型数据渲染到视图上，将数据以一定的形式展现给用户
• Controller(控制器)：负责处理用户请求，并建立适当的模型，把它传递给视图渲染

在Spring MVC中还可以定义逻辑视图，通过其提供的视图解析器能够很方便的找到对应的视图进行渲染，或者使用消息转换功能，比如在Controller的方法内加入注解@ResponseBody后，SpringMVC就可以通过其消息转换系统，将数据转换为JSON，提供给前端Ajax或者移动端应用使用

Redis

目前为止Redis应该属于最流行的NoSQL(Not Only SQL)式的存储，它具备一些持久层的功能，也可以作为缓存工具；NoSQL数据库作为持久层，其存储的数据是半结构化的，这意味着计算机在入读内存中只存在少量规则，因此读入速度更快凸显其性能优势；作为缓存，它可以支持数据存入内存，只要命中率高便能快速响应，因为内存的读写速度是磁盘的数倍到上百倍，具体特点如下：

• Redis响应非常快，每秒可执行大约110000个写操作，或者81000个读操作；在高并发场景下完全可以将被操作频次高的数据放在Redis中，性能远超过关系型数据库；这里可以想象一下把常用数据第一次从MySQL中读取后，在Redis里存一份，后续的操作直接从Redis中读取；

• 支持多种数据类型，包括字符串、哈希结构、列表、集合、可排序集合等等，字符串可以存一些Java基础数据，哈希结构可以存储对象，列表可以存储List对象等，Redis虽然只支持几种常用数据类型，但这也是其性能高的一个原因，虽然几种数据类型但已经可以满足常规需求，数据类型少则规则少判断少逻辑少从而性能高

• 操作都是原子的，所有Redis的操作都是原子的，从而确保了数据的一致性，多个客户端同时访问Redis服务器时，得到的是更新后的最新数值，在高并发的场合可以考虑使用Redis事务处理一些需要锁的业务

• MultiUtility工具，Redis可以在如缓存、消息传递队列中使用，因为它支持“发布+订阅”的消息模式，在Web应用中存储会话信息(Session),或者记录某个时间段页面点击量等短暂使用的数据

Spring微服务

微服务并没有明确的规范，每家公司都各自的特点，微在合适便是其正解，更理性的一种解释是带有一定风格的分布式架构，本质上属于分布式系统的一种，要使用微服务理念，在当今Spring横行的下，不得不掌握Spring Cloud和SpringBoot，本质上他们可以理解成微服务工具

SpringBoot

微服务开发利器之一，其设计目的是简化Spring应用的初始搭建及开发过程，该框架使用了特定的方式进行配置，工程师无需再定义样板化的配置，工程师可以将更多的精力放在实际的开发工作中而非如何结构化项目繁琐思路中，在快速开发领域(rapid application development)中SprintBoot的作用非常之大，简单说SpringBoot的设计理念就是约定优于配置，它提供了很多默认配置，用户可以通过Spring Boot给的默认配置修改即可，例如链接数据库或者其他资源的配置和属性

spring.datasource.url=jdbc:mysql://localhost:3306/ssm
spring.datasource.username=root
spring.datasource.username=root
srping.datasource.driver-class-name=com.mysql.jdbc.Driver
#最大等待连接中的数量，设为0为没有限制
srping.datasource.tomcat.max-idle=10
#最大活动连接数
spring.datasource.tomcat.max-active=50
#最大等待毫秒数，单位为ms，超过时间会抛异常
spring.datasource.tomcat.max-wait=10000
#数据库连接池初始化连接数
spring.datasource.tomcat.initial-size=5

SpringCloud

微服务开发利器之一，在微服务体系中，一个庞大的单体系统需要根据业务进行拆分，每一个微服务都应该是独立的产品，可以拥有独立的数据库、服务器及其他资源，可以独立运行，然而当微服务拆分后就需要一个规则工具对其进行管理，并将其联系起来一起工作，因此SpringCloud提供了服务发现、服务注册、配置中心、消息总线、负载均衡、服务调用、断路器、数据监控等组件

然而Spring Cloud的这些组件并非都是自己开发而来，会选用当前开源的一些优秀的分布式组件，然后采用Spring Boot风格将这些组件进行封装