队完成公司第一代基于Kubernetes的云平台开发和第 二代基于Kubernetes的DevOps云平台开发 来自于浙江大学SEL实验室目录 CONTENTS Kubernetes平台下的微服务演进 Pilot核心功能解读 Pilot-Agent核心流程解读Kubernetes平台下的微服务演进当我们在讨论微服务的时候我们在讨论什么？ • 解决如何微服务的问题 • 解决微服务化后带来的问题 温饱问题 • 计算资源的快速分配 功能上的重叠 • 服务降级 • 细粒度的鉴权（服务间的调用） • RPC支持 • 跨语言的问题 • …云平台微服务演进之Service Mesh云平台微服务演进之Service Mesh Pilot Envoy • 服务发现 • Envoy生命周期管理 • Envoy配置下发 • 服务模型 • 配置模型 • 负载均衡 • 智能路由（灰度、蓝绿） • 流量管理（超时、重试、熔断） 件，内部提供了多个模块化的适配器(adapter)。 • Pilot 翻译过来是领航员，Pliot对Envoy的生命周期进行管理，同时提供了智能路由（如A/B测试、金丝雀部 署）、流量管理（超时、重试、熔断）功能。Pliot接收用户指定的高级路由规则配置，转换成Envoy的 配置，使这些规则生效。 • Istio-Auth 服务间认证和终端用户认证功能Istio的Pilot功能解析Pilot官方架构Istio – En

是选择Istio，进行定制和扩展，解耦k8s国内公司的选择之三：另辟蹊径 UCloud：Service Mesh • 非常有意思的轻量ServiceMesh实践 • 从Istio中剥离Pilot和Envoy • 去掉Mixer和Auth • 定制Pilot，实现ETCD Adapter • 脱离k8s运行Sofa Mesh在技术选型时考虑 Envoy • 数据平面：Envoy最符合要求 • XDS API的设计更是令人称道 没有提供和侵入式框架互通的解决方案Sofa Mesh：istio的增强扩展版 Pilot Auth Mixer Envoy Pilot Auth Mixer Golang Sidecar Istio现有架构 Sofa Mesh架构 1. 用Golang开发 Sidecar，替代Envoy 2. Mixer被部分合 并进入Sidecar 3. Pilot/Auth 做扩展和增强 Control plane plane Control plane Data plane Data plane Mixer架构设计 Architect2Golang版Sidecar Pilot Auth Golang Sidecar Mixer XDS API Mixer Service HTTP/1.1 HTTP/2 Sofa RPC ü 参照Envoy的设计 ü 实现XDS API ü 兼容Istio

Microservice Envoy (Telemetry， Policy check) 配置数据(服 务信息，路由 信息等) 定制Istio组件 应用微服务 业务请求 控制流 图例说明 Pilot Mixer APP: Canary Deployment K8s API Server 管控规则 灰度发布 网格增强组件 原生组件 APP： Traffic Management Registration Registration Pilot Pull Services xDS Client Request Client Request Client RequestConsul Registry遇到的坑： 1.0版本的Consul Registry只能算PoC（原型验证），远未达到产品要求 CPU占用率超高不下 (Pilot+Consul 占用冲高到 400%) • TIME_WAIT 平面产品化增强-支持多网络平面 Istio1.0中不支持多网络平面，当服务地址和Envoy地址分别位于两个网络上时，会导致转发请求时 发生死循环，导致socket耗尽，Envoy不停重启。 Pilot Service Registry Register service (IP :10.75.8.101) 10.75.8.101 10.75.8.0/24 192.168.10.0/24

Istio 以 Sidecar 的形式运行在 Pod 中， 自动注入，自动接管流量，部署过程对业务 透明 • 提供了完整的 Service Mesh 解决方案 • 数据面：Envoy • 控制面：Pilot，Mixer，Citadel，Galley10/24 功能视角 - 服务治理能力 – 基于Istio+Envoy 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） cNginx（256并发 6.707 vs 15.771）13/24 当前演进方向 整体基于 Envoy+Istio 方案： • 数据面以 Envoy Proxy 作为代理组件 • 控制面以 Pilot 为核心组件 • 平台开放与扩展主要通过 Kubernetes CRD与Mesh Configuration Protocol（简称为 MCP，一套标准 GRPC 协议） • 高可用设计主要基于 访问控制（如白名单能力） • 灰度引流使架构透明化 • 服务间调用灰度引流 • 外域调用灰度引流18/24 API 网关 • 整体基于 Envoy+Pilot 方案： • 数据面以 Envoy Proxy 作为代理组件 • 控制面以 Pilot 为核心组件 • 平台开放与扩展主要通过 Kubernetes CRD与Mesh Configuration Protocol（简称为 MCP，一套标准

