springboot与ssm的关系 springboot相比于ssm

转载

陌陌香阁 2024-03-18 08:39:16

文章标签 springboot与ssm的关系 java spring 加载微服务 文章分类 架构后端开发

SSM和Spring Boot区别，谈谈

SSM是WEB应用框架，涵盖整个应用层，而spring boot它约定大于配置，你可以看做一个启动、配置、快速开发的框架，本身针对的是微服务。他最明显的就是将原有的xml配置，简化为java配置（yml. properties）还提供了大量的starter
SSM：面相XML编程。SpringBoot：面相注解编程

回答3：springboot采用约定大于配置的方式，简化了大量的xml配置，真正做到了开箱即用。减少了web开发的难度

若是使用ssm架构，或许架构师会这么做。
先引入对应的jar包，然后处理对应的依赖，若是有冲突，则需要解决依赖冲突，解决完毕后，配置对应的配置文件，然后再配置spring的xml。
换成springboot ，就只需要两步，寻找starter，在application.properties配置必要参数
这就解决了好几个问题，首先，参数配置均在application.properties中，其次，依赖问题有starter自己解决，依赖冲突有springboot parent去解决。我们只需要关注最核心的几个参数配置即可，而且其他人上手该项目，也只需要去关注最重要的几个点即可，而不是在一堆xml中去查证对应配置。
springboot和传统的ssm的区别，则在于其提供了一个良好且有效的标准，虽然它允许你可以自由配置，但是它仍旧希望你在满足需求的前提下，使用它的默认配置，而在目前看来，springboot的默认配置，也已经满足了绝大多数情况下的开发要求。

SpringBoot自动配置原理：

@SpringBootApplication
public class MydemoSpringBootApplication {

    public static void main(String[] args) {
        SpringApplication.run(MydemoSpringBootApplication.class, args);
    }

}

@SpringBootApplication

他其实是一个组合注解，复合注解。包含了：

@SpringBootConfiguration，也是组合注解，是配置注解，代替了@Configuration
@EnableAutoConfiguration，关键！他让Spring Boot根据当前应用项目所依赖的jar自动配置项目相关的配置。例如：在pom文件中添加了spring-boot-starter-web依赖，Spring Boot项目会自动添加Tomcat和Spring MVC的依赖，同时对Tomcat和Spring MVC进行自动配置。
@ComponentScan，该注解是让Spring Boot自动扫描@SpringBootApplication所在类的同级包以及它的子包中的配置，所以将这个@SpringBootApplication注解入口放在项目包下，让他自动扫描

关于 @EnableAutoConfiguration复合注解

他下含有

