TDK CLI实战：ERP销售栈20个服务的依赖与调试

在ERP系统中，销售是最繁忙的领域之一：线索转化为商机，商机转化为报价，报价转化为订单，订单又涉及定价与支付。tdk-erp-system示例中的销售栈包含20个资源，本文梳理这些服务如何关联，以及如何用TDK CLI检查一条完整流程。

销售栈的服务构成

销售栈围绕销售周期组织，核心服务各司其职：

• lead-management-api：跟踪线索
• crm-api：管理客户关系，运行在4300端口
• opportunity-api：跟踪交易管道
• quoting-api：生成报价
• pricing-api：管理价格
• order-management-api：处理订单
• sales-forecasting-api：销售预测

其余服务包括payment-processing-api（支付处理）、territory-management-api（区域管理）和sales-portal-api（客户门户），共同覆盖支付、区域和面向客户的入口。这种按业务能力拆分的微服务架构，让每个服务可以独立演进，但也带来了服务间依赖的复杂性。

启动销售栈

在仓库根目录执行：

tdk up sales

如果修改过某个service.json，建议先加--dry-run查看启动计划：

tdk up sales --dry-run

这个习惯能帮你提前发现配置错误，避免服务启动到一半才报错。对于包含20个资源的栈来说，dry-run几乎是必做步骤。

依赖顺序是关键

销售服务之间存在明确的依赖关系：报价需要价格，订单需要客户。每个服务通过dependsOn声明依赖，TDK会按此顺序启动服务。

如果quoting服务在pricing就绪前启动，它的第一个请求会以令人困惑的方式失败。因此，新增服务时务必检查依赖列表——这是维护销售栈时最容易忽略的细节。依赖声明不仅是启动顺序的保证，也是服务契约的一部分。

dependsOn是TDK中声明服务启动依赖的字段，定义在服务的service.json配置中。TDK在启动栈时会解析所有服务的dependsOn，构建有向无环图（DAG），并按照拓扑排序决定启动顺序。如果两个服务之间存在循环依赖，TDK会报错并中止启动。dependsOn仅保证启动顺序，并不等待依赖服务完全就绪（健康检查通过），因此服务内部仍需实现重试或等待逻辑。此外，dependsOn也用于停止栈时的逆序停止，确保先停止依赖方再停止被依赖方。正确使用dependsOn是保证微服务架构下启动一致性的基础。

端到端检查一条流程

不要孤立地测试单个服务，而应选择一条完整路径，比如“创建线索→转化→请求报价”，逐步检查每个环节。

先调用健康检查路由，再调用实际执行业务的端点。由于其他服务通过crm-api查找客户，建议从4300端口的crm-api开始。

遇到失败时，读取对应服务的日志：

tdk logs --json --service quoting-api --tail 200

执行流程前，先用tdk status --json确认就绪状态。一个仍处于pending状态的服务，即使代码正确也会导致流程失败。

健康检查路由通常是一个轻量级的HTTP端点（如/health或/ready），用于快速判断服务进程是否存活以及是否准备好接收流量。它不涉及业务逻辑，也不验证下游依赖是否可用。因此，健康检查通过仅代表服务自身运行正常，不能保证其依赖的服务（如数据库、消息队列或其他微服务）可用，更不能保证业务契约（如API参数格式、数据模型）匹配。在微服务架构中，健康检查常用于容器编排的存活探针和就绪探针，但端到端测试必须超越健康检查，直接调用业务端点并验证跨服务的交互结果。

测试流程，而非服务

这是原文强调的核心原则：一个销售服务可以通过健康检查，却在报价请求价格时失败。真正需要关注的集成点在服务之间，因此要刻意演练跨服务的路径。

健康检查只能证明进程存活，无法证明业务契约成立。把测试重心放在跨服务的业务流程上，才能暴露依赖配置错误、数据契约不一致等深层问题。

业务契约指的是服务之间交互时所遵循的接口约定，包括API的请求/响应格式、错误码、数据字段含义、超时行为等。在微服务架构中，每个服务独立演进，契约可能在不经意间被破坏。例如，pricing-api修改了价格查询的响应结构，但quoting-api仍按旧格式解析，就会导致报价失败。健康检查无法发现这类问题，因为服务本身是健康的。端到端测试通过模拟真实业务流程，跨多个服务验证契约的一致性，从而暴露字段缺失、类型不匹配、状态码错误等集成缺陷。维护明确的契约文档（如OpenAPI）并定期进行契约测试，是减少这类问题的有效手段。

收尾：停止栈

完成后运行tdk down。未停止的栈会占用端口，影响下一次启动。这个简单的收尾动作能避免“端口被占用”这类低级故障。

总结

销售栈是沿销售周期排列的20个资源。用tdk up sales启动，新增服务前检查依赖，从4300端口的crm-api开始端到端测试一条流程。TDK CLI的价值在于把依赖管理和流程验证变得可操作，让复杂的ERP销售栈调试有章可循。