当前位置:首页 > 短网址资讯 > 正文内容

权限申请审批流程设计

www.ft12.com7年前 (2017-08-24)短网址资讯8129
摘要

目前Do平台下各类资源比较多(像任性、驾驶舱、烽火、数据集市等等),对应的各种角色也比较多,需要对do平台的每个用户进行权限控制。Do平台功能权限申请之前都是通过发送邮件的方式提交申请,对于审批人来说,工作较为繁琐,容易出错。为方便审批人实现一键通过或者一键驳回的审批功能,同时也为使用户权限申请的流程规范化,设计此权限申请产品。下面主要介绍权限申请中审批流程的设计。


1. 业务流程介绍 


下面是权限申请的业务流程图:



主要有以下几个模块:

1)用户提交申请:        

用户通过do平台权限申请入口页面提交申请,用户可以根据自己的角色,选择不同类型的申请(代理商、RD、非RD)。用户提交的申请内容会以快照的方式保存,快照的方式便于申请内容需求扩展,同时减少前后端逻辑交互,减小开发交流成本。


2)创建审批流程        

用户提交申请之后,会根据用户提交的申请内容,动态的创建审批流程,后面内容会详细介绍。


3)审批人审批        

审批人可以通过do平台权限申请页面(我的审批)、workflow、HI等三种方式进行审批。workflow是运维部提供的一个工作流服务,通过接入workflow,可以复用邮件提醒、HI审批等功能,丰富用户体验。如果审批人通过workflow、HI方式审批,我们无法立即得到该审批信息(因为workflow不会回调任何接口),所以我们通过CT任务的方式定时扫描申请单状态信息,同步到自己系统。



2. 审批流程设计


审批流程如下:



1)存储设计       

由于每个节点只有一个审批人,因此在设计工作流时,建了两张mysql表:auth_apply(存储用户提交的申请,一条记录代表一个申请)、auth_approve(存储审批流程,一条记录代表一个审批节点,auth_apply表中的一个申请对应该表中多个审批节点)。这样的设计能够完全满足现有需求,但是这并不是一个标准的工作流设计(没有考虑一个节点多个审批人情况),这也为后续功能扩展带来了麻烦。


2)代码框架       

由于代理商、RD、非RD申请大体的审批流程是一样的,但是具体到审批流程的每一步可能又不一样,为此采用“模板方法模式”来设计。



Service_Data_ApplySave为抽象基类,模板方法createApplyAndApprove()给出了整个审批流程业务逻辑的骨架,包括一些列抽象操作:genAuditors()生成审批人(包括workflow的审批人)、createApplyWorkFlow()调用workflow接口生成申请单、saveApply()保存申请内容、createApprove()创建本地审批流。Service_Data_AgentApplySave、Service_Data_NordApplySave、Service_Data_RdApplySave等各子类实现相应的抽象方法即可。


3)接入workflow      

由于workflow在创建审批流程时,必须提前配置好流程模板,而且不同类型的审批流程需要创建不同的流程模板,所以需要根据业务逻辑推断可能出现的审批流程情况,提前手动创建好流程模板(这种方式极不灵活,也促使后续迭代想办法尽量减少创建流程模板的操作)。


3. 审批流程功能迭代


权限申请产品到现在为止经历了两次迭代,而这两次迭代都对代码进行了重构。


3.1 迭代1.0


1)需求:

1. 在最终审批人中增加多个人审批, 有其中一人审批通过并授权即可

2. 如果申请的ad-hoc表中,有托管库中的表,需要将托管表的所有人的上级加入到审批流程


2)需求分析:

要满足上面两个需求,就必须实现一个节点支持多个审批人,同时节点也要区分操作方式(“与”和“或”,“与”表示该节点所有人都通过,则该节点通过;“或”表示该节点任意一人通过,则该节点通过)。


3)设计方案:       

