基于Dubbo的运营管理平台权限系统的设计与实现

程磊， 程俊达， 严明， 王嘉威， 张小贝

(上海大学 上海先进通信与数据科学研究院，上海 200444)

0 引言

随着我国人均收入水平的提高，人们对自身和家人的安全越来越重视。买保险的人越来越多，我国总体的保费也逐年升高[1]。我所在的实习公司的主要业务就是提供网上保险投保服务。后台运营管理系统主要是对我们公司安卓端、IOS端、HTML5端的保险业务提供支撑、数据统计和运营维护而统一的运营管理平台。随着公司保险业务越来越大，后台运营管理系统也越来越复杂，使用的人员也越来越多，由于业务数据的敏感性和隐私性，必须要对运维后台系统用户的权限进行管理，使每个人都只能进行符合自己权限范围类的操作，从而保证数据的安全。我所在的小组设计并实现了后台运营管理平台权限系统。以往的权限系统一般都是企业在项目中的一部分，而我们开发的权限系统使用了当前主流的SOA思想，将权限系统和后台运营管理平台解耦出来，通过API接口进行调用，减小了项目的复杂度，提高了项目的鲁棒性。

本文主要是设计和实现后台运营管理平台的权限系统。权限系统主要分为2个部分，一个部分是权限的处理，另一个部分是权限的显示。

1 主要框架技术

1.1 Dubbo框架

Dubbo是一个分布式SOA(Service-Oriented Architecture)框架，随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进[2]。

Dubbo的架构，如图1所示。

其中，Provider是暴露服务的服务提供方、Consumer是调用远程服务的服务消费方、Registry是服务注册与发现的注册中心、Monitor是统计服务的调用次调和调用时间的监控中心、Container是服务运行容器。Dubbo将项目拆分为一个一个的服务，提高了应用整体的连通性、健壮性、伸缩性、升级性。

图1 Dubbo框架的架构

1.2 ZooKeeper框架

ZooKeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等[3]。Dubbo框架支持多种框架作为Registry中心，譬如ZooKeeper、Redis、Simple等。我们使用最广的，最成熟的框架ZooKeeper来作为Dubbo框架中的服务注册与发现的注册中心。

1.3 SSM框架

SSM框架是目前主流web项目开发框架，它其实是3个框架的缩写，分别是Spring、SpringMVC、Mybatis。

Spring是一个开源框架，主要是为了降低企业应用程序开发的复杂性。Spring框架主要提供了轻量级的控制反转(IoC)和面向切面编程(AOP)，可以单独使用，也可以和SpringMVC框架、Mybatis框架等框架整合使用。Spring可以用大家熟悉的xml文件进行配置，也可以使用注解配置，还可以同时使用xml和注解混合进行配置，给开发者带来了极大的方便和灵活性。Spring的这些优点，给开发权限系统带来了极大的便利。

Spring MVC是一种基于Java的实现了Web MVC设计模式的请求驱动(请求-响应模型)类型的轻量级Web框架，其使用了MVC架构模式的思想，将web层进行职责解耦，方便开发者开发企业应用程序[4]。

Mybatis是持久层框架，可以通过XML文件或者注解来配置Map接口，开发者通过Map接口就可以调用数据库，实现SQL语句和程序代码相分离，使系统的设计和开发更加清晰明了。权限系统的数据库表结构比较稳定，主要操作是对数据进行增加和查询，为了提高读取数据库的效率，选择Mybatis框架作为权限系统的持久层框架是非常合适的。

2 权限系统设计

后台运营管理平台和权限系统分属不同的项目部署在不同的服务器上，后台运营管理平台作为消费者，权限系统作为生产者是通过Zookeeper作为桥梁进行交互。权限系统主要包括2部分，一部分是对用户展现的菜单的权限，一部分是用户对页面操作的权限。而后台运营管理平台主要是通过调用权限系统来进行权限的展示和控制。

2.1 运营平台权限控制设计

根据公司运营管理平台的需求，目前运营管理主要有以下几个模块账户管理、金豆管理、活动管理、信使管理、MDR管理、保单导入等一级菜单，在一级菜单先下面还有很多二级菜单，而在二级菜单之下还有很多具体的三级菜单。平台菜单结构，如表1所示。

表1 平台菜单结构表

