队完成公司第一代基于Kubernetes的云平台开发和第 二代基于Kubernetes的DevOps云平台开发 来自于浙江大学SEL实验室目录 CONTENTS Kubernetes平台下的微服务演进 Pilot核心功能解读 Pilot-Agent核心流程解读Kubernetes平台下的微服务演进当我们在讨论微服务的时候我们在讨论什么？ • 解决如何微服务的问题 • 解决微服务化后带来的问题 温饱问题 • 计算资源的快速分配 Centralized Logging API Gateway Job Management Singleton Application Load Balancing Service Discovery Configuration Management Application Packaging Deployment & Scheduling Process Isolation Environment 功能上的重叠 • 服务降级 • 细粒度的鉴权（服务间的调用） • RPC支持 • 跨语言的问题 • …云平台微服务演进之Service Mesh云平台微服务演进之Service Mesh Pilot Envoy • 服务发现 • Envoy生命周期管理 • Envoy配置下发 • 服务模型 • 配置模型 • 负载均衡 • 智能路由（灰度、蓝绿） • 流量管理（超时、重试、熔断）

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 和API Gateway的分工与协同 External request MSB API Gateway API Management Ingress Sidecar Service Discovery & Traffic Management Server Sidecar Sidecar Client Service Mesh Service Mesh Control Plane

8.11 Service Mesh Meetup #6 广州站基于 Secret Discovery Service Sidecar 的证书管理方案 使用可信身份服务构建敏感数据下发通道 Service Mesh Sidecar 的 TLS 生产级落地实践 分享内容基于 Secret Discovery Service Sidecar 的证书管理方案 Kubernetes Secret 以明文形式挂载在容器的文件系统中，存在安全隐患  Secret 更新时，Sidecar 需要通过热重启方式重新加载，成本高昂基于 Secret Discovery Service Sidecar 的证书管理方案 Envoy SDS 证书管理流程 Secret Discovery Service 是 Envoy 提出的 Sidecar 证书管理方案，方案的核心流程在于引入 SDS Server 进行密钥管理和分发，Sidecar 方式获取通信证书  Sidecar 与 SDS Server 采用 UDS 方式实现纯内存通信，不需要使用证书。基于 Secret Discovery Service Sidecar 的证书管理方案 Envoy SDS 证书管理流程基于 Secret Discovery Service Sidecar 的证书管理方案 Istio With Envoy SDS Istio 基于 Envoy 的 SDS方案，实现了

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 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

instances：[”192.168.1.104:12220”] SOFA Registry CoreDNS RPC Controller Kube API server Discovery services renew RPC services Watch services renew RPC DNS b.svc -> 10.0.3.100 1. 在客户端代码中， 请求发送给”b 指向ClusterIPSOFAMesh 的DNS寻址方案的实现细节 POD 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

是选择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

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+升级 没有银弹 开源标准