上篇文章主要是搭建了一下Zuul的服务,并且实现了Zuul过滤器的自定义需求。

里边讲到了,Zuul 已经集成了 Ribbon、Hystrix ; 而 Ribbon无需配置,会在请求路由时自动给你进行负载均衡。

但是在Zuul服务路由不到对应微服务时,是没有对应的回退机制的,还是得自己手动写一下。

 

实现路由失败回退机制,首先需要继承 FallbackProvider 类,实现其getRoute() 和 fallbackResponse() 方法。

getRoute方法是指定你需要回退的线路,返回一个服务名就行。它会在路由该服务发生故障时调用 fallbackResponse 方法从而返回你一个 ClientHttpResponse 对象。

 

我写的回退代码:

 

 

这个代码会在路由到sc-demo-microservice-user这个服务出错时触发,然后根据不同的异常给出不同的响应(我这就是变了个Status哈)

配上一个回退机制后,就让Zuul服务更加完善健壮了,这样子,就算路由的服务挂掉了,我也能返回个东西让前端显示,也能做一些其余的抢救操作。

 

Zuul这个服务到这,其实也就差不多了,该有的都有,虽说也有Zuul这个服务挂掉的可能,但是Zuul也是可以集群的呀,前端可以访问一个负载均衡的服务器(比如Nginx),让他来转发请求到集群Zuul服务上边,这样子,整个微服务架构就非常健壮了(像这种Nginx服务一般不会挂哈,就一个纯走流量的服务器都能挂了,那你的流量是有多猛   除非硬件问题,那没辙)

 

咳咳, 说起来Zuul服务搭是搭好了,但是你就做一个服务路由+负载均衡,那也不是个事啊,我客户端那边请求服务,我要是需要多个数据,我是不是要发多个请求?

每个请求都要走–>zuul–>service 这一套流程,是不是不大好,毕竟我发多个请求来请求多个服务,总会有性能损耗。

那要是我就发一个请求到Zuul Server ,然后由Zuul 来帮我聚合请求多个微服务,包装成一个数据返回响应给我好不好鸭,那当然是极好的。这些微服务所在的服务器八成是在一个局域网里(除非你买的实例所在地区不同甚至供应商都不同哈) 那个网络传输速度,快的飞起来。

 

这个是我写请求聚合的代码:

 

我这就请求了zuul一个服务,然后就全权交给zuul给我把我要的数据都拿到了,组合成一个数据响应给我,是不是非常nice。我客户端的请求代码编写,也变得简单了。

 

到现在为止,整个Zuul架构就差不多了。自定义过滤器、回退、请求聚合、我还提供了一个zuul的集群高可用方案。基本上可以满足大多生产需求。

我的项目地址:Github

阅读全文

其实SpringDataJPA很方便,虽然他是重量级ORM框架,但是在SQL定制上一点都不输于Mybatis。

用@Query注解能使用QueryDsl语法。将nativeQuery属性设置为true就能使用原生SQL手写,也就是Mybatis一样的效果。

实现方式也挺简单的,DAO层接口继承一下CrudRepository就可以进行开发。看国内用的少,应该是因为比较新吧。

这是目前最新的官方文档,里边很多操作可以学习https://docs.spring.io/spring-data/jpa/docs/2.1.3.RELEASE/reference/html/

 

那么SpringDataJPA在代码中如何进行优雅的动态查询呢 ?

如何通过各种条件组装不同的SQL呢 ?

在复杂SQL中为了避免全表扫描要用函数代替某关键字要如何使用呢?

 

使用SpringDataJPA后,DAO层接口一般会继承JpaRepository接口,它可以提供大量供开发者使用的重载查询方法。

比如带Sort的findAll()方法可以按照指定列排序,带Pageable 的findAll()方法可以轻松地实现分页+排序的功能。

但是对于动态查询、复杂SQL来说还是少了。普通的复杂SQL,子查询左右连接啥的,大不了用@Query注解手写。

但是要再加上动态就不一样了。三个参数就会有七种查询方式(1/2/3/12/13/23/123)。总不能写七个方法定制吧。

莫慌,这个时候, JpaSpecificationExecutor 该接口应该就是所需要的了。

 

来看看 JpaSpecificationExecutor  接口自带的方法:

T findOne(Specification<T> spec);
List<T> findAll(Specification<T> spec);
Page<T> findAll(Specification<T> spec, Pageable pageable);
List<T> findAll(Specification<T> spec, Sort sort);
long count(Specification<T> spec);

 

 

最核心的就是 Specification 这个入参。

若想使用 JpaSpecificationExecutor  该接口的方法,则需要创建出实现了 Specification 的对象。然后将其作为查询条件才行。

这是Specification接口:

 

关于 toPredicate() 的几个核心参数 :

  • CriteriaQuery
    接口:该接口定义了顶级查询功能,它包含着查询到各个部分,如:select、from、where、group by、order by 等,CriteriaQuery 对象必须在实体类或嵌入式类型上才起作用
  • CriteriaBuilder
    类:它是 CriteriaQuery 的工厂类,用于构建 JPA 安全查询,可通过 EntityManager.getCriteriaBuilder 而得
  • Root
    接口:该接口继承了 From接口,From 接口继承了 Path 接口,该代表 Criteria 查询的根对象,定义了查询的实体类型,类似于 SQL 中的 FROM 子句,可有多个查询根
  • Predicate
    接口:代表了简单或复杂的查询断言(语句),一个 Predicate 可认为由多个连接词构成

 

这是我在公司写的一个model,可以接收前台用户输入的参数,然后通过一个getSpecification() 方法获取一个Specification实现。

之后该Specification即可作为入参进行 findAll() 的查询。

