问一个系统设计的问题

• 資深大佬 : 519718366

  最简单的快速迭代方式就是，a 服务直接出相关服务，B rpc 调用。

  有没有必要把相关的 dao 抽成单独模块，就看你们的划分了

• 資深大佬 : firefox12

  RPC， 高内聚，A 就负责它的数据和逻辑，B 就复制 A 的数据里变报表。

• 資深大佬 : limuyan44

  你说的前 2 种方案 b 服务上线 a 服务难道不跟着上线吗，哪天业务新增一个字段不是从 a 服务频繁上线变成了 ab 服务频繁上线了。

• 資深大佬 : cassyfar

  A 的 mapper 和 pojo 移到公共的 module 来。不要通过 A 拿数据。。。因为业务逻辑上，A 和 B 是完全独立的。

• 資深大佬 : shizepeng

  一个好的系统设计者应该要多角度去综合考虑问题，如果你选择 RPC 方式，那么维护成本肯定低，但是可扩展性不强，系统耦合性高，而且 A 的改造升级会不会影响 B 的正常运转，系统之间的耦合性强。

  如果采用 B 方案，那么维护成本高容易出错，但是可扩展性强，耦合性低，生产活动、升级改造过程中不会互相干扰。

  各有优劣，没法抉择，这时候就看需求，需求很重要，仔细阅读需求后，再来考虑问题。如果对生产活动的稳定性要求高，对可扩展性要求强，那么采用 B 方案，反之，采取 A 方案。

• 資深大佬 : lecher

  问题是如何满足频繁变更的报表需求。
  成本最低的方案其实是用专门的报表基础设施解决这几个问题：
  1. 报表计算逻辑的声明
  2. 报表同步数据

  自己另起服务定制写统计是成本最高的方案，不管你是 rpc 还是定制写计算逻辑。
  两个业务其实可以通过数据库解耦。
  不管你有多少业务项目：A1 、A2 、A3……
  业务项目只负责自己的业务数据读写的约束。

  报表业务应该只关注数据库的数据是什么样，如何通过数据库的数据计算出需要的报表，clickhouse 、tableau 、superset 这类开箱即用的报表解决方案不是更合适吗。

• 資深大佬 : lazyfighter

  B 依赖 A，也解决不掉，需求来了，不改 A 啊

• 資深大佬 : teddy2725

  再搞个 B 数据库以 A 的数据做数据源，联机分析和联机事务场景不同，表结构也需要不一样

• 資深大佬 : ychost

  B 去调用 A 就行了，用 dubbo 之类的也方便

• 資深大佬 : lix7

  直接 mono-repo 复用代码，但是分开部署