现 Demo 的演示3/23 为什么需要 Service Mesh 改造 /01 对比传统微服务架构和 Service Mesh 化之后有哪些优缺点4/23 微服务 模块 • 安全 • 配置中心 • 调用链监控 • 网关 • 监控告警 • 注册和发现 • 容错和限流 特点 • 独立部署 • 强化模块边界 • 技术多样性5/23 Service Mesh 优点 • 负责网格中的流量管理以及控制面和数据面之间的配置下发，在 Istio1.5 之后合并了 Galley、Citadel、Sidecar-Inject 和 Pilot 成为 Istiod。 功能 • 根据不同的平台（Kubernetes、Console） 获取一些资源（Kubernetes 中使用 Informer 机制获取 Node、Endpoint、 Service、Pod 变化） • 根据用户的配置（CR、MCP 面，旨在为服务提供 多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network 的简称。 MOSN 可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡， API Gateway，云原生 Ingress 等使用。 配置文件 • mosn_config : MOSN 的配置信息 • listener

设计及开发工作。 Copyright © Huawei Technologies Co., Ltd. All rights reserved. Page 3 目录 1. Envoy启动及配置文件 2. Envoy流量拦截原理、常用部署方式 3. Envoy可扩展过滤器架构、可观测性 4. Envoy线程模型 5. 生产环境问题分析及解决方法 6. 针对Envoy做的一些优化及效果 reserved. Page 5 Envoy介绍 • Envoy采用C++实现，本身为四层及七层代理，可以根据用户应用请求内的数据进行高级服务治理 能力，包括服务发现、路由、高级负载均衡、动态配置、链路安全及证书更新、目标健康检查、 完整的可观测性等。 • 目前常见数据面主要有三种：Envoy、Linkerd、Traefic。Envoy由于高性能和扩展能力前在数据面遥 遥领先。 • I Virtual inbound -15006 kubelet 拦截指定命名空间 Pod创建请求 xDS Iptables 规则 ./etc/istio/proxy/SDS 证书 获取 配置 文件 可以修改全局注入参数 作用于所有目标空间的 pod 证书更新 Envoy启动流程 Envoy控制面流量 Envoy数据面流量 ./etc/istio/proxy/XDS SDS xDS

Layer Service 1 Istio 流量管理 – 概览 • 控制面下发流量规则： Pilot • 数据面标准协议：xDS • 集群内Pod流量出入： Sidecar Proxy • 集群外部流量入口：Ingress Gateway • 集群外部流量出口：Egress Gateway（可选,在一个集中点对外部访问进行控制） • Service discovery • Load balancing 内部客户端 Service2 Service1 网格内部 定义网格入口 • 服务端口 • Host • TLS 配置 • 路由配置 • 根据 Host 路由 • 根据 Header • 根据 URI 路由 目的地流量策略配置 • LB 策略 • 连接池配置 • 断路器配置 • TLS 配置 Gateway External Service 统一网格出口 • 出口地址（Gateway Workload） 对外请求 对外请求（Passthrough/ServiceEntry） 缺省路由 （服务名） 5 Istio 流量管理 – 数据面 – Envoy配置模型和xDS协议 ADS Server LDS RDS CDS EDS Envoy 配置模型的主要概念： • Downstream：连接到 Envoy 的下游 Host，发送请求并接收响应。 • Upstream： 上游 Host 接收来自 Envoy

错综复杂的服务调度掩盖了 问题的源头 服务间交互的复杂性： Ø 难以可视化 Ø 难以全面测试 Ø 多服务联动时问题难以察觉 Ø ... 服务间通信的复杂性： Ø 网络延迟 Ø 消息序列化 Ø 不可靠的网络 Ø 异步机制 Ø ... 开发难 排错难 测试难 运维难 Ø 服务变得非常多 Ø 版本变得非常复杂 Ø 上线十分痛苦 Ø 排查问题更难 Ø 解决手段更复杂 Ø 学的东西更多 Copyright © 2021 Cloud To Go 为什么我们需要服务网格 - 业务上k8s带来的问题 Ø 集群内的情况不可见 Ø 环境不统一，很难复现问题 Ø 集群中的网络限制 Ø ... Ø 学习k8s成高 Ø 测试方法发生了改变 Ø 有些问题只能在集群内出 现，难以测试 Ø ... 测试难 运维难 Ø 学习k8s成高 Ø 缺少好用的工具 Ø ... 排错难 Copyright © 2021 Cloud To Go 应用场景 - 异地容灾 通过智能路由实现异地容灾 在SolarMesh中，只需要声明哪些 集群是属于同一个mesh，借助istio 的智能路由能力，同名service将会 获得多集群容灾的能力 流量将会按照策略智能分配到正常 的工作负载上 Copyright © 2021 Cloud To Go SolarMesh的架构设计

Listener Downstre am Filter Filter Filter Cluster Upstrea m Filter Chain 扩展自定义Filter, 并通过xDS API动态配置 L4 Network Filters L7 Http Filters 3 Listener & Filters before outbound services Listener Downst ~10MB for V8 ● 事件驱动模型 ● 兼容native filter调用 方式 8 Example Wasm filter configuration ● 下发到Envoy Proxy侧的配置 9 OCI Registry As Storage ● OCI Artifacts项目的参考实现, 可显著简化OCI注册库中任意内容的存储; ● 可以使用ORAS API/SDK Library来构建自定义工具， UpdateMeshFeature -- ServiceMeshId=xxxxxx --WebAssemblyFilterEnabled=true ○ 部署一个DaemonSet(asmwasm-controller)到K8s集群中 ○ asmwasm-controller监听一个configmap, 该configmap存放要拉取的wasm filter 的地址, 例如： acree-1-registry.cn-hangzhou

