关于API网关(三)权限

eoLinker 技术开发  2021-09-07 17:58:41

想象一下,我们的API网关对外开放了好多个接口,有的接口是通用的,大家都可以访问,有的接口是定制的,只对特定用户开放,比如付费用户、合作伙伴等,这就涉及到接口权限控制的问题。

权限功能的示意图如下:

接口权限是一个网关系统最基本的需求,实现方式也有很多。我们这里只讨论最简单的一种。

ACL这个英文缩写,大家都不陌生,全拼是Access Control Lists 访问控制列表。

 

举个例子,我们有service1,service2,service3三个接口,有userA, userB, userC三个用户。

userA可以访问service1,service2,service3。

userB可以访问service2。

userC可以访问service3。

 

下面讲一些技术上的细节

存储结构

根据上面的场景,我们的ACL怎么设计呢?

第一种办法是:

service1 -> userA

service2 -> userA,userB

service3 -> userA,userC

 

第二种办法是:

userA -> service1,service2,serivce3

userB -> service2

userC -> service3

 

看起来好像都可以,那么,让我们来看一看,对一个大型网关来说,系统有什么特点:

  • 用户可能是百万级别的。
  • 按百万总数算,活跃用户大概有十万左右。
  • 接口的数目在几百到几千。
  • QPS一般在几十万级别,每个请求都需要校验权限。所以这些数据是要存到缓存中的。

所以,根据网关的特点,第二种存储结构更适合我们。

那么,mysql的表结构就是下面这样:

user_idacl
A1,2,3
B2
C3

然后,把这份数据存到redis中。当B用户的请求进来时,比如说,B用户请求的是service1,我们取出B的acl,发现没有service1,那么就给B返回无权限。

到这里,似乎一切都没什么问题,文章似乎该结束了。

但是,如果接口数量增长到几百甚至上千时,会发生什么呢?

这时,mysql的存储会变成下面的样子:

user_idacl
A1,6,105,106,112,120,123,125,128,138,205,206,207,208,220,226,229,230,448,459,460,468,469,645,685,686,687,688,689,691,696,699,706,710,712,724,725,726,727,728,729,730,731,732,733,734,735,736,737,738,739,740,741,743,745,746,748,751,756,757,758,759,760,761,762,764,765,766,767,768,769,770,777,778,779,780,781,785,789,797,800,801,806,807,808,809,810,811,812,813,814,822,825,830,834,836,839,840,848,849,850,851,852,862,863,865,866,867,868,869,873,874,875,877,880,882,883,884,885,886,887,888,889,890,891,901,903,905,906,907,909,910,911,912,913,914,921,922,930,931,932,933,934,935,936,937,938,939,940,941,944,945,946,949,950,951,952,953,954,955,956,957,958,959,960,961,962,963,965,966,967,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,987,988,989,990,1009,1010,1011,1012,1013,1014,1015,1016,1017,1018,1019,1020,1021,1022,1023,1024,1025,1026,1027,1028,1029,1030,1031,1032,1033,1034,1035,1037,1038,1039,1040,1041,1042,1043,1044,1045,1046,1047,1048,1049,1050,1051,1056,1058,1059,1060,1061,1064,1065,1066,1067,1068,1069,1070,1071
B1,6,105,106,112,120,123,125,128,138,205,206,207,208,220,226,229,230,448,459,460,468,469,645,685,686,687,688,689,691,696,699,706,710,712,724,725,726,727,728,729,730,731,732,733,734,735,736,737,738,739,740,741,743,745,746,748,751,756,757,758,759,760,761,762,764,765,766,767,768,769,770,777,778,779,780,781,785,789,797,800,801,806,807,808,809,810,811,812,813,814,822,825,830,834,836,839,840,848,849,850,851,852,862,863,865,866,867,868,869,873,874,875,877,880,882,883,884,885,886,887,888,889,890,891,901,903,905,906,907,909,910,911,912,913,914,921,922,930,931,932,933,934,935,936,937,938,939,940,941,944,945,946,949,950,951,952,953,954,955,956,957,958,959,960,961,962,963,965,966,967,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,987,988,989,990,1009,1010,1011,1012,1013,1014,1015,1016,1017,1018,1019,1020,1021,1022,1023,1024,1025,1026,1027,1028,1029,1030,1031,1032,1033,1034,1035,1037,1038,1039,1040,1041,1042,1043,1044,1045,1046,1047,1048,1049,1050,1051,1056,1058,1059,1060,1061,1064,1065,1066,1067,1068,1069,1070,1071
C1,6,105,106,112,120,123,125,128,138,205,206,207,208,220,226,229,230,448,459,460,468,469,645,685,686,687,688,689,691,696,699,706,710,712,724,725,726,727,728,729,730,731,732,733,734,735,736,737,738,739,740,741,743,745,746,748,751,756,757,758,759,760,761,762,764,765,766,767,768,769,770,777,778,779,780,781,785,789,797,800,801,806,807,808,809,810,811,812,813,814,822,825,830,834,836,839,840,848,849,850,851,852,862,863,865,866,867,868,869,873,874,875,877,880,882,883,884,885,886,887,888,889,890,891,901,903,905,906,907,909,910,911,912,913,914,921,922,930,931,932,933,934,935,936,937,938,939,940,941,944,945,946,949,950,951,952,953,954,955,956,957,958,959,960,961,962,963,965,966,967,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,987,988,989,990,1009,1010,1011,1012,1013,1014,1015,1016,1017,1018,1019,1020,1021,1022,1023,1024,1025,1026,1027,1028,1029,1030,1031,1032,1033,1034,1035,1037,1038,1039,1040,1041,1042,1043,1044,1045,1046,1047,1048,1049,1050,1051,1056,1058,1059,1060,1061,1064,1065,1066,1067,1068,1069,1070,1071

