PostgreSQL按业务拆分独立库后关联用户数据的架构设计问询

你规划的按业务域拆分数据库的方案完全可行，非常匹配你们业务快速扩张、业务数据静态化的诉求，能有效避免单库性能瓶颈、业务数据耦合的问题，后续新增业务线只需要新增独立业务库即可，扩展性很强。

针对你关心的用户一次注册全业务通用的需求，有3种落地方式可以根据你们的技术栈选择：

• 用户中心服务层透传方案（最推荐）
  单独封装独立的用户中心服务，所有业务线的用户身份校验、用户信息查询都统一调用用户中心接口，业务库只需要存储关联的user_id字段即可，不需要存储完整的用户信息。用户注册后统一在UserDB写入数据，开通任意业务线的时候只需要对应业务库关联该user_id打开通标记就行，完全满足一次注册全业务通行的需求。
• PostgreSQL外部表方案
  如果你们暂时不想新增服务层，依赖数据库层面实现关联，可以在所有业务库中创建UserTable的外部表映射：使用PostgreSQL的postgres_fdw插件，直接在PkwDB、LorryTruckDB等业务库中挂载UserDB的用户表视图，业务侧可以直接在本地库做关联查询，和之前单库的查询逻辑几乎无差。要注意这种方案涉及跨库写入的时候需要处理分布式事务一致性问题，适合读多写少的用户查询场景。
  示例创建外部表命令：

  -- 先安装插件
  CREATE EXTENSION postgres_fdw;
  -- 创建远程服务器连接
  CREATE SERVER user_db_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '你的UserDB实例地址', port '5432', dbname 'UserDB');
  -- 创建用户映射
  CREATE USER MAPPING FOR CURRENT_USER SERVER user_db_server OPTIONS (user '数据库账号', password '数据库密码');
  -- 导入外部表到当前业务库
  IMPORT FOREIGN SCHEMA public LIMIT TO (UserTable) FROM SERVER user_db_server INTO public;
  

• 数据定时同步方案
  如果业务侧对用户信息查询的一致性要求不高，也可以用数据同步工具（比如pg_dump定时任务、Debezium）把UserDB的用户数据增量同步到各个业务库的冗余用户表中，查询直接走本地库，适合静态用户信息的场景，同步延迟可以根据业务需求调整。

你的现有方案已经比较合理，只需要做几处小调整就能规避后续的坑：

• 避免把ServiceTable、BookingTable完全复制到每个业务库，建议把业务通用的服务、订单字段抽出来做公共层存储，业务库中存储的ServiceTable、BookingTable只保留对应业务线的个性化扩展字段，关联通用订单ID就行，后续做全业务线的订单统一统计的时候不用跨多个库拉取数据。
• 如果你家后续业务线数量会超过10个，且业务线之间没有强隔离、单独扩容的要求，不用每个业务线都建独立数据库，可以改为按业务域建schema，同一个PostgreSQL实例下用不同的schema隔离不同业务线的数据，和独立数据库的隔离效果几乎一致，还能降低跨库查询、实例运维的成本。如果有单独的性能扩容、数据权限隔离要求，还是保持独立库的设计即可。
• 用户库建议做高可用集群部署，避免用户中心单点故障影响所有业务线的正常使用。

内容的提问来源于stack exchange，提问作者bitsmyth