数据层是否可以独立为RPC？

Question

假设有多个应用，调用同一套Models数据，多个应用都需要各自实现数据访问层方法，有大量的重复代码，所以想是否可以将这部分代码独立为RPC，这样不管是模型声明还是方法只需要实现一次，各个应用通过调用RPC实现数据读写。

实践中这样是否可行？

Answer 1

从道理上来说是可行的，最近我针对用户部分就做了一套类似的东西，用k8s部署在同一套内网损耗不了多少性能。

但是用golang的话，且都是用的同一套数据库或者说数据库、表结构一致，可以作为一个 pkg 不同项目引入进来就行了，使用起来更方便，然后统一维护这套 pkg 就行了，不需要搞得那么复杂。

然后以我的经验来说一下用RPC做数据层的场景：

1. 控制不同应用拿到的数据不同，可以放到 RPC 里统一做控制。
2. 底层数据库部分对于实际应用访问来说，不能完全暴露，只有后台才可以访问全部数据，那么基于这种情况考虑可以独立成 RPC 调用，并把这一层的数据库独立出来专门用这套服务来做管理。

Answer 2

把数据层提升为数据服务是可行的，但肯定会牺牲性能(相比代码复用)，好处是减少了维护成本；

Answer 3

当然可以，将数据访问层实现为RPC是一种可行的方案，可以让多个应用共享同一份代码，避免冗余实现。但是需要注意的是，RPC调用会带来额外的性能开销，需要根据实际情况综合考虑，选择适当的方案。同时，还需要确保RPC服务的高可用性、稳定性和安全性，这也需要付出一定的努力。

答案引用AI生成内容，并进行了验证

Answer 4

假设你有一个电商应用，需要访问商品、订单、用户等数据。你可以将这些数据层封装为RPC服务，提供统一的接口和规范。这样，你的电商应用就可以通过调用RPC服务来获取或更新数据，而不需要关心数据层的具体实现和存储方式。这样做的好处是，你可以在不影响电商应用的情况下，对数据层进行优化、扩展或替换。例如，你可以将商品数据从MySQL迁移到MongoDB，或者将订单数据从单机部署改为分布式部署。只要你保证RPC服务的接口和功能不变，电商应用就不需要做任何修改。这样可以提高系统的灵活性和可维护性。