介绍

本文档主要针对我们项目内部正在使用的框架，以及代码审查发现的一些共性问题提出一些开发规范。

JavaBean 规范

1 驼峰命名法【强制】

2 布尔类型规范【强制】
【说明】所有的布尔类型不允许以 is 开头，否则会导致部分序列化，hibernate 框架出现解析异常。
【反例】
原来项目的 BaseDomain 中标记逻辑删除的字段, 在部分场景下会出现问题

陆陆续续，写博客已经写了有 4 年多了，之前一直在 CSDN 维护博客（博客旧址），最近有了点空余时间，使用 hexo 搭了这个博客，的确比 CSDN 清爽多了，首先感谢 @程序猿 DD 推荐的 icarus 模板，国人开发的一个 hexo 模板，插件支持可能不是很完善，但是样式非常让人喜欢。

作为一个前端弱渣，搭建博客的过程还是遇到了不少的困难。原先是打算直接使用 github 个人主页作为博客地址，hexo 对 git 有很好的支持，源代码和博客静态页面都托管在了 github，master 分支放静态页面，hexo 分支放源文件。可惜的是国内坑爹的网速,github.io 的访问速度不尽如人意（github.com 倒还好），于是在宇泽学妹 @ntzyz 的帮助下，搞了 github 的 hook，本地提交到 github 时，代理服务器自动向 master 分支拉取页面，同时设置反向代理和 https。由于 hexo 是静态文件搭建的博客，这种方式可以说是非常合适的。所以，国内的朋友浏览本博客可以直接访问 https://www.cnkirito.moe，如果有国外代理的朋友可以直接访问我的 github 个人主页 https://lexburner.github.io。

目前博客功能还不算完善，缺少评论，分享，和一些小插件，以后逐渐完善，不过不影响主要功能。以后这儿就作为我主要更新博客的地方了！

1 引子

项目开发中的工具类代码总是随着项目发展逐渐变大，在公司诸多的公用代码中，笔者发现了一个简单的，也是经常被使用的类：BaseDomain，引起了我的思考。
在我们公司的开发习惯中，数据库实体类通常会继承一个叫做 BaseDomain 的类，这个类很简单，主要用来填充一些数据库实体公用的属性，它的设计如下：

前言

数据的校验是交互式网站一个不可或缺的功能，前端的 js 校验可以涵盖大部分的校验职责，如用户名唯一性，生日格式，邮箱格式校验等等常用的校验。但是为了避免用户绕过浏览器，使用 http 工具直接向后端请求一些违法数据，服务端的数据校验也是必要的，可以防止脏数据落到数据库中，如果数据库中出现一个非法的邮箱格式，也会让运维人员头疼不已。我在之前保险产品研发过程中，系统对数据校验要求比较严格且追求可变性及效率，曾使用 drools 作为规则引擎，兼任了校验的功能。而在一般的应用，可以使用本文将要介绍的 validation 来对数据进行校验。

简述 JSR303/JSR-349，hibernate validation，spring validation 之间的关系。JSR303 是一项标准,JSR-349 是其的升级版本，添加了一些新特性，他们规定一些校验规范即校验注解，如 @Null，@NotNull，@Pattern，他们位于 javax.validation.constraints 包下，只提供规范不提供实现。而 hibernate validation 是对这个规范的实践（不要将 hibernate 和数据库 orm 框架联系在一起），他提供了相应的实现，并增加了一些其他校验注解，如 @Email，@Length，@Range 等等，他们位于 org.hibernate.validator.constraints 包下。而万能的 spring 为了给开发者提供便捷，对 hibernate validation 进行了二次封装，显示校验 validated bean 时，你可以使用 spring validation 或者 hibernate validation，而 spring validation 另一个特性，便是其在 springmvc 模块中添加了自动校验，并将校验信息封装进了特定的类中。这无疑便捷了我们的 web 开发。本文主要介绍在 springmvc 中自动校验的机制。