发现问题没?

acl太长,会导致至少两个问题:

存储空间。这其实倒没啥,毕竟现在硬盘已经很便宜了。

更新。比如新增了一个通用的接口,所有用户都有权访问,那么,得把这个接口的id追加到所有用户的acl末尾。这其实也没啥,毕竟新增接口的频率特别特别低,新接口也没那么着急上线,慢慢更新呗。

但是,作为一个程序员,看着又长又慢的系统,心里还是不爽的。

有没有什么更好的办法?

其实,对于权限来说,一个用户对一个接口要么有权限,要么没权限。也就是说,0和1就可以表示权限的有和无,理论上,1个bit就可以存储一个用户对一个接口的权限信息,显然比接口id拼接字符串划算的多。刚好,我们的接口id可以是从1开始递增的。

是不是想到了一种数据结构?

是的,bitmap,这简直是最适合bitmap登场的场景。(关于bitmap这种数据结构,不清楚的同学可以网上搜一搜,很多详细的介绍)。

先来直观的感受一下,用bitmap替换字符串之后,数据长度的变化:

user_idacl
A����Z���X� �l��������<�������p \����:���Q����?����
B����Z���X� �l��������<�������p \����:���Q����?����
C����Z���X� �l��������<�������p \����:���Q����?����

是不是短了很多很多?


为啥是乱码?8个bit组成一个字节,本质上,存储的是字节数组,这些字节展示出来,就是这样了。。。

牺牲了可读性,换来了其他好处。

以上,对MySQL的影响其实还好,最严重的是对Redis的影响。

一开始,接口不多时,我们在redis中是用set存储的,读取也方便,读写类似下面这样:

sadd A 1,2,3

sadd B 2

sismember A 1

sismember B 1

比如我们有100W用户,那么,在redis中,也就是100W个set,每个set长度在几百左右。

这其实也就占用二三十G的空间,一切看起来都还好。

 

然而,随着接口数量的增长,很多用户的set的长度同时来到513时,恐怖的事情发生了。

redis直接报警,空间不足,扩容一倍,依然报警空间不足,事情似乎不太对。

各种调查之后,得到的结论简单说就是:当set的长度小于512时,redis用intset(可以认为是字符串)存储set结构,空间上能节省很多,当长度大于512时,出于性能考虑,redis的存储结构退化为hashtable,退化发生时,内存占用会增加10倍左右。

 

这可不得了,好在,Redis提供bitmap操作。bitmap在redis中其实存的是一个string,string的内容和mysql中看到的乱码差不多。redis的对bitmap的操作就不介绍了,网上有很多。

改成bitmap存储之后,redis空间稳定缓慢增长,不会再出现暴增的情况了。

...全文
500 点赞 收藏 回复
写回复
回复
切换为时间正序
请发表友善的回复…
发表回复

还没有回复,快来抢沙发~

相关推荐
发帖
API及云原生
创建于2021-06-07

152

社区成员

API接口以及云原生相关如容器、微服务等内容的讨论
帖子事件
创建了帖子
2021-09-07 17:58
社区公告
暂无公告