Spring Cloud 终于改了

最近 Spring Cloud 把版本号从 A 到 Z 的伦敦地铁站，改成用日期命名了。

• https://spring.io/blog/2020/04/17/spring-cloud-2020-0-0-m1-released

也就是从 Greenwich.SR6, Hoxton.SR9 这样的风格改成了 2020.0.0 的形式。广大人民终于不用为 Spring Cloud 的版本号烦恼了。

Spring Cloud 推广不力，固然有自身复杂的原因，版本号太复杂也是一个坑。

以日期为版本号，即所谓的 Calendar Versioning，可以参考这个网站：

• https://calver.org/overview_zhcn.html

前言

很久没有写关于 Spring 的文章了，最近在系统梳理 Dubbo 代码的过程中发现了 XML schema 这个被遗漏的知识点。由于工作中使用 SpringBoot 比较多的原因，几乎很少接触 XML，此文可以算做是亡羊补牢，另一方面，也为后续的 Dubbo 源码解析做个铺垫。

XML schema 扩展机制是啥？这并不是一块很大的知识点，翻阅一下 Spring 的文档，我甚至没找到一个贯穿上下文的词来描述这个功能，XML Schema Authoring 是文档中对应的标题，简单来说：

SpringSecurityFilterChain 作为 SpringSecurity 的核心过滤器链在整个认证授权过程中起着举足轻重的地位，每个请求到来，都会经过该过滤器链，前文 《Spring Security( 四)– 核心过滤器源码分析》 中我们分析了 SpringSecurityFilterChain 的构成，但还有很多疑问可能没有解开：

今天我们来放松下心情，不聊分布式，云原生，来聊一聊初学者接触的最多的 java web 基础。几乎所有人都是从 servlet，jsp，filter 开始编写自己的第一个 hello world 工程。那时，还离不开 web.xml 的配置，在 xml 文件中编写繁琐的 servlet 和 filter 的配置。随着 spring 的普及，配置逐渐演变成了两种方式—java configuration 和 xml 配置共存。现如今，springboot 的普及，java configuration 成了主流，xml 配置似乎已经“灭绝”了。不知道你有没有好奇过，这中间都发生了哪些改变，web.xml 中的配置项又是被什么替代项取代了？

缘起

前端时间将一个集成了 spring-security-oauth2 的旧项目改造了一番，将 springboot 升级成了 springboot 2.0，众所周知 springboot 2.0 依赖的是 spring5，并且许多相关的依赖都发生了较大的改动，与本文相关的改动罗列如下，有兴趣的同学可以看看：Spring Security 5.0 New Features ，增强了 oauth2 集成的功能以及和一个比较有意思的改动—重构了密码编码器的实现（Password Encoding，由于大多数 PasswordEncoder 相关的算法是 hash 算法，所以本文将 PasswordEncoder 翻译成‘密码编码器’和并非‘密码加密器’）官方称之为

Modernized Password Encoding — 现代化的密码编码方式

去年我曾经写过几篇和 Spring Session 相关的文章，从一个未接触过 Spring Session 的初学者视角介绍了 Spring Session 如何上手，如果你未接触过 Spring Session，推荐先阅读下「从零开始学习 Spring Session」系列（https://www.cnkirito.moe/categories/Spring-Session/） Spring Session 主要解决了分布式场景下 Session 的共享问题，本文将从 Spring Session 的源码出发，来讨论一些 Session 设计的细节。

在服务比较少的年代，一个系统的接口响应缓慢通常能够迅速被发现，但如今的微服务模块，大多具有规模大，依赖关系复杂等特性，错综复杂的网状结构使得我们不容易定位到某一个执行缓慢的接口。分布式的服务跟踪组件就是为了解决这一个问题。其次，它解决了另一个难题，在没有它之前，我们客户会一直询问：你们的系统有监控吗？你们的系统有监控吗？你们的系统有监控吗？现在，谢天谢地，他们终于不问了。是有点玩笑的成分，但可以肯定的一点是，实现全链路监控是保证系统健壮性的关键因子。

介绍 Spring Cloud Sleuth 和 Zipkin 的文章在网上其实并不少，所以我打算就我目前的系统来探讨一下，如何实现链路监控。全链路监控这个词意味着只要是不同系统模块之间的调用都应当被监控，这就包括了如下几种常用的交互方式：

1 Http 协议，如 RestTemplate，Feign，Okhttp3，HttpClient…

2 Rpc 远程调用，如 Motan，Dubbo，GRPC…

默认序列化方案

在上一篇文章《Spring Data Redis（一）》中，我们执行了这样一个操作：

1

redisTemplate.opsForValue().set("student:1","kirito");

谈及系统优化，缓存一直是不可或缺的一点。在缓存中间件层面，我们有 MemCache，Redis 等选择；在系统分层层面，又需要考虑多级缓存；在系统可用性层面，又要考虑到缓存雪崩，缓存穿透，缓存失效等常见的缓存问题… 缓存的使用与优化值得我们花费一定的精力去深入理解。《Spring Data Redis》这个系列打算围绕 spring-data-redis 来进行分析，从 hello world 到源码分析，夹杂一些不多实战经验（经验有限），不止限于 spring-data-redis 本身，也会扩展谈及缓存这个大的知识点。

至于为何选择 redis，相信不用我赘述，redis 如今非常流行，几乎成了项目必备的组件之一。而 spring-boot-starter-data-redis 模块又为我们在 spring 集成的项目中提供了开箱即用的功能，更加便捷了我们开发。系列的第一篇便是简单介绍下整个组件最常用的一个工具类：RedisTemplate。

在开始这篇文章之前，我们似乎应该思考下为什么需要搞清楚 Spring Security 的内部工作原理？按照第二篇文章中的配置，一个简单的表单认证不就达成了吗？更有甚者，为什么我们不自己写一个表单认证，用过滤器即可完成，大费周章引入 Spring Security，看起来也并没有方便多少。对的，在引入 Spring Security 之前，我们得首先想到，是什么需求让我们引入了 Spring Security，以及为什么是 Spring Security，而不是 shiro 等等其他安全框架。我的理解是有如下几点：

1 在前文的介绍中，Spring Security 支持防止 csrf 攻击，session-fixation protection，支持表单认证，basic 认证，rememberMe… 等等一些特性，有很多是开箱即用的功能，而大多特性都可以通过配置灵活的变更，这是它的强大之处。

2 Spring Security 的兄弟的项目 Spring Security SSO，OAuth2 等支持了多种协议，而这些都是基于 Spring Security 的，方便了项目的扩展。

3 SpringBoot 的支持，更加保证了 Spring Security 的开箱即用。

4 为什么需要理解其内部工作原理? 一个有自我追求的程序员都不会满足于浅尝辄止，如果一个开源技术在我们的日常工作中十分常用，那么我偏向于阅读其源码，这样可以让我们即使排查不期而至的问题，也方便日后需求扩展。

5 Spring 及其子项目的官方文档是我见过的最良心的文档！~~ 相比较于 Apache 的部分文档 ~~

这一节，为了对之前分析的 Spring Security 源码和组件有一个清晰的认识，介绍一个使用 IP 完成登录的简单 demo。