
核心链路单点
不做系统隔离,要挂一起挂
程序中大量使用多层循环,CPU使用率百分百
系统引入大量依赖,即使自己不挂,总会被某个依赖拖垮的
服务调用失败了,也不做补偿
没用重试策略,调用失败了,甩锅给被调用方
核心写接口被外部调用,死也不做幂等控制,出现问题甩锅给调用方
服务之间调用不设置合理超时时间,能多大写多大,一丁点调用量可以消耗完内存
大量同步调用,链路耗时长,就甩锅给被调用方
不控制流量,不限流,被打垮了甩锅给调用方
不做核心指标监控及预警,全靠运气
不做热数据缓存,微服务吗,就应该无脑RPC调用
不做服务分级,一视同仁,不考虑核心高可用
不做服务降级,被拖挂了,甩锅被调用方
不做灰度发布和回滚方案,上线全凭运气,就是这么自信
能做远程调用,就做远程调用,5G时代了,延迟都不是事儿
不做熔断机制,拖垮我,甩锅给被调用方
不做代码扫描,自己的代码自己欣赏,那些做CR的完全不懂艺术,各种神奇注释、奇妙函数用起来,这才叫才华
不做线上压测,流量什么的就靠菩萨保佑吧
做什么容量规划,不费钱吗?
本文揭示了微服务架构中常见的错误做法,包括单点故障、过度依赖、无补偿策略、无幂等控制、不合理超时、同步调用过多、流量控制缺失、监控预警不足等问题,指出这些问题可能导致系统稳定性下降。建议实施系统隔离、重试策略、幂等控制、服务分级、降级策略、灰度发布、熔断机制、代码质量把控、容量规划和热数据缓存等优化措施,以提升微服务的健壮性和可靠性。
564

被折叠的 条评论
为什么被折叠?



