惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

SecWiki News
SecWiki News
H
Help Net Security
罗磊的独立博客
Stack Overflow Blog
Stack Overflow Blog
M
MIT News - Artificial intelligence
Jina AI
Jina AI
L
LangChain Blog
K
Kaspersky official blog
I
Intezer
Martin Fowler
Martin Fowler
爱范儿
爱范儿
AWS News Blog
AWS News Blog
The Hacker News
The Hacker News
Recorded Future
Recorded Future
人人都是产品经理
人人都是产品经理
H
Hackread – Cybersecurity News, Data Breaches, AI and More
C
CXSECURITY Database RSS Feed - CXSecurity.com
Spread Privacy
Spread Privacy
Simon Willison's Weblog
Simon Willison's Weblog
U
Unit 42
N
News and Events Feed by Topic
A
Arctic Wolf
G
GRAHAM CLULEY
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - 聂微东
F
Fortinet All Blogs
C
Cisco Blogs
美团技术团队
Vercel News
Vercel News
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
H
Hacker News: Front Page
T
Tailwind CSS Blog
I
InfoQ
宝玉的分享
宝玉的分享
Google DeepMind News
Google DeepMind News
博客园 - 司徒正美
P
Palo Alto Networks Blog
A
About on SuperTechFans
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
云风的 BLOG
云风的 BLOG
TaoSecurity Blog
TaoSecurity Blog
Google Online Security Blog
Google Online Security Blog
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
P
Privacy & Cybersecurity Law Blog
H
Heimdal Security Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Hacker News: Ask HN
Hacker News: Ask HN
O
OpenAI News
博客园 - Franky
Scott Helme
Scott Helme

ypingcn

为什么我还在用 Firefox - ypingcn [streamscharts]2025年全年全球直播平台报告 [streamscharts]2025年全年全球直播平台报告 [streamscharts]2025年Q4第四季度全球直播平台报告 [streamscharts]2025年Q4第四季度全球直播平台报告 奇点前尘:回望人工智能2025 奇点前尘:回望人工智能2025 [streamscharts]2025年Q3第三季度全球直播平台报告 [streamscharts]2025年Q3第三季度全球直播平台报告 在工作中使用 AI 辅助 在工作中使用 AI 辅助 连麦、PK和语音房的实现设计思路 连麦、PK和语音房的实现设计思路 数据密集型应用系统设计笔记 数据密集型应用系统设计笔记 Podcast 是新一代的 Blog?| 播客收听体验分享 Podcast 是新一代的 Blog?| 播客收听体验分享 2022 年终总结 2022 年终总结 追「个人养老金」热点?不如多了解观望看看 追「个人养老金」热点?不如多了解观望看看 静态页面也能实现短链接 | 个人博客历史(二) 何为同路人? | 人生七年(一) 简化开发逻辑的用户属性服务设计 博客更新记录总结 | 个人博客历史(一) 使用本地缓存优化微服务 blade build 在微服务开发中的应用 如何高效地搜索 投顾服务初观察 The South 18 年春招记录 2017 年终总结 Firefox Quantum 引发的思考 续写 《像我这样的一个女子》 用 WPS 生成文档目录 用 nodePPT 完成网页演示 Dr.com 认证的校园网里使用 WiFi 初试 ssh 命令 MATLAB 选修课上的一些有趣的代码 用 Jekyll 在 Github 上搭建一个简易博客 Hello! Github Page 感谢
用户权限服务的设计
ypingcn · 2022-07-28 · via ypingcn
[AD] -- 下方为内容广告,点击支持作者,想过滤广告? -- [AD]

背景:在实际业务场景中,或多或少都有定制特殊名单的逻辑,这些名单可以用来作为活动的特邀用户,亦或者是禁止特定条件的访问权限。这些名单简单划分可以分为白名单和黑名单,按实际约束条件则是用户白名单、地区白名单等。这些名单可以是手动由特定人员添加,或者是由任务分析后生成的结果。下面以 Tars 服务来实现上述目标,简化权限判断的业务逻辑。

