目前 MSE 服务治理的 离群实例摘除、标签路由、金丝雀发布、全链路灰度等功能已经使用该路由方案,经过我们的压测与演练,在CPU、RT等方面均有不少提升,以 Demo 应用为例 (服务调用的跳数为2,下游30节点,每个节点1c2g) 其中调用 RT 提升约 6.7%。
本文从常见的微服务治理场景出发,从流量路由这个场景入手。先是根据流量路由的实践设计流量路由的 Spec,同时在 Spring Cloud Alibaba 中实践遵循 OpenSergo 标准的流量路由能力。
Spring Cloud 版本众多,组件也在不断扩充中,是一个非常强大的微服务框架,不过也不是万能的,任何框架都不是完美的,需要适当的评估是否适合自己。
“从一次常见的发布说起,在云上某个系统应用发布时,重启阶段会导致较大数量的 OpenAPI、上游业务的请求响应时间明显增加甚至超时失败。随着业务的发展,用户数和调用数越来越多,该系统又一直保持一周发布二次的高效迭代频率,发布期间对业务的影响越来越无法接受,微服务下线的治理也就越来越紧迫。”
“可观测”是近几年比较火的一个议题,而 OPLG 就是包含了 OpenTelemetry、Prometheus、Loki 和 Grafana 在内的开源可观测技术合集,它们之间将碰撞出什么样的火花?请阅读本文介绍的基于 OPLG 从 0 到 1 构建统一可观测平台实践。