2024年7月 的存档
20247 月23

BudIot 开源物联网设备平台v1.0发布

BUDIOT 是一个开源的、企业级的物联网平台,它集成了设备管理、协议解析、消息订阅、场景联动等一系列物联网核心能力,支持以平台适配设备的方式连接海量设备,支持在线下发指令实现远程控制,支持扩展水电气等各类计费业务场景。

本平台是在千万级设备实时计费物联网平台经验基础上,在不损失性能的前提下进行功能删减、结构优化而来,小而美,同时又具备灵活的扩展性。

源码: https://github.com/budwk/budiot

在线演示地址: https://demo.budiot.com 用户名: superadmin 密码: 1

官网: https://budiot.com

开发框架

基于自研 Java 微服务框架 https://budwk.com

简单说明

Jar 运行模块

  • budiot-access/budiot-access-gateway 设备网关,用于设备协议和 network 组件
  • budiot-access/budiot-access-processor 设备数据上报业务处理模块
  • budiot-server WEB 服务 API ,定时任务等

其他模块说明

  • budiot-access/budiot-access-network 网络组件,支持 TCP/MQTT/UDP/HTTP 等
  • budiot-access/budiot-access-protocol 设备协议开发包,内含 demo 示例
  • budiot-access/budiot-access-storage 设备数据存储,可扩展时序数据库等

前端模块

  • budiot-vue-admin Vue3 + Element-Plus

开发环境

  • OpenJDK 11
  • Redis 6.x
  • MariaDB 10.x
  • MongoDB 7.0.x
  • RocketMQ 5.2.x

设备上报有效数据存储

默认采用 MongoDB 7 的时序集合,可根据项目规模需要,扩展为 TDEngine 等时序数据库

20247 月16

为群晖 Container Manager 配置代理

原文地址:https://blog.chai.ac.cn/posts/docker-proxy

最后更新:2024年7月15日

最近又见识到了一些神奇的骚操作,考虑到在将来 Docker 的国内各个镜像站可能变得不可用,需要未雨绸缪一下。 有旁路由自然是好的,但现在打算用 Proxy 来解决这个问题。 由于群晖的 Container Manager 是基于 Docker 的,但部分配置路径不同,所以特意记录一下。

注意事项:

  • 本教程在全新的 Ubuntu 22.04 LTS 系统环境下通过测试
  • 本教程在群晖 DSM 7.2 版本通过测试,假定具备 root 权限
  • 假定你已有可以代理 HTTP 或 SOCKS 协议的端口:例如 192.168.50.100:7893
  • 尽可能引用官方文档,本文主要针对需要代理的部分的设置

安装 Docker,为 apt 设置代理

群晖 Container Manager 用户可以跳过这一小节,你实际上已经有 Docker 了。

Docker Engine 安装过程请参考 官方文档

Docker 官方给出了许多安装方式,我选择用 apt 从官方维护的源中安装。

你也可以选择手动下载二进制包,然后用 dpkg 安装.

这里选择使用 apt 演示,关键在于很多人还不清楚如何为 apt 设置代理:

shell

sudo vi /etc/apt/apt.conf

shell

Acquire::http::Proxy "http://192.168.50.100:7893";
Acquire::https::Proxy "http://192.168.50.100:7893";

注意第二个行依旧是 http 协议,否则会碰到 TLS Could not handshake 问题。 代理服务器只需要负责做请求转发和响应转发,不会像 HTTPS 协议一样进行解密和加密。

为 Docker Daemon 设置代理

安装完成后,官网教程会让你运行 docker run hello-world 来验证安装是否成功。

默认情况下,你的本地肯定不存在任何有关镜像(如下所示),因此会从官方库拉取:

shell

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Retrying in 1 second
docker: error pulling image configuration: 
  download failed after attempts=6: dial tcp 31.13.82.33:443: i/o timeout.

执行拉取操作的是 Docker Daemon,参考 官方文档 进行 Proxy 有关的设置:

对于 Docker 引擎 23.0 及更高版本

提示

使用 docker info 可以查询到版本信息,版本太低的话请参考下一节的方法。

Docker Daemon 大多数配置选项都可根据 daemon.json 文件进行设置。

对于 Docker 引擎 23.0 及更高版本,可以在该文件中设置代理行为:

  • Root 模式:/etc/docker/daemon.json
  • Rootless 模式:~/.config/docker/daemon.json
  • 群晖 Container Manager:/var/packages/ContainerManager/etc/docker.json

