询问微服务改造价格之前，先要说明“改造完成”指什么。是获得一份架构评估报告，还是搭建服务骨架；是拆出一个试点，还是将多个业务模块迁移并交付生产运行？这些目标对应的工作范围差异很大，不能放在同一个价格标签里比较。
一、先把一次性实施和持续运行分开
建议使用下面的预算框架：一次性实施费用，加上约定期间的基础设施、软件服务和维护投入，再单独列出已识别风险的处理预算。这里提供的是拆分方法，不是市场报价，也不预设工期和改善比例。
| 工作项 | 常见产物 | 影响工作量的条件 |
|---|---|---|
| 现状评估 | 依赖分析、风险清单、改造建议 | 资料完整度、业务复杂度、环境访问条件 |
| 基础工程 | 服务骨架、认证与入口集成、配置管理 | 已有能力能否复用、组织内统一规范 |
| 业务改造 | 试点服务、接口契约、回归验证 | 业务规则、调用关系、历史兼容要求 |
| 数据迁移 | 迁移工具、对账与恢复方案 | 数据规模、停机限制、写入路径和一致性要求 |
| 工程交付 | 流水线、部署配置、日志与监控 | 环境数量、审批流程、告警与恢复要求 |
| 上线与交接 | 演练记录、上线支持、操作手册 | 上线窗口、支持范围、团队熟悉程度 |
二、报价之外，还有内部投入
客户团队需要解释业务规则、提供环境、参与接口评审和回归测试，也需要安排上线决策与验收。若这些资源没有纳入计划，外部实施人员等待确认的时间可能影响整体进度。
运行成本也应独立估算，包括新增环境、数据库与消息基础设施、日志存储、监控保留周期及维护工作。计算资源的单价只是其中一部分，不能仅根据服务器数量判断总投入。
三、要求报价写清假设和排除项
- 包含哪些业务流程、接口和环境？
- 是否包含数据清洗、历史数据迁移和外部系统联调？
- 现有代码与基础设施由谁调整？
- 验收依据是什么，客户需要提供哪些配合？
- 缺陷修复与新增需求如何区分，后续支持覆盖什么？
可以用一份统一的范围说明向不同服务方询价。比较时，将每项交付映射到相同的验收清单；如果某份报价没有覆盖生产切换或数据恢复，应先补齐范围，再讨论价格差异。
四、不确定性较高时，分阶段估算
现状资料不足时，可以先约定一段范围明确的评估工作。评估完成后给出候选方案、实施依赖、待验证项和估算区间，再为试点定价。试点完成后，根据真实的依赖复杂度与交付结果更新后续计划。
每个阶段都应有独立产物和决策点，让企业可以选择继续、调整范围或暂停。风险预算也应对应具体风险，例如数据质量未知或第三方接口资料不全，而不是随意加一个百分比。
五、先准备一页范围说明
写下当前系统、最主要的问题、期望改造的业务范围、部署环境、可接受的切换方式及验收目标。即使暂时没有完整答案，也可以标记未知项。这份说明比单独问“拆成十个服务多少钱”更容易得到可比较的方案。
如果尚不清楚工作边界，可以先从架构诊断开始，确认应改什么、暂不改什么，再讨论实施预算与阶段安排。