淘宝直播长连接弹幕分析(无乱码)

淘宝的powermsg真是个无比神奇的东西,因为现在已经过时了,特地拿出来说道一下:

  • powermsg的相关接口最早是可以直接拿到pv、uv、甚至当前在线人数,这玩意没记错的话在19年下半年被封了
  • 上边的powermsg接口被封了之后仍然可以通过websocket或nativemsg拿到上边的数据,只是没有那么方便,这玩意在20年下半年被封了
  • 淘宝的封是简单粗暴的把和淘宝直播相关的topic数据改成固定值或者随机数,所以对分析协议没有影响
  • 目前淘宝直播的powermsg(可以说web版)已经下线,可以去同源的1688直播看看,以下内容也是基于1688直播

Kubeon中对Nvidia显卡的支持

kubernetes提供了device-plugin框架,只要设备厂商实现了自己的device-plugin就可以将硬件发布到kubelet,并在pod里访问这些设备

其中nvidia实现了nvidia-device-plugin,其显卡的ResourceName被公布为nvidia.com/gpu

节点是否支持及显卡数量可以通过describe nodesCapacity去查看。注意显卡调度的最小粒度是1,并且是pod独占的,也就是说一张显卡只能给一个pod使用

kubeon里通过--with-nvidia进行开启,默认是开启状态(只要检测到有nvidia显卡,在创建集群和新增节点时会自动开启容器的显卡支持),下面我们看下一般安装流程和限制

从x-tt-trace-id来看逆向苦力

宇宙大厂在web和安卓的反扒上是当之无愧的宇宙级,更新速度更是宇宙第一

再接触在它pc版时候我从来没想过签名还能这么玩!安卓这块先是引入cronet解决可以抓包的问题,随后签名放入了so,又调整了混淆!一个字:NB!

以下内容来自对安卓19.2.0的抓包,只谈x-tt-trace-id生成的思路流水账,它只是整个伪造请求的一小部分

Kubeon简介及高可用的实现

kubeon是一个用来一键安装kubernetes高可用集群的命令行工具,特性如下

  • 可以在一台中控机上管理多个集群
  • 使用堆叠etcd,提供外部lb、local-haproxyapiserver-updater三种高可用模式
  • 可以在国内网络环境下正常使用
  • 只需要手动下载这个命令行工具,不需要手动下载其它安装包,所以中控机需要能联网
  • 支持密码和密钥两种模式登录所有节点
  • 有一个直观的完善的cluster-info命令
  • 进行过中等规模集群验证(300+),足够的简单并易用,证书100年有效期缓解焦虑
  • 对新版本支持够快,并且免费(通常从1.x.1开始支持,不包括1.x.0)

Tiddlywiki添加剪藏和本地图片

剪藏这里使用的是MaoXian Web Clipper(以下简称MWC),这个浏览器插件非常好用,支持Chrome和Firefox

Tiddlywiki(以下简称TW)作为一个免费的知识库也是非常棒的,如果希望快速开始可以参照林一二大佬的模版和教程

但是在TW使用过程中也有两个问题一直困扰着我:

  1. 图片只能嵌入,导致单html巨大
  2. 无法通过简单的操作收藏web页面到TW

Doris数据库编译、容器化及踩坑

Doris目前被我们拿来给Tidb减轻压力,主要是两个用途

  1. 把大数据相关组件生成的的超大中间表从Tidb转移到Doris
  2. 定时同步线上的大表到Doris相当于一个只读库。这样大数据相关组件可以在只更改数据源情况下,将批量读写操作都放在Doris从而把Tidb还给业务

这里记录以下编译和容器化中的坑,以及如果要在容器中使用可以直接用现成的镜像febe,文章也可以跳过编译进入启动,编译还是挺慢的

以下内容基于当前(2021-02-02)的最新版(0.13.0),可能不适用于之后的版本

使用Caddy加速所有Docker仓库(包括gcr

引用一下这里的开头,这也是现在的真实感受。Envoy配置略显复杂不利于自行搭建推广,这里我们讨论下如何使用Caddy的反向代理来加速DockerQuayGCR,当然方法是通用的不止限于这些站点

在使用DockerKubernetes时,我们经常需要访问gcr.ioquay.io镜像仓库,由于众所周知的原因,这些镜像仓库在中国都无法访问,唯一能访问的是 docker.com,但速度也是奇慢无比
gcr.azk8s.cngcr.io镜像仓库的代理站点,但是目前*.azk8s.cn已经仅限于Azure中国的IP使用,不再对外提供服务了。国内其他的镜像加速方案大多都是采用定时同步的方式来缓存,不能保证及时更新,中科大和七牛云等镜像加速器我都试过了,非常不靠谱,很多镜像都没有

K8S下挖空Dubbo的一些思路--@Sevice

通过@Service的定义可以发现,这个注解可以作用在类上

从dubbo的角度说来:@Service作用的类会去spring中注册成单例bean,只不是需要增强一下。这里同样可以将@Component作为元注解使用

这里的增强其实只是要把有@Service标记的类按照/classFullName/methodName格式去vertx的路由里注册,能进行http访问即可

实际上这里使用BeanPostProcessor在实例完全初始化完成之后去执行添加路由就可以了

K8S下挖空Dubbo的一些思路--@Reference

通过@Reference的定义可以发现,这个注解可以作用在字段、方法和注解上

实际只需要实现作用于字段和方法上的情况,作用和@Autowired类似:填充字段和方法参数。可以直接将@Autowired作为元注解来使用

但是和@Autowired最大区别的是:@Reference作用的字段或方法参数是不会有实现类,需要在属性填充之前将代理类注册到spring容器中;当然可以不使用@Autowired作为元注解,参照dubbo或者spring的方式自己实现属性填充

实际可以使用的有两个:InstantiationAwareBeanPostProcessorBeanFactoryPostProcessor

K8S下挖空Dubbo的一些思路--可行性

在kubernetes环境下,dubbo显得有些臃肿。我们从用户接口、协议、注册中心三部分来看一下

  • 用户接口:正常情况下开发只会使用三个@Reference@SeviceRpcContext;足够简洁、没问题
  • 协议:默认是单一长连接;首先http2是大势所趋、而且两者实现类似,其次Istio对原始tcp的支持不是很理想
  • 注册中心:无论是ZookeeperNacos都是一个独立的大组件,属于需要单独维护的那种。而且目前的Nacos我没有使用的欲望

那么明确下目的:在保持用户接口的情况下,替换掉dubbo协议和注册中心