对审批流程进行了简单的重构:增加auth_approve_user表(用于存储每个节点的审批人,一条记录对应一个审批人,一个节点可能对应多条记录),同时auth_approve表增加mode字段,用于判断该节点操作方式。由于增加了一张mysql表,为了兼容老的数据(用户已经提交的单子),就必须在新代码上线前将老的数据按一定的逻辑导入新表中,为了保证导入老数据后,在代码上线前不再有新数据进入,就必须让线上服务在这个上线过程中(导入老数据、代码上线)不可用,这就是上文所说的“麻烦”,不过这个“麻烦”可以接受,因此没有专门去开发平滑迁移的方案。


由于需求2需要在审批流程增加一个节点,该节点是“与”操作节点,workflow不支持动态添加审批人,因此必须去修改流程模板。这里就涉及到并发问题(在创建审批流程时,不能同时有多个进程修改该“与”节点审批人),为此增加了锁机制(下文介绍实现方法),来避免这种并发问题。

      

抽象类Service_Data_ApplySave增加获取锁和释放锁的方法(使用redis来标记某个流程模板是否正在被修改),Service_Data_RdApplySave类增加相关业务方法,如下图:



4)redis实现锁机制方法:

      

1.进程A获取锁:$get = hincrby($key, $processId, 1); 如果$get等于1,则A成功获取锁,A操作完毕后释放锁:$get = hincrby($key, $processId, -1);;

      

2.进程B获取锁:$get = hincrby($key, $processId, 1); 发现$get大于1,说明锁已被占用,B获取锁失败,同时进行回滚操作:$get = hincrby($key, $processId, -1);

      

3.进程B每隔一段时间重新进行获取锁的操作,直到成功获取。


该锁机制实现方法比较简单,强依赖redis服务,其他优缺点就不在此讨论了。



3.2 迭代2.0


1)需求:

1.特殊审批流程增加VP审批节点

2.审批委托功能:A可委托B帮其审批


2)需求分析:       

上面两个需求都要增加workflow流程模板,同时修改相关代码。我们已经根据之前的需求增加了很多个workflow流程模板了,而这次的需求又要增加流程模板。可以看到,由于接入workflow的方式极不灵活,当涉及到流程修改时,都要大篇幅的修改代码逻辑,导致开发成本比较高。


3)设计方案:       

通过如上分析,决定在这次迭代时,对创建审批流程的代码进行底层的重构,通过这次重构,希望能够在以后功能扩展时,尽量减少创建workflow流程模板的操作,尽量只增加业务代码而不是修改与workflow相关的代码甚至底层逻辑。重构后的代码框架如下:



此次重构主要是对创建审批流程进行细化、解耦(与接入workflow解耦),主要思想就是通过将流程步骤细化,将接入workflow从业务逻辑拆解出来,从而达到解耦目的,如下图所示:




将genAuditors()方法拆解成genMyAuditors()、ifModifyToOneState()、repaceProxyAuditor()、genWorkflowAuditors()、selectWorkflowTpl()等方法(图中绿色),createApplyWorkFlow()方法拆解成getUpdateProcessLock()、updateWorkflowTplAuditors()、createApplyWorkFlow()、freeUpdateProcessLock()等方法(图中蓝色),其中红色虚线框内的方法是生成审批人的步骤,黑色虚线框内的方法是接入workflow的步骤。


重构后,添加workflow流程模板不在依赖业务逻辑,而是根据审批流程节点个数和类型(“与”和“或”)来添加模板,如下图所示:



4)重构后的优点:

      

1.实现业务逻辑与接入workflow解耦        

用户提交的申请,可能是不同类型的(代理商、RD、非RD),也可能是特殊申请,还有可能涉及tuoguan库表的申请等等,因此会有不同的业务逻辑来处理。重构前,是根据业务逻辑来选择workflow的流程模板,这样的话,生成审批人和接入workflow是耦合在一起的(重构前的genAuditors()里包含了生成workflow的审批人genWorkflowAuditors()和选择workflow流程模板selectWorkflowTpl()),他们都是业务逻辑的一部分;重构后,根据业务逻辑来生成审批人,然后根据生成的审批人来选择workflow的流程模板,这样就把接入workflow从业务逻辑中拆分出来,从而实现解耦,如下图所示。


 2.减小功能扩展及维护成本       

