一个系统设计问题，请各位大佬帮助出出主意。

[xuxonce]

近期遇到这样一个需求。

就是，需要对多个业务系统的多个上下游的节点进行清结算，同时要把多个业务系统上下游节点单独拉出来进行统一管理。

那这个需求，规划了三个部分： （ 1 ）业务系统：包括多个业务项目的流程，业务数据（如订单数据等）； （ 2 ）上下游管理系统：包括上有供应商，下游分销商的信息，并且这些信息都是有层次的树结构信息。希望可以在这个系统中追溯和查看到上下游个节点，在本公司参与过的所有业务的详情； （ 3 ）算账系统：记账，算账，希望算出的帐可以溯源到业务数据。

如果这样来分的话，那么数据存储要如何处理呢？

最简单的办法就是，各存各的，用的时候通过接口互相调用。但是系统之间的数据不但需要调用，还需要进行修改，如对业务数据打标签等。这样做耦合有点儿太严重了，相当于把所有的数据都放到一个库里了。

另一个方法，就是中间一个数据仓，数据 T+1 同步到数据仓，系统之间不直接连接，通过数据仓交互数据。这样设计的话工作量有点儿大，而且 T+1 的延迟，可能对部分业务不太友好，系统之间一些直连可能使不可避免的。

还想了些其它的方式，但是似乎都有各种的不太合适的地方。只能说自己还是水平太 low 了。

请问各位见多识广的大佬，像这样的情况，应该怎么处理比较好呢？

[lhx2008]

没有接触过这类的业务，瞎想的
如果是集中存的话，只要存最重要的部分就行，相当于一个网关 /代理，中间拦截一下数据存下来，至于追溯的话再回去掉。然后再跑任务做缓存。

或者是用信息队列推拉，数据推过来统一处理，有问题再回推消息让业务数据自己处理。不过数据别太多了。

[SbloodyS]

2、3 点实时数仓都可以解决

[dongeast52123]

个人推荐用后者，这样你的业务就不会去其他业务系统耦合。在细节一点，可以通过 binlog 抓取数据，抓取到的数据怎么折腾，还不是你自己决定的么。

[betajun]

1. 上下游系统是不是你有完全的控制权?
如果你有控制权，都可以
如果你没有控制权，是别的团队(人)在维护，最好通过调用接口来处理，你可以要求接口不变。

我觉得能少耦合就少耦合~

[dongisking]

我现在用子系统的结算就是“是中间一个数据仓，数据 T+1 同步到数据仓，系统之间不直接连接，通过数据仓交互数据”这个方案