细粒度的鉴权（服务间的调用） • RPC支持 • 跨语言的问题 • …云平台微服务演进之Service Mesh云平台微服务演进之Service Mesh Pilot Envoy • 服务发现 • Envoy生命周期管理 • Envoy配置下发 • 服务模型 • 配置模型 • 负载均衡 • 智能路由（灰度、蓝绿） • 流量管理（超时、重试、熔断） • 故障处理 • 故障注入 • … 前提条件检查：安全认证，黑白名单， ACL检查 • 限流管理 • 遥测报告：日志监控 控制平面 数据平面 Istio-Auth • 服务间认证 • 终端用户认证Istio的核心组件 • Envoy 是一个高性能轻量级代理，它掌控了service的入口流量和出口流量，它提供了很多内置功能，如动态负 载服务发现、负载均衡、TLS终止、HTTP/2 & gRPC流量代理、熔断、健康检查等功能。 展组 件，内部提供了多个模块化的适配器(adapter)。 • Pilot 翻译过来是领航员，Pliot对Envoy的生命周期进行管理，同时提供了智能路由（如A/B测试、金丝雀部 署）、流量管理（超时、重试、熔断）功能。Pliot接收用户指定的高级路由规则配置，转换成Envoy的 配置，使这些规则生效。 • Istio-Auth 服务间认证和终端用户认证功能Istio的Pilot功能解析Pilot官方架构Istio

增加端到端延迟 • 进程外适配器进一步增加了延迟 • 授权和认证功能是天然适合mixer pipeline的，但是由于mixer 设计 的延迟和SPOF（单点故障）特性，导致直接在Envoy中实现 (Envoy SDS) • 复杂性 • Mixer使用一组称为模板的核心抽象，来描述传递给适配器的数据。 这些包括“metrics”，“logentry”，“tracepan”等。这些抽 象与后 embedded in Envoy. There will no longer be any stand-alone Mixer service. This will improve performance and reduce operational complexity. Mixer-In-Proxy/Mixer合并进Proxy。 Mixer 将用C ++重写并直接嵌入到Envoy。 将不再有任何独立的 灵活的适配器模型，使其以下操作变得简 单： • 运维添加、使用和删除适配器 • 开发人员创建新的适配器（超过20个适配器）合并没问题，如何合并才是问题 Part 2：ServiceMesh灵魂拷问二：性能有了，架构怎么办？Envoy在设计上是可扩展的 Part 2：ServiceMesh灵魂拷问二：性能有了，架构怎么办？ 扩展点： ● L4/L7 filters ● Access loggers ● Tracers ●

2017年1月23日 加入 CNCF 2017年4月25日 1.0Releases Linkerd 2016年9月13日 1.0Releases 2017年9月14日 加入 CNCF Envoy 2017年9月15日 发布 最新版本：0.7.1 nginmesh 2016年9月29日第一次被公开提出 Service Mesh 概念正式提出9/24 云原生 Service Mesh 中， 自动注入，自动接管流量，部署过程对业务 透明 • 提供了完整的 Service Mesh 解决方案 • 数据面：Envoy • 控制面：Pilot，Mixer，Citadel，Galley10/24 功能视角 - 服务治理能力 – 基于Istio+Envoy 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） 服务注册与发现 注册发现：云外基于 Consul，云内基于 X/2.X，GRPC,WebSocket，Dubbo， Thrift √ 路由控制：静态路由、动态路由、流量染色、分流控制等 √ 负载均衡：支持 RR、权重、一致性 Hash 等 √ 流量复制：Envoy 自带 √ 故障转移 √ 安全 访问控制：RBAC vs Mixer √ 治理控制 熔断降级 √ 限流 √ 中间件 资源隔离 √ 故障注入 √ 超时控制、重试、重写、重定向等 √

Plane Control Layer Application Layer通过Service Mesh控制面统一管理F5和Envoy https://aspenmesh.io/2019/03/expanding-service-mesh-without-envoy/ Control Plane Security Policy： • Enable mTLS between services 南向接口 • 面向流量和路由配置 • xDS v2将统一数据面标准？ • xDS接口包含有较多实现相关内容：Listener, Filter, 能否可以成为一个通用的接口协议？ 是否会出现Envoy之外的大量数据面实现？ • 建议：对xDS接口进行改进，去掉实现相关内容 Ø Service Mesh的发展 • 控制面对数据面软硬件的统一控制能力？ • 通过控制面API接入各种丰富的应用场景 MSB-SDClient MSB-Consul Jaeger DexMesh数据面 Pod Microservice Envoy Desktop OtherSystems Mobile DexMesh Ingress Pod Microservice Envoy (Telemetry， Policy check) 配置数据(服 务信息，路由 信息等) 定制Istio组件 应用微服务

可扩展性有限，dtab不易理解和使用 • 功能不能满足蚂蚁的需求，没法做到 类似envoy xds那样的扩展性 • 未来发展前景黯淡 Envoy • 安心做数据平面， 提供XDS API • 设计优秀，性能和稳定性表现良好 • C++编写，和蚂蚁的技术栈差异大 • 蚂蚁有大量的扩展和定制化需求 • 我们非常认可envoy在数据平面上的表现开源方案选择之第二代Service Mesh Istio Service Mesh • 数据平面选择Envoy：成熟产品，符合 腾讯语言体系，内部广泛使用 • 控制平面据传“挣扎了一下”，最终还 是选择Istio，进行定制和扩展，解耦k8s国内公司的选择之三：另辟蹊径 UCloud：Service Mesh • 非常有意思的轻量ServiceMesh实践 • 从Istio中剥离Pilot和Envoy • 去掉Mixer和Auth • 定制Pilot，实现ETCD 定制Pilot，实现ETCD Adapter • 脱离k8s运行Sofa Mesh在技术选型时考虑 Envoy • 数据平面：Envoy最符合要求 • XDS API的设计更是令人称道 • C++带来的技术栈选择问题 • 我们有太多的扩展和定制 • 而且，proxy不仅仅用于mesh Istio • 控制平面：Istio是目前做的最好的 • 认可Istio的设计理念和产品方向 •

