CRD 扩展新的能力 • …MESH 落地碰到的问题 • 客户端服务发现与负载均衡无法与 ISTIO 一起工作 • ENVOY 不支持微服务使用的通信协议 • RPC 服务使用的接口，方法，参数语义无法匹配 ISTIO 的路由模 型 • 一个应用上部署了多个 RPC 服务，每个服务有自己的版本 • …ISTIO 控制平面路由的抽象模型 INBOUND OUTBOUNDSOFA 服务注册模型落地一个微服务框架需要的工作

Mixer 基于 Metric 高效、但技术门槛高 Mixerless 13/28挑战2：无 Tracing VS 14/28挑战3：维度匹配-Mixer Instance Service Endpoint 15/28挑战3：维度匹配-Telemetry2 Instance Service Endpoint 16/28应用方案 /03 针对 Mesh 场景下的方案演化 只能二选一 SkyWalking8.0 Tracing，Metrics 可以同时支持维度匹配 SkyWalking Mixer Mixerless Service App without version 同左 Instance Work load 同左 Endpoint Path - 26/28维度匹配-service 命名规则 Version|App|Namespace|Cluster

Ø 简单匹配路由 Ø 集群管理 & 基本负载均衡(RR、 RANDOM) Ø SofaRpc及HTTP/1.1、 HTTP/2.0支持 Ø 进程平滑升级 Ø SOFAMesh集成，支持 xDS on ADS Ø X-Protocol协议扩展机制， 以及Dubbo支持 Ø 支持network/stream filter 扩展 Ø 支持WRR负载均衡 Ø 支持subset复杂匹配路由 Ø ProtocolMatch 返回AGAIN 匹配成功，获 取对应协议 无法识别协议， 断开链接 继续读取数据技术案例 – HTTP/2.0优化 官方HTTP/2.0实现问题： 1. syscall read较多，效率低下 2. 每个stream分配单独的goroutine处理， 调度开销高 3. 临时对象多，GC占比高 4. 基本实现了RFC中MUST部分，部分功 能需求上不匹配，如GRPC trailer实现技术案例

找有关路由相关信息，并动态更新 • 基于标签、key-value、注解、文 件 • Docker、Kubernetes、Marathon 、Rancher、FileEntryPointsRouters匹配器Services • Services 负责配置最终处理传入请求 的实际服务。 • 负载均衡（针对应用实例）：轮询（ 目前支持）、session 亲和性 • 带权重的轮询：仅可用于在 Service Port=8080" - "traefik.http.routers.jenkins.rule=Host(`mycompany.org`) && PathPrefix(`/jenkins`)" # 规则匹配 - "traefik.http.routers.jenkins.service=jenkins" Docker With PathPrefixDocker With Rewrite # https://mycompany

超过最大访问频率后，请求阻塞等待或者直接拒绝（等待时间=0） 常用限 流算法25/总页数 治理策略 & 高可用 • 微服务高可用设计手段 - 服务限流 • 基于来源限流（from） • 系统标签 • 自定义标签 • 基于标签匹配（to） • 系统标签 • 自定义标签 常用限 流用法 matchLabels Exclusion matching26/总页数 治理策略 & 高可用 • 微服务高可用设计手段 - 熔断27/总页数

pod Sidecar 6. Sidecar收到请求 • 从TCP options中的 original dest 获取ClusterIP • 根据ClusterIP从 VirtualHost 中匹配Rule规则，得到转发目标地址SOFAMesh 的DNS寻址 interface1 pod DNS interface2 interface3 1. 服务部署 • ServiceType=ClusterIP

SDS) • 复杂性 • Mixer使用一组称为模板的核心抽象，来描述传递给适配器的数据。 这些包括“metrics”，“logentry”，“tracepan”等。这些抽 象与后端想要消费的数据不匹配，导致运维需要编写一些手动配置， 以便在规范的 Istio 样式和后端特定的样式之间进行映射。原本期望 这种映射可以在适配器中实现很大程度上的自动化，但是最终还是 太复杂并需要手动配置。如果要性能，该怎么做？