实现简单的权限管理系统

工作中开发一个网站,设计有所变动,原计划是从第三方系统获取权限,现在变成了我们的网站自己要注册用户,并且要进行权限的控制,这样,我们就要在我们的系统上完成一个三级角色权限的角色权限管理系统。

准备从网上找一个直接介绍使用spring mvc 实现的角色权限管理系统来进行参考,找了一圈发现,要么太简单,要么太复杂。

我们的系统不涉及多级部门之类的内容,只包括平台管理员,组织管理员,普通用户三部分,其中组织相当于部门。那么好,现在只是参考部分文档的实现方式,当时权限系统自己设计。

故事:不同级别的用户登录后要能选择自己当前登录的组织,并在该回话中进行自己能够进行的操作。

细化:

最高级别用户(平台管理员)从前台登录后要跳转到后台系统,不能在前台进行操作。

其余两个级别的用户(组织管理员和普通组织用户)登录后要确认自己当前会话所登陆的组织,以便登陆后的操作获取组织信息和权限。

组织管理员登陆后要能看到审核相关的列表(页签),并能进行相关的审核审批操作;同时也能进行普通用户的操作。

普通用户登陆后能够看到自己的列表和自己数据、订单的查看和操作列表(页签),并能对自己创建的内容进行更新、删除等管理操作。

 

设计:(假设一个用户在使用不同组织的身份时,必须都是一个角色,即如果该用户是一个组织的管理员,那么同时他登录其他组织时也是以管理员身份登录,而不会一会是管理员一会是普通用户。如果是后一种情况,则需要在用户-组织映射表中加入该映射的角色)

用户表:存储用户数据(注册时添加)

用户-组织映射表(存储用户与组织的管理)

组织表(存储组织信息)

系统角色表(存储系统内角色,按照当前规划应该具有三个角色:平台管理员,组织管理员,普通用户)

角色权限表(该表存储已经创建的角色所能进行的操作<可能以该操作触发的url的方式存储>,以及展现的页面等)

【===============================================】

以上为今天的数据库设计,代码实现可能参考一些spring mvc注解的方式进行实现。

可能参考资料:

《blog.csdn.net/ycyk_168/article/details/18456631》

 

工作内容转变,企业发展方向转变

前几个月一直在做一个项目,一直也做的好好的,是整个后台部分的负责人。虽然说公司要转型互联网,但是总的来看,有些新组建的,做新业务的部门是有所改变,正在做一些互联网产品的东西;但是对于我们部门,一个在技术和经验上都没有什么互联网方面的积累的部门,转变不是一句话的事,也不是三两天能够完成的事。

一开始接过来这个项目的时候,几乎部门所有的人员,包括产品,设计,开发,仍然是把这个项目当作了一个外包项目在做。话说回来,虽然这个项目在公司层面上仍然是个外包的项目,但是里面的性质已经不一样了。之前 公司会做一些什么样的项目呢,比如给某企业开发一个内部办公系统,给某服务商开发一个子产品,等等。那种是完全人家什么需求基本都定了,然后要我们来做,我们出体力的民工,就是码农。

但是这个项目不一样了。这个项目是在智慧城市概念的引导下,房地产商想要在自身服务上做出突破和改变而产生的需求,他们有需求要做,要改变,但是,要做成什么样,要改变成什么样,他们也没有一个非常清晰明了的概念。这就是跟之前不一样的地方了。我们要参与设计,我们要创新,并且让客户接受,让客户的客户接受;我们不能只是站在一个体力劳动者的角度去考虑问题了,我们需要站在客户的位置,站在运营者的位置和角度,去考虑我们的产品如何设计能够更美,更合理,能更吸引用户,更方便用户,如何能让我们的产品做出来之后能够方便用户。

虽然做这个软件,做这个网站仍然是客户的需求,但是我们不能再把自己只是放在一个体力劳动者的位置去干活了。我们要转型,就必须转变心态,转变思维方式,转变角度。(虽然哪怕是做外包工作时候,想要把工作做好就要持有这个心态,但是现实总是比较骨干的,终于把大家想要好好设计产品,好好做出产品的心气磨灭了之后,现在又要我们把它捡起来。)

服务器内存溢出

昨天晚上发出来的邮件,有一台服务器又宕掉了,无法连接登录。今天去服务器上看了一下,发现服务器是正常的,但是jvm内存已经被使用完了,最后的log是java.lang.outofmemoryerror java heap space,时间是昨天晚上接近零点,就是说昨天晚上接收到这些请求报出这些 错误之后就不再处理请求了。

之前怀疑是由于jdk版本的原因,导致的是堆外内存泄露,从而导致我们的服务器宕机。然而现在从我们观察到的日志来看,并不是堆外内存导致的服务无法使用,而是Java虚拟机内部内存无法回收导致的(在JVM中如果98%的时间是用于GC且可用的 Heap size 不足2%的时候将抛出此异常信息)。那么也就是说,应该不是jdk版本中堆外内存回收机制的bug导致的我们系统崩溃,而是我们的代码中确实存在不合理的代码,导致Java虚拟机内存资源被持续占用得不到释放。

上面这个报出此异常的条件是从网上搜索得来的,需要从其他地方进行查证后再确认。

需要仔细研究一下Java虚拟机内存的分配、使用机制,对此足够的熟悉才能从这些现象中就找到触发这些问题的根本可能原因,不像现在两眼一抹黑,完全无头绪让人牵着走。这感觉太难受了。

之前的使用不同jdk版本进行压力测试的计划继续执行(原来这个计划应该是为了观察是否有高版本比低版本更好的堆外内存回收机制处理方法的,虽然我现在觉得这个测试已经意义不大,但是现在主导人将这个计划的目标定位为确定高版本jdk比低版本整个有更好的gc机制),正好这个计划执行期间有非常多的空余时间,我趁这个机会阅读一些Java虚拟机对于内存的管理方法相关的内容,尽量也了解一些Linux对于内存的管理机制。这两块都太不熟悉。

对于java.lang.outofmemoryerror java heap space这个错误的解决方案,这篇博文比国内搜到的大多数内容都好太多《http://blogs.opcodesolutions.com/roller/java/entry/solve_java_lang_outofmemoryerror_java》。

留:《http://outofmemory.cn/c/java-outOfMemoryError》