tainer-management-4e5298736d4213/39 Part 2： 在当下『路口』的思考 • Mixer V1 性能堪忧 • Mixer V2 遥遥无期 • Pilot 性能也有较大隐患 现实场景 – 云原生方案离生产级尚有一定距离 图片来源： https://istio.io/docs/reference/config/policy-and-telem Pod Spring Cloud 应用 SOFAMosn SOFA 服务注册中心 Service Mesh 控制平面 Galley Citadel Inspector Pilot 双模微服务 = 传统微服务 + Service Mesh 双剑合璧 服务路由 服务限流 服务拓扑 实时监控 ........ Pod Dubbo 应用 SOFAMosn 的传统微服务 基于 Sidecar 的 Service Mesh 微服务 互联互通，平滑迁移，灵活演进20/39 Part 3： 蚂蚁金服的产品实践 大规模场景下的服务发现 • Pilot 的问题 • 集群容量无法支撑海量数据 • 全量推送性能差 • 沿用 SOFA Registry • 支持千万级的服务实例信息 • 秒级推送 SOFARegistry：https://github

⽬目录4 一、Service Mesh 简介 Service Mesh 简介5 Service Mesh 简介-比较 Pilot/Gallery/Citadel/Mixer App A Proxy App B Proxy HTTP gRPC Pilot/Gallery/Citadel/Mixer App A MOSN App B MOSN HTTP SOFARPC SDK/透明劫持：运维和可监控性不好，性能不高，风险不太可控。12 方案落地-目标架构 MOSN APP Pod MOSN APP Pod 服务发现 More Sidecar More Sidecar Pilot MQ Kubernetes Sidecar Operator 产品层 运维能力 监控能力 流量调控 安全能力 扩展能力 HTTP/RPC13 方案落地-拷问 现有框架升级 Service Mesh 未来的思考 我们对 Service Mesh 的思考与未来 Pod APP MOSN Pod APP Envoy Control Plane Citadel Pilot Galley Other Registry Nacos SOFARegistry 11/10+升级 没有银弹 开源标准

service mesh - istio ● https://www.katacoda.com/courses/istio /deploy-istio-on-kubernetes ● Mixer, pilot and envoy exposes prometheus metrics by default. ● Configure prometheus to collect data from service mesh - istio ● https://www.katacoda.com/courses/istio /deploy-istio-on-kubernetes ● Mixer, pilot and envoy exposes prometheus metrics by default. ● Configure prometheus to collect data from service mesh - istio ● https://www.katacoda.com/courses/istio /deploy-istio-on-kubernetes ● Mixer, pilot and envoy exposes prometheus metrics by default. ● Configure prometheus to collect data from

Transport Mixer Envoy Pilot Citadel Istio Registry control plane data planeService Mesh Meetup · BeiJing 和Istio在Discovery上的区别 �38 微博Service Mesh实践 - 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 Mesh实践 - WeiboMesh 服务透明 VS 模块耦合

的统一解决方案 • 采用 Kubernetes Native 方式落地微服务应用 • 使用 INTERFACE 作为 DNS 来寻址服务 • 开发一个通用协议处理框架 • 避免为不同的微服务框架修改 PILOT 代码 • 通过插件的方式按需支持新的协议 • 对应用代码无侵入性 • 为微服务框架提供轻量化客户端落地一个微服务框架需要的工作 • 部署 ZK 集群作为 RPC 框架的注册中心 • 开发 ZK local 80% 20%POD DNS 寻址方案 APP Register Agent RPC Service Controller CoreDNS Kube API Server Pilot Discovery SOFA MOSN Get Service Info Get Service Info Watch RPC Service Watch Service Endpoints

SDS方案，实现了 SDS Server 和 SDS 配置管理。Istio 方案中选择 UDS 通信方案，Istio的 方案证书管理流程由 Citadel , Citadel Agent , Pilot 协同完成  Pilot 负责 UDS 路径配置下发，用户通过 Policy CRD 和 DestinationRule 来决策需要给哪些 Sidecar 下发  Sidecar 收到SDS Config