多点生活在 Service Mesh 上的实践 Istio + MOSN 在 Dubbo 场景下的探索之路 陈鹏 多点生活 平台架构组研发工程师1/23 自我介绍 • 陈鹏、多点生活平台架构组研发工程师 • 开源项目与云原生爱好者 • 多年网上商城、支付系统相关开发经验 • 2019 年至今从事云原生和 Service Mesh 相关开发工作2/23 /01 /02 /03 为什么需要 为什么需要 Service Mesh 改造 探索 Istio 技术点 Dubbo 场景下 的改造 • 对比传统微服务架构 • 和 Service Mesh 化 之后有哪些优缺点 • MCP • Pilot • xDS • MOSN 结合 Istio 的技术点， 介绍多点生活目前的 探 索 以 及 服 务 发 现 Demo 的演示3/23 为什么需要 Service Mesh Other link: https://github.com/istio/istio12/23 MOSN MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供 多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network 的简称。 MOSN 可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，

Kubernetes容器应用基于Istio的灰度发布实践 张超盟 @ Huawei Cloud BU 2018.08.25 Service Mesh Meetup #3 深圳站 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布 An open platform to connect, manage, and secure microservices SDK Sidecar 服务治理 Node 2 svc 2 自身业务 SDK Sidecar 服务治理 通信基础 服务发现 负载均衡 熔断容错 动态路由 … for (封装++) { 应用侵入--； 治理位置--； } 微服务角度看Istio: 服务网格 服务网格控制面 从基础设施(Kubernetes)看Istio: 服务访问 Node svca svcc svcb "unknown" response_code: response.code | 200 Istio & Kubernetes: 总结 对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用 Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布 灰度发布：蓝绿

1 Kubernetes容器应用基于Istio的灰度发布实践 张超盟 @ Huawei Cloud BU 2018.08.25 Service Mesh Meetup #3 深圳站2 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布3 An open platform to connect, manage, and secure SDK Sidecar 服务治理 Node 2 svc 2 自身业务 SDK Sidecar 服务治理 通信基础 服务发现 负载均衡 熔断容错 动态路由 … for (封装++) { 应用侵入--； 治理位置--； }6 微服务角度看Istio: 服务网格 服务网格控制面7 从基础设施(Kubernetes)看Istio: 服务访问 Node svca svcc svcb "unknown" response_code: response.code | 20015 Istio & Kubernetes: 总结 对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用 Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。16 Agenda • Istio & Kubernetes • Istio & Kubernetes上的灰度发布17

对Istio社区的产品化改进 5. SolarMesh的架构 6. SolarMesh 组件介绍 7. 应用场景 Copyright © 2021 Cloud To Go 为什么我们需要服务网格 - 微服务化带来的问题 错综复杂的服务调度掩盖了 问题的源头 服务间交互的复杂性： Ø 难以可视化 Ø 难以全面测试 Ø 多服务联动时问题难以察觉 Ø ... 服务间通信的复杂性： Ø 网络延迟 Ø 消息序列化 消息序列化 Ø 不可靠的网络 Ø 异步机制 Ø ... 开发难 排错难 测试难 运维难 Ø 服务变得非常多 Ø 版本变得非常复杂 Ø 上线十分痛苦 Ø 排查问题更难 Ø 解决手段更复杂 Ø 学的东西更多 Copyright © 2021 Cloud To Go 为什么我们需要服务网格 - 业务上k8s带来的问题 Ø 集群内的情况不可见 Ø 环境不统一，很难复现问题 Ø Ø 学习k8s成高 Ø 缺少好用的工具 Ø ... 排错难 Copyright © 2021 Cloud To Go 为什么我们需要服务网格 - 微服务+k8s Kubernetes上 应用的网络问题 困扰开发、测试、运维最突出的问题: Copyright © 2021 Cloud To Go 为什么我们需要服务网格 - 服务网格带来了什么 服务网格是一个云原生的网络基础设施，

基于Mixer的开发流程和实例微服务平台的监控演进典型的运维场景 传统的监控面临容器化和微服务化的困境 测试运维沟通鸿沟，如何提升沟通效率 监控工具繁杂，如何快速找到合适工具进行问题定位 偶发性问题场景复杂，如何保留发生现场 如何在错综复杂的未服用调用链路中找到错误源头监控场景转换 帮助运维人员快速的定位问题，解决问题 基于容器化和微服务化的监 控场景 • 应用规模巨大 • 服务之间依赖呈现为网状 • 除了日志、性能指标，需要 基于请求的依赖追踪监控 基于虚拟化的监控场景 • 应用规模大 • 服务之间依赖呈现为线型 • 日志、性能指标需要集中化 存储 基于主机的监控场景 • 应用规模较小 • 服务之间没有互相依赖 • 日志、性能指标都在单个主 机问题一：什么是用户想要的监控 什么是用户想要的监控？分布式监控的三个维度 Metrics Logging Tracing • SQL 日志系统 • 代码逻辑处理事件 • 异常、debug信息容器化和微服务下的监控需求 微观下的监控需求 快速错误追踪 可快速排查在性能测试场景下的 慢方法、异常调用以及异常报文 等信息 单次链路追踪 可细粒度排查应用单次链路调用 的包括日志、网络数据在内的所 有信息。 宏观下的监控需求 链路总体展示 展示整个服务调用过程中链路上 每一个节点的服务状况，包括延 时、吞吐量等基本信息。

