服务拆分不合理，越拆越乱
刚开始搞微服务，很多人图新鲜，恨不得把一个简单的后台管理拆成十几个服务。结果呢？启动要半小时，调一个接口得绕八个人，查个问题从A服务追到Z服务。就像你家厨房本来够用，非得分出洗菜间、切菜间、炒菜间，走个流程比做顿饭还累。
合理的拆分应该基于业务边界，比如订单、用户、支付各自独立，而不是按技术功能硬拆。一个服务最好能独立开发、测试、部署，别动一发而牵全身。
服务间通信不稳定
HTTP调用看着简单，但网络不是理想的。今天网卡抖一下，A服务调B服务超时，B再调C，整个链路就卡住了。更糟的是，没人设超时时间，请求堆着堆着就把线程吃光了。
加超时、重试、熔断是基本操作。比如用Hystrix或者Resilience4j，某个服务挂了，直接返回默认值或缓存数据，别让整个系统瘫掉。就像小区停电，你家的应急灯该亮就得亮，不能全家摸黑等供电恢复。
resilienceConfiguration = TimeLimiter.of(Duration.ofSeconds(3));
retryConfig = Retry.ofDefaults("backendService");
circuitBreaker = CircuitBreaker.ofDefaults("backendService");分布式事务难搞
下单扣库存、减余额，两个服务各管一段。如果扣完库存，转账失败，钱没扣成，货却被锁了，用户不炸才怪。
强一致性在微服务里太贵，一般用最终一致性。比如发个消息，让余额服务自己去处理，失败了就重试几次。像支付宝转账，有时候显示“处理中”，过几分钟才到账，其实就是背后在慢慢对账。
日志和监控分散
以前单体应用，日志全在一个文件里，grep一下就能找问题。现在十个服务，每个都在打日志，出了问题得登录十台机器翻日志，效率低得像用锄头挖地铁。
统一日志收集是必须的。ELK（Elasticsearch + Logstash + Kibana）或者EFK（加个Fluentd）能把所有服务的日志集中起来，加个TraceID串联请求，查问题就像查快递物流，一目了然。
配置管理混乱
开发改了个数据库地址，本地测试没问题，上线后发现忘了改生产配置，连错库了。多个环境、多个实例，靠手动改配置文件迟早出事。
用配置中心，比如Nacos或Apollo，所有服务启动时自动拉取对应环境的配置。改个参数不用重启服务，点个按钮就行，省心又安全。