用来举例应是足够了。

我是用了一个lambda来实现 , 没用过JDK1.8以上版本的可以使用 new Specification 也是一样的。

 

可以看到我的标题匹配使用了mysql的 locate 函数,为的就是避免like关键字的效率低下。

再加上between and获取两个参数的区间,最后还带了一个in,  关键是这几个值都是动态的!若不满足条件则不会进行拼接!

若是该model的值全为默认, 通过这个get方法获取的 Specification 默认就变成一个 WHERE 1=1 的子句。

否则则会根据传入的值返回相应的表达。可以算是比较优雅了。

 

最后,以上边代码的

举个栗子,具体说明一下,这个Predicate是怎么得来的,代表了什么逻辑。

root.get(“title”) 表示为我查询的表(TaoBaoItem)中一个名为 title的列。

cb.locate() 代表使用mysql的 locate函数,它可以找出字符串中一个子串的位置/下标。

 

LOCATE(substr,str) :返回子串 substr 在字符串 str 中第一次出现的位置。如果子串 substr 在 str 中不存在,返回值为 0: 

 

 

cb.gt() 表示 > 符号,gt应该清楚,到处都能用到。第一个参数我填入LOCATE函数,第二个写了个0。

这个Predicate若是以sql的形式表示出来,则是这样子的:

 

这么一举例大概就明白了⑧ , Specification 来定制 sql 确实是好用啊。

 

 

 

 

阅读全文

 

又到了我第二喜欢的玩反射时间了。真快乐啊。

如标题所说,我写了个权限控制。权限控制的精髓就是限制用户访问范围。一个系统,总得有后台、管理者这些绕不开的玩意儿。

还有用户所代表的各种不同角色,如游客、登陆者、管理员、代理商、作者、编辑,等等等等。他们这些角色在一个庞大的系统里能够操作的地方总归是不同的。

如果单单依赖前端的权限控制,难免会被人家利用抓包之类的手段获取其他角色能操作的区域信息来做一些危险操作。

后端的权限控制是必不可少的,当然,在java领域现在SpringSecurity、shiro之类的安全框架肯定是一个优选,我很久之前也写过关于SpringSecurity的配置,可见: Spring Security集成以及配置

但是我就是tm要自己写一个,哎嘿嘿,(⁄ ⁄•⁄ω⁄•⁄ ⁄)

 

咳咳,关于我写的这个权限控制,我自己感觉还是特别骚的。亲自试了两天,确实没什么问题。我需要它能够做它确实做到了。

下面详细解释一下。

这个注解,是关键。里面有一个内部枚举,与其息息相关。注解的唯一一个参数就是该枚举。

@Impower 注解代表需要控制

Level 枚举表示控制范围

 

实现的效果就是:在上(Controller层的)写入该@Impower 注解,例如: @Impower(level = Impower.Level.Admin) ,那么,即代表该类需要权限控制,并且只有 Admin 这个角色,或者比Admin角色权限更高的角色 ,才能够请求该类中的方法。

如果在方法上加入该@Impower 注解,如果@Impower同时存在类上,外部请求该方法时,则会无视类注解,按照方法上该注解来进行判定权限是否能够访问。

Level 枚举内部的权限可自己随意定义,只要保证其权限范围顺序从左到右、从上到下线性递减即可。

注:系统的用户必须有一个属性是以Impower . Level 作为其类型。才能够进行权限控制。

 

前后端均可使用,前台可通过thymeleaf、freemark等模板来对用户显示进行控制,若是前后端分离的项目也没事,请求后台的时候做一下check()判定就好了。

并且想修改非常方便,这已经很极限的做到了降低耦合。想要增加不同的权限也好、修改某些方法可访问的权限也好、前台对权限的控制也好。有变更只需要更改很小的地方。

 

 

这儿是具体进行权限判定、从而决定是否放行的拦截器,关于SpringBoot的拦截器配置,若有不清楚的地方可看我之前写过的文章:

SpringBoot使用WebMvcConfigurerAdapter+HandlerInterceptorAdapter实现拦截

 

这里我对基本只会验证是否登录的拦截器做了拓展,获取了该请求所请求的类、方法上的注解,从而通过Session中的已登录对象来进行判定权限是否能够访问。

会使用Level  中的 check() 方法来进行判定该登陆角色的权限是否能够通过。

若通过判定,则成功访问该页面(能够正常请求响应),若判定失败,则请求失败,但是response状态码仍然会是200,只不过返回的内容是空罢了。

 

又写了一些骚东西,别的不嗦,我这玩意写出来还真挺好用的。实际体感顺滑流畅,代码优雅,功能简洁却强悍。

但是后端的权限控制可不止这么点哦,最好与JWT(JSON Web Token)进行同步使用,我本来也想自个写个Token验证之类的玩玩,妈耶想起来是有点麻烦,还是算了,我还是挺懒得。

阅读全文

虽然网上说 WebMvcConfigurerAdapter 已经过时了,但是我看我的 SpringBoot 里用的还是好好的。

而且这个确实也比较容易理解,比较简单。可以很轻易的实现拦截、过滤功能。

如下是我写的一个登陆拦截的例子,只有在 session 域中 adminUser 该 key 下有值的话才会跳转到能够登陆的页面

我这拦截的是所有路径,对登录页和登陆的登陆验证ajax请求做了开放。即除登陆也页以外所有页面都需要登录才能进入,不然就跳转到登录页。

我代码注释还是写的很清晰的。应该算便于理解

 

 

阅读全文

弹框宽高自适应,核心代码

 

阅读全文
EA PLAYER &

历史记录 [ 注意:部分数据仅限于当前浏览器 ]清空

      00:00/00:00