ionfev

简单实现过，使用 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 就行。

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