内网穿透被针对是因为不知道你对外提供了什么服务，风险较高。组网工具是自己的一堆设备互联，风险很低。

@babymonster 内网穿透工具通常是把内网中的某个服务映射到公网，例如 frp 。
而组网工具通常是基于 WireGuard 等技术，把多个设备组成一个虚拟局域网，实现设备之间的互联。
由于 WireGuard 主要依赖 UDP ，一些运营商或网络环境会对 UDP 做限制，导致 P2P 打洞失败，只能走中继节点。

Tailscale + Peer Relay （国内的云服务，设置为 Peer Relay 节点，局域网内节点通过这个节点中转），或者使用 wg-easy 在云服务上搭建 WireGuard 。

感觉想法很棒呢，通信上了自动协商采集速率，，面向对象的方式管理不同的协议感觉和 PLC4x 好像。

云效，免费的

简单实现过，使用 Redis 发布订阅，查资料看到还有 MQ 、Zookeeper 、微服务的服务发现。笔记： https://www.cnblogs.com/ioufev/p/17559480.html

@murmur 有了在 k8s 上部署 SpringBoot 程序的经历，觉得微服务时代"启动快，内存占用低，因为有集群，可以不再追求长时间不间断不出错的运行"是有一种不可阻挡的潮流。Java 现在生态非常好，但是也要顺应潮流。至于 Serverless ，感觉只是服务交付方式的一种形式，从原来的高配置虚拟机按月租年租的时间付费，转变为按使用量付费，应用场景适合算法训练类型的按次数运行的任务，不适合长时间不间断的运行的任务。

前段时间在 B 站看到了 2020 年周志明的演讲：《云原生时代，Java 的危与机》，觉得非常有启发。

16+1T ，看价格 1878 ，6 月份买的时候 2109 元，除了夜间的拍照效果不好，其他很满意。

MyBatis 和 MyBatis-Plus 的缺点

借用别人的观点：dao 层和 sevice 层交叉混用。

比如一个用户查询，用 UserMpper 查询也行，用 UserService 查询也行，想用哪个用哪个。

----对比 JPA----

MyBatis 允许开发人员自定义 SQL 语句，适应特定的业务需求。

JPA 更倾向于使用命名查询和基于方法名称的查询，可能在某些情况下不如自定义 SQL 灵活。

JPA 不鼓励写手动写 SQL 语句，鼓励要用 JPQL 。使用原生 SQL 时可能会失去一些 JPA 提供的跨数据库的抽象和便捷性。

对于开发时表结构改来改去的时候，手写 SQL 方便。

当业务逻辑复杂，使用 JPA 生成的 SQL 也复杂到让人看不懂的时候，手写 SQL 直观灵活方便调试。

突然不能用了，访问官网： https://www.yuque.com/500?real_status=500

JWT 是个字符串，是服务端使用密钥单向哈希计算出来的。按理说前端用后端给的 Token 字符串请求，服务端只验证，不保存状态，适合多个后端的分布式。但是呢，后端从来不信任前端（虽然说 Token 是后端生成的，所有的接口后端都要验证判断），所有一般还是后端使用 Redis 保存 Token 的有效期，所以对于踢人功能来说，删除后端 Redis 里的 Token 就行。

精神疲惫，人会变笨，表现为专牛角尖，揪着一个点不放。
睡一觉后精力满满，思维活跃，很容易找到问题所在。