Heroku 12-Factor应用方法论：第四要素 - 将支撑服务视为附加资源

Heroku 12-Factor应用方法论：第四要素 - 将支撑服务视为附加资源

12factor 项目地址: https://gitcode.com/gh_mirrors/12/12factor

什么是支撑服务（Backing Services）？

在现代应用架构中，支撑服务是指应用程序通过网络消费的各种服务，这些服务是应用正常运行不可或缺的组成部分。典型的支撑服务包括但不限于：

• 数据存储服务：如MySQL、PostgreSQL、MongoDB等数据库系统
• 消息队列系统：如RabbitMQ、Kafka等
• 邮件服务：如SMTP服务器或第三方邮件服务
• 缓存系统：如Redis、Memcached
• 文件存储服务：如AWS S3、阿里云OSS
• 监控与日志服务：如New Relic、Sentry等
• 第三方API服务：如支付网关、地图服务等

传统与12-Factor应用的区别

在传统应用部署中，支撑服务（特别是数据库）通常由系统管理员与应用程序一起部署和管理。这种模式下，应用代码往往会对本地服务有特殊处理，导致服务切换困难。

而12-Factor应用方法论提出了革命性的观点：所有支撑服务都应被视为附加资源，无论它们是：

1. 本地部署的服务（如公司内网的MySQL实例）
2. 第三方托管的SaaS服务（如Amazon RDS、SendGrid等）

关键原则：无差别对待

12-Factor应用的核心原则是：代码中不应区分本地服务和第三方服务。这意味着：

1. 所有服务都通过URL或其他连接标识符/凭证访问
2. 这些连接信息存储在配置中，而非代码中
3. 服务可以随时替换而不需要修改代码

实际应用示例

假设你的应用使用MySQL数据库：

• 传统方式：代码中可能直接使用localhost或特定IP连接数据库
• 12-Factor方式：数据库连接信息（包括主机、端口、凭证等）完全通过配置提供

这种设计带来的直接好处是：你可以轻松将本地MySQL迁移到Amazon RDS，只需修改配置，无需改动代码。

资源的概念

在12-Factor方法论中，每个独立的支撑服务都被视为一个资源。例如：

• 单个MySQL实例是一个资源
• 用于分片的两个MySQL实例是两个独立资源
• 生产环境和预发布环境使用的Redis实例是两个不同资源

这些资源与部署环境是松耦合的，可以随时附加或分离。

实践建议

1. 统一访问方式：对所有服务使用相同模式的访问方法（如都通过URL）
2. 配置管理：确保所有服务连接信息都通过配置管理，绝对不要硬编码
3. 资源可置换性：设计时要考虑任何资源都可以被同类型服务替换
4. 环境一致性：开发、测试、生产环境应使用相同类型的服务架构

优势与价值

采用这种架构模式带来以下优势：

1. 灵活性：可以轻松切换服务提供商或迁移服务
2. 可维护性：配置变更不需要代码部署
3. 环境一致性：减少"在我机器上能运行"的问题
4. 可扩展性：易于添加新的服务实例
5. 灾难恢复：出现问题时可以快速替换故障服务

总结

将支撑服务视为附加资源是构建现代化、云原生应用的重要原则。通过消除本地与远程服务的差异，你的应用将获得前所未有的灵活性和可维护性。这一原则与12-Factor的其他要素（如配置、构建发布运行分离等）共同构成了构建高质量云应用的基础。

12factor 项目地址: https://gitcode.com/gh_mirrors/12/12factor