
#IstioCon
背景
l 核心业务线已完成微服务改造,数万个微服务对架构服务治理能力提出了更高的要求。
l 高级架构能力能否多语言、多框架支持?
l 运维架构能力是否具备可移植性?是否能低成本复制新的产品线?
l 可观测性不足,是否有通用机制提升产品线可观测性?
Ø 部分模块上下游超时配置不合理,超时倒挂,集中管理调整成本比较高。
Ø 多数模块对单点异常,慢节点等异常缺乏容忍能力,推动每个模块独立修复,成本高,上线周期长。
Ø 因重试导致雪崩,底层RPC框架需要重复建设来定制动态熔断能力。
Ø 升级一级服务建设中,发现很多模块单点、多点故障不能容忍,能否低成本解决?
Ø 比如常用运维降级、止损能力各个产品线重复建设,方案差异大,OP期望运维能力在不同产品线之间能够通用化,
集中化管理,甚至做到自动决策
Ø 精细故障能力(异常query、注入延迟等)期望能够标准化、低成本跨产品线复制
Ø 百度APP架构缺少上下游模块视图和流量视图,黄金指标不足,导致容量管理压测效率低、混沌工程实施成
本高、故障定位成本高。
文档被以下合辑收录
评论