【REST2SQL】14 基于角色的数据权限设计与实现

【REST2SQL】01RDB关系型数据库REST初设计
【REST2SQL】02 GO连接Oracle数据库
【REST2SQL】03 GO读取JSON文件
【REST2SQL】04 REST2SQL第一版Oracle版实现
【REST2SQL】05 GO 操作 达梦 数据库
【REST2SQL】06 GO 跨包接口重构代码
【REST2SQL】07 GO 操作 Mysql 数据库
【REST2SQL】08 日志重构增加输出到文件log.txt
【REST2SQL】09 给Go的可执行文件exe加图标和版本信息等
【REST2SQL】10 REST2SQL操作指南
【REST2SQL】11 基于jwt-go生成token与验证
【REST2SQL】12 REST2SQL增加Token生成和验证
【REST2SQL】13 用户角色功能权限设计


0 前言废话

0.1 常见的权限管理模型

  • ACL ACL的全称是 Access Control List (访问控制列表)
    ACL 是最简单的权限管理模型之一。它基于对象与主体之间的关系来控制访问权限。ACL 将权限直接与用户或用户组相关联,管理员直接给用户授予某些权限即可。
    这种模型适用于小型和简单系统,其中权限控制较为简单,并且角色和权限的变化较少。

  • RBAC(Role-Based Access Control,基于角色的访问控制)
    RBAC 是应用最广泛的权限管理模型之一。它通过定义角色和角色的权限集合来管理访问控制。用户被分配到角色,角色与权限相关联,从而精确地控制用户对系统资源的访问。
    RBAC 适用于大型系统,特别是那些需要灵活、可扩展的权限管理的场景。使用 RBAC 可以简化权限管理的复杂性并提高系统的安全性。
    RBAC权限管理的模式,最适合公司内部的管理系统,不适合对外互联网用户的系统。

  • ABAC(Attribute-Based Access Control,基于属性的访问控制)
    ABAC(Attribute-Based Access Control,基于属性的访问控制),又称为PBAC(Policy-Based Access Control,基于策略的访问控制),或CBAC(Claims-Based Access Control,基于声明的访问控制)。ABAC 是一种基于属性的权限管理模型,它根据多个属性(如用户属性、环境条件、时间等)来进行访问控制决策。ABAC 通过定义策略来决定用户是否有权访问特定的资源。
    这种模型适合于需要更细粒度、动态和灵活的访问控制的场景。ABAC 在复杂的环境中可以提供高度的可配置性和可扩展性。

0.2 数据权限分级

  • 系统级
  • 对象级,表或视图
  • 行级,表或视图的行
  • -列级,表或视图的具体字段

1 数据权限设计

权限管理的核心是角色,角色上接用户,下接功能,功能关联数据。
权限管理的5大实体 : 用户-角色=页面#数据,角色-数据对象关系
实体之间的关系:用户1对多角色,角色1对多页面,页面1对多数据,角色1对多数据。
实体及关系图如下:
在这里插入图片描述
此数据权限设计兼顾了灵活与通用。

  • 支持一个用户多角色,多角色都关联同一数据对象时,用户的数据权限是多个角色数据权限的并集。比如一个用户 user1 分配了2个角色 role1 和 role2,则user1 可以查阅 role1 和 role2 所有数据。
  • 根据角色的功能权限自动获取相关数据对象(视图或表),并在角色上定义数据权限约束 Where条件。

1.1 权限实体(表)设计

  • 用户表 s_user (p_id, s_name, s_passw…)
  • 角色表 s_role (p_id, s_name…)
  • 页面表 s_menu(p_id, s_name,s_page…)
  • 数据(对象)视图 user_tabs_views
  • 角色-数据权限表s_role_data(pf_role,pf_data,s_where)
    数据对象包括表和视图。
-- Oracle 数据库的表和视图
CREATE OR REPLACE VIEW USER_TABS_VIEWS AS
SELECT TABLE_NAME,TABLE_TYPE,COMMENTS,tab_cnt(table_name) as rowcount
FROM user_tab_comments
order by table_type,table_name;
comment on table USER_TABS_VIEWS is '用户表及视图';

1.2 权限关系(表)设计

  • 用户角色关系表 s_user_role (pf_user,pf_role…)
  • 角色功能权限关系表 s_role_menu (pf_role,pf_menu…)
  • 页面数据对象关系表 s_menu_data (pf_menu,pf_data…)
  • 角色数据对象权限关系表 s_role_data (PF_ROLE,PF_DATA,s_where,s_note…)
    角色项下所有功能页面关联的数据对象的集合(页面和数据是多对多的关系,此集合不去除了重复的数据对象)

1.3 角色数据权限视图设计

其它视图参阅 【REST2SQL】13 用户角色功能权限设计

  • 角色关联的数据对象视图,就是角色功能权限用到的数据对象。
	create or replace view role_data_v as
	select distinct m.pf_role, d.pf_data
	from S_MENU_DATA d
	left join s_role_menu m on m.pf_menu = d.pf_menu
	where m.pf_role is not null;
	comment on table ROLE_DATA_V is '角色关联的数据对象视图';
  • 角色数据权限重置连接表,就是角色功能权限或功能数据对象发生变化时,角色当前数据权限和应该拥有的数据权限对照视图
create or replace view role_data_join_v as
select "CROLE","CDATA","HROLE","HDATA"
from ( select pf_role as crole, pf_data as cdata from S_ROLE_DATA  ) c
full outer join (select pf_role as hrole, pf_data as hdata from role_data_v  ) h
 on h.hdata = c.cdata  and h.hrole = c.crole;
