蒲公英路由器，自带远程开机。应该是路由器里面默认装好了 wake on lan

PVE 。喜欢飞牛的影视和相册，就在里面装一个飞牛。喜欢其他系统就在里面装其他系统。PVE 太好用了。像飞牛每周更新的频率，裸机升级有暴毙风险，PVE 就随便折腾了，还能远程搞。

公网 IP ，不是固定公网 IP 。我们联通的，都是免费给的公网 IP 。

买了 20 USDC 支持一下

我说一个场景，自己搭的 k8s 估计不会考虑 k8s 升级的问题。我们用的 AWS EKS ，它每过一段时间就会升级一次，不仅升级 k8s 版本，还有插件版本，还有 k8s 所在镜像版本（服务器的 linux 版本），而且它能做到无缝升级，还是很牛逼的。不知道这个跟 OP 研究的方向是否有关。

我是在 nas 上装的，清晰度确实比 mstsc 差很远，好处是 macos 、windows 、手机全平台都能用。代码可以看清，感觉有点像向日葵免费版本的那种清晰度，但不卡。虽然软件可以调节画质，但感觉效果不太明显。
安全方面感觉应该还可以吧，RustDesk 有个 ID 服务器和中继服务器，即使被攻破，黑客也无法控制你电脑。Rustdesk 是端对端加密，ID 服务器告诉客户端 A 客户端 B 的网络地址，而中继服务器转发加密的数据包。本身 Rustdesk 客户端还有个 ID 和密码，所以就算服务器被攻破也不行。不过为了 ID 服务器被攻破还是有隐藏的风险，毕竟所有的连接的客户端 ID 会被黑客知道，理论上他可以暴力破解密码。我觉得 ID 服务器和中继服务器不要用默认端口。客户端密码设置长一些。

eks ，不过 aws 比较鸡贼，过期不升级额外收一大笔 support 费用，其实感觉它啥都没干。

我有个几台服务器，群晖 918+，自己 DIY （ i5 8400 ），NUC 豆子峡谷（ i5-8259U ），mac mini4 。其中 NUC 装了 PVE ，跑 4 个 LXC 和 2 个 VM ，这个 NUC 性能其实还可以的，功耗也不高大概 10W ，如果对存储没有需求的话可以考虑，它只能装 1 块 SSD 和 1 块 M2 。群晖是特别稳，跑了 6 年多了，一次问题都没有，目前作为代码仓库和主要资料备份，缺点是性能较弱，不适合跑太多高负载应用，另外功耗偏高大概 50W 左右。自己 DIY （也是 PVE ，6 个 VM+2 个 LXC ）主要跑一些高负载的应用，像 jenkins 、nexus 、数据库各种中间件，还装了飞牛主要用于影视相册啥的，缺点是不稳定，经常重启，不知道是不是跑的东西太多了，功耗也高也在 50W 左右。mac mini4 开发 APP 、AI 知识库跑 ollama 啥，它的功耗逆天，平时待机 1W ，调用 AI 时把内存和 GPU 吃满，也就是 30W 左右。

看大家都在喷阿里云，感觉对阿里云不公平。Verisign 改之前都不审核的吗？如果有人让他改 google 的他也会改吗？明明责任就在它。

MQTT

自从 k8s 一统江湖之后，spring cloud 的生态已经不吃香了，注册中心、配置中心、gateway 、Sentinel ，k8s 都有，而且不限语言。

非常棒，支持楼主。已经用上了，顺便问下 namespace 功能可用吗？没有看到怎么配置它。

twilio 、vodafone 、aws sns 、telnyx

看了下 OOMOL 的介绍，发现东西做得很棒，但门槛很高。其实现在类似的工作流工具很多，但用起来并不是很方便，它们提供的功能都类似。我之前玩过 n8n ，我要完成的一个工作流大概这样：每月我会收到某个供应商的邮件，邮件附件里面有个账单，我要把这个账单下载下来，然后到我们 OA 系统里面提付款申请，这个付款申请要填一堆跟供应商和账单相关的信息。我希望工作流能帮我自动从收到的邮件里面提取出账单并完成付款申请提交。
现实操作的时候发现有很多问题，n8n 提供了邮件收发的功能，也能提取附件，但要分成很多步骤。然后还要读取附件内容，解析出账单编号、金额、日期等信息，这部分就要自己写代码了。再往后给 OA 系统提付款申请，还得对接 OA 系统，然后发现 OA 没有开放 API ，完犊子。
我相信有很多人会碰到类似的诉求，但是基于现有的工作流工具并不能很方便的解决。

怪物史莱克

spring data jpa 中可以给实体加个 @Version 就能自动处理乐观缩，这种方式没有毛病，只有更新的一瞬间判断，感觉效率比行锁高。

@heqingpan 感谢，期待 rust 版本的 xxl-job 。

@heqingpan 感谢作者的无私奉献。关于 xxl-job ，在我使用过程中碰到过 2 个问题，第一个问题是每个任务每执行一次都会产生一个小的日志文件，当任务特别多执行很频繁的时候，这些日志会把服务器 inode 数量耗光。第二个问题是 xxl-job 有个日志表 xxl_job_log 数据量特别大时（任务执行比较多且频繁），会严重影响数据库性能，它会不定期查询这个表来判断任务完成情况。建议做成按照日期的分区表。