最后的实现如下,主要逻辑是从不同的数据源加载数据,根据配置中指定的逻辑进行组合,最后提供接口给外部系统调用。

该微服务可以简单设计为名单权限的判断,再在其上增加一个服务来满足实际应用中更为复杂的逻辑需要。

对外接口设计

FunctionID 是用来区分不同的应用场景。 其他字段可以根据需要拓展。

struct AuthResult
{
    0 optional int iCode; // 判断的结果
    1 optional string sMessage; // 错误信息(或者其他需要用作提示的信息)
    2 optional int iPermission; // 是否有权限(已经判断了黑名单、白名单的逻辑)
    3 optional int iExpireTimestampSec; // 过期时间(秒级),非 0 则为到对应时间后权限可能发生改变。
};
struct AuthReq
{
    0 optional User tUser; // 用户信息
    1 optional vector<long> vFunctionIDs;
};
struct AuthRsp
{
    0 optional int iCode; // 返回值
    1 optional string sMessage; // 错误信息(如果有)
    2 optional map<long, AuthResult> mResult; // 结果
};

版本迭代

从头到位,服务的核心逻辑都是从数据库中加载数据到内存中,然后根据配置进行不同的判断返回结果。

v1 直接判断

第一版是直接把所有数据库数据从固定的一个表内按 FunctionID 区分后,加载到内存中,接口在处理请求时就上以 FunctionID 为维度的读锁,然后根据配置从请求体中取出数据,与内存中的数据进行比较。根据名单类型返回 iPermission 字段的值。

v1.1 从固定的表内加载数据判断

随着单个数据源的增加(某种程度上也有名单维护不合理的原因),每次更新内存中的数据都会因为 SQL 语句执行时间过长(网络传输的数据大),导致服务处理其他请求变慢甚至异常。所以针对数据源的加载问题,做了一点细节优化:

  1. 增加分页查询的逻辑,默认以数据库自增 ID 为依据,每次数据库查询限制 2000 条(一个拍脑袋定一下的配置),如果需要可以自行配置 Pagination 和 PageSize 调整此处逻辑。
  2. 缩小读写数据时的加锁力度,将原有的全局读写单例改为按 FunctionID 划分的不同读写锁。定时更新数据时只对需要更新的部分进行加锁,尽可能避免影响其他数据的判断逻辑。

v1.2 从多变的表内加载数据判断

v1.1 的版本实现里只实现了一个固定语句的查询,形如 select xxx from white_list where function_id = xxx 的语句直接从管理后台中读取手动更新的配置。随着该服务使用范围的推广,已经慢慢无法满足实际需要。

假设有一份名单是由其他部门根据某些条件定时计算出来的,按原有设计只能是每次到处名单再手动加入管理后台里,费时费力。为了更为灵活的实现数据源加载,对数据库读取的逻辑做了以下优化:

  1. 支持自定义配置数据库链接,没有设置则直接使用管理后台的数据库链接。
  2. 支持配置需要读取的数据库字段,留空则默认为udbuserid
  3. 支持配置需要读取的数据库表名,不再只是原有的 white_listblack_list
  4. 增加开关以便关闭默认的function_id = xxx 查询过滤逻辑。
  5. 支持配置where 条件的写法。

实现完本版本后,只需要定时重新读取配置即可避免上述人工操作过程,更加方便地支持动态+自动化变更的需要。

v1.3 优化数据的管理逻辑

到目前为止,所有的数据都是存放在一个全局的 map[string][]string mData 中,key 是functionid,value 则是集合,每次请求过来则从一个map[string]int mFunctionID2FieidID 中取出需要请求中的哪个字段,再与 mData 中的集合进行比较。

这种设计无法满足后续对多个字段进行判断的场景,故进行改造。

TODO

[AD] -- 下方为内容广告,点击支持作者,想过滤广告? -- [AD]