上一篇文章中我们介绍了获取 token 的流程，这一篇重点分析一下，携带 token 访问受限资源时，内部的工作流程。

@EnableResourceServer 与 @EnableAuthorizationServer

还记得我们在第一节中就介绍过了 OAuth2 的两个核心概念，资源服务器与身份认证服务器。我们对两个注解进行配置的同时，到底触发了内部的什么相关配置呢？

上一篇文章重点介绍的其实是与身份认证相关的流程，即如果获取 token，而本节要分析的携带 token 访问受限资源，自然便是与 @EnableResourceServer 相关的资源服务器配置了。

我们注意到其相关配置类是 ResourceServerConfigurer，内部关联了 ResourceServerSecurityConfigurer 和 HttpSecurity。前者与资源安全配置相关，后者与 http 安全配置相关。（类名比较类似，注意区分，以 Adapter 结尾的是适配器，以 Configurer 结尾的是配置器，以 Builder 结尾的是建造器，他们分别代表不同的设计模式，对设计模式有所了解可以更加方便理解其设计思路）

1
2
3
4
5
6
7
8
9
10
11

public class ResourceServerConfigurerAdapter implements ResourceServerConfigurer {
	@Override
	public void configure(ResourceServerSecurityConfigurer resources <1>) throws Exception {
	}

	@Override
	public void configure(HttpSecurity http) throws Exception {
		http.authorizeRequests().anyRequest().authenticated();
	}

}

<1> ResourceServerSecurityConfigurer 显然便是我们分析的重点了。

本文开始从源码的层面，讲解一些 Spring Security Oauth2 的认证流程。本文较长，适合在空余时间段观看。且涉及了较多的源码，非关键性代码以… 代替。

准备工作

首先开启 debug 信息：

1
2
3

logging:
  level:
    org.springframework: DEBUG

可以完整的看到内部的运转流程。

client 模式稍微简单一些，使用 client 模式获取 token
http://localhost:8080/oauth/token?client_id=client_1&client_secret=123456&scope=select&grant_type=client_credentials

由于 debug 信息太多了，我简单按照顺序列了一下关键的几个类：

1
2
3
4

ClientCredentialsTokenEndpointFilter
DaoAuthenticationProvider
TokenEndpoint
TokenGranter

前言

今天来聊聊一个接口对接的场景，A 厂家有一套 HTTP 接口需要提供给 B 厂家使用，由于是外网环境，所以需要有一套安全机制保障，这个时候 oauth2 就可以作为一个方案。

关于 oauth2，其实是一个规范，本文重点讲解 spring 对他进行的实现，如果你还不清楚授权服务器，资源服务器，认证授权等基础概念，可以移步 理解 OAuth 2.0 - 阮一峰，这是一篇对于 oauth2 很好的科普文章。

需要对 spring security 有一定的配置使用经验，用户认证这一块，spring security oauth2 建立在 spring security 的基础之上。第一篇文章主要是讲解使用 springboot 搭建一个简易的授权，资源服务器，在文末会给出具体代码的 github 地址。后续文章会进行 spring security oauth2 的相关源码分析。java 中的安全框架如 shrio，已经有 跟我学 shiro - 开涛，非常成体系地，深入浅出地讲解了 apache 的这个开源安全框架，但是 spring security 包括 oauth2 一直没有成体系的文章，学习它们大多依赖于较少的官方文档，理解一下基本的使用配置；通过零散的博客，了解一下他人的使用经验；打断点，分析内部的工作流程；看源码中的接口设计，以及注释，了解设计者的用意。spring 的各个框架都运用了很多的设计模式，在学习源码的过程中，也大概了解了一些套路。spring 也在必要的地方添加了适当的注释，避免了源码阅读者对于一些细节设计的理解产生偏差，让我更加感叹，spring 不仅仅是一个工具框架，更像是一个艺术品。

Spring Cloud Feign