@Import，自动装配真正的核心！
导入了一个类```AutoConfigurationImportSelector.class，他selectImport，（配合Import注解）放类的全路径字符串，供给spring的IoC容器通过反射方式放入，变成spring的bean。同时他也会配合@Configuration和@Bean完成自动装配。不需要再像以往
@AutoConfigurationPackage，手动注册bean，注册扫描所有全局变量

Spring Boot中的Starter：

使用Spring和SpringMVC时候如果需要使用Mybatis框架，往往需要在xml中配置bean

starter就是一个jar包，你写一个@Configuration配置类，这些bean将会定义在里面，然后在Starter包的META-INF/spring.fatories中写入该配置类，springboot会如期加载。

springboot中SPI机制：

SPI的全名为Service Provider Interface.这个是针对厂商或者插件的。

在springboot的自动装配过程中，最终会加载META-INF/spring.factories文件，而加载的过程是由SpringFactoriesLoader加载的

从CLASSPATH下的每个Jar包中搜寻所有META-INF/spring.factories配置文件，然后将解析properties文件，找到指定名称的配置后返回。

java类加载机制说起：

java中的类加载器，负载加载来自文件系统、网络或者其他来源的类文件。

jvm的类加载器默认使用的是双亲委派模式。

三种默认的类加载器

Bootstrap ClassLoader：负责加载JDK自带的rt.jar包中的类文件，是所有类加载的父类
Extension ClassLoader：负责加载java的扩展类库从jre/lib/ect目录或者java.ext.dirs系统属性指定的目录下加载类，是System ClassLoader的父类加载器
System ClassLoader（Application ClassLoader）：负责从classpath环境变量中加载类文件

每一个中类加载器都确定了从哪一些位置加载文件。也可以通过继承java.lang.classloader实现自己的类加载器。

java双亲委派：

当一个类加载器收到类加载任务时，会先交给自己的父加载器去完成

因此最终加载任务都会传递到最顶层的Bootstrap ClassLoader

只有当父加载器无法完成加载任务时，才会尝试自己来加载。

Spring MVC

参考链接：

1、什么是Spring MVC ？简单介绍下你对springMVC的理解?

Spring MVC是一个基于Java的实现了MVC设计模式的请求驱动类型的轻量级Web框架，通过把Model，View，Controller分离，将web层进行职责解耦，把复杂的web应用分成逻辑清晰的几部分，简化开发，减少出错，方便组内开发人员之间的配合。

什么是Spring Cloud

Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集成，更专注于服务治理。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。

SpringCloud_Alibaba

springboot与ssm的关系 springboot相比于ssm_微服务

Narcos分布式配置，注册中心，服务发现

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

Dubbo (RPC)
Dubbo已经在圈内很火了,SpringCloud Alibaba基于上面提到的Nacos服务注册中心也同样整合了Dubbo。
Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Ribbon负载均衡

服务调用
Ribbon：也进入了维护状态，停止更新了，但是Spring官方还在使用（轻度患者）。
ribbon的负载均衡策略
RoundRobinRule: 轮询策略，Ribbon以轮询的方式选择服务器，这个是默认值。所以示例中所启动的两个服务会被循环访问;
RandomRule: 随机策略，也就是说Ribbon会随机从服务器列表中选择一个进行访问;
BestAvailableRule: 最大可用策略，即先过滤出故障服务器后，选择一个当前并发请求数最小的;
WeightedResponseTimeRule: 带有加权的轮询策略，对各个服务器响应时间进行加权处理，然后在采用轮询的方式来获取相应的服务器;
AvailabilityFilteringRule: 可用过滤策略，先过滤出故障的或并发请求大于阈值的一部分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选出一个;
ZoneAvoidanceRule: 区域感知策略，先使用主过滤条件(区域负载器，选择最优区域)对所有实例过滤并返回过滤后的实例清单，依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数(默认1)和最小过滤百分比(默认0)，最后对满足条件的服务器则使用RoundRobinRule(轮询方式)选择一个服务器实例。

LoadBalance替代Ribbon

服务调用
LoadBalancer：Spring官方推出的一个新的组件，打算逐渐取代掉Ribbon，但是现在还处于萌芽状态。

Sentinel服务熔断，高可用流量管理框架， (分布式流控)

服务降级
把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel 是阿里开源的一个面向微服务的轻量级流量控制框架。
从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

https://github.com/alibaba/Sentinel

Sentienl：来自于SpringCloudAlibaba，在中国企业替换Hystrix的组件，国内强烈建议使用。

什么是服务熔断和服务降级？

熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。
服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然会出现局部的错误，但可以避免因为一个服务挂机，而影响到整个架构的稳定性。

Feign服务调用，服务限流降级

ribbon和feign区别
Ribbon添加maven依赖 spring-starter-ribbon 使用@RibbonClient(value=“服务名称”) 使用RestTemplate调用远程服务对应的方法。
feign添加maven依赖 spring-starter-feign 服务提供方提供对外接口调用方使用在接口上使用@FeignClient(“指定服务名”)
Ribbon和Feign的区别：
Ribbon和Feign都是用于调用其他服务的，不过方式不同。
启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的@EnableFeignClients。
服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。
Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，
不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。