PAD-网关
@RestController@RequestMapping(\"/Permission\")public class OrderController { @GetMapping(\"/check\
难点1：网关稳态，如何解决场景识别？方案1：能力中心各组注释，能力中心启动进行自身扫描，注册场景到redis中方案2：基础中心新建配置表，拦截URL、业务ID、校验类型。基础中心启动后加载redis
定义方法注解@Target(ElementType.METHOD)@Retention(RetentionPolicy.RUNTIME)public @interface DataPermission { Enum businessType();//定义不同业务场景，如客户号、合同号、申请流水号 String paramName() default \"id\"; //定义不同controller下vo对象映射的流水号字段，未避免同一个场景流水号命名不一致 boolean enableCache() default true;//是否需要走redis缓存 long cacheTTL() default 300L;//redis缓存的失效时间}
@FeignClient(name = \"payment-service\
2、方案二：查询中心提供1个接口，内部路由实现 优势：沿用原有方式，只需要依赖一个client， 劣势：数据非实时
1、方案一：client依赖，各能力中心实现 优势：沿用原有方式 劣势：各能力中心需要依赖全量其他能力中心
loan-PAD
方案二：网关Filter拦截请求，直连查询中心
@FeignClient(name = \"order-service\
公共拦截器
查询中心
作业中心
方案一：公共权限拦截器设计在公共模块中实现一个可配置的权限校验拦截器，统一处理所有需要权限校验的请求，并进行redis缓存。以jar包的形式依赖到各能力中心；步骤一：定义注解并标记场景步骤二：编写公共拦截器步骤三：根据标准接口，各能力中心实现校验逻辑（工厂模式）难点一：校验逻辑查询接口会分散在不同能力中心，client需要全量依赖违反框架难点二：如果业务交易无感，无性能影响
PC-网关
@Aspect@Componentpublic class DataPermissionAspect { @Autowired private PermissionHandlerFactory handlerFactory; //业务权限校验工厂类 @Autowired private PermissionCacheManager cacheManager; //缓存处理类 @Around(\"@annotation(dataPermission)\
@Datapublic class EmployeeDetailVO { private String employeeId; @PermissionControlled（paramName = \"orderId\"） private String orderId; private String phone; @PermissionControlled（paramName = \"idCardNumber\"） private String idCardNumber; private BigDecimal salary; private String orderId;}
redis
基础中心
根据标准接口，各能力中心实现校验逻辑1、方案一：client依赖，各能力中心实现 优势：沿用原有方式 劣势：各能力中心需要依赖全量其他能力中心2、方案二：查询中心提供1个接口，内部路由实现 优势：沿用原有方式，只需要依赖一个client， 劣势：数据非实时3、方案三：redis、ES缓存，直接获取 优势：不依赖能力中心，响应快 劣势：关系变更需要刷新缓存，设计复杂，对存量功能有改造
@RestController@RequestMapping(\"/orders\")public class OrderController { @DataPermission(businessType = \"order\
标记需要进行越权的二种方式1、方式一：定义注解 简单版本：方法注解（启用校验、校验字段名称） 优势：使用简单 劣势：无法满足多属性列表查询条件，如cstId、orderId 其中一个有值 复杂版本：方法注解（启用校验）+熟悉注解 （校验字段名称） 优势：方法与属性松耦合，个性化强，劣势：实现复杂
loan-PC
common-jarAOP权限校验拦截
客户中心
