如何应对即要使用云即时通讯又要资料安全的BOSS(nodejs方案)
发布于 8 年前 作者 ruder 3412 次浏览 来自 分享

先自我介绍,土逼程序猿一名,普通不能再普通,放到动物园立马认不出来的那种。我本过着太平日子,平时七分code三分马屁,好生自在。

但是,不得了了!就在上个月,我们换BOSS了,别问我为什么换了,TMD又不是我要换的我怎么知道!!!新BOSS好生威猛,先是砍了几个案子,再是停了几个案子,最后硬是只留了一个!然后就是调整人力,开了一个新案子。对,没错,我被调到了这个新案子。

新案子分给我的任务是做一个即时通讯,允许使用现在的即时通讯云服务,但必须保证资料安全,什么安全等级?资料不能传到第三方服务器!

即时通讯用第三方云服务,资料不能传到第三方?这是搞笑么?BOSS,剧情不是这样写的!!!消息不能传到第三方,第三方如何帮我传给用户?

BOSS回应,这是我的任务,是我应该要解决的事情!这个,这个,这是要炒我的节奏么?不行,作为一个太平程序猿,不能轻易认输,我,是一只牛逼的猿!于是我惯性打开了百度。

三个小时过去了,我列出以下几种解决方法: 1,写封辞职信,委婉交给BOSS 2,直接翻脸,说不干了,直接回家 3,…

========================万能的分隔线=========================== 以上是背景介绍,太搞,见笑。下面是自己严格的求解之路 ========================万能的底隔线===========================

我列举了几种可能的解决方案: 1,自己架建即时通讯,保证资料绝对不传送第三方 优势:绝对满足BOSS的要求,资料安全 劣势:因没有架建即时通讯经验,强行架建问题不少,后面还有各种维护。 2,使用现在云即时通讯,发送消息时将消息存至我方服务器,然后将消息id即时发送出去;当其它用户通过此消息id从我方服务器拿回消息内容体。 优势:也满足BOSS要求,资料安全;同时使用云即时通讯,靠谱些。 劣势:因为此方式非云即时服务的原生支持,在很多地方需要自己写代码转换,体验可能并不佳。

我尝试了第2种方案,我尝试从几个模块来分析:

1, 收发消息。 发消息可分两步:首先将消息保存到我方业务服务器,得到消息ID;再将消息ID发送到即时通讯云,传送到目标用户。 收消息也可分两步:首先收到即时通讯云推送的消息ID;再从我方业务服务器通过消息ID取到消息内容显示出来。 目前来说,就是性能稍微有点影响,但还是可以接受的。

2, 消息历史记录和搜索 因为即时通讯云上已经没有我们的消息内容,所以这一块必须自己做了。这时要注意保存消息的所属,特别是单聊的情况,所属不是很好定义。

这个方案我实施后发现,因为网络的原因,有些消息可能漏接,或错掉等,甚是尴尬。后来学习了微信的后台架构,引入同步概念,将以上方案稍作修改,发送消息不再是发送消息ID,而是发送一个某会话(群或单聊)的同步信号,用户收到后直接和我方业务服务器同步消息。使用此方案后,就不再出现漏消息的情况。

(此方案后台是用nodejs开发的,等我整理再开源出来。)

经过数月的努力,总算是交了差!亲们,这样的BOSS极品吗?对我的方案是否有更好的建议?欢迎吐槽!

6 回复

只利用云通信的消息收发功能也还好,在一定并发范围内是比较快的实现

@i5ting 看样子兄台在这方面有经验!请教这个并发范围是多少?可否告知?

写一套自己的加密算法就可以啊,信息安全性并不是因为拿不到就安全了,再说了,你怎么知道你家服务器没被人拖出去卖了 不反对使用云服务,说明你们新boss只是希望增加安全性而已,加固信道即可,您现在方案的风险并不比用云服务的低,拖云的数据库和拖你们自己数据库的区别

@CarlosRen 非常感谢您的回答。我们BOSS觉得消息送到第三方服务器,怕别人留下。并不是指信道加密泄漏,而是担心提供云服务的第三方。也许是他们心中的一道疙瘩吧,总觉得数据传到别人服务器就是不放心。

@ruder 我的意见是换一种思路让你们领导安心,就信安来说,没有黑产拿不到的,所以方法上来看,加固信息>>>物理隔离,而且对你们的难度要小很多

@CarlosRen 我应该领会到兄台的意思了。然说服也是一个不小的困难啊,听兄台的意思应该对信安问题颇有心得,还请多指教。

回到顶部