鉴权系统和改良

到新公司报道一周了,实际工作时间四天。做的是即时通信产品的不良信息管控系统。即时通信家族里,最有名的应该时微信了吧。但微信里可能没有这个不良信息管控系统。大概因为微信没有这个义务吧。

什么时不良信息管控?举个栗子,如果微信有这个功能,你在朋友圈中发一张黄色图片,这张图片在朋友圈中呈现出来之前,它会先被发给服务器(集群),服务器会对这张图片进行鉴权,判断它是黑(非法)还是白(合法),如果合法,则放行,并最终在朋友圈呈现。如果非法,则被拦截,同时它的相关信息被记录,并上报给集中管控点。

如何实现?最简单的想法就是编写一个算法,以函数方式提供,输入图片,输出鉴权结果。也就是说这台服务器就运行这个函数,图片发到服务器就交给这个函数处理,根据函数返回结果,决定放行或拦截并上报。这和分布式和消息队列没有半毛钱关系。

我们把需求扩展一下,以接近实际情况。首先,输入除了图片,还有文字、音频、视频。 

从鉴权的流程来讲,可以先对所有的输入一视同仁,先做一次黑白指纹命中,如果直接命中黑指纹,则表面该文件、图片、音频、视频非法,且曾经留有“案底”。如果命中白指纹则直接放行。如果没有命中,则继续后面的流程。这里有必要说明一下什么是指纹。对于文字、图片、音频、视频,我们都可以看作是一个字节流,计算这个字节流的md5值,就是它的指纹。除了指纹检测,可以想像还有很多鉴权手段,比如对于文字,进行分词、模式匹配等等,对于图片、音频、视频都有各自的鉴权算法。除此之外,对于荐权结果为黑的输入,有时还要发给集控中心,进行人工审核,以免误判。

白指纹、黑指纹匹配就是这个系统的业务,除此之外还有其他业务。我们为业务编号,分别为svc0,svc1,svc2,...,svcn。目前的系统以模块方式组织,每个模块对应一个业务。同时每个模块都是独立的进程,之间以消息队列方式连接。一个消息进入系统后在各个模块之间流转。即每个模块既是客户端也是服务端,它接收消息的时候就是服务端,将消息传递给下一个模块的时候,它就是客户端。

我的意思是,这个软件框架用的有些重了。跨进程通信的任务,虽然被底层封装了,但相比函数调用时的参数传递,它还是太重了些。函数调用可以查看调用栈就可以看到整个数据流,而进程件的数据传递只能依赖log了。

真对这个项目本身,完全可以横向将业务划分为两类:实时业务和非实时业务。即文本和体积小于一个阀值的媒体文件,可以快速处理,他们被划分都一个模块中(进程中),同步处理。体积大于一个阀值的媒体文件,划到另一个进程中,异步处理。这样业务进程被简化为两个。同时可以把原先分散在各个业务模块中的配置加载和配置更新模块,汇集到第三个进程中。

这就是我的方案,相信比拥有大量进程的原方案,更贴近业务模型,也更简单易调试。

 

补充

其实我想说的是,现有系统,一个业务流程被分散到不同的进程中,进程间用消息队列通信。同时多进程也是为了增大吞吐量,充分利用cpu的能力。

但更好的模型应该是,一个业务流程只在一个进程中,这样利于调试,只看调用栈就可以看到业务流程。同时为了利用cpu能力,增加进程,提高吞吐量。

 

转载于:https://www.cnblogs.com/mjohh/p/5024210.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值