mock服务架构设计

前言

在公司的日常adx开发流程中,我发现其中一个很费心,很费时的行为,那就是要拿到上游的广告offer。

要拿到一个正常的offer,不单单需要匹配内部的逻辑,还要看上游是否需要对你的这次展示机会进行竞价。

由于在adx的业务逻辑中,一次请求会同时请求N次上游,所以必然少不了对上游的询价(请求)行为,那我们在日常开发,以及做代码调试的过程中,有没有办法可以更好的做到能拿到offer来对我们的竞价行为进行调试和开发呢?

还有一种场景就是测试同学会面临的,就是如何在尽量不影响线上数据的情况下,能安全无痛的进行测试adx呢,如果因为测试的行为,导致线上业务数据异常,或者出现了结算问题,对于大规模流量的广告自动化交易程序来说,这都是致命的,严重点来说,可能随时导致破产。

又换句话说,有没有办法能在我们想要做模拟压测的时候,也能进行正常的内部逻辑呢?其中一个难点就是我们在压测的环节,并不想正式去对上游询价,但是我又想要拿到上游的offer,除了 hard code offer的动作外,有没有一些更理想的架构方案呢?

答案是:有的,接下来就是我们的主题

树莓派4b Home Assistant

前言

前面做了几期关于Home assistant的教程,在前面我是完全使用docker手动部署,并且采用基本都是通过安装home-assistant-core去处理。后面我发现很多东西的使用方式都特别别扭,而且确实很多东西都比较麻烦,所以后面再反过来看,发现了一个叫hass的生态,这个其实就是home-assistant的周边生态,而这些周边,几乎都是必备的,于是我妥协了使用了hass的生态,但是有一点不同的是,我这里并没有使用hassOS,而是采用hassIO,也就是home-assistant-supervisor

ha-install-compare.jpg

下面开始,我就会我的正式体现记录我后面的智能家居做法。

ssp-adx-localcache优化

前言

最近在处理ssp-adx-rtb的服务的性能优化,做了好多方面的优化,其中一个就是我们的本地的localcache的问题。

经过pprof的性能分析,发现cache2go,在 CPU Flame Graph 中,占比十分严重,基本大于1/3,既然是localcache,那么,我们的目的本意就是为了提速,所以占比那么大,是十分不合理的。

所以需要找到原因,并且解决它。降低cpu使用率,从而提高服务的QPS,减少服务器成本。

cache2go1

Home Assistant (二)

前言

本次主要是讲解一下进阶版的HA,为什么说是进阶版本呢,因为我也是花了几天的时候,去了解各种知识才了解得到的内容。

内容包括:什么叫hassiohassos,并且他们和Home Assistant 是什么关系。

并且我会重点讲解docker版本HA都是需要怎么玩(不借助hassio),你问我为什么,我就告诉你因为过于繁琐,并且多了很多无用的容器占用系统资源。

为什么我偏执于docker版本的ha?因为我不想一台机器,只做一件事,这对高配置和高性能的机器是一种绝对的浪费。

在这个时候,环境隔离就成了重要的因素, 而docker就很好的做到了这一点,并且不像hassio的底层依赖。

Home Assistant (一)

前言

既然是技术博客,那么这一期,我会开始做一系列的关于智能家居的玩法。

Home Assistant 也叫 HA + Zigbee协议(硬件之间的通信协议)

HACSHA 的一个第三方插件,这个插件包括了许多开发者所贡献的插件,如果你是一名开发人员,那么你一定了解什么叫依赖库。所以可以理解为 HACS 就是 HA 的第三方插件依赖库,你可以在连找到需要对你有用的插件,而你不必重新开发。

为什么选择 Zigbee协议 ? 在对比过蓝牙mesh,wifi协议之后,我最终选择了zigbee协议,在于硬件之间的控制信号量传输本身就少,所以它自身的稳定性和分布式的特点,可以很好的支持到家庭中的各个角落,不会出现由于信号差导致失灵的情况,并且zigbee协议的特点,电量的消耗也是十分的低。

【DevOps】git命令场景用法

前言

现在,git已经成为了大家的代码仓库管理的一个工具了。在日常工作,我们会遇到各种个样的git问题,因此,用一篇文章来累计记录,日常生活中,我们会遇到,但是不常用的命令。