实现接入workflow与业务逻辑解耦,会给以后审批流程功能修改带来极大便利:只需关注业务逻辑变化,增加或修改生成审批人的逻辑,而不需要去修改接入workflow的逻辑,功能扩展更加灵活,从而减小新功能开发及维护成本。


5)重构之后存在的缺点:

       

1.性能影响     

重构之后,每次接入workflow时,都要去修改选好的workflow流程模板的每个节点的审批人(因为一个流程模板可能被多个业务逻辑使用到),而这在重构前是不需要的(只需要修改部分模板部分节点审批人),这对性能是有影响的,不过考虑到“提交申请”接口的访问量并不大,因此是可以接受的。

       

2.额外增加锁机制        

为了避免两个进程同时修改同一个workflow流程模板,就必须要额外去增加锁机制解决并发问题(锁机制同样使用redis实现,方法同上)。


4. 总结


每一次功能迭代,如果都需要修改大量代码,甚至大篇幅改动原有逻辑,那么就要考虑重构了。其实重构不只是在功能迭代时,当我们在开发过程中,发现部分功能修改需要很大开发及维护成本,这时也要考虑重构自己的代码。当然,我们在产品开发中还是要尽量避免重构,毕竟重构是要开发成本的。因此在产品开发初期,要深入了解产品需求,与产品经理多交流,尽可能多的去预测未来产品需求变化,并为此做相关设计,从而减少后期重构。

扫描二维码推送至手机访问。

版权声明:本文由短链接发布,如需转载请注明出处。

本文链接:https://www.ft12.com/article_432.html

分享给朋友:

相关文章

短网址生成网站的源码都有哪些?

对于短网址生成站来说,目前国内做的很不是很多,所以开源的代码也很少,多数是基于国外大牛的开源代码改编过来的。比较著名的有phurl,比较老牌,但是似乎已经停止更新和支持了。另外还有yourls,这款开源代码使用最广泛,目前仍然在更新之中,支...

Golang Slice 的一些事

女主宣言使用 Golang 编程时,常会使用到一个数据结构 —— Slice,这篇文带大家看看 Slice 具体的数据结构以及常用手法。PS:丰富的一线技术、多元化的表现形式,尽在“HULK一线技术杂谈”,点关注哦!1. Slice 数据结...

网易严选开通海外配送服务 发力海外市场?

网易严选开通海外配送服务 发力海外市场?

【FT12短网址】2017年9月27日消息,FT12短网址获悉,日前,网易严选发布《海外及港澳台地域物流配送公告》,这意味着海外的消费者也能在网易严选停止购物且网易严选能直接把产品发送到海外消费者手上。该公告指出,值此中秋佳节之际,网易严选...

FT12短网址:互联网生态未来将发展趋势解析

【FT12短网址资讯】这些年,业界对互联网生态的评论不断增加,在不少人看来,互联网生态不只会推进全部IT产业进入下一个黄金十年,更主要的是,它也将对IT产业格式带来主要的影响。简略来说,BAT这种格式是不是会完全被推翻,要害就在于互联网生态...

ofo飞鸽代工厂探访:一分钟造4辆车

ofo飞鸽代工厂探访:一分钟造4辆车

共享单车竞争趋于“白热化”的同时,各地方正在赶紧办理整治乱停乱放。大家不禁思考,这些单车终究产于何处?怎样的流程才能让单车在短时间内大批下线?带着疑问,短网址资讯小编走进天津飞鸽自行车厂,对ofo出产线进行了实地看望。  在这家位于天津市区...

编程语言的动静之争:Clojure太灵活,我们该如何驾驭它?

编程语言的动静之争:Clojure太灵活,我们该如何驾驭它?

作者|FT12短网址 编辑|短链接 编程语言的圣战,除了语言种类之分,也有动静门派之别。我们写着静态语言往往想着动态语言的灵活,写着动态语言又容易想着静态语言的稳定和可靠。常听到有人说,Clojure 确实...

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。