Bilibili课程模块内容管理系统一、大咖课程管理对接内部提现系统。1.业内大咖课程管理就是对课程数据的增删改查。2.对接内部提现系统基础的大咖的身份认证与银行卡绑定已经完成将统一的B站内部的UID、提现金额和我们自己生成的提现流水号传给提现系统提现系统会返回成功与否以及一个提现系统自己的流水号。3.使用Webscraper浏览器模拟脚本爬取海外课程数据课程标题、简介、标签/分类、作者信息、评价Kettle进行ETL过滤至数据中台空值/异常值处理多语言文本的翻译处理评分系统的归一化处理如5分制转10分制用于后续系统进行AI数据挖掘。如推荐系统、热门趋势分析等APISEC安全平台1.API资产发现汇聚企业全部的服务应用、API、源IP和账号资产。2.脆弱性分析通过发送流量至ZAP工具检测明文密码、参数可遍历、服务器或调试信息泄露。3.异常行为分析账号暴力破解先根据Token获得认证API在根据源IP的调用次数分析、4.路径试探使用余弦相似性判断相似API、5.爬虫翻页识别翻页API接着存储访问信息6.访问基线对比异常核密度估计根据历史的访问数据绘制24小时访问概率基线7.敏感数据内置各个行业的344种敏感词正则探测API响应流量体和数据库数据是否存在敏感8.内置常见国产软件漏洞PayLoad探测高危风险API直接curl一段shell脚本发送至目标应用探测部分版本的国产软件的高位漏洞。10.对接Kafka流量消息做吞吐量优化参数调优。首先增大吞吐量就意味着增加数据延迟生产端增大生产者缓冲区(默认32MB)至64M增大batch.size(默认16KB)至32KB调整linger.ms (默认0)至200ms启用压缩默认Nonesnappy减少网络传输量。消费端fetch.min.bytes (默认1)至512B参数调整要先压测出峰值在循序渐进每次只改1-2个参数调整。11.对接ClickHouse源数据插入从流量中做源数据抽取(API、源IP等等)通过内存表高效写入ClickHouse定义分区策略高效查询数据定义物化视图聚合计算结果表。12.对接Tdengine数据库的应用研究将流量数据批量插入Tdengine定义TagIndex配合时间窗口流式计算和Python的Sql脚本的做流量分析。13.自研异常检测算法如核密度估计(KDE)机器学习基线绘制算法将访问趋势符合正态分布的API当日访问基线与学习历史基线做对比。格拉布斯(Grubbs)异常检测算法根据IP日访问次数做异常排查。余弦相似度(Cosine Similarity)算法识别相似访问的API路径做路径试探检测。翻页异常检测识别源IP是否进行了类似爬虫爬取。14.编写静态探针Java-Agent使用Byte-Buddy字节码增强技术识别代理Jar包内业务方法的敏感词或直接对SkyWalking做源码修改后进行商用。15.编写定时任务将流量数据发送至Zap做漏洞检测结合漏洞PayLoad做国产软件漏洞检测。16.新老版本迭代使用DataX做离线数据同步至Tdengine。17.前端全查询接口优化从代码、Sql和缓存进行优化配合异步缓存使得接口响应在毫秒级别。18.客户现场线上问题解决使用Arthas排查运行Jar线程和内存的异常情况支持实施部署。CPU一瞬间直接变成100%内存正常5秒钟后又恢复正常后面使用Arthas排查thread -n监控到敏感词分析的线程正则匹配一瞬间占用大量cpu后面发现是我们的实施在安装的时候没有根据公司类型打开对应的敏感词检测全开了然后我们的敏感词匹配使用了Trie树已知敏感词身份证、银行卡待检测 存款需要身份证密码账号。根节点├─ 身│ └─ 份│ └─ 证└─ 银└─ 行└─ 卡“存” → 不在第一层不是身或银→ ❌ 跳过“款” → 不在第一层 → ❌ 跳过“需” → 不在第一层 → ❌ 跳过“要” → 不在第一层 → ❌ 跳过“身” → 找到入口进入身分支下一个字份 → 匹配继续下一个字证 → 匹配✨ 发现敏感词身份证老版本对接Kafka流量消息做吞吐量优化参数调优。1.Kafka流量消息做吞吐量优化参数调优。生产端RecordAccumulator(阿q米leite)生产内存池由32m变64m。batch.size默认16k。配合linger.ms 10ms 就是16k一批次发送最多延迟10ms。配合linger.ms默认0ms不进行延迟即来一条发一条。默认-1 等待所有的主从节点全部落盘才去应答。0 不需要任何落盘应答直接确认。1 主节点落盘就直接确认应答。broker 采用0 1 -1 的应答策略使用了0。消费端fetch.min.bytes 默认1B 设置为 128KBfetch.max.wait.ms 默认500msMax.poll.records 最大拉取批次条数默认500条设置为1000条。3.对接ClickHouse源数据插入从流量中做源数据抽取通过内存表高效写入ClickHouse定义分区策略高效查询数据定义物化视图聚合计算结果表。批量写内存表之后进入mergetree表将流量按照apiid进行分区按照createtime进行order排序我们业务上经常需要根据某个api进行流量查询先锁定分区块在进行查询同时定义好物化视图的结果表比如按照没分钟每个api的请求流量体大小去获取到结果表。4.对接Tdengine数据库的应用研究将流量数据批量插入Tdengine定义TagIndex配合时间窗口流式计算和Python的Sql脚本的做流量分析。因为ClickHouse的物化视图不好用Tdengine时序列式数据库更加适合我们这种需要按照时间去分析流量的场景所以后续将流量数据按照projectid 和apiid 进行tag分区同时创建流水窗口计算函数按照没分钟每个api的请求流量体大小去获取到结果表。Python的Sql脚本的做流量分析查询td和clickHouse直接在服务上运行脚本获取敏感词漏洞热点api、错误响应状态之类的top 几。5.自研异常检测算法如核密度估计(KDE)机器学习基线绘制算法将访问趋势符合正态分布的API当日访问基线与学习历史基线做对比。格拉布斯(Grubbs)异常检测算法根据IP日访问次数做异常排查。余弦相似度(Cosine Similarity)算法识别相似访问的API路径做路径试探检测。翻页异常检测识别源IP是否进行了类似爬虫爬取。基线学习对于已知服务正太分布规则的api选定时间范围绘制出历史的基线就是一天当中各个秒的访问次数出现的概率。和当前日基线进行对比查看是否有特别的异常偏离。格拉布斯(Grubbs)异常检测算法根据IP日访问次数做异常排查会计学的异常值剔除算法去按照每天的访问次数量剔除异常的数值。格拉布斯算法基于正态分布的前提通过计算每个测量值与数据集均值的残差并与预设的临界值进行比较从而判断该测量值是否为异常值。1.计算均值 x_bar2.计算标准差 s sqrt[(Σ(xi - x_bar)^2) / (n - 1)]3.格拉布斯统计量Gi abs(xi - x_bar) / (s * sqrt(1 - (1/n)))4.确定格拉布斯临界值n10和α0.05临界值G_crit大约是2.2左右。5.数据点10.0的Gi值将远大于G_crit因此被判断为异常值。余弦相似度(Cosine Similarity)算法相似访问的API路径做路径试探检测。cos(θ) (A·B) / (||A|| ||B||) 1(不相似)到1(非常相似)API1/api/group/v1/2/ipAPI2/api/group/v1/3/pro②选定向量维度。将两API的子目录名称相加且去重得到目录名称集合M{api, group, v1, 2, 3, ip, pro}记M的数组大小为s。③构造向量。构造s维向量各个维度取值等于M各个元素在API中出现的次数如api在API1中出现1次则取值为1依次法构成向量A(1,1,1,1,0,1,0)B(1,1,1,0,1,0,1)。翻页异常检测识别源IP是否进行了类似爬虫爬取。识别api中的翻页遍历的标识如页号的标识、页码大小的标识。url成对出现 要么在 reqbody 成对出现 并且每个应用的分页标识相同并且都是数字并且必须包含过1,2。这样去写代码识别出来。之后就进来的流量查看是否是识别出翻页参数的应用并且根据翻页参数的组合记录每个ip对每个api的访问组合数大于30则触发报警。6.编写静态探针Java-Agent使用Byte-Buddy字节码增强技术识别代理Jar包内业务方法的敏感词或直接对SkyWalking做源码修改后进行商用。配置扫描包路径之后选择业务分类启动参数传进去内置了一个12M的敏感词、还有一系列相关的正则选择业务分类会按需开启对应的匹配用字节码技术匹配出敏感词skywalking的话直接打到控制台日志上普通代理直接 打log。7.编写定时任务将流量数据发送至Zap做漏洞检测结合漏洞PayLoad做国产软件漏洞检测。Zap就是开源的扫描工具我们把api访问路径给它他会自己在路径或者请求体去组装攻击数据直接发起调用调用包含的应用查看响应是否存在漏洞。漏洞PayLoad做国产软件漏洞检测我们的网络安全专家已经预置好了国产软件全部的常见的PayLoad攻击脚本curl 带着这些PayLoadbody过去若出现响应带有admin字样则存在get shell 风险。8.新老版本迭代使用DataX做离线数据同步至Tdengine。ck数据送到td编写配置文件主要解决ts时间序列问题使用了mysql的随机时间函数加上我们流量的创建时间秒一直随机到纳秒。9.前端全查询接口优化从代码、Sql和缓存进行优化配合异步缓存使得接口响应在毫秒级别。中泰证券数据量极其大做了假的异步缓存。10.客户现场线上问题解决使用Arthas排查运行Jar线程和内存的异常情况支持实施部署。有时候会特别卡有时候又不卡了。shell连上客户的 centos发现cpu确实会每隔大概1分钟有一瞬间的飙升至90%使用Arthas 进行持续监控在cpu达到90时一瞬间执行 Thread -n 10 打印出当前消耗cpu资源最高的线程的堆栈发现是一个敏感词的正则匹配的方法堆栈信息。我检查了代码代码距离上次修改很久了测了好几个客户按照道理稳定的功能我们是累计到200条流量进行一批次的敏感词正则判断看了 Pattern pattern Pattern.compile(regex); 来一条流量就去创建重新创建一个这样的对象完全不需要一个正则是固定的可以重复使用这是个优化点。但仔细想想这也不会导致cpu吃紧。最后发现去实施的同事照着操作手册忘记配置了一步就是按照当前行业选择对应的敏感词大类造成了全量的敏感词规则的匹配总共有3000多个造成了一批次匹配时cpu瞬时彪高。刚需加载了江西电力行业的敏感词也就180多个就好了。
