应用场景

多语言微服务治理

挑战：

• 业务代码与服务调用耦合
  基于Lib/SDK的微服务治理，SDK的维护、升级等变更会造成整个服务的维护升级、业务开发与微服务升级相互制约。
• 微服务框架治理能力差异大
  同一种框架无法支持多语言的微服务治理。使用不同的技术栈来开发微服务带来开发效率的提升，微服务治理手段参差不齐。

我们能提供：

• 开发运维关注点分离
  通过服务网格代理，将服务治理能力与业务代码相互独立，实现分离关注点。
• 统一的微服务治理方案
  服务网格能够支持多种开发语言的服务治理。无需针对多种开发语言维护多套微服务技术体系，明显节省人力成本。

跨集群/地域灾备

挑战：

• 服务注册发现难
  微服务容器化可通过Kubernetes的服务（Service）进行集群内服务发现。跨集群场景，如额外部署注册中心，即引入额外维护成本也不具备Kubernetes原生方案在时效性等方成的诸多优势。
• 流量调度粒度粗
  集群入口级别的故障容灾策略，单一个微服务发生故障就需要整集群切流，部分可用集群承担了全部的流量压力，带来扩容压力大、资源浪费等问题。

我们能提供：

• 零成本跨集群服务发现
  无需额外部署注册中心，基于Kubernetes原生服务发现全自动实现跨地域的服务发现机制，实例迁移1秒同步。
• 服务级流量调度
  通过服务网格，可以实现服务级别的自动切流和自动恢复。影响范围小，资源变更少。

服务高可用

挑战：

• 故障场景难以避免
  微服务的数量众多，每个微服务的实例众多，不可避免的出现实例级别和微服务级别的故障，对重大隐患预防和故障止损提出了极高的要求。
• 可观测难
  微服务间流量调用复杂，微服务数量和实例数量众多，监控配置复杂，故障定位难。

我们能提供：

• 故障隔离
  通过主动和被动的健康检查机制，在流量转发时自动规避故障实例，提供限流、熔断能力，在服务级别故障发生时，防止雪崩，保障全局可用性。
• 故障注入
  用户可指定服务、指定比例，注入超时、中止等不同类型故障，提前发现微服务体系可用性的不足。
• 多种重试机制
  支持超时或指定的返回信息进行请求重试，提升用户请求成功率；支持重试比例设置，防止重试造成过载。
• 快速获得可观测能力
  Sidecar内置Exporter，支持OpenTelemetry接口，可无侵入采集流量指标、流量日志和调用链信息。

灰度发布与测试环境复用

挑战：

• 灰度发布场景多样，随着业务的运营精细化，灰度版本面向的目标用户群体有多种不同的分类方式。
• 测试环境搭建费时费力，单个微服务的测试时，也需要同时部署上下游的多个微服务，造成资源和人力的浪费。

我们能提供：

• 灵活的流量灰度策略
  服务网格可基于百分比、流量特征等多种方式进行流量分发，支撑用户基于不同场景的灰度发布需求。
• 测试环境复用能力
  借助服务网格的流量规则动态下发、流量镜像等能力，可复用基准环境或线上环境现有资源，仅额外部署要测试的单个微服务，即可达到端到端的测试效果。