微服务落地需规避“分布式单体”陷阱：必须用ihttpclientfactory管理http客户端、严格使用dto隔离数据边界、按场景选型grpc或rest、通过healthcheck主动等待关键依赖就绪，确保服务真正自治。
微服务不是靠加个 ServiceCollection 或起一堆 WebHost 就算落地的。C# 项目里硬拆服务，又没处理好通信边界、序列化兼容、失败重试和上下文传递，八成会变成“分布式单体”——看着是多个进程，实际比单体还难查错。
用 HttpClient 调用其他服务时，为什么总是超时或 500？
根本原因常不在网络，而在调用方没做请求生命周期管理。直接 new HttpClient() 每次都新建实例，会快速耗尽端口（TIME_WAIT 状态堆积），尤其在高并发下；而全局复用一个静态 HttpClient 又可能因 DNS 变更不刷新、连接池僵死等问题导致请求失败。
- 必须用
IHttpClientFactory注册并获取客户端，它自动管理连接池、重试策略和 DNS 刷新 - 不要手动
Dispose从工厂获取的HttpClient实例——它的生命周期由工厂控制 - 为不同下游服务注册独立命名客户端，比如
services.AddHttpClient<iuserservice userservice>("user-api")</iuserservice>，避免共用配置污染 - 超时要分层设：DNS 解析、TCP 连接、TLS 握手、请求发送、响应读取，不能只靠
Timeout总控
服务间传参用 DTO 还是直接传 Entity？
传 Entity 是最常见也最危险的做法。Entity 带有 EF Core 的跟踪状态、导航属性、延迟加载代理，一旦序列化进 JSON 或 gRPC，要么抛 NotSupportedException，要么把整个关联图谱拖进网络，还可能暴露数据库字段（如 PasswordHash）。
- 所有跨服务数据交换必须走显式定义的 DTO 类，字段名、类型、可空性全部明确声明
- DTO 不继承、不含方法、不实现接口（除非为反序列化必需的标记接口），保持纯数据容器语义
- 用
AutoMapper或Mapster做 Entity ↔ DTO 映射，但禁止在映射配置里写业务逻辑（如字段拼接、条件过滤） - 如果服务 A 需要服务 B 的某字段用于本地缓存，别让 B 返回整张表结构——A 应该定义自己需要的最小 DTO，B 按需投影
gRPC 和 REST API 该怎么选？
不是“新就一定好”。gRPC 默认用 Protocol Buffers + HTTP/2，强契约、高性能、天然支持流式，但它对浏览器直连不友好、调试成本高、防火墙穿透更复杂；REST+JSON 更通用、可观测性强、工具链成熟，但序列化开销大、无强制契约约束。
- 内部服务间高频调用（如订单创建链路中库存扣减、积分更新）优先用 gRPC，定义清晰的
.proto文件，生成强类型客户端 - 对外暴露的 API（面向 App、Web、第三方）必须用 REST，且要配 OpenAPI/Swagger 文档，别指望别人去读 proto
- 别混合使用：同一个服务既暴露 gRPC 端点又暴露 REST 端点，除非有明确网关路由隔离，否则版本演进、错误码统一、认证方式都会撕裂
- gRPC 的
Deadline是硬性超时机制，比 HTTP 的Timeout更底层有效，但需客户端和服务端同时配合设置
服务启动时怎么确保依赖服务已就绪？
HealthCheck 不是摆设，但很多人只把它挂给 Prometheus 或 K8s Liveness Probe，却没在启动阶段用它阻塞主流程。结果服务一启动就疯狂重试调用未就绪的下游，打爆对方熔断器。
- 在
Program.cs中用WaitForHealthyAsync主动等待关键依赖（如配置中心、数据库、认证服务）通过健康检查 - 健康检查本身要轻量：数据库只执行
SELECT 1，HTTP 依赖只发 HEAD 请求，避免带业务逻辑的 GET - 别把所有依赖都设为启动强依赖——非核心服务（如日志上报、异步通知）允许降级启动，用后台任务定期重试
- K8s 中
initContainer可以替代部分等待逻辑，但无法替代服务内对依赖状态的主动感知和优雅退避
最难的从来不是把代码拆成多个项目，而是让每个服务真正拥有独立部署、独立扩缩、独立演化的边界能力。通信协议、错误传播、数据一致性、分布式追踪这些细节，漏掉任何一环，微服务就只是套壳的单体。