Management, Security, Observability) #IstioCon What Do We Expect From a Service Mesh? 为了将基础设施的运维管理从应用代码中剥离，我们需要七层的流量管 理能力： ● Routing based on layer-7 header ○ Load balancing at requet level ○ HTTP 可观测性：七层（请求级别）Metrics ○ 安全：基于 Interface/Method 的服务访问 控制 #IstioCon Aeraki Demo: 用户请求和批处理任务隔离(Dubbo) 场景：隔离处理用户请求和批处理任务的服务实例，为用户请求留出足够的处理能 力，避免批处理任务的压力影响到用户体验。 ● 将服务端划分为两个服务实例组，分别用于处理批处理任务和用户请 求。 ● 客户端发起请求时通过一个“batchjob” 设置相应的 DR 和 VS 流量规则 https://docs.qq.com/doc/DVnlqUVB1ek1laFBQ #IstioCon Aeraki Demo: 地域感知负载均衡(Dubbo) 场景：在开通地域感知负载均衡功能时，consumer 的请求将缺省被发送到本区域 的provider实例，当本地域无可用的provider实例，请求会被分发到其他区域。 实现原理：控制面根据 consumer

百度APP基于Istio实现 基础架构升级 许超 #IstioCon 背景 l 核心业务线已完成微服务改造，数万个微服务对架构服务治理能力提出了更高的要求。 l 高级架构能力能否多语言、多框架支持？ l 运维架构能力是否具备可移植性？是否能低成本复制新的产品线？ l 可观测性不足，是否有通用机制提升产品线可观测性？ Ø 部分模块上下游超时配置不合理，超时倒挂，集中管理调整成本比较高。 强化稳定性工程。（Case覆盖、故障自动恢复） l 实现现有能力整合。（Mesh作为基础层，完全有能力整合内部Trace系统、压测平台等） l 积极拥抱社区。（积极贡献Istio社区） l 探索新应用。 （机房扩建，流量染色分级等） #IstioCon Thanks 添加讲师微信

Envoy采用C++实现，本身为四层及七层代理，可以根据用户应用请求内的数据进行高级服务治理 能力，包括服务发现、路由、高级负载均衡、动态配置、链路安全及证书更新、目标健康检查、 完整的可观测性等。 • 目前常见数据面主要有三种：Envoy、Linkerd、Traefic。Envoy由于高性能和扩展能力前在数据面遥 遥领先。 • Iptables使Pod间出入应用的流量均由Envoy代理，对应用来说完全透明。支持主要常用网路协议 工作模式 功能介绍 envoy.listener.tls_inspector 监听过滤器 检测下游连接是否为TLS加密，并且获取ALPN（应用层 协商协议），用于网络层过滤器匹配判断。 envoy.listener.http_inspector 监听过滤器 检测应用层协议是否HTTP，并判断具体类型为HTTP/1.x 或HTTP/2，用于网络过滤器匹配判断 envoy.listener.original_dst • 15001上监听器通过ORIGINAL_DST获取原始目标地址（服务的clusterIp），匹配业务监听器（不真正监听网络）地址并传递新建下游连接。 • 下游连接过滤器判断TLS，ALPN（应用协议名），HTTP版本后匹配到L4层http_connection_manager网络过滤器。 • http_connection_manager使用http codec解码http协议heade

是一家为客户提供数字视频广告管理技术和服务的公司。其业务端产 品需要对接客户，提供视频广告投放优化界面，类似于 Web ERP，是一个典型 的三层架构。 微服务之痛 • 两年来，我们将若干复杂的Rails单体应用拆分、迁移到微服务架构， 逻辑用Golang重写，引入了Kubernetes。随着模块越来越多，复杂 的通信带来矛盾日渐突出：流量管理、监控… 最初的尝试：Gateway • 如右图，最初我们尝试用一个自研的 扩展Sidecar：加入认证支持，提供了对业务系统的认证支持，将用 户相关信息以header的形式传入mesh，后续的授权、监控、限流 都可以用Istio原生的机制来完成 • 扩展Mixer：选择一部分流量来应用对应的授权逻辑 FreeWheel的Istio实践 • 右图为接入FreeWheel自定义认证和 授权模块的原理图 扩展Sidecar接入认证 • 修改 istio-system/istio-sidecar- 决策容量是否足够 Mixer or Sidecar，这是一个问题 • Mixer提供了一种非常灵活的模型，让Handler可以在流量中动态的选 择一部分来引入额外的机制（如权限控制、限流等），在应用运维中 这是很重要的能力，只要是不修改请求、响应的功能都可以采用扩展 Mixer来实现 • Sidecar里接入额外的反向代理其实提供了一个修改请求、响应的接口 ，如认证之后需要将用户信息通过header传给下游服务