ljzxloaf

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

有用 C 写 crud 的吗

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

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

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 的设备指纹是怎么取的