微服务架构最大的谎言是“先拆了再说”。很多团队在没想清楚技术栈怎么选的情况下就急着把单体拆成几十个服务结果半年后陷入运维泥潭服务间调用超时、链路追踪缺失、配置散落各处、发布一次要动十个仓库。选型时偷的懒上线后都会加倍还回来。微服务技术栈选型本质是在团队能力、业务阶段、运维成本之间找平衡。以下五个维度是踩坑最多的地方。一、服务框架别被“先进”绑架Java生态里Spring Cloud Alibaba和Spring Cloud Netflix曾是主流但Netflix组件已进入维护模式。目前更稳妥的选择是Spring Cloud AlibabaNacos Sentinel Seata或Spring Cloud Gateway Consul。Go生态中gRPC Kit或Kratos是常见组合。Node.js则多用NestJS gRPC。避坑点不要因为某个框架“看起来先进”就选它。比如Service MeshIstio确实强大但如果团队只有十几个服务运维能力还没跟上引入Sidecar只会让排障链路从“业务→数据库”变成“业务→Sidecar→Pilot→证书→规则”。服务框架的第一原则是团队能Hold住。二、通信协议HTTP不是唯一也不是最优RESTful HTTP简单通用但性能开销大尤其在高频调用场景。gRPC基于HTTP/2和Protobuf序列化效率高、支持流式通信适合内部服务间调用。消息队列Kafka、RocketMQ适合异步解耦和削峰填谷。避坑点不要所有服务都用HTTP。内部核心链路用gRPC异步场景用MQ对外API用REST。混合使用没问题但要有统一规范避免“每个服务一种协议”的混乱。三、服务治理没有治理微服务就是灾难服务发现、负载均衡、熔断限流、配置管理——这些是微服务的“水电煤”。Nacos和Consul是主流选择Sentinel和Hystrix负责熔断。配置中心必须统一否则改一个参数要登录十台机器。避坑点不要等到线上雪崩才想起熔断。从第一天就要把Sentinel或Resilience4j接进去。另外服务发现和配置中心尽量用同一套组件减少运维复杂度。Nacos之所以流行就是因为它把这两件事一起做了。四、数据一致性分布式事务是最后选项微服务拆分后跨库操作不可避免。Seata的AT模式、TCC模式、Saga模式各有适用场景。但最务实的建议是能不跨库就不跨库能最终一致就别强一致。避坑点不要为了“技术先进”硬上分布式事务。很多业务场景用本地消息表MQ就能解决性能更好复杂度更低。Seata适合金融级强一致场景但引入成本高团队要有人真正懂它的原理。五、可观测性没有它微服务就是黑盒日志、指标、链路追踪是微服务的“三根支柱”。ELK或Loki收集日志Prometheus Grafana监控指标Jaeger或SkyWalking做链路追踪。没有这些线上出问题只能靠猜。避坑点不要等系统复杂了才补可观测性。从第一个服务上线就要接入。Spring Boot Actuator Micrometer Prometheus是Java系最顺滑的组合。链路追踪的Trace ID要贯穿所有服务否则排障时只能一个个服务翻日志。六、部署与运维K8s不是必选项Kubernetes很强大但学习曲线陡峭。如果团队只有几个服务Docker Compose 简单脚本可能更高效。K8s适合服务数量多、需要弹性伸缩和自动恢复的场景。避坑点不要为了“云原生”而强行上K8s。运维K8s集群本身需要专门的人力。如果团队没有SRE托管K8s如ACK、EKS比自建更稳妥。另外CI/CD流水线要尽早标准化否则每个服务一套发布脚本维护成本会指数级上升。结语微服务技术栈选型没有标准答案。Spring Cloud Alibaba适合Java团队快速起步gRPC Go适合追求性能的基础设施Nacos Sentinel Seata是国内最成熟的组合之一。但无论选什么都要问自己三个问题团队能运维吗业务真的需要吗出问题能快速定位吗选型时多花一周调研比上线后花三个月填坑划算得多。别等踩坑才后悔——那时候代价已经付出了。