shell

{
  "proxies": {
    "http-proxy": "http://192.168.50.100:7893",
    "https-proxy": "http://192.168.50.100:7893",
    "no-proxy": "127.0.0.0/8"
  }
}

这些配置将覆盖 docker.service 默认的 systemd 设定。

如果您位于 HTTP 或 HTTPS 代理服务器后面,例如在公司设置中, 则必须在 systemd 服务文件中指定守护程序代理配置,而不是在 daemon.json 文件中或使用环境变量。

较为通用的 systemd 设置方法

如 Docker 版本太低,不支持通过 daemon.json 配置代理,则需手动创建 systemd 文件:

  • Root 模式:/etc/systemd/system/docker.service.d
  • Rootless 模式:~/.config/systemd/user/docker.service.d
  • 群晖:/etc/systemd/system/pkg-ContainerManager-dockerd.service.d

添加 http-proxy.conf 文件,下面以群晖 Container Manager 为例:

shell

sudo mkdir -p /etc/systemd/system/pkg-ContainerManager-dockerd.service.d
sudo vi /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/http-proxy.conf

shell

[Service]
Environment="HTTP_PROXY=http://192.168.50.100:7893"
Environment="HTTPS_PROXY=http://192.168.50.100:7893"
Environment="NO_PROXY=localhost,127.0.0.1"

如果你有内建的 registry-mirrors, 记得加入 NO_PROXY 中。

重启 Docker Daemon

不论采用上面哪种方式,都需要重启 Docker Daemon 服务:

  • 如果是旧版本群晖(6.0+),要用 synoservice 代替 systemctl.
  • 如果是 rootless 模式,要用 systemctl --user 代替 sudo systemctl.

下面仅仅给出 root 模式和群晖 Container Manager 的重启方法:

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl restart pkg-ContainerManager-dockerd.service

重启 Docker/Conatiner Manager 服务需要一定的时间,取决于你正在运行的容器数量。

检查设置是否生效:

sudo systemctl show --property=Environment docker
systemctl show --property=Environment pkg-ContainerManager-dockerd.service

再次跑 docker run hello-world,应该就能成功了。

为 Docker 容器设置代理

有的时候,你使用的 Docker 镜像在 build 和 run 时也需要代理。 大部分应该都知道怎么配置,或者会通过环境变量来设置。 但有的时候希望代理配置默认对所有容器生效(那为什么不用机器或路由级别的代理呢),可以参考下面的方法。

参考 官方文档 中的说明,你可以在 ~/.docker/config.json 中设置代理。

shell

{
 "proxies": {
   "default": {
     "httpProxy": "http://192.168.50.100:7893",
     "httpsProxy": "http://192.168.50.100:7893",
     "noProxy": "127.0.0.0/8"
   }
 }
}

保存文件后配置将生效,适用于新容器的生成和运行,无需重启 Docker,

本质上,它通过影响 Docker CLI 来添加环境变量,效果类似于:

shell

docker build --build-arg HTTP_PROXY="http://192.168.50.100:7893" .
docker run --env HTTP_PROXY="http://192.168.50.100:7893" redis

但一般还是建议单独针对需要代理服务的容器手动设置这些环境变量, 同样地,一些 Docker 内的应用是不按照环境变量来设置代理的,需要手动配置,需要额外注意。 折腾了这么多,是不是还是觉得旁路由+规则代理的方法会更加简单呢?这就看个人需求了。

20247 月9

Java项目运行一段时间后报错 Comparison method violates its general contract

java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Comparison method violates its general contract!

错误代码:
children.sort((o1, o2) -> (int) (o2.getLong("createdAt", 0) - o1.getLong("createdAt", 0)));

修复后:
children.sort((o1, o2) -> Long.compare(o2.getLong("createdAt", 0), o1.getLong("createdAt", 0)));

排序器 children.sort((o1, o2) -> (int) (o2.getLong("createdAt", 0) - o1.getLong("createdAt", 0))); 存在一个潜在的问题,即当时间戳的差值超出 int 的范围时,强制转换为 int 会导致数据溢出,从而导致比较结果不正确。

一个解决方法是使用 Long.compare 方法进行比较,而不是手动进行减法运算。Long.compare 方法确保了比较的对称性和一致性。

20247 月8

600万设备连接平台遇到的坑

MongoDB 的坑