不同的用户显示页面是根据该用户所具有的权限显示和加载页面。其中一级菜单为模块菜单，二级菜单的上级菜单为一级菜单，三级菜单的上级菜单为二级菜单，是一种树形结构。

不同的页面所具有的查询权限是根据权限系统返回的信息进行限定的。权限系统返回的字段信息，如表2所示。

表2 权限返回字段及含义

根据目前的项目需求只需要这些字段，后续如果有新的需求可以后续更改，添加字段。后台运营管理平台在加载三级页面时会发送一个获取权限的请求，之后页面上会根据请求返回的字段对页面中搜索选项框中的选项进行限定，同时在进行查询的时候也会把权限返回的字段添加到查询请求的报文中。

运营管理平台的用户主要是各个地区和不同合作方的运营人员。每个地区或者公司的人分为一个组，每个人员在系统中扮演注册用户的角色，而在不同的项目组中也扮演不同的角色，例如管理员和普通用户[5]。系统中需要控制的对象类型主要有2种，一种是数据库的查询，一种是页面的显示。权限模型与系统用户对应的关系，如表3所示。

表3 权限模型与系统用户对应的关系

系统中用户权限的判断逻辑主要分为两部分：①系统用户在登陆时只显示用户所在组所具有的展示菜单，运营管理平台的菜单加载主要通过权限系统的返回加载对应的菜单。②每个用户在点击二级菜单的时候会显示三级菜单，在加载三级菜单的时候会向权限系统发送请求，页面上的一些选项会根据权限系统的返回加载下拉的按钮。譬如地区的选项不同权限的用户加载的省份是不同的。

2.2 权限系统数据库设计

数据库的设计基本按照上一小结的思路来设计，符合项目的实际需求，数据库的总体设计，如图2所示。

图2 数据库表

在图2中，smc_menu是菜单表，主要是用来存储运营管理平台的菜单显示的，其中ID为每个菜单的ID编号，UPPERID为上一级菜单的编号，MENUNAME是页面的名称，ACTIONURL为点击菜单之后的返回的页面，SYSTEMCODE为公司不同系统的编码，其他还有很多属性就不逐一介绍了。saa_grade是分组表，主要用来记录组别，其中有分组的ID，分组GradeCName等字段。saa_usergrade表主要是用来记录用户对应的分组，saa_task主要是用来对每个页面和行为进行标记的任务表。saa_gradetask主要是记录每个分组可以执行的任务。最右边的5个表分别为saa_premitapp，saa_permitcompany，saa_permitenvironment，saa_permitproduct，saa_permitsystem几个表主要对应的是搜索查询权限的设置，分别对应搜索权限返回的appid字段、partner字段、和地区的几个字段。

3 系统实现

整个系统的实现不是单一的某一部分，而是运营管理平台和权限系统结合实现的，对用户权限的存储和处理是权限系统的工作，而权限的控制则需要运营管理平台的支持和实现。

对于整个系统，用户在登陆系统的时候，会调用权限接口的方法，然后前端页面根据权限系统返回的信息加载菜单，当用户点击二级菜单时，返回的三级菜单中的选择选项会根据权限系统返回的权限限定可以选择的选项。具体的流程，如图3所示。

图3 系统权限认证流程

权限系统的代码主要分为两部分，一部分为菜单显示权限提供服务，另一部为搜索权限提供服务。后台运营管理平台主要通过在页面发送ajax请求调用SaaPowerService和MenuService接口获取用户的权限，然后在通过Jsp和js文件展现给用户。

整个系统各个组件之间是通过Dubbo框架来进行交互的，每个组件通过Dubbo暴露各自的服务，运营管理平台通过Zookeeper发现各个服务的具体地址。各个组件的配置类似金豆模块的Dubbo配置，如图4所示。

运营管理平台的权限显示，如图5所示。

图4 项目Dubbo配置

图5 后台运营管理平台权限显示

4 总结

本文的权限系统结合了当前主流的SOA思想，将权限系统单独开发为一个服务，该服务整合了Spring、Spring MVC和Mybatis框架实现了权限系统的内部的业务逻辑、数据、显示页面的分离，使得系统的可维护性大大提高。权限系统的开发使用了DUBBO作为RPC框架，Zookeeper作为服务注册和发现的调度中心，后台运营管理平台通过API接口的方式与权限系统进行交互，解耦了后台运营管理平台和权限系统的耦合性，提高了系统的鲁棒性。