Build a Local Refund Workflow Service

Build a simplified refund workflow using local HTTP services. Start three independent services that communicate over HTTP: Order Service: stores order information and exposes an order lookup endpoint. Refund Service: accepts refund requests and records refund results. Workflow Service: accepts refund workflow requests, executes nodes in dependency order according to a DAG, and calls the other two services. Minimum functional requirements: Order Service: GET /orders/{order_id} returns whether the order exists, its amount, and its status. Refund Service: POST /refunds accepts order_id and amount. It must be idempotent for the same request_id; duplicate requests must not issue duplicate refunds. Workflow Service: POST /workflows/refund accepts order_id, amount, and a DAG. Each node contains id, type, and depends_on. Support at least: fetch_order: calls Order Service; issue_refund: calls Refund Service and must depend on a successful fetch_order node. Workflow Service must validate that the DAG is acyclic and that dependencies exist. It must not execute a node whose dependencies have not succeeded. Each service must run on a different port and use real HTTP requests. Do not merely call methods among classes in one process. For network timeouts or 5xx errors from Order Service or Refund Service, Workflow Service must retry at least once using the same request_id. Example DAG: { "nodes": [ {"id": "get_order", "type": "fetch_order", "depends_on": []}, {"id": "refund", "type": "issue_refund", "depends_on": ["get_order"]} ] } Explain how to run the services locally, which ports they use, and which HTTP requests can verify the end-to-end flow. Example Input 订单 order-1 存在，金额 25；DAG 为 fetch_order -> issue_refund；请求退款 25 Output 工作流成功；两个节点均成功；返回退款记录