Spring Cloud Feign 是一套基于 Netflix Feign 实现的声明式服务调用客户端。它使得编写 Web 服务客户端变得更加简单。我们只需要通过创建接口并用注解来配置它既可完成对 Web 服务接口的绑定。它具备可插拔的注解支持，包括 Feign 注解、JAX-RS 注解。它也支持可插拔的编码器和解码器。Spring Cloud Feign 还扩展了对 Spring MVC 注解的支持，同时还整合了 Ribbon 和 Eureka 来提供均衡负载的 HTTP 客户端实现。

分布式应用早在十几年前就开始出现，各自的应用运行在各自的 tomcat，jboss 一类的容器中，他们之间的相互调用变成了一种远程调用，而实现远程调用的方式很多。按照协议划分，可以有 RPC，Webservice，http。不同的框架也对他们有了各自的实现，如 dubbo(x)，motan 就都是 RPC 框架，本文所要讲解的 Feign 便可以理解为一种 http 框架，用于分布式服务之间通过 Http 进行接口交互。说他是框架，有点过了，可以理解为一个 http 工具，只不过在 spring cloud 全家桶的体系中，它比 httpclient，okhttp，retrofit 这些 http 工具都要强大的多。

入门

先用一个简单的例子，看看如何在项目中使用 Feign。示例项目使用 maven 多 module 构建，采用 springcloud 的 Dalston.SR1 版本

前言

领域驱动的火爆程度不用我赘述，但是即便其如此得耳熟能详，但大多数人对其的认识，还只是停留在知道它的缩写是 DDD，知道它是一种软件思想，或者知道它和微服务有千丝万缕的关系。Eric Evans 对 DDD 的诠释是那么地惜字如金，而我所认识的领域驱动设计的专家又都是行业中的资深前辈，他们擅长于对软件设计进行高屋建瓴的论述，如果没有丰富的互联网从业经验，是不能从他们的分享中获取太多的营养的，可以用曲高和寡来形容。1000 个互联网从业者，100 个懂微服务，10 个人懂领域驱动设计。

可能有很多和我一样的读者，在得知 DDD 如此火爆之后，尝试去读了开山之作《领域驱动设计——软件核心复杂性应对之道》，翻看了几张之后，晦涩的语句，不明所以的专业术语，加上翻译导致的语句流畅性，可以说观看体验并不是很好，特别是对于开发经验不是很多的读者。我总结了一下，为何这本书难以理解：

1. 没有阅读软件设计丛书的习惯，更多人偏向于阅读偏应用层面的书籍，“talk is cheap，show me the code”往往更符合大多数人的习惯。
2. 没有太多的开发经验支撑。没有踩过坑，就不会意识到设计的重要性，无法产生共情。
3. 年代有些久远，这本书写于 2004 年，书中很多软件设计的反例，在当时是非常流行的，但是在现在已经基本绝迹了。大师之所以为大师，是因为其能跨越时代的限制，预见未来的问题，这也是为什么 DDD 在十几年前就被提出，却在微服务逐渐流行的现阶段才被大家重视。

诚然如标题所示，本文是领域驱动设计的一个入门文章，或者更多的是一个个人理解的笔记，笔者也正在学习 DDD 的路上，可能会有很多的疏漏。如有理解有偏颇的地方，还望各位指摘。

案例描述

本文主要描述了开发中常见的几个与 spring 懒加载和事务相关的案例，描述常见的使用场景，以及如何规避他们，给出具体的代码。

1. 在新的线程中，访问某个持久化对象的懒加载属性。
2. 在 quartz 定时任务中，访问某个持久化对象的懒加载属性。
3. 在 dubbo，motan 一类 rpc 框架中，远程调用时服务端 session 关闭的问题。

上面三个案例，其实核心都是一个问题，就是牵扯到 spring 对事务的管理，而懒加载这个技术，只是比较容易体现出事务出错的一个实践，主要用它来引发问题，进而对问题进行思考。