@xifangczy #4 谢谢，亲测可用

@dot #2 离不开 b 站小姐姐😂

用 mq 挺好的，自带进度管理，client 宕机恢复，自动 rebalance 。就是要把任务多倒腾几趟，多些资源开销。

有用 C 写 crud 的吗

写小说 /homelab/厨艺 /vlog/播客 /blog/github

@ljzxloaf #26 好吧，是节点的原因。。

https://i.imgur.com/8BPVb8g.png
v2 的广告可以

需要换个角度去思考问题。

打个比方，产品需求描述一般是用户场景和交互流程，而这些变化是非常快的，我们不可能给每个场景、每个流程写一套代码，所以需要从业务模型的角度去思考，而不能从业务流程的角度去思考。比如你这种就可以看做是几种业务模型组合起来的流程，其中的业务模型有第三方业务、缓存、日志等，我认为你这种写法没啥问题。如果有些逻辑重复读较高，可以根据业务更为细致的封装。比如 A 业务与 B 业务组合起来形成一个业务。这种组合就看具体需求了。

流程与对象是相对的，流程的每个节点都是对象，对象的内部逻辑也是流程。

实践中，我们一般可以同时提供两种接口：一种是不依赖其他业务的“原子”接口；另一种是依赖其他业务的“组合”接口。

比如搜索，我可以同时提供：返回 id 集合的接口和返回 item 集合的接口。item 信息是我从 item 服务拿到的，这样我等于组合了 item 服务和搜索。反过来也类似，比如敏感内容过滤，我也可以提供两种接口：传参 id 集合和传参 item 集合，如果只传 id 我需要去 item 服务查 item 信息，就是组合接口；如果传给我 item 集合，我就不需要去依赖 item 服务。

这种做法有什么好处呢？我们可以先考虑这样一个问题，我们有底层服务 A （ atom ），有两个上层服务 C1 、C2 （ combination ），现在有个需求要调用 C1 的接口 C1.I1 和 C2 的接口 C2.I1 ，这两个接口都要调用 A 的接口 A1.I1 ，这样我们为何不先调 A1.I1 ，然后把返回的信息传给 C1 和 C2 呢？当然当我们没有这种冗余调用的时候，还是用原来的接口，这样更方便。

我分析下来这样做从性能方面应该是有利无害的。从 IO 方面来看，虽然直接传递 item 信息增加了传递参数的网络开销，但是由于不需要去查 item 服务，减少了一次 item 服务返回 item 信息的网络开销，这两者已经抵消了。而后者还减少了查 item 的请求网络开销，item 服务的计算开销，和依赖服务或 db 的计算和网络开销。所以性能无疑是提高了很多。

上面只讨论了最简单的情况，其实实践中远比这复杂。上层服务会依赖多个下层服务，组合是千变万化的，不可能为每种组合都开个接口。比如 C 依赖 A1 和 A2，那就要四个接口，依赖 A1 的接口（ A2 信息通过传参）；依赖 A2 的接口（ A1 信息通过传参）；都不依赖（全部信息通过传参）；都依赖。假设依赖 n 个服务，就需要（排列组合 n 选 n 、n-1...1,0 加和）个接口（感觉像科里化过程...），所以还是要根据实际情况具体问题具体分析，只提供那些用户普遍需要的组合。

@marczhao #9 谷歌咋了

@marczhao #6 对的，我直接用的 11 的 image，按官方的说法是兼容 arm 的，但是我用下来大部分都不行。我是想看看一些 app 的设备指纹是怎么取的

ddd，如果業務模型發生顛覆性變化的話不能算是程序設計的問題。另外，這不叫健壯，這叫可擴展性。有個原則叫做 ETL （ easy to change ）

@sytnishizuiai #4 這個命令叫啥，我用的 Ubuntu

每天少吃一点，渐渐的胃口就小了，别老想着一蹴而就。该吃啥还吃啥，但是要“浅尝辄止”，其实食物第一口是最美味的不是吗，尝到了前面的美味，没必要一直重复个没完。“光盘行动”已经不适合时代了，是要把国民吃成美国那种体型吗？我简直要怀疑这是医疗行业的阴谋了。

结贴了，感谢
@yitingbai #4
@IgniteWhite #5

@ljzxloaf #13 正常的业务需求走开发测试部署流程，不正常的需求也尽量走正常流程，除非你 100%能 hold 住。你这么玩是否定了测试的价值。

动态加载 class 不是什么难事，但是你这样不是等于直接上生产调试？理论上你可以把所以的业务逻辑都弄成动态的，问题是必要性在哪？ OSGI 发展这么久为什么被 JPMS 干掉了，因为它所谓的热部署 /热替换根本没啥必要。Web 服务都是集群，无损上下线简单得很，要啥热部署 /热替换。

“但是这样做要发布到正式环境，调试也是非常不方便，每次发布要等好久” 这是啥理由，造点数据调试不就行了。

如果只是偶尔手动修改数据，直接用 sql 。如果经常需要手动修改数据，那应该反思的是，为啥要手动修改数据，用户的数据我们没有权限修改，除非是 bug 。