多团队持独立数据库场景下跨项目共享通用微服务的最佳方案

核心架构思路 #

将共享微服务封装为和环境、CI/CD工具完全解耦的可复用构件，每个下游项目独立部署专属实例，既保证复用性，也满足账户隔离、数据独立的要求。

具体落地步骤 #

1. 共享微服务标准化封装 #

• 所有待共享的微服务统一通过serverless.yml做配置抽象，把差异化配置项（AWS区域、数据库规格、环境变量、权限策略）全部抽成入参，禁止硬编码业务相关值
• 每个微服务的IaC模板同时覆盖计算资源（Lambda、API Gateway等）和配套独立数据库资源（DynamoDB表、RDS实例等），保证单次部署就能生成完整可用的微服务实例
• 微服务代码存放在独立的私有代码仓库，和下游业务项目的代码库完全隔离

2. 统一生成版本化部署产物 #

• 为共享微服务单独维护CI/CD流程，和下游项目的CI/CD工具无关，每次迭代生成带语义化版本号（如v1.3.0）的标准部署包，同步归档对应版本的参数模板、数据库初始化脚本
• 部署产物统一上传到专属S3存储桶，给两个业务项目的AWS账户开通该存储桶的只读权限，不需要给下游开放代码仓库权限

3. 适配下游不同CI/CD流程 #

Bitbucket Pipelines项目适配

在项目的部署脚本中增加部署步骤：

• 从共享S3存储桶拉取指定版本的微服务部署包
• 执行serverless deploy命令传入当前项目的专属参数（环境标识、数据库配置、权限规则等），直接部署到当前项目的AWS账户，自动生成独立的微服务实例和配套数据库

CodePipeline项目适配

在Pipeline中新增CodeBuild阶段：

• 构建步骤拉取对应版本的部署包
• 传入当前项目的专属参数后执行部署，所有资源自动创建在当前项目的AWS账户下，和另一个项目完全隔离

4. 版本与隔离管理 #

• 两个项目可独立选择使用的微服务版本，无需强制同步迭代，升级时只需修改部署脚本中引用的版本号即可
• 每个项目部署的微服务实例完全独立，配套数据库天然隔离，不会出现数据串用、故障互相影响的问题

不建议采用跨账户调用共享微服务实例的方案，会带来权限配置复杂、故障影响面大、数据隔离难合规等问题，独立部署实例是当前场景下成本最低的方案。

可选优化 #

如果后续共享微服务不需要做定制化修改，可以封装为AWS Serverless Application Repository（SAR）应用，两个账户直接从SAR部署即可，无需手动拉取部署包。

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