List/Watch KubeAPIserver上service、 endpoint等资源对象 3. DiscvoeryServer使用 ServcieDiscovery接口上的服务发 现方法和用户配置的规则构造xDS 4. Envoy从Discovery获取xDS，动态 更新 Kubernetes Service Instance Instance Service Endpoint response_code: response.code | 200 Istio & Kubernetes: 总结 对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用 Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布 灰度发布：蓝绿 灰度发布：A/B Testing 基于K8S的Serverless容器服务 云容器引擎 企业级高可靠、高性能K8S服务 服务网格 K8S原生Service Mesh Istio在华为云：华为云容器应用 Istio在华为云：服务网格 只需在创建集群时选 择“启用服务网格” 即可使用Istio服务治 理功能 Istio在华为云： 灰度发布流程 Y N Y N Istio在华为云： 灰度发布 Istio & Kubernetes 在Google

List/Watch KubeAPIserver上service、 endpoint等资源对象 3. DiscvoeryServer使用 ServcieDiscovery接口上的服务发 现方法和用户配置的规则构造xDS 4. Envoy从Discovery获取xDS，动态 更新 Kubernet es Service Instance Instance Service Endpoint response_code: response.code | 20015 Istio & Kubernetes: 总结 对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用 Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。16 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布17 灰度发布：蓝绿18 灰度发布：A/B 基于K8S的Serverless容器服务 云容器引擎 企业级高可靠、高性能K8S服务 服务网格 K8S原生Service Mesh28 Istio在华为云：华为云容器应用29 Istio在华为云：服务网格 只需在创建集群时选 择“启用服务网格” 即可使用Istio服务治 理功能30 Istio在华为云： 灰度发布流程 Y N Y N31 Istio在华为云： 灰度发布32 Istio & Kubernetes

理，成为了微服务中的瓶颈，模 块流量会互相影响 • 大锅饭带来了复杂的配置管理， 渐渐难以为继 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作 • FreeWheel的痛点 Istio架构 • Istio Proxy: 劫持Pod的所有通信， 是Mesh的基础 • Pilot: 为Proxy提供动态配置管理 • Citadel: 自动维护mTLS密钥 • Telemetry提供监控数据收集能力 基本原理 • Istio从架构上可以分为4个板块： • Istio Proxy: Mesh的基础 • 网络安全：兼容Spiffe标准实现 • 配置管理：为C++实现的Proxy接 入k8s的动态配置管理 • Attribute Machine: 授权，Quota ，Tracing，监控的基础 Istio管理下的微服务 • 右图是部署mock1.v1 Pod之后发生的事 这里实现的例子mymock会完全拒绝所有 被匹配到的流量，右图是mymock Handler的基本原理 • mymock handler 是 mymock adapter的初始化配置 • 完成初始化后rule将checknothing配置 与handler关联起来，其实就是做了流 量的匹配，满足一定条件的流量上应用 mymock handler • mymock adapter直接拒绝被匹配的请 求

背景 l 核心业务线已完成微服务改造，数万个微服务对架构服务治理能力提出了更高的要求。 l 高级架构能力能否多语言、多框架支持？ l 运维架构能力是否具备可移植性？是否能低成本复制新的产品线？ l 可观测性不足，是否有通用机制提升产品线可观测性？ Ø 部分模块上下游超时配置不合理，超时倒挂，集中管理调整成本比较高。 Ø 多数模块对单点异常，慢节点等异常缺乏容忍能力，推动每个模块独立修复，成本高，上线周期长。 技术方案 l 核心原则 Ø 务实、高稳定性、低迁移成本。 l 核心思路 Ø 先单跳，后双跳。 Ø 服务发现下沉到Envoy。 Ø 基于 RPC + 服务发现实现透明流量劫持。 Ø 自建配置中心，产品化封装。 l 关键技术 Ø 内核劫持，使用Loopback IP 与 服务发现一一对应。 Ø RPC劫持，构建可快速扩展标准方案。 Ø 自身稳定性，降级（兜底）、隔离、监控多种方式保证。 envoy离线或者被干预则立即通知bns-agent， fallback会使用原有治理策略。 #IstioCon 架构介绍 Ø Mesh控制中心： ü 运维中心：基于Mesh的统一运维操作中心。 ü 配置中心：维护模块上下游拓扑，管理路由配 置、通信策略。 ü 上线中心：管理Mesh组件版本，统一上线入口。 l 核心组件 Ø 控制面板：Istio-Pilot组件，路由管理、通信 策略等功能 Ø

策略 • 安全试用服务范围 • 不要 All in！ • 稳定——性能和业务！ • 什么服务不怕死？ • 什么服务可以慢？ • 集群规模别太大。 • 能切换/回滚。 • 有完善的性能、功能测试方案。禁则 �������� ����� ����制定目标 • 集群环境申请：版本、开关、资源等。 • 功能性需求：本次试用中Istio需要提供的功能，再次强调：No Freestyle • 非功 非功能需求：并发、成功率、响应时间等服务质量参数。 • 故障处理需求：故障预案。 • 影响范围分析。 • 选定测试版本：研读开放Issue以及Release Notes。测试方案部署 • Istio部署 • 复查集群环境 • 调整资源参数 • 调整亲和性参数 • 调整HPA • 日志输出和调试开关复查 • Istio功能裁剪 • 备用业务部署 • 试用服务部署 • 服务YAML复查 • 缺省路由设置 • 根据功能需求，编写和部署