标签：颗粒度 数据管理 服务器 alt min string 地址 远程调用 ash
?1. 整体解决方案概述
? ? 权限设计主要有一下几大部分组成：
? ? ?PassPort：
? ? 针对现在系统的分析，系统之间有部分信息是共享的，这部分信息将由中心话的Passport来统一维护
? ?权限订阅模块：
? ?负责订阅接受Passport发出的相关实体修改的信息。
? ?资源权限绑定：
? ?有效的将资源-角色-组-成员在数据库中简历绑定。
? ?数据权限高速内存数据缓存:
? ?将数据权限相关的数据缓存在内存，提供高性能访问能力。
? ?Struts页面权限过滤和绑定：
? ?使用Struts的tag动态根据资源权限的设置，决定页面中资源(按钮，菜单，URL，页面元素)的访问能力。
? ?数据权限过滤：
? ? 根据数据过滤权限的特定，定义的数据权限过滤的通用数据结构。
? ? 根据业务集成和整合的需要，和优先级别的需要，权限部分的开发设计将逐步推进，初期会以各应用系统为单元进行资源权限和数据权限的改造，随后将根据重要业务系统的需要，逐步建立中心话的passport。
?
?（1）功能级授权采用通常的权限分组，角色绑定资源的通用设计思路来完成。基本设计思路如下图：
??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?资源权限绑定概览
? ? 资源：
? ? 菜单，按钮，URL，页面中的任何元素。
? ? 角色：
? ? 根据业务定义的各种角色，比如订单生成角色，结算角色等。
? ? 组：
? ? 用于联系角色和用户。
? ? 用户：
? ??系统中登录的用户。
?
（2）资源权限在开发，测试，项目上线后维护中的不同作用：
???项目开发和测试阶段：
? ?在项目上线之后和运维阶段：
??分组和角色分别都有两种类型，一种是管理类型，一种是普通类型，以下做详细说明：
? ?分组表设计(Group)
列 | 类型 | 空 | 说明 |
Id | Number(10) | Not null | PK |
Name | Varchar2(128) | Not null | 组名称 |
Admin | Boolean | Not null | 是否为管理类型 |
??功能级授权的意义在于对页面可见元素的操作性，单纯从页面的可见性可简单划分成如下几个部分：
? ?以上三点其实都可以归结为第三点，即：任何页面可见的元素均可纳入功能级权限管理。
实现方法：采用自写JSP标签完成，执行该标签时需要从后台或缓存中查找当前用户是否有使用当前资源的权限，如果有则正常显示，如果没有则将标签内所有内容从服务端剔除后再响应客户端。如下图：
? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 资源权限流程
[java]?view plain?copy
? ??页面元素的可见性并不能控制URL的可访问性，在系统设计中，使用Struts2的拦截器机制来过滤URL，防止用户不通过页面直接通过URL访问系统。
? ? 系统资源的抽取设计。
? ? 系统资源包含了以上提到的两个部分页面元素和URL，两种资源在某些时候是可组合的，比如按钮点击后提交URL，则该按钮与该URL可组成一个资源。
? ? 页面元素可独立成为一个资源，而URL不能脱离页面元素独立成为资源。每个资源都有唯一的标标识。
? ? 资源与资源之间也存在层级关系，比如下图：
? ? ? ? ? ??
列名类型(长度) 可否空 | 说明 |
Key?varchar2(256) not null | 标识资源的唯一的代码 |
Name?varchar2(256) not null | 资源名称 |
Url?varchar2(256) null | 对应的URL |
Parent_key?varchar2(256) null | 父资源代码 |
Desc?varchar2(256) null | ? ? ? ? ? ? ? ? ? ? ? ?描述或备注信息 |
? ? Key值的设定建议采用会意的字符串，比如新增按钮资源属于第三级资源则它的代码应该为"sysres_duty_add".
? ? ?对资源的授权采用ZTree插件实现，效果见下图：
? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?对资源进行管理的树状插件
[html]?view plain?copy
? ?
? ? ? ? ? ? ? ? ??数据权限业务关键字定义
?? ?
??
? ? ? ? ? ? ? ? ? ? ? ? ?岗码大体结构
?? ?
? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??岗码的格式规则
? ? ?岗码格式如下：
? ? ?岗位ID_岗位类型(管理/业务)_岗位职位_工贸ID_渠道ID_经营体ID_产品线code_BUCode_品牌_型号经营体.
? ? ?注意：根据业务需要，岗码会不断的扩充，以存储更多用于分析查询的信息.
??
? ? ? ? ??岗码生成和岗码从数据库刷新至业务服务器
?? ?
??定时更新策略
? 每天定时执行岗码更新SQL脚本，更新数据库中的岗码，并且定时重置内存中的数据缓存。这里建议采用增量式更新，否则对数据库压力过大。这里所使用的SQL脚本可参考下面第2点实时更新策略所使用的脚本。
??实时更新策略
? 对于更新相对较频繁的表（如人员表、岗位表），首先在该表上设立触发器，基于表做的所有修改将记录到历史表中，系统定时扫描历史表，发现改动则执行SQL脚本更新岗码，并更新缓存。这里的更新指单条记录的更新，非批量更新。
? 当蓝色部分使用应用服务的时候可以直接更新缓存，从而略过橙色部分活动图。
? 历史表ecc_oms.sys.his
列名类型(长度) 可否空 | 说明 |
Id Number(12) not null PK | PK |
Table_name varchar2(128) not null | 表名 |
PK_Valuevarchar(512) not null | 主键值如：123, 张三 |
PK_namevarchar(128) not null | 主键字段如：empId, empName |
Oper_type number(2) not null | 操作类型：增：1、删：2、改：3 |
Create_time Date not null | 创建时间 |
flag varchar2(1) not null | 完成标记位： 0：未完成，1完成 |
?? ?
?(1) 新增用户-岗位关系表和岗位-用户岗码关系表：ecc_oms.sys_emp_code
? Emp_id :用户ID
? Code_id:岗码ID-对应ecc_oms.ecc_oms.sys_code表主键
?(2) 岗位-客户岗码关系表：ecc_oms.ecc_oms.sys_cust_code
? Cust_code:客户code
? Code_id:岗码ID
??系统启动时，将所有岗码涉及到的表全部读取成JavaBean(不是持久化对象)，放在缓存中。
? ?/**********资源相关**********/
? ?人员信息: ?ecc_oms.sys_employee
? ?组织(部门信息)信息: ?ecc_oms.sys_org
? ?职位信息: ?ecc_oms.duty_title
? ?区域(工贸)基本信息-ecc_oms.sys_area_info
? ?所属产品线,产品系统的产品(型号)信息:ecc_fnd.product_v
? ?产品线信息:ecc_fnd.product_line_v
? ?大小渠道基本信息-ecc_fst.sales_channel_properties
? ?岗位基本信息:ecc_fst.station_config
? ?客户关系信息 -ecc_customer.customer_info_v
? ?BU信息表 -ecc_oms.sys_bu_info
? ?BU与产品线对应关系表 -ecc_fnd.bu_product_group_pl
? ?/*********授权相关*********/
? ?--组织经营体: ?ecc_oms.SYS_ORG_SALECHANN
? ?--组织产品线: ?ecc_oms.sys_org_prod
? ?--组织职位: ?ecc_oms.org_duty_title
? ?岗码表: ?ecc_oms.sys_station_config
? ?用户岗码表: ?ecc_oms.sys_emp_code
? ?客户岗码表: ?ecc_oms.sys_cust_code
? ?经营体与小渠道关系信息(按产品线): ecc_fst.sales_channel_manager_relation
? ?客户信息表-二级区域与客户关系表
? ?主要类列表和简单描述：
类/接口名 | 简介 | 核心接口描述 |
CacheServiceFacade | 暴露给客户端远程调用的接口 | 1.根据用户id和岗位查询该用户的客户列表，返回结果集自动关联客户对应的产品线信息? |
DefaultCacheServiceFacade | CacheServiceFacade的默认实现类，根据请求的岗位类型自动判断查找客户信息 | ?? |
CacheService | 从缓存中读取数据的顶层接口，定义内存中数据的读取接口 | 1.根据用户id查找用户信息? |
AbstractCacheService | CacheService的抽象实现，读取客户数据的公共方法抽取在里面 | ?? |
CacheServiceA | AbstractCacheService的子类实现，为MD_XSJL下单 门店销售经理查找客户逻辑 | ?? |
CacheServiceB | AbstractCacheService的子类实现，BU代表下单 | ?? |
CacheService | AbstractCacheService的子类实现，查询权限信息实现 | ?? |
CacheLoader | 缓存加载器 | 1.将指定表的数据加载到内存中? |
DefaultCacheLoader | CacheLoader接口的实现类 | ?? |
TableOperation | 对单表进行的操作接口，用户往操作历史里插入记录时单条更新/删除缓存操作 | 1.根据操作记录对缓存进行操作? |
AbstractTableOperation | TableOperation的抽象实现，定义公共操作方法 | ?? |
BasGCustomerInfoTableOperation? | AbstractTableOperation类的子类，表示? | ?? |
ReloadTableCacheJob | 定时任务，重新载入主数据表到缓存，每小时执行一次 | ?? |
UpdateCacheJob | 根据操作历史记录，对缓存中的数据进行单条更新，每15分钟执行一次 | ?? |
UpdateCodeJob | 定时任务，定期扫描岗码历史表ecc_oms.sys_his，调用存储过程，触发更新岗码操作，每10分钟执行一次 | ?? |
? ?
? ? 在客户端调用的应用中定义一个springbean,如下：
[html]?view plain?copy
? Java代码调用：
[html]?view plain?copy
? ? 将需要客户端调用的接口方法添加在CacheServiceFacade类中，并编写实现类。
? ? 客户端调用根据实际情况可进行调整，以下给出样例
[html]?view plain?copy
[html]?view plain?copy
标签：颗粒度 数据管理 服务器 alt min string 地址 远程调用 ash
原文地址：http://www.cnblogs.com/lxl57610/p/7144198.html
