理想很丰满，但是能做到何种程度就难说了，就像项目立项时都奔着改变世界去的，最终大多数结局是“能用就行”。

http status code 是与业务无关的，业务相关的 status 还是需要通过报文返回，所以我们讨论的其实是业务无关给状态应该如何返回。其实用啥都可以，但是如果用 http status code 的话会增加一些沟通成本和程序员的心智负担，因为要学习和沟通两套 code 。我觉得能 All in one 都尽量 all in one ，看看现在企业的各种平台不都是能集成在一起的都集成在一起了，多转个圈就多了一分成本。

而且现在有些公司用 http 是对外的 web 接口，有些公司则直接用 http 作为 rpc ，后者如果为了以后升级方便，应该尽量不要依赖 http status code ，http 仅作为传输层使用。

@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