原文Spring中获取request的几种方法，及其线程安全性分析

前言

本文将介绍在使用 Spring MVC 开发中，获取 request 对象的几种方法，并讨论其线程安全性。

概述

在使用 Spring MVC 开发 Web 系统时，经常需要在处理请求时使用 request 对象。比如：获取客户端 IP 地址、请求的 URL、header 中的属性（Cookie、授权信息）、body 中的数据等。

由于在 Spring MVC 中，处理请求的 Controller、Service 等对象都是单例的，因此获取 request 对象时最需要注意的问题，便是 request 对象是否线程安全：当有大量并发请求时，能否保证不同请求/线程中使用不同的 request 对象。

前记

项目需要用到 Spring OAuth2 SSO，但是还没使用过，记录下来。

项目包括：
UI 站点【常规网站】：admin-ui，admin-ui2
网关【Zuul】：gateway
RESTFulAPI 服务 +　认证中心：uac
服务发现：eureka

问题：

1. UI 站点用到的某些资源是通过 ajax 请求 uac，如果未登录认证，则无法获取，而且因为是 ajax，无法通过后端直接重定向，只能由前端识别到未登录时进行跳转登录。
2. RESTFulAPI 是由网关 gateway 进行统一管理的，所以路由到认证中心 uac 时需要记录下请求的地址，不然无法在登录后重定向回去。
3. admin-ui 登录后，再访问 admin-ui2 时应该能自动登录上，因为实现了 SSO 单点登录。

问题解决：

1. 在请求是 ajax 时，只返回 Json 和未认证的 HttpState，不要返回认证中心的登录页面，之后再由前端自己根据返回的包含认证中心字段的 Json 重定向过去。
2. 认证中心应该放在网关 gateway，这样可以更好管理用户登录认证问题，并且更易从 savedRequest 中获取请求前的地址。
3. 注解内部应该直接实现了，具体还得看运行情况。

前记

单点登录（Single Sign On）严格上来说和 OAuth2 没太大关系，只是 SSO 可以通过 OAuth2 实现。本文延续 OAuth2 初识的模式，看完原理写 Demo，在上一个 Demo 的基础上加以改造。

认证中心仍然是 QQ，然后子系统是 QQ 邮箱 + QQ 游戏，两个子系统除了配置上有少许差别外，基本一样。

代码：GitHub

原理参考单点登录原理，内容上有删改。

前提知识：

• session 和 cookie 的使用

前记

本文主要是理解 OAuth2 协议中的 state 参数的用意——防止第三方客户端被 CSRF 攻击。

Demo 依然是 OAuth2 初识中的 模拟 QQ 授权银行客户端（授权码模式）。

参考文章：
RFC 6749 – Cross-Site Request Forgery
OAuth2 CSRF攻击

前记

OAuth2 可以方便第三方应用获取用户在其他应用的信息。

比如用 QQ 账户登录优酷，优酷就会先让用户登录 QQ，然后让用户确认授权优酷访问 QQ 上的信息，确认后优酷就获得了 QQ 的 OAuth 服务器返回的 token，之后就可以通过 token 访问到权力范围内的用户相关信息。

共同点：装配 Bean，写在字段或 setter 方法上。

@Autowired

Spring 的注解，来自 org.springframework.beans.factory.annotation.Autowired

默认按类型装配，也可以使用名称装配，但要配合 @Qualifier 注解。

依赖对象必须存在，如果要允许 null 值，可以设置 @Autowired(required=false)

前记

上两章粗略的使用了配置中心和客户端，这一章将开始使用服务链路追踪（SpringCloud Sleuth）。

服务追踪分析

微服务架构上通过业务来划分服务，通过 REST 调用，对外暴露一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。

随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下：

前记

一开始我们就创建了一个注册中心，但是当成千上万个服务向它注册的时候，它的负载是非常高的，这在生产环境上是不太合适的，这章将把 Eureka Server 集群化。