更新时，Sidecar 需要通过热重启方式重新加载，成本高昂基于 Secret Discovery Service Sidecar 的证书管理方案 Envoy SDS 证书管理流程 Secret Discovery Service 是 Envoy 提出的 Sidecar 证书管理方案，方案的核心流程在于引入 SDS Server 进行密钥管理和分发，Sidecar 通过 gRPC 请求获取证书，并利用 方式实现纯内存通信，不需要使用证书。基于 Secret Discovery Service Sidecar 的证书管理方案 Envoy SDS 证书管理流程基于 Secret Discovery Service Sidecar 的证书管理方案 Istio With Envoy SDS Istio 基于 Envoy 的 SDS方案，实现了 SDS Server 和 SDS 配置管理。Istio 方案中选择 UDS 通信方案，Istio的 会先检查缓存中是否已有证书，如果不 存在的话，会基于Citadel 启动时配置的二级ROOTCA签发证书基于 Secret Discovery Service Sidecar证书管理方案 Istio With Envoy SDS Benefits:  The private key never leaves the node: It is only in the Citadel agent and sidecar’s

Kubernetes优缺点www.163yun.com Service Mesh作为微服务框架www.163yun.com Service Mesh生态www.163yun.com 数据面Envoy • 轻量级的proxy • 静态配置，热加载，热重启 • 动态配置，拉取模式www.163yun.com 控制面Pilotwww.163yun.com Service Mesh优缺点163yun 可视化163yun.com 网易微服务框架www.163yun.com 网易微服务框架www.163yun.com 新一代微服务治理平台 服务A jar envoy 服务B jar envoy 服务C jar envoy 降级 限流 路由 日志收集 日志分析 调用次数 调用时间 服务治理 日志分析 统计监控 Data Stream Kafka Storm集群 Hbase 三、基于容器服务的微服务架构实践www.163yun.com 内部金融产品架构www.163yun.com Haproxy作为service mesh的Agentwww.163yun.com 从haproxy到envoy consul consul consul 注册中心 配置中心 haproxy 平台 haproxy 订单 haproxy 会员 /agents/haproxy/haproxy

Controller • Kubernetes深度整合 • Gimbal生态组件Contour特点 • 基于Envoy • 协议转换 • 对象翻译 • IngressRouterContour的优劣 • 优势 • 兼容Istio生态，融入Service Mesh生态 • 南北向流量使用Envoy • 兼容Kubernetes标准Restful接口 • 统一的Kubernetes管理接口 • Gimbal生态 API版本共存（Istio & Kubernetes Ingress） • 东西向流量 • Istio支持全量功能 • Contour支持Tracing能力 • 数据面共存 • 共用边车组件Envoy七牛现有Service Mesh体系 • Istio产品化 • 东西流量产品化 • 南北流量产品化 • TLS管理优化 • Contour增强 • 入口流量管控 • 跨集群调度 • 发展策略 生态链七牛容器云产品未来发展 • 更多功能 • 故障熔断 • 故障注入 • 业务配置动态分发 • 优化升级 • 性能优化： • DPDK + eBPF • 系统优化 • 根据需求裁剪Istio。解耦Envoy和其他组件 • 裁剪Istio相关CRD，简化系统结构ServiceMesher公众号 SOFAStack公众号 http://www.servicemesher.com

BeiJing 和Istio在数据⾯面和控制⾯面的区别 �37 微博Service Mesh实践 - WeiboMesh Weibo Mesh Filters Transport Mixer Envoy Pilot Citadel Istio Registry control plane data planeService Mesh Meetup · BeiJing 和Istio在Discovery上的区别 WeiboMesh Istio：Pilot适配云平台 WM：注册中⼼心 云 VS ⾮非云 WM Consul、ZK、Vintage WM Envoy Pilot Envoy K8s、Mesos、Eureka Register Register Envoy API AdapterService Mesh Meetup · BeiJing 和Istio在业务感知上的区别 �39 微博Service

0-327.ali2008.alios7.x86_64 Ø软件 üMOSN 0.1.0 üEnvoy 1.7 Ø场景 ü代理模式: client -> mesh -> server üClient直连server请求耗时1.6msSOFARPC + 1K字符串 8 指标\软件 SOFAMosn Envoy QPS峰值 103500 104000 RT(avg) 16.23ms 15.88ms 88ms MEM 31m 18m CPU 100% 100%HTTP/1.1 + 1K字符串 9 指标\软件 SOFAMosn Envoy QPS峰值 29670 38800 RT(avg) 5.715ms 5.068ms RT(P99) 16ms 7ms RT(P98) 13ms 7ms RT(P95) 11ms 6ms MEM 56m 24m CPU 100% 95%单核SOFARPC转发 1.0 Ø场景 ü代理模式: client -> mesh -> server üClient直连server请求耗时1.6ms单核SOFARPC转发 11 指标\软件 SOFAMosn Envoy QPS峰值 18000 N/A RT(avg) 12.354ms N/A MEM 100m N/A CPU 100% N/AGolang TLS单核性能测试 12 Ø环境 ü CPU：