listCollections

  • 问题:代码中存在 listCollections 操作,大量数据上报时,造成MongoDB CPU高升,使处理性能受到影响。经过检查,发现通信报文日表是自动创建的,每次都会判断集合是否存在;而mongo驱动包里判断集合是否存在的操作,就是先执行 listCollections;
  • 优化:提前创建好需要的集合,不要在数据上报的时候进行判断、创建;ps:其实其他数据库,比如mysql、tdengine等,都是同样的道理;

连接数过大

  • 问题:MongoDB 连接数配置较大,导致很多handler服务,过多的线程会导致上下文切换开销变大,同时内存开销也会上涨;
  • 优化:调低连接数配置,进行压力测试;

规则引擎的坑

  • 问题:为了提升性能,往往采用队列+规则引擎来处理业务,设备协议解析+计费业务是在一个handler里,而规则引擎则在下一个队列处理;规则引擎负责为欠费的表具创建短信提醒、关阀指令(产品欠费规则配置),往往在第一个队列里需等待N秒,将规则引擎创建的指令一起下方给表具,每天几百万表具实时上报数据+实时计费,数据并发量较大,如果都等待N秒,会严重影响处理性能;
  • 优化:对计费后余额大于等于0的的表具,不等待N秒,直接回复结束指令,绝大部分表具其实已经是关阀状态,无需本次下发关阀指令,哪怕有需要关阀的,延后到下次通信再执行也没影响;对于小于0的表具,则使用原有逻辑;优化后,降低了90%的等待时间,大大提升高峰高并发处理性能;

HTTP订阅的坑

  • 问题:前期主要通过AEP平台的http订阅实现NB表的通信,但是http服务在高并发时有时候会挂掉(具体表象就是两个http服务,只有一个存活,另一个服务存在,但不处理数据);
  • 优化:将http服务单独服务部署,不要和其他handler、服务抢占服务器资源,jvm也就不会崩了;后期采用MQ订阅方式;

站内信的坑

  • 问题:原有产品设计当设备产生告警时(原生告警、规则告警等)有站内信提醒,经过项目实际运行,站内信数据非常庞大,时刻都有设备告警,导致web页面卡顿、后台web服务资源占用高;
  • 优化:去掉设备站内信告警功能,一是站内信管理人员完全看不过来,二是设备告警在功能菜单里可以查询到;

20247 月5

MongoDB 为什么要限制连接数

Mongod 的服务模型是每个网络连接由一个单独的线程来处理,每个线程配置了1MB 的栈空间,当网络连接数太多时,过多的线程会导致上下文切换开销变大,同时内存开销也会上涨。

  • 连接是要消耗资源的,而且消耗的并不少。
    • 内存:MongoDB为例,每个线程都要分配1MB的栈内存出来。1000个连接,1G内存就这么没了,甭管是否是活跃连接
    • 文件句柄:每个连接都要打开一个文件句柄,当然从成本上讲,这个消耗相对内存是小了很多。但换个角度,文件句柄也被其他模块消耗着,比如WT存储引擎,就需要消耗大量的文件句柄
  • 是否真的需要这么多的链接,一般的业务场景下请求压力在1000QPS左右,按照每个请求50ms计算,最多也就需要1000/(1000/50)==50个链接即可满足需求,并且是整个系统50个链接即可。
  • 很多人平时没有怎么注意过链接数概念,上云后发现居然有这样的限制,心里很不舒服,可能非常不理解。这里说下常见的两种情况:
    • 短链接:一般都是PHP环境,因为PHP的框架决定了PHP短链接的特性,并且链接数的需求一般是在1000-3000左右,具体多少还要根据业务部署的PHP数量来计算。并且MongoDB开源版本在短链接Auth处理上并不优雅,会消耗非常多的CPU资源,3000链接即可跑满24Core的CPU。PHP大拿Facebook也有同样的问题,所以他们用go语言自行开发了一套Proxy代理,来解决对MongoDB的短链接请求问题,但这毕竟带来部署成本和兼容性问题。
    • 长链接:比较健康合理的使用方式,但是也要正确的配置客户端,相关的参数为&maxPoolSize=xx 在ConnectionURI上追加上去即可,否则默认每个客户端就是高处100来个,平白的浪费资源
  • 链接数的上限需要综合考虑性能,稳定性,业务需求。多方面去考虑,缺一不可。超低的内存,配置超高的链接数,得到的只能是OOM。