spring原理

微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如 Dubbo 和 Spring Cloud。 目前微服务实现方式主要有两种Dubbo和SpringCloud： 一、 Dubbo ：(https://www.cnblogs.com/liangblog/p/6165070.html） Dubbo是一个分布式服务框架，致力于提供高性能透明化RPC远程调用方案，提供SOA服务治理解决方案。 Dubbo使用 RPC 通讯协议。 架构原理 ：（http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html） 服务容器负责启动，加载，运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 zookeeper注册中心： 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

该文章转载自： https://blog.csdn.net/lvoyee/article/details/82017057 Spring Boot中有一种非常解耦的扩展机制：Spring Factories。这种扩展机制实际上是仿照Java中的SPI扩展机制来实现的。 什么是 SPI机制 SPI的全名为Service Provider Interface.大多数开发人员可能不熟悉，因为这个是针对厂商或者插件的。在java.util.ServiceLoader的文档里有比较详细的介绍。 简单的总结下java SPI机制的思想。我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。 java SPI就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。 Spring Boot中的SPI机制 在Spring中也有一种类似与Java SPI的加载机制。它在META-INF/spring

@Configuration : 配置类 == 配置文件,告诉Spring这是一个配置类 @ComponentScan(value="com.atguigu",excludeFilters = { @Filter(type=FilterType.ANNOTATION,classes={Controller.class}) }) @ComonentScan value : 指定要扫描的包(这个注解可以定义多个) excludeFilters = Filter[] : 指定扫描的时候按照什么规则排除那些组件 includeFilters = Filter[] : 指定扫描的时候只需要包含那些组件 useDefaultFilters = false : 表示去掉默认扫描 FilterType.ANNOTATION : 按照注解类型 例如 : Controller.class FilterType.ASSIGNABLE_TYPE : 按照给定的类型 例如 : UserService.class FilterType.ASPECTJ : 使用ASPECTJ表达式 FilterType.REGEX : 使用正则指定 FilterType.CUSTOM : 使用自定义规则 自定义规则需要实现TypeFilter接口 public class MyTypeFilter implements

@Transactional 事务管理的目的 在出现异常的情况下，保证数据的一致性；数据提交操作回滚至异常发生前的状态 事务管理的方式： Spring（Spring Framework 提供对事务管理的抽象接口） 支持两种事务管理方式： 编程式事务管理：使用TransactionTemplate或PlatformTransactionManager实现 声明式事务管理：建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务（此处取决于事务的传播行为），在执行完目标方法之后根据执行情况提交或者回滚事务（执行成功则提交，失败则进行实物的回滚） 编程式事务管理优势：可以控制事务的粒度，最细粒度到代码块级别； 声明式实物管理优势：在方法外进行声明，事务控制的代码不会与业务逻辑代码混在一起，最细粒度到方法级别（解决方法：可以将需要进行事务管理的代码块独立为方法，通过方法间调用实现）；符合spring倡导的非侵入式的开发方式，即业务处理逻辑代码与事务管理代码不放在一起 声明式事务管理实现方式： 基于tx和aop名字空间的xml配置文件 // 基本配置 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns

文章目录 Spring Data JPA常用接口分析 Spring Data JPA的实现过程 Spring Data JPA完整调用过程分析 Spring Data JPA常用接口分析 在入门案例中，我们仅仅定义了CustomerDao的接口，并没有提供任何的方法，那么我们所调用的增删改查的方法来自哪里呢？答案很简单，对于我们自定义的Dao接口，由于继承了JpaRepository和JpaSpecificationExecutor，所以我们可以使用这两个接口的所有方法。 进入JpaRepository，在类上按住ctrl+F2： 在JpaSpecificationExecutor中也是类似的情况。 但是我们注意到，JpaRepository和JpaSpecificationExecutor是接口，其只是一些方法声明，没有具体的实现方式，那么在 Spring Data JPA中它又是怎么实现的呢？ Spring Data JPA的实现过程 已根据id查询用户代码为例： 打断点，观察我们定义的customerdao的实现对象是谁： 我们可以看到产生了一个动态代理对象JdkDynamicAopProxy，而该对象是Spring内部通过AOP帮助我们创建对象的，单机右键，查看源码： 进如到JdkDynamicAopProxy对象中：

该文章转载自： https://blog.csdn.net/lvoyee/article/details/82017057 Spring Boot中有一种非常解耦的扩展机制：Spring Factories。这种扩展机制实际上是仿照Java中的SPI扩展机制来实现的。 什么是 SPI机制 SPI的全名为Service Provider Interface.大多数开发人员可能不熟悉，因为这个是针对厂商或者插件的。在java.util.ServiceLoader的文档里有比较详细的介绍。 简单的总结下java SPI机制的思想。我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。 java SPI就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。 Spring Boot中的SPI机制 在Spring中也有一种类似与Java SPI的加载机制。它在META-INF/spring

Spring-Boot 攻略 day01 spring-boot 一. 基本配置加运行 1. 导入配置文件（pom.xml 文件中） <parent> <groupId> org.springframework.boot </groupId> <artifactId> spring-boot-starter-parent </artifactId> <version> 1.5.9.RELEASE </version> </parent> <dependencies> <dependency> <groupId> org.springframework.boot </groupId> <artifactId> spring-boot-starter-web </artifactId> </dependency> </dependencies> 2. Application.java @SpringBootApplication public class HelloApplication { public static void main ( String [] args ) { SpringApplication . run ( HelloApplication . class , args ); } } 3. Controller.java /* @RestController

种一棵树最好的时间是十年前，其次是现在。 Spring Boot 对比 Spring MVC 最大的优点就是使用简单，约定大于配置。不会像之前用 Spring MVC 的时候，时不时被 xml 配置文件搞的晕头转向，冷不防还因为 xml 配置上的一点疏忽，导致整个项目莫名其妙的不可用，顿感生活无所依恋，简称生无可恋。 这要归功于组成了 Spring Boot 的各种各样的 starters，有官方提供的，也有第三方开源出来。可以这么说，基本上你打算用的功能都可以找到，如果没有找到，那就再找一找。 用 Spring Boot 的功能组件（例如 spring-boot-starter-actuator、 spring-boot-starter-data-redis 等）的步骤非常简单，用著名的把大象放冰箱的方法来概括的话，有以下三步就可以完成组件功能的使用： 第一步 在 pom 文件中引入对应的包，例如： < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-actuator </ artifactId > </ dependency > 第二步 在应用配置文件中加入相应的配置，配置都是组件约定好的，需要查看官方文档或者相关说明

Spring历史版本变迁和如今的生态帝国 版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/bntX2jSQfEHy7/article/details/78918119 前两篇： 为什么要有Spring? 为什么要有Spring AOP? 前两篇从Web开发史的角度介绍了我们在开发的时候遇到的一个个坑，然后一步步衍生出Spring Ioc和Spring AOP的概念雏形。Spring从2004年第一个正式版1.0 Final Released发展至今，俨然已经成为了一个生态帝国（开局只有一把枪，装备全靠打！），目前也已经迭代到5.0，拥有诸多的子项目，基本可以解决绝大多数场景的应用！ 而在进一步学习Spring的核心原理之前，有必要和大家一起梳理一下Spring历史版本的变迁，知晓一下每一个版本新增了哪些东西，解决了哪些我们开发中的问题，以便我们更清楚的理解这个生态帝国是如何一步一发展壮大的！ 一、Spring历史版本变迁 1、Spring 1.x 大概在2004年3月24日这一天，Spring Framework 1.0 final正式出现在我们的视野中，源码项目结构如下： 引用依赖如下： Spring 1.0当时只包含一个完整的项目，他把所有的功能都集中在一个项目中，其中包含了核心的Ioc、AOP，同时也包含了其他的诸多功能，例如

疯狂创客圈 Java 高并发【 亿级流量聊天室实战】实战系列 【 博客园总入口 】 架构师成长+面试必备之 高并发基础书籍 【 Netty Zookeeper Redis 高并发实战 】 疯狂创客圈 高并发 环境 视频，陆续上线： Windows Redis 安装（带视频） Linux Redis 安装（带视频） Windows Zookeeper 安装（带视频） Linux Zookeeper 安装（带视频） RabbitMQ 离线安装（带视频） Nacos 安装（带视频） ElasticSearch 安装, 带视频** 小视频以及所需工具的 百度网盘链接 ，请参见 疯狂创客圈 高并发社群 博客 Spring Security 的重要性 在web应用开发中，安全无疑是十分重要的，选择Spring Security来保护web应用是一个非常好的选择。Spring Security 是spring项目之中的一个安全模块，特别是在spring boot项目中，spring security已经默认集成和启动了。 Spring Security 默认为自动开启的，可见其重要性。 如果要关闭，需要在启动类加上，exclude ={SecurityAutoConfiguration} 的配置 @EnableEurekaClient @SpringBootApplication