厂商锁定
评估并最小化离开厂商的成本，而非拒绝用厂商。
为什么
厂商锁定是切到不同供方的成本——以工程月计。有些锁定可（S3 API 事实标准、离开便宜）；有些严重（DynamoDB 专有 API、离开是重写）。拒所有锁定意味全自建（贵、慢）；拥所有锁定意味厂商涨价翻倍账单。纪律是按组件评估锁定、自由接受便宜锁定、仅锁定严重且切换可能处加可移植层（薄抽象、标准格式）。盲目"无锁定"和盲目"全 押一厂商"一样贵。
何时使用
选任何厂商管理组件时。1 小时评估。厂商定价或路线图变时重访。
如何做
1. 对厂商组件识别专有面： - API（标准如 S3，或专有如 DynamoDB？） - 数据格式（标准如 SQL/JSON，或专有？） - 集成（绑其他厂商服务吗？） 2. 估切换成本：移备选的工程月 - < 1 工程月 → 低锁定，自由接受 - 1-6 工程月 → 中，若切换可能加薄抽象 - > 6 工程月 → 高，避免或自觉接受+文档 3. 高锁定则谈：多年价锁、数据导出保证 4. 即使专有存储也用标准格式（SQL、JSON、Parquet）存数据 5. 标准（容器+队列）可行处避免厂商专编排（Lambda 绑 Kinesis） 6. 按组件把锁定评估记架构文档
示例
组件及锁定： S3（存储）：标准 API（MinIO 兼容），切换 < 1 工程周 → 低 DynamoDB（KV）：专有 API，切 Postgres = 3 工程月 → 中 Lambda（计算）：专有事件绑，切 Fargate = 2 工程月 → 中 Bedrock（LLM）：专有模型 API，切 = 1 工程周（提 示可移植）→ 低 行动： - S3、Bedrock：自由接受（低锁定） - DynamoDB：加薄 DAO 层使查询可换 Postgres - Lambda：保持函数小+基于容器以可移植 - 数据：全 JSON/Parquet，永不厂商专格式
常见问题
- ⚠把所有锁定当等——S3 锁定可忽略（标准 API）、DynamoDB 锁定真（专有）；按组件评估非全局。
最佳实践
- ✓商品服务（存储、队列）API 标准化处接受锁定；嵌业务逻辑服务（工作流引擎）抗之。
- ✓任何高锁定组件留"厂商退出 runbook"——即使永不用，写它揭示真实切换成本。