谢谢大家的建议，总结下提出来的方案：

sqlite：优点单进程最简单，缺点是有并发性能上的问题，一个连接写入数据的时候别的连接无法读取数据。这样可能需要有个 sqlite 管理进程自己实现备份管理，读写分流等。搜索了有个开源的 rqlite 可能能满足需求，需要再研究一下。

用规范规定开发者必须遵守租户隔离用户数据：优点是把负担转移到开发者上，缺点是还是需要每个插件单独创建数据库（或者每个开发者），如果测试不完备的话可能会出现同一个插件下不同最终用户数据被混淆。然后如果数据库部署在开发者这边，开发者还多了承担数据库维护的责任。

用 tenant id 单库解析 sql 限定租户：优点是架构简单，缺点是实现复杂，可能无法保证真数据隔离。sql 是图灵完备语言，很难分析全部情况。

自建数据库实例，用数据库自带的分库（或者 pg 的 schema ）管理机制：优点是数据库本身不出 bug 的话，数据是真正隔离开的。目前还没有想到太大的缺点，可能需要自己管理一套数据库工具，不能采用云厂商提供的数据库服务，算是一个缺点。

控制 docker, k8s 等自动创建数据库容器：优点缺点和上一条应该一样，还有一个可能的缺点就是资源占用有点大。

修改需求，不要允许开发者使用数据库，用简单存储 kv 等代替：这个方案其实就是只提供有限功能的 Api，我们一开始也是考虑的这个方案，确实值得仔细考虑一下，有提到的 trello 我们得参考下是怎么设计的。优点是完全消解了这个问题，我们推测的缺点可能无法支持聚合等数据库操作，插件比较难给出统计信息等数据，不过这个问题可能可以好好设计一套符合需求的接口来规避。

再次感谢！

有没有看过 piral.io

按 pr 分钱

那看来是必须要开启 https 回源了

@Aliencn 原来如此，这样就说得通了

*5 寸

屏幕起码 5 存以上吧，猎奇的产品只能看看，不能实际用

http 回源是不是不安全？

@sucai 谢谢我去看看

重量最好不要超过 180g

zmq 你开 n 个端口都可以，你的问题是哪个 connect 哪个 bind，这个你考虑清楚就行了，完全可以随机选一个端口 bind，剩下的 connect

@janxin 这个看起来挺不错的，有什么坑吗，准备下个项目试试

试试 zmq

找了答案 https://dzone.com/articles/practical-transaction-handling-in-microservice-arc

数据量小加列 parent id，数据量大上图数据库

顶一顶

顶一顶。

再顶一顶

顶一顶