看了代码优雅实现的帖子想到的实践思路

前情提要:t/796126?p=1#r_10794970

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

比如搜索，我可以同时提供：返回 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 加和）个接口（科里化?），所以还是要根据实际情况具体问题具体分析，只提供那些用户普遍需要的组合,必要的时候可以另起服务以维护业务模型的清晰性（ message passing -> multiple dispatch?）。

XDM 觉得这种实践靠不靠谱，欢迎分享讨论