comment on table ROLE_DATA_JOIN_V is '角色数据权限重置连接表';

1.4 角色数据权限更新的存储过程

角色-功能权限或功能-数据对象发生变化时,执行此存储过程变更角色的数据权限,增加或删除角色的数据对象权限。

	CREATE OR REPLACE PROCEDURE reset_role_data
	IS
	--PRAGMA AUTONOMOUS_TRANSACTION;
	BEGIN
	  
	    -- 这里放置处理数据的代码
	    NULL; -- 示例中,我们不执行任何操作
	
	    for rec in ( select crole,cdata,hrole,hdata from role_data_join_v ) loop
	      if rec.crole is null then
	        --当前角色插入数据对象
	        dbms_output.put_line('A 当前角色增加数据对象...');
	        insert into s_role_data (pf_role,pf_data) values (rec.hrole,rec.hdata);
	      end if;
	
	       if rec.hrole is null then
	         --当前角色删除数据对象
	         dbms_output.put_line('B 当前角色删除数据对象...');
	         delete from s_role_data where pf_role = rec.crole and pf_data = rec.cdata;
	      end if;
	    end loop;
	
	    --提交数据操作数据
	    --commit;
	
	END;

1.5 触发器设计

  • 功能s_menu_data数据对象变化时触发器,功能页面数据对象变化时触发
	create or replace trigger s_menu_data_trigger
	  FOR INSERT OR DELETE on s_menu_data
	  compound TRIGGER
	/*
	  BEFORE STATEMENT IS -- 语句执行前触发(表级)
	  BEGIN
	    DBMS_OUTPUT.put_line('1、BEFORE STATEMENT .');
	  END BEFORE STATEMENT;
	
	  BEFORE EACH ROW IS -- 语句执行前触发(行级)
	  BEGIN
	    DBMS_OUTPUT.put_line('2、BEFORE EACH ROW .');
	  END BEFORE EACH ROW;
	
	  AFTER EACH ROW IS -- 语句执行后触发(行级)
	  BEGIN
	    DBMS_OUTPUT.put_line('3、AFTER EACH ROW .');
	  END AFTER EACH ROW;
	*/
	  AFTER STATEMENT IS -- 语句执行后触发(表级)
	  BEGIN
	    DBMS_OUTPUT.put_line('4、AFTER STATEMENT .');
	    reset_role_data;
	  END AFTER STATEMENT;
	
	end s_menu_data_trigger;
  • 角色s_role_menu功能权限变更时触发器,角色功能权限变化时触发
	create or replace trigger s_role_menu_trigger
	  FOR INSERT OR DELETE on s_role_menu
	  compound TRIGGER
	
	/*
	  BEFORE STATEMENT IS -- 语句执行前触发(表级)
	  BEGIN
	    DBMS_OUTPUT.put_line('1、BEFORE STATEMENT .');
	  END BEFORE STATEMENT;
	
	  BEFORE EACH ROW IS -- 语句执行前触发(行级)
	  BEGIN
	    DBMS_OUTPUT.put_line('2、BEFORE EACH ROW .');
	  END BEFORE EACH ROW;
	
	  AFTER EACH ROW IS -- 语句执行后触发(行级)
	  BEGIN
	    DBMS_OUTPUT.put_line('3、AFTER EACH ROW .');
	  END AFTER EACH ROW;
	*/
	
	  AFTER STATEMENT IS -- 语句执行后触发(表级)
	  BEGIN
	    DBMS_OUTPUT.put_line('4、AFTER STATEMENT .');
	    reset_role_data;
	  END AFTER STATEMENT;
	
	end s_role_menu_trigger;

1.6 用户-数据权限

  • 用户-角色关系视图
create or replace view user_role_v as
select r.p_id as r_id,r.s_name ,s.pf_user,u.p_id as u_id,
  decode(length(s.pf_role),4,1,0) as b_yn
 from s_role r
cross join s_user u --先做一个用户与角色的笛卡尔交叉,再连接用户角色表
left join s_user_role s on s.pf_user = u.p_id and s.pf_role = r.p_id
order by u.p_id,r.p_id
;
comment on table USER_ROLE_V is '用户角色勾选';

在这里插入图片描述

  • 用户-数据视图
create or replace view user_data_v as
select distinct u.u_id, u.r_id, --多角色同一个数据对象,用户的数据权限用 or 连接
       d.pf_data, d.s_where
  from user_role_v u --用户-角色关系视图
  left join s_role_data d -- 角色-数据表
    on d.pf_role = u.r_id
 where d.pf_data is not null and u.pf_user is not null
 ;
 
 comment on table USER_data_V is '用户-数据权限';

1.7 用户-数据权限字符串生成函数

根据用 用户 userid 和 数据对象 dataid 查询user_data_v 视图生成数据权限字符串,此字符串作为 sql 语句的 Where的一部分。

CREATE OR REPLACE FUNCTION GET_DATA_WHERE (userid varchar2,dataid varchar2) RETURN varchar2 is
  -- 获取userid的dataid的数据权限Where字符串
  where_str varchar2(512) := ' ';
BEGIN

  for curs in (select s_where,r_id from user_data_v where u_id = userid and pf_data = upper(dataid) ) loop
    --DBMS_OUTPUT.PUT_LINE(curs.r_id || ':' || curs.s_where);
    -- 循环组合where字符串,用 or 连接
    if curs.s_where is null then
      --定义了数据对象,权限where为空的,用 1=1 表示没有数据权限控制
       where_str := ' ';
    else
       where_str := where_str || curs.s_where || ' or ';
    end if;
  end loop;

  if instr(where_str,'or') > 5  then
    where_str := substr(where_str,1,length(where_str) - 3); --去除最后的 or
  else
    --没有定义的数据对象(游标返回行数为0)返回null
    where_str := null;
  end if;
  
  return where_str;
