应用场景
多语言微服务治理
挑战：
-
业务代码与服务调用耦合
基于Lib/SDK的微服务治理，SDK的维护、升级等变更会造成整个服务的维护升级，业务开发与微服务升级相互制约。 -
微服务框架治理能力差异大
同一种框架无法支持多语言的微服务治理。使用不同的技术栈来开发微服务带来开发效率的提升，微服务治理手段参差不齐。
我们能提供：
-
开发运维关注点分离
通过服务网格代理，将服务治理能力与业务代码相互独立，实现分离关注点。 -
统一的微服务治理方案
服务网格能够支持多种开发语言的服务治理。无需针对多种开发语言维护多套微服务技术体系，明显节省人力成本。
跨集群/地域灾备
挑战：
-
服务注册发现难
微服务容器化可通过Kubernetes的服务（Service）进行集群内服务发现。跨集群场景，如额外部署注册中心，即引入额外维护成本也不具备Kubernetes原生方案在时效性等方成的诸多优势。 -
流量调度粒度粗
集群入口级别的故障容灾策略，单一个微服务发生故障就需要整集群切流，部分可用集群承担了全部的流量压力，带来扩容压力大、资源浪费等问题。
我们能提供：
-
零成本跨集群服务发现
无需额外部署注册中心，基于Kubernetes原生服务发现全自动实现跨地域的服务发现机制，实例迁移1秒同步。 -
服务级流量调度
通过服务网格，可以实现服务级别的自动切流和自动恢复。影响范围小，资源变更少。
服务高可用
挑战：
-
故障场景难以避免
微服务的数量众多，每个微服务的实例众多，不可避免的出现实例级别和微服务级别的故障，对重大隐患预防和故障止损提出了极高的要求。 -
可观测难
微服务间流量调用复杂，微服务数量和实例数量众多，监控配置复杂，故障定位难。
我们能提供：
-
故障隔离
通过主动和被动的健康检查机制，在流量转发时自动规避故障实例，提供限流、熔断能力，在服务级别故障发生时，防止雪崩，保障全局可用性。 -
故障注入
用户可指定服务、指定比例，注入超时、中止等不同类型故障，提前发现微服务体系可用性的不足。 -
多种重试机制
支持超时或指定的返回信息进行请求重试，提升用户请求成功率；支持重试比例设置，防止重试造成过载。 -
快速获得可观测能力
Sidecar内置Exporter，支持OpenTelemetry接口，可无侵入采集流量指标、流量日志和调用链信息。
灰度发布与测试环境复用
挑战：
- 灰度发布场景多样，随着业务的运营精细化，灰度版本面向的目标用户群体有多种不同的分类方式。
- 测试环境搭建费时费力，单个微服务的测试时，也需要同时部署上下游的多个微服务，造成资源和人力的浪费。
我们能提供：
-
灵活的流量灰度策略
服务网格可基于百分比、流量特征等多种方式进行流量分发，支撑用户基于不同场景的灰度发布需求。 -
测试环境复用能力
借助服务网格的流量规则动态下发、流量镜像等能力，可复用基准环境或线上环境现有资源，仅额外部署要测试的单个微服务，即可达到端到端的测试效果。
