这是一个创建于 1878 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前有一个 springboot 的业务项目，打个比方叫做服务 A 。
现在需要在这项目 A 的数据基础上，出一些报表，由于可能需要频繁的更改代码并更新，所以打算再起一个服务 B 。
现在的问题是怎么让 B 调用 A 的数据，RPC ？还是把 A 的 Mapper 和 POJO 转移到公共的 module ？还是在服务 B 上单独重新写 Mapper 和 POJO ？
10 条回复 2020-09-07 19:12:37 +08:00
 | 1 519718366 2020-09-05 16:39:42 +08:00 via iPhone 最简单的快速迭代方式就是，a 服务直接出相关服务，B rpc 调用。 有没有必要把相关的 dao 抽成单独模块，就看你们的划分了 |
 | 2 firefox12 2020-09-05 17:09:34 +08:00 RPC， 高内聚，A 就负责它的数据和逻辑，B 就复制 A 的数据里变报表。 |
 | 3 limuyan44 2020-09-05 18:39:58 +08:00 你说的前 2 种方案 b 服务上线 a 服务难道不跟着上线吗，哪天业务新增一个字段不是从 a 服务频繁上线变成了 ab 服务频繁上线了。 |
 | 4 cassyfar 2020-09-05 18:54:18 +08:00 A 的 mapper 和 pojo 移到公共的 module 来。不要通过 A 拿数据。。。因为业务逻辑上，A 和 B 是完全独立的。 |
 | 5 shizepeng 2020-09-05 19:14:16 +08:00 一个好的系统设计者应该要多角度去综合考虑问题，如果你选择 RPC 方式，那么维护成本肯定低，但是可扩展性不强，系统耦合性高，而且 A 的改造升级会不会影响 B 的正常运转，系统之间的耦合性强。 如果采用 B 方案，那么维护成本高容易出错，但是可扩展性强，耦合性低，生产活动、升级改造过程中不会互相干扰。 各有优劣，没法抉择，这时候就看需求，需求很重要，仔细阅读需求后，再来考虑问题。如果对生产活动的稳定性要求高，对可扩展性要求强，那么采用 B 方案，反之，采取 A 方案。 |
 | 6 lecher 2020-09-06 00:16:44 +08:00 问题是如何满足频繁变更的报表需求。 成本最低的方案其实是用专门的报表基础设施解决这几个问题： 1. 报表计算逻辑的声明 2. 报表同步数据 自己另起服务定制写统计是成本最高的方案，不管你是 rpc 还是定制写计算逻辑。 两个业务其实可以通过数据库解耦。 不管你有多少业务项目：A1 、A2 、A3…… 业务项目只负责自己的业务数据读写的约束。 报表业务应该只关注数据库的数据是什么样，如何通过数据库的数据计算出需要的报表，clickhouse 、tableau 、superset 这类开箱即用的报表解决方案不是更合适吗。 |
 | 7 lazyfighter 2020-09-07 11:14:50 +08:00 B 依赖 A，也解决不掉，需求来了，不改 A 啊 |
 | 8 teddy2725 2020-09-07 11:17:32 +08:00 再搞个 B 数据库以 A 的数据做数据源，联机分析和联机事务场景不同，表结构也需要不一样 |
 | 9 ychost 2020-09-07 14:43:25 +08:00 B 去调用 A 就行了，用 dubbo 之类的也方便 |
 | 10 lix7 2020-09-07 19:12:37 +08:00 直接 mono-repo 复用代码，但是分开部署 |
Select Language