END GET_DATA_WHERE;

2 数据权限的后端实现

基于以上的用户数据权限设计,后端验证 token 时返回用户的帐号 userid ,根据用户的 userid 和 数据对象 dataid 显示数据的访问范围。

2.1 创建数据权限函数 getDataWhere

// 获取用户 userid 的数据对象 dataid 的数据权限 where 字符串
func getDataWhere(userid string, dataid string) string {
	dataID := strings.ToUpper(dataid) // 数据对象名改为大写
	sSql := "select get_data_where('" + userid + "','" + dataID + "') as s_where from dual"
	result := Icrud.SelectData(sSql)

	var swhere []map[string]string
	err := json.Unmarshal([]byte(result), &swhere)
	if err != nil {
		panic(err)
	}
	//fmt.Println(swhere)
	s_where := swhere[0]["S_WHERE"]

	return s_where
}

2.2 重构token验证函数

增加返回 token 里的 userid

// token 验证函数
func vToken(w http.ResponseWriter, tokenString string) (string, int) {
	tokenmap := make(map[string]interface{})
	tokenmap = token.ValidateTokenHandler(w, tokenString)
	if tokenmap["status"] != http.StatusOK {
		// 抛出错误信息
		httpResWriter(w, tokenmap)
		return "", 401
	}
	// 返回userid 和 200
	return tokenmap["userid"].(string), 200
}

2.3 Token验证时保存Userid

REST请求时验证token,代码片段:

