paul的专栏

若依的数据权限实现思路和过程（二）-数据模型

今天研究了下 若依的数据权限，还是很有收获，尤其从全县管理的思路上。 其基本实现思路是通过注解的方式，把需要权限通知的部分在注解中提前拼接好，当使用的时候根据注解中传入的 参数决定控制的权限范围。 过程大致如下 一、自定义注解 二、通通过切面方式来处理需要进行权限管理的方法 三、需要进行权限控制的方法 四、把aspect拦截加工好的sql在mybatis中进行处理 ，已达到数据权限控制的目的 ps： 第四部的params.dataScope 这个怎么来的？ 所有对象都集成了一个基类：BaseEnt

Spring Cloud Feign的使用方法主要有以下两种方式： 1、服务提供者的RequestMapping和Feign接口的RequestMapping保持一致的形式 2、 服务提供者实现Feign接口的形式 两种调用方式主要体现在服务提供者的写法上 同一个feign接口： 第一种实现方式： 第二种实现方式 ...

在项目中，大部分都会使用到hyrtrix做熔断机制，通过某个预定的阈值来对异常流量进行降级处理，除了做服务降级以外，还可以对服务进行限流，分流，排队等。 当然，zuul也能做到限流策略，最简单的方式就是使用自定义的filter加上限流算法，生产环境中zuul网关肯定是部署的多节点，所以还会借助类似Redis的K/V存储工具。 这里借助的是第三方工具《spring-cloud-zuul-ratelimit》，开箱即用，直接加入pom依赖即可： <dependency> &l

前言 在生产环境中，如何保证在服务升级的时候，不影响用户的体验，这个是一个非常重要的问题。如果在我们升级服务的时候，会造成一段时间内的服务不可用，这就是不够优雅的。那什么是优雅的呢？主要就是指在服务升级的时候，不中断整个服务，让用户无感知，进而不会影响用户的体验，这就是优雅的。 实际上，优雅下线是目标，而不是手段，它是一个相对的概念，例如kill PID和kill -9 PID都是暴力杀死服务，相对于kill -9 PID来说，kill PID就是优雅的。但如果单独拿kill PID出来说，我们能说它是

业务需求： 有个AService和BService都配置了事务，AService调用了BService，BService需要记录日志，但是当BService出现异常的时候，发现没有记录日志，原因是AService和BService配置事务的时候有个参数propagation，默认都配置了REQUIRED <tx:method name=“save*” propagation=“REQUIRED”/> 使用这种策略时BService将使用Aservice的事务，所以AService回滚将整个方法体