<dependency>
<groupId>com.agentsflex</groupId>
<artifactId>agents-flex-bom</artifactId>
</dependency>
里面的依赖
<dependency>
<groupId>com.agentsflex</groupId>
<artifactId>agents-flex-llm-tencent</artifactId>
<version>1.0.5</version>
<scope>compile</scope>
</dependency>
里面的依赖
<dependency>
<groupId>com.tencentcloudapi</groupId>
<artifactId>tencentcloud-sdk-java-common</artifactId>
<version>LATEST</version>
<scope>compile</scope>
</dependency>


搞不明白 都写 java 了你用个的 LATEST

<dependency>
<groupId>dev.tinyflow</groupId>
<artifactId>tinyflow-java-core</artifactId>
<version>1.0.2</version>
</dependency>

里面的依赖

[ERROR] dependency: com.tencentcloudapi:tencentcloud-sdk-java-common:jar:LATEST
应该是还没同步最新的...

@liaohongxing 上面就一个官网 没啥流量的
感觉是有人批量扫这个机房的 ip d

@liaohongxing 买基础款也没用啊 发工单人家的客服扔出来的截图是峰值到了 30Gbps
假设你买基础版的防护 那么还是会被打爆到阈值扔黑洞
高级点超过 30G 的防护一个月 5 万起步了

https://www.nodeseek.com/post-324644-1

类似的反馈

https://x.com/q1ngyang/status/1916848047243608161
推上也找到了类似情况的，一样是阿里深圳区域机房

评价：互联网赛博黑帮 不交保护费就定时 d 你

正常服务器被攻击应该是和售后沟通解决 来了个阿里云卖高防的售前？
很难不让人怀疑 毕竟成交一单高防标准版就有至少每月 2w 的业绩 钱这么好赚是吧

用就不要怕
9.1.0 直接冲 哪里报错改哪里

另一个方法
使用 maven 作为运行时 base image
或者 dockerfile 里安装 maven
springboot 使用 thin-launcher

https://github.com/spring-projects-experimental/spring-boot-thin-launcher

这样打包时所有依赖都不会带上 配置好 maven 运行时会自动拉取 缺点是首次运行会慢很多
优点是极度节省 docker 镜像的空间 完整 jar 包 500M
thin-layout 打出来 5M

napcat-desktop + koishi + koishi plugin database mysql +koishi plugin database mysql + koishi-plugin-messages-slim

onebot 直接存消息到数据库
怎么备份数据库自己掌控

docker-compose.yml
```
name: docker-proxy
services:
registry:
image: registry:2
ports:
- '5000:5000'
volumes:
- ./config.yml:/etc/docker/registry/config.yml
- registry_data:/var/lib/registry
restart: always
container_name: registry
hostname: registry
logging:
driver: "json-file"
options:
max-size: "10m"
volumes:
registry_data:

```


config.yml
```
version: 0.1
log:
fields:
service: registry
storage:
cache:
blobdescriptor: inmemory
filesystem:
rootdirectory: /var/lib/registry
http:
addr: :5000
headers:
X-Content-Type-Options: [nosniff]
proxy:
remoteurl: http://registry-1.docker.io
```


nginx xxx domain.conf
```
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;

ssl_certificate /path/to/cert.crt;
ssl_certificate_key /path/to/cert.key;
ssl_trusted_certificate /ssl/origin_ca_rsa_root.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519:P-256:P-384:P-521;
ssl_early_data on;
ssl_stapling on;
ssl_stapling_verify off;

add_header Strict-Transport-Security "max-age=63072000" always;
server_name xxx.domains;

location /v2/ {
# Allow GET, HEAD, OPTIONS requests
if ($request_method !~ ^(GET|HEAD|OPTIONS)$ ) {
return 405; # Method Not Allowed
}
# Proxy requests to the registry
proxy_pass http://127.0.0.1:5000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}


}

server {
listen 80;
listen [::]:80;
server_name xxx.domains;
return 301 https://xxx.domains$request_uri;
}
```


usage:
```
官方镜像
docker pull youdomain/library/postgres:12.22-bookworm

非官方镜像
docker pull youdomain/redis/redis-stack-server

```

小爱音箱 play 增强版
带红外 带蓝牙网关 带 wifi
传统的不智能不联网的空调也能远程控制了

有预算 致远\蓝凌
没预算 钉钉

定义好表单和流程后接 api 触发事件进行操作,一般都没啥问题
小团队没预算用钉钉,调用次数应该是够的
大团队用自部署的致远\蓝凌之类 可以定制化
自己从头写一套 oa 不现实,30 个人的内部团队维护一套 oa 都很够呛,出问题有你背锅的

(建议三台 nas 装 pve 组 ceph
设置双副本或者三副本
坏了块盘直接换,甚至不影响读写
(硬件层面的 raid 或者软 raid 并不保险 现在普遍 10t 单盘以上,真坏盘你还得得一两周重建时间,我猜大部分人等不起

问就是三台 pve 组 ceph
单块物理盘做 osd
三副本或者双副本能够保证坏一块盘时不影响虚拟机上数据的读取写入
换完盘直接重平衡就行