switch req["RESTorSQL"] {
	case "REST":
		// 是否配置了需要token验证
		if config.Conf.OpenToken {
			// token有效性验证
			tokenString := req["Authorization"].(string)
			userid, status := vToken(w, tokenString)

			if status != 200 {
				return
			}
			req["Userid"] = userid //token里的userid
		}

2.4 Where 条件增加数据权限

// 根据 userid 和 数据对象 加数据权限,数据库函数 get_data_where实现,返回的where 用 and 连接
	if config.Conf.OpenToken {
		userid := req["Userid"].(string)

		dataWhere := getDataWhere(userid, resName) // 数据权限 where
		urlWhere := qry["Where"]                   // url 上的 where
		if len(dataWhere) > 3 {
			if len(urlWhere) > 3 {
				// 如果有数据权限约束就加上
				qry["Where"] = qry["Where"] + " and (" + dataWhere + ")"
			} else {
				qry["Where"] = dataWhere
			}
		}
	}

3 前端实现

3.1 页面-数据对象设置

创建一个页面-数据对象设置页面即可。这个需要开发人员来设置,只有开发人员才知道页面用到那些数据,当然不进行数据权限约束的数据对象是不需要设置的。
在这里插入图片描述

3.2 角色-数据对象权限设置

创建角色-数据对象权限设置页面即可。就是定义sql查询语句的where条件,这个也由开发人员设置。
在这里插入图片描述

3.3 用户-数据权限查询

创建查询用户的数据权限页面
在这里插入图片描述

4 实操演练

4.1 设置页面-数据对象

在这里插入图片描述

4.2 设置角色-数据权限

  1. 新建一个角色 YSSH
  2. 设置功能权限
    在这里插入图片描述
  3. 设置角色-数据权限
    在这里插入图片描述

4.3 查询用户-数据权限

  1. 设置用户-角色 在这里插入图片描述
  2. 查询用户-数据权限
    在这里插入图片描述

4.4 用户登录

在这里插入图片描述

4.5 企业管输需求

在这里插入图片描述
如上图,列表只显示本企业的数据,企业ID的列选也只有本企业可选了。
后台的SQL查询语句类似如下:

select *
  from dd_xuqiu
 where to_char(date_t, 'YYYY-MM-DD') >= '2022-07-10' 
   and qy_id = nvl('', qy_id)
   and yz_id = nvl('', yz_id)
   and (qy_id = 'Q0010')

其中 qy_id = ‘Q0010’ 就是权限控制条件。

5 跋尾

此数据权限基于管输管理平台设计,管输平台主要角色有总部、企业、油库、港口、货代等,不用角色的数据权限都不同,还有很大差别,此设计完全满足数据权限的管理。如果参与的主体很多年的话,可能会有角色组合爆炸。
对于有层级关系的数据也基本能实现数据权限的控制。不需要构建组织机构表,但要用角色实现组织机构关系。


本文完

  • 12
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
基于Spring Boot的医药管理系统是一个针对药店或药房管理药品、销售、库存及客户信息的综合应用程序。该系统利用了Java开发平台,特别是Spring Boot框架,以及MySQL作为后端数据库,以实现快速开发和易于部署的微服务架构。 技术栈主要包括: Spring Boot:用于简化新Spring应用的初始搭建以及开发过程,提供默认配置来快速启动项目。 Spring Data JPA:简化数据库操作,自动生成SQL语句,实现对MySQL数据库的高效访问。 Spring Security:用于实现系统的认证和授权,确保数据安全。 Thymeleaf:作为模板引擎,用于前端页面的动态渲染。 Maven/Gradle:用于项目的依赖管理和构建。 MySQL:作为后端数据库,存储所有的药品信息、交易记录和用户数据RESTful API:设计符合REST原则的接口,便于不同前端设备或系统与后端服务交互。 功能特点包括: 药品信息管理:允许管理员添加、修改、删除和查询药品信息,包括药品名称、生产厂家、价格、库存量等。 库存管理:自动跟踪药品库存变化,及时提醒库存不足,支持库存补充操作。 销售管理:处理药品的销售流程,记录每一笔销售的详细信息,包括销售时间、数量、顾客信息等。 客户管理:维护顾客信息数据库,记录顾客的购买历史和偏好。 报表统计:提供销售和库存相关的统计报表,辅助做出商业决策。 权限控制:根据用户角色分配不同的操作权限,保障系统的安全性。 总之,该医药管理系统通过整合现代Java开发的最佳实践,提供了一个健壮、可扩展且易于维护的解决方案,适用于毕业设计项目,能够展示学生在软件开发方面的综合能力。
JeeSpringCloud是一个基于SpringBoot2.0的后台权限管理系统,界面简洁美观敏捷开发系统架构。核心技术采用Spring、MyBatis、Shiro没有任何其它重度依赖。 互联网云快速开发框架,微服务分布式代码生成的敏捷开发系统架构。项目代码简洁,注释丰富,上手容易,还同时集中分布式、微服务,同时包含许多基础模块和监控、服务模块。模块包括:定时任务调度、服务器监控、平台监控、平台设置、开发平台、单点登录、Redis分布式高速缓存、会员、营销、在线用户、日志、在线人数、访问次数、调用次数、直接集群、接口文档、生成模块、代码实例、安装视频、教程文档 代码生成(单表、主附表、树表、列表和表单、redis高速缓存对接代码、图表统计、地图统计、vue.js)、dubbo、springCloud、SpringBoot、mybatis、spring、springmvc。 功能 用户管理:用户是系统操作者,该功能主要完成系统用户配置。 部门管理:配置系统组织机构(公司、部门、小组),树结构展现支持数据权限。 岗位管理:配置系统用户所属担任职务。 菜单管理:配置系统菜单,操作权限,按钮权限标识等。 角色管理:角色菜单权限分配、设置角色按机构进行数据范围权限划分。 字典管理:对系统中经常使用的一些较为固定的数据进行维护。 参数管理:对系统动态配置常用参数。 通知公告:系统通知公告信息发布维护。 操作日志:系统正常操作日志记录和查询;系统异常信息日志记录和查询。 登录日志:系统登录日志记录查询包含登录异常。 在线用户:当前系统中活跃用户状态监控。 定时任务:在线(添加、修改、删除)任务调度包含执行结果日志。 代码生成:前后端代码生成(单表、主附表、树表、列表和表单、增删改查云接口、redis高速缓存对接代码、图表统计、地图统计、vue.js) ,并生成菜单和权限直接使用。 系统接口:根据业务代码自动生成相关的api接口文档。 连接池监视:监视当期系统数据库连接池状态,可进行分析SQL找出系统性能瓶颈。 在线接口文档:使用swager生成在线文档。 ActiveMQ队列:提供ActiveMQ队列,处理批量发送大数据量邮件、大数据量日志文件。 工作流:功能包括在线办公、我的任务、审批测试、流程管理、模型管理。 CMS:功能包括内容管理、内容管理、统计分析、栏目设置、首页。 dubbo:代码生成直接生成dubbo对接代码。 服务器Down机邮件监控:通过定时任务监控服务器是否Down机,并发送通知邮件。 服务器监控:通过sigar进行服务器图形化监控。 异常邮件监控:全局拦截系统异常,并发送通知邮件。 单点登录:使用shior和Redis、共享session方式实现单点登录。 Redis分布式高速缓存:代码生成直接生成Redis对接代码。 特性: JeeSpringCloud基于SpringBoot+SpringMVC+Mybatis+Redis+SpringCloud+Vue.js微服务分布式代码生成的敏捷开发系统架构。项目代码简洁,注释丰富,上手容易,还同时集中分布式、微服务,同时包含许多基础模块(用户管理,角色管理,部门管理,字典管理等10个模块。成为大众认同、大众参与、成就大众、大众分享的开发平台。JeeSpring官方qq群(328910546)。代码生成前端界面、底层代码(spring mvc、mybatis、Spring boot、Spring Cloud、微服务的生成)、安全框架、视图框架、服务端验证、任务调度、持久层框架、数据库连接池、缓存框架、日志管理、IM等核心技术。努力用心为大中小型企业打造全方位J2EE企业级平台ORM/Redis/Service仓库开发解决方案。一个RepositoryService仓库就直接实现dubbo、微服务、基础服务器对接接口和实现。 努力用心为大中小型企业打造全方位J2EE企业级平台开发解决方案。 Spring Boot/Spring cloud微服务是利用云平台开发企业应用程序的最新技术,它是小型、轻量和过程驱动的组件。微服务适合设计可扩展、易于维护的应用程序。它可以使开发更容易,还能使资源得到最佳利用。 微服务/集群(nignx) 支持REST风格远程调用(HTTP + JSON/XML):基于非常成熟的Spring Boot框架,在Spring Boot Spring Cloud中实现REST风格(HTTP + JSON/XML)的远程调用,以显著简化企业内部的跨语言交互,同时显著简化企业对外的Open API、无线API甚至AJAX服务端等等的开发。 事实上,这个REST调用也使得Dubbo可以对当今特别流行的“微服务”架构提供基础性支持。 另外,REST调用也达到了比较高
源码简介与安装说明: JeeSpringCloud是一个基于SpringBoot2.0的后台权限管理系统,界面简洁美观敏捷开发系统架构。核心技术采用Spring、MyBatis、Shiro没有任何其它重度依赖。 互联网云快速开发框架,微服务分布式代码生成的敏捷开发系统架构。项目代码简洁,注释丰富,上手容易,还同时集中分布式、微服务,同时包含许多基础模块和监控、服务模块。模块包括:定时任务调度、服务器监控、平台监控、平台设置、开发平台、单点登录、Redis分布式高速缓存、会员、营销、在线用户、日志、在线人数、访问次数、调用次数、直接集群、接口文档、生成模块、代码实例、安装视频、教程文档 代码生成(单表、主附表、树表、列表和表单、redis高速缓存对接代码、图表统计、地图统计、vue.js)、dubbo、springCloud、SpringBoot、mybatis、spring、springmvc。 功能 用户管理:用户是系统操作者,该功能主要完成系统用户配置。 部门管理:配置系统组织机构(公司、部门、小组),树结构展现支持数据权限。 岗位管理:配置系统用户所属担任职务。 菜单管理:配置系统菜单,操作权限,按钮权限标识等。 角色管理:角色菜单权限分配、设置角色按机构进行数据范围权限划分。 字典管理:对系统中经常使用的一些较为固定的数据进行维护。 参数管理:对系统动态配置常用参数。 通知公告:系统通知公告信息发布维护。 操作日志:系统正常操作日志记录和查询;系统异常信息日志记录和查询。 登录日志:系统登录日志记录查询包含登录异常。 在线用户:当前系统中活跃用户状态监控。 定时任务:在线(添加、修改、删除)任务调度包含执行结果日志。 代码生成:前后端代码生成(单表、主附表、树表、列表和表单、增删改查云接口、redis高速缓存对接代码、图表统计、地图统计、vue.js) ,并生成菜单和权限直接使用。 系统接口:根据业务代码自动生成相关的api接口文档。 连接池监视:监视当期系统数据库连接池状态,可进行分析SQL找出系统性能瓶颈。 在线接口文档:使用swager生成在线文档。 ActiveMQ队列:提供ActiveMQ队列,处理批量发送大数据量邮件、大数据量日志文件。 工作流:功能包括在线办公、我的任务、审批测试、流程管理、模型管理。 CMS:功能包括内容管理、内容管理、统计分析、栏目设置、首页。 dubbo:代码生成直接生成dubbo对接代码。 服务器Down机邮件监控:通过定时任务监控服务器是否Down机,并发送通知邮件。 服务器监控:通过sigar进行服务器图形化监控。 异常邮件监控:全局拦截系统异常,并发送通知邮件。 单点登录:使用shior和Redis、共享session方式实现单点登录。 Redis分布式高速缓存:代码生成直接生成Redis对接代码。 特性: JeeSpringCloud基于SpringBoot+SpringMVC+Mybatis+Redis+SpringCloud+Vue.js微服务分布式代码生成的敏捷开发系统架构。项目代码简洁,注释丰富,上手容易,还同时集中分布式、微服务,同时包含许多基础模块(用户管理,角色管理,部门管理,字典管理等10个模块。成为大众认同、大众参与、成就大众、大众分享的开发平台。JeeSpring官方qq群(328910546)。代码生成前端界面、底层代码(spring mvc、mybatis、Spring boot、Spring Cloud、微服务的生成)、安全框架、视图框架、服务端验证、任务调度、持久层框架、数据库连接池、缓存框架、日志管理、IM等核心技术。努力用心为大中小型企业打造全方位J2EE企业级平台ORM/Redis/Service仓库开发解决方案。一个RepositoryService仓库就直接实现dubbo、微服务、基础服务器对接接口和实现。 努力用心为大中小型企业打造全方位J2EE企业级平台开发解决方案。 Spring Boot/Spring cloud微服务是利用云平台开发企业应用程序的最新技术,它是小型、轻量和过程驱动的组件。微服务适合设计可扩展、易于维护的应用程序。它可以使开发更容易,还能使资源得到最佳利用。 微服务/集群(nignx) 支持REST风格远程调用(HTTP + JSON/XML):基于非常成熟的Spring Boot框架,在Spring Boot Spring Cloud中实现REST风格(HTTP + JSON/XML)的远程调用,以显着简化企业内部的跨语言交互,同时显着简化企业对外的Open API、无线API甚至AJAX服务端等等的开发。 事实上,这个REST调用也使得Dubbo可以对当今特别流行的“微服务”架构提供基础性支持。
我们今天以企业用户常用的CRM系统,来看一看标准的SaaSCRM应该是一个什么样子。   实际上,很多用户对于CRM并不陌生,早在2000年的时候,有一些企业就已经开始尝试CRM系统。在很多人眼中,CRM就是一套C/S或者B/S的应用系统。   而当CRM进入了SaaS,他在架构上会是一个什么样子呢?我们以361CRM为例,来看一下SaaSCRM的架构。   361CRM系统采用分布式架构。采用企业级的多层次、多应用的系统结构的SaaS在线CRM平台平台架构从大的层次上来分主要为四层,根据调用关系依次为应用层、缓冲层、服务层以及存储层,如下图所示:   应用层   从浏览器发送过来的请求,直接由应用层来进行直接响应;   平台是多租赁用户的在线多应用来实现的,由于每个用户的具体业务需求不同,因此每个租赁用户的应用是相互隔离的,但应用层的结构却都是相同,从上到下主要分为业务展现层、业务逻辑层、业务模型层、实体访问层;   业务展现层主要为用户数据的不同视图表现,为用户呈现各种易于浏览、便于理解的各种数据表现方式,如表单、表格、报表、图表等;   业务逻辑层主要是业务逻辑的具体实现层,对于用户动作、触发事件以及工作流程等由业务逻辑层来实现业务的处理以及响应,通过业务逻辑层对下层业务模型的访问来实现具体的逻辑处理;   业务模型层主要是业务对象的具体定义与封装,是对于现实中业务在平台中的最直接的映射;   实体访问层是对于业务逻辑层对于业务模型操作的封装,业务模型的实体状态的更新、删除、查询等都是通过实体访问层来实现。   缓冲层   缓冲层主要对于静态资源以及动态数据的缓存。静态资源主要是指应用层中展现层中所要使用到的静态资源文件,以及由用户在业务操作中产生的文件等,如图片、上传的文件等;   而动态数据是指用户在使用平台的过程中所产生的业务数据,在实现业务中,这部分数据大部分都是读操作比较多,而写操作比较少,因此可以针对这部分数据根据特定的缓存失效策略机制来进行相应的缓存;   缓冲层的缓存针对应用层是透明的,而且针对多应用也是透明的,因此缓冲层具有更大的弹性与灵活性。   服务层   服务主要是指平台的核心服务,核心服务分为业务共通服务以及平台共通服务,平台共通服务是指与业务无关且是平台最基础的服务,如任务调度、消息队列、邮件服务、图片处   理、工作流引擎等;而业务共通服务指基于平台共通服务,而对于所有业务具有共通性的服务,如日志审核、操作回滚、数据安全、全文检索、权限角色等;   服务层是对于平台运营、维护最核心的服务实现,是平台正常运行的基础。   存储层   存储主要分为两部分:分布式文件存储以及分布式的数据存储;   由于是多应用的平台,因此随着平台的运营,会产生海量的业务数据以及资源文件,因此伴随着海量的数据而来的问题就是存储、检索、分析以及统计等问题;   针对上述问题,361CRM平台采用了分布式的存储系统,基于Map-Reduce来进行相应的检索、分析以及统计,实现了对于海量数据的统一操作。   这种结构能做到真正的分布式网络计算,有效降低网络流量,减轻客户端负担,还能安全、方便地与互联网接口。另外公司员工或客户分布或行走于全国各地,通常都有移动办公需求。   REST 架构   REST是基于HTTP的,因此天生就有在互联网上穿透防火墙的能力,REST可以简单地认为它是轻量级的WebService,但是它具有自己的一些显著特点:   所有的资源通过统一的接口访问(HTTP/HTTPSGET、POST、PUT、ELETE),而且接口比较统一,便于与第三方的集成;   因为是基于HTTP/HTTPS的,因此可以将资源(响应)分为可缓存的和不可缓存的,以及采用浏览器的标准压缩方式,有效地提升网络效能。也可以在客户和资源之间插入不同的中间组件来提升性能和安全等,如,代理服务,缓存服务,网关服务等;   因为是基于HTTP/HTTPS的资源请求,因此本次连接和下一次到服务器的连接之间没有状态。由于361CRM平台采用了REST架构,因此也就决定了361CRM平台天然就具备以下几方面的优势:   由于REST本身无状态的特性,361CRM平台天然就是分布式的,决定了后台通过根据业务量而弹性地增加服务器就可以实现平台计算能力的线性增加;   所有的请求都是统一通过RESTAPI进行相应的资源与服务的请求,这样就能够保证系统提供的服务都是解耦的,极大的简化了系统,从而改善了系统的交互性和可重用性,同时也能够根据业务进行相应统一且透明的内存缓存   客户端浏览器能够轻松通过Ajax实现REST资源的异步调用处理,同时也可以有效地减少应用服务器地压力   通过提供开放的RESTAPI,能够轻松实现与第三方的集成   平台服务   平台服务层的调用是通过RESTAPI进行的,由于REST的特点,通过在URI中添加资源路径以及版本信息,很方便地能够实现平台的平滑升级以及数据兼容性问题。   平台服务层实现的都是共通的服务,服务之间是独立的,而且是插件式的方式来实现的,平台选用了面向分布式计算的Erlang语言来实现的,因此保证了这些插件式的服务能够热拔插地部署,实现真正地不宕机地部署与更新。   平台服务层的插件式架构,决定了平台的无限扩展能力,能够根据不断变化地用户需求而进行平台的不断地在线迭代与更新,与用户的需求形成一个良性的循环。配置定制平台通过服务器(Apache)的自定义开发,实现了企业用户应用的透明隔离,因此平台具有面向不同企业用户根据不同需求进行个性化定制的能力。不同的企业用户,一般主要有几方面的自定义需求:业务对象、工作流程、报表、布局等,而361CRM平台的平台框架就决定着能够很好地满足用户的自定义需求,主要分为以下几个方面:   由于用户使用的是文档数据库,有着松散的数据结构,因此用户根据需求,而可以随意自定义自己的业务对象;   361CRM平台后台的平台服务层,有相应的实时的工作流引擎,提供给用户强大的自定义工作流程功能;   361CRM平台有业内是丰富的报表模板,用户只需要根据自己的需要来选择即可,针对一些自定义的动态数据,还提供模板的再定义功能,能够很好地满足用户的报表需求;   由于平台是应用隔离的,因此针对着页面的布局,可以很容易地实现个性化地定制;   361CRM平台的配置功能的强大,并不以损失平台应用的易用性为基础,361CRM平台在操作上采用引导式操作,以及提供方便易用的在线帮助,大大地降低了系统使用的复杂度,使系统更加地人性化、简易化。   实时即时   361CRM平台的平台服务层与通常的应用服务不同,它是实时运行的服务,平台服务层有相应的任务调度机制,邮件服务、消息队列以及实时的工作流引擎等,这些服务都是实时运行的,因此当企业用户的业务对象或者业务流程发生变化时,通过这些平台服务就可以把即时的状态消息(通过邮件、短信或者其它的IM工具)推送给用户,让用户真正了解到业务的即时与实时的状态信息。   而通常的应用服务是静态的,只有当用户登录时,才会进行相应的业务状态的检查,这样就严重影响了业务处理的速度,对于即时性业务,就会带来很大的损失。   多级负载   平台是一个多租赁用户的在线SaaS系统,因此会给平台带来大量的高并发的请求,361CRM平台是一个多层次的结构,而且采用了REST架构,REST天生就是分布式,因此通过物理部署就可以实现高并发带的负载均衡。   四层负载在链路层解决来自互联网的并发请求压力,使用LVS+Heartbeat的主从双备的架构,保证不会出现单点故障;   Web应用的大部分压力都来自于资源的请求,如图片,静态文件,样式表等文件的请求,服务器压力的70%都来自于这些资源的请求,因此对于这些静态资源的请求,通过静态资源缓冲层就能够很好解决这些请求对于后台造成的压力;   经过实测,经过一段时间稳定运行之后,静态资源缓冲层能够命中前台请求的80%以上,有效地缓解了应用服务器的压力;   七层负载层主要是做业务、以及资源的请求分流,把负载均衡到多台文件服务器以及应用服务器上;   文件服务器与应用服务器是分布式的,通过Map-Reduce进行任务的拆分与结果的合并,充分利用多台服务器的并行计算能力,提升整体平台的运行性能;   文件缓存采用多级缓存策略,解决命中率高的文件的频繁请求。而数据缓存则通过业务标签以及时效性策略进行数据的缓存,并且进行缓存的增量更新,有效地解决了对于后台的   数据读写压力;   分布式的存储系统有效地解决了海量数据的存储、检索、分析以及统计等问题。   可见,当传统的CRM系统转换为SaaS服务后,其架构方面还是发生了不少的变动的,也只有这样的变动,才使得CRM能够在SaaS平台上更好的为客户所服务。   附:什么是REST架构   REST软件架构是当今世界上最成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议HTTP本来面貌。它正在成为网络服务的主流技术,同时也正在改变互联网的网络软件开发的全新思维方式。AJAX技术和Rails框架把REST软件架构思想真正地在实际中很好表现出来。今天微软也已经应用REST并且提出把我们现有的网络变成为一个语义网,这种网络将会使得搜索更加智能化。   REST与HTTP协议   REST软件架构是由RoyThomasFielding博士在2000年首次提出的。他为我们描绘了开发基于互联网的网络软件的蓝图。REST软件架构是一个抽象的概念,是一种为了实现这一互联网的超媒体分布式系统的行动指南。利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常我们把REST也写作为REST/HTTP,在实际中往往把REST理解为基于HTTP的REST软件架构,或者更进一步把REST和HTTP看作为等同的概念。   今天,HTTP是互联网上应用最广泛的计算机协议。HTTP不是一个简单的运载数据的协议,而是一个具有丰富内涵的网络软件的协议。它不仅仅能够对于互联网资源进行唯一定位,而且还能告诉我们对于该资源进行怎样运作。这也是REST软件架构当中最重要的两个理念。而REST软件架构理念是真正理解HTTP协议而形成的。有了REST软件架构理念出现,才使得软件业避免了对HTTP协议的片面理解。只有正确的理论指导,才能避免在软件开发的实际工作过程中少走弯路。   REST与URI(资源定位)   REST软件架构之所以是一个超媒体系统,是因为它可以把网络上所有资源进行唯一的定位,不管你的文件是图片、文件Word还是视频文件,也不管你的文件是txt文件格式、xml文件格式还是其它文本文件格式。它利用支持HTTP的TCP/IP协议来确定互联网上的资源。   REST与CRUD原则   REST软件架构遵循了CRUD原则,该原则告诉我们对于资源(包括网络资源)只需要四种行为:创建、获取(Read)、更新和销毁就可以完成对其操作和处理了。其实世界万物都是遵循这一规律:生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数据库表的数据操作:(生)、select(见)、(变)和(灭),所以有时候CRUD也写作为RUDI,其中的I就是,这四个操作是一种原子操作,即一种无法再分的操作,通过它们可以构造复杂的操作过程,正如数学上四则运算是数字的最基本的运算一样。   REST与网络服务   尽管在Java语言世界中网络服务目前是以SOAP技术为主,但是REST将是是网络服务的另一选择,并且是真正意义上的网络服务。基于REST思想的网络服务不久的将来也会成为是网络服务的主流技术。REST不仅仅把HTTP作为自己的数据运输协议,而且也作为直接进行数据处理的工具。而当前的网络服务技术都需要使用其它手段来完成数据处理工作,它们完全独立于HTTP协议来进行的,这样增加了大量的复杂软件架构设计工作。REST的思想充分利用了现有的HTTP技术的网络能力。在德国电视台上曾经出现过一个这样的五十万欧元智力题:如何实现网络服务才能充分利用现有的HTTP协议?该问题给出了四个答案:去问微软;WSDL2.0/SOAP1.2;WS-Transfer;根本没有。这个问题告诉我们HTTP并不是一个简单的数据传来传去的协议,而是一个聪明的会表现自己的协议,这也许是REST=RepresentationalStateTransfer的真正含义。   实际上目前很多大公司已经采用了REST技术作为网络服务,如Google、Amazon等。在Java语言中重要的两个以SOAP技术开始的网络服务框架XFire和Axis也把REST作为自己的另一种选择。它们的新的项目分别是ApacheCXF和Axis2.Java语言也制定关于REST网络服务规范:JAX-RS:JavaAPIforRESTfulWebServices(JSR311)。相信还会出现更多与REST相关的激动人心的信息。   REST与AJAX技术   尽管AJAX技术的出现才不到两年时间,但是AJAX技术遵循了REST的一些重要原则。AJAX技术充分利用了HTTP来获取网络资源并且实现了HTTP没有的对于异步数据进行传输的功能。AJAX技术还使得软件更好地实现分布性功能,在一个企业内只要一个人下载了AJAX引擎,其它企业内部的人员,就可以共享该资源了。AJAX技术遵守REST准则的应用程序中简单和可伸缩的架构,凡是采用AJAX技术的页面简洁而又丰富,一个页面表现了丰富多彩的形态。   AJAX技术还使用了一种不同于XML格式的JSON文件格式,这个意义在哪里呢?在REST软件架构下我们不能对于XML文件进行序列化处理,这样程序员必须要使用自己的XML绑定框架。而以序列化的JavaScript对象为基础的JSON已经获得了广泛认可,它被认为能以远比XML更好的方式来序列化和传输简单数据结构,而且它更简洁。这对REST是一个极大贡献和补充。   当前的网络应用软件还违背了REST的“无状态服务器”约束。REST服务器只知道自己的状态。REST不关心客户端的状态,客户端的状态自己来管理,这是AJAX技术的应用之地。通过AJAX技术,可以发挥有状态网络客户机的优势。而REST的服务器关心的是从所有网络客户端发送到服务器操作的顺序。这样使得互联网这样一个巨大的网络得到有序的管理。   REST与Rails框架   RubyonRails框架(简称Rails或者Rails框架)是一个基于Ruby语言的越来越流行的网络应用软件开发框架。它提供了关于REST最好的支持,也是当今应用REST最成功的一个软件开发框架。Rails框架(从版本1.2.x起)成为了第一个引入REST作为核心思想的主流网络软件开发框架。在Rails框架的充分利用了REST软件架构之后,人们更加坚信REST的重要性和必要性。Rails利用REST软件架构思想对网络服务也提供了一流的支持。从最直观的角度看待REST,它是网络服务最理想的手段,但是Rails框架把REST带到了网络应用软件开发框架。这是一次飞跃,让REST的思想从网络服务的应用提升到了网络应用软件开发。利用REST思想的simply_restful插件已经成为了Rails框架的核心内容。   REST安全性   我们把现有基于SOAP的网络服务和基于REST/HTTP网络服务作个比喻,前者是一种传统的寄信方式,而后者是现代网络的电子邮件方式。要是是寄信和电子邮件都有病毒存在的话,传统的寄信被送到对方就很危险,而电子邮件是开发的,电子邮件供应商比如Google为我们检查了电子邮件是否有病毒。这里并不是说明SOAP网络服务消息包含义病毒,而是说明HTTP是无法处理SOAP信息包究竟好不好,需要额外的软件工具解决这一问题,包括防火墙也用不上和管不了。   REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包,如你可以规定从外部来的只能读取(GET操作)自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。REST的安全性还可以利用传输安全协议SSL/TLS、基本和摘要式认证(BasicundDigestAuthentication)。除了这些REST自身的安全性功能外,还可以利用像基于信息的WebServicesSecurity(JSR155)作为REST不错的补充。   我曾经遇到一个求职者,他的简历看起来不错,基本上没有大问题,但他就是没有收到任何回复。一天我半开玩笑似的问他是不是电话写错了,我一检查,果不其然。他改正后,立即收到了他所期望去的公司的面试电话。从这个故事中我们得到一点教训:哪怕只剩最后一秒钟,也要检查你的联系方式两遍。这是理所当然应该做到的细节,早做比晚做好。
基于Spring Boot的旅游管理系统设计实现是一项复杂而具有挑战性的任务。在设计实现系统时,需要考虑到不同角色和功能的需求,包括游客、管理员、导游和旅行社等等。 这个系统基于Spring Boot框架,并且使用Spring Security实现了安全机制,确保只有授权的用户才能获得访问权限。同时,还使用了Spring Data JPA实现数据持久化,使得系统数据存储和管理具有高效性和可靠性。 在实现系统的过程中,需要有一个清晰的需求分析和设计文档。需要仔细考虑每个角色的需求,将其分解为任务和子任务,并确保每个功能都有在系统中得到体现。需要创建合适的数据模型、UI设计,以及设计实现相关的REST接口,以便客户端能够与系统通过网络连接进行交互。 对于游客来说,系统必须提供一种便捷的方法来搜索和浏览旅游行程和地点,以及进行预订和支付。对于管理员和导游来说,系统需要提供一种易于使用的后台管理系统,以管理旅游行程和交通安排、旅游点和景点信息、导游信息和内容等等。同时,系统还需要提供报表和统计信息,以便旅行社在运营方面做出更好的决策。 在实现系统的过程中,还需要进行适当的测试和调试,以确保系统的稳定性和正确性。最终,需要将系统部署到可靠的服务器上,以便公司员工和客户可以安全地使用该系统

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值