管理Mixer是许多客户不想负担的 • 进程外适配器强制运维管理适配器，增加此负担 • 性能 • 即使使用缓存，在数据路径中同步调用Mixer也会增加端到端延迟 • 进程外适配器进一步增加了延迟 • 授权和认证功能是天然适合mixer pipeline的，但是由于mixer 设计 的延迟和SPOF（单点故障）特性，导致直接在Envoy中实现 (Envoy SDS) • 复杂性 • Mixer使用 Traffic Director 支持虚拟机，而且可以 虚拟机和容器相互访问 Linkerd 1.* 天然支持 Envoy 天然支持 Istio 开始准备支持，后 来实质性取消，基 本只有k8s好用 Linkerd 2.0 只支持k8s AWS app mesh 支持虚拟机，而且 可以虚拟机和容器 相互访问 ServiceMesh主流产品对虚拟机的支持情况Part 3：Se 4：ServiceMesh灵魂拷问四：说好的供应商不锁定呢？ AWS：我原以为只有我这长相的会背叛革命， 想不到你这浓眉大眼的家伙也背叛革命了。 AWS Google SMI出来之前： • Istio迟迟未贡献给CNCF • Istio API 是私有API，未见有标准化动作 • Envoy xDS v2 API是社区事实标准，但这是Envoy • 统一数据平面API，感觉更像是Envoy在推动

通过应用Pod 中增加一个安全 Sidecar，以API接口的形式为APP及其他Sidecar 提供基础的身 份颁发、身份验证功能  解耦应用的业务逻辑与认证授权逻辑，减少开发量；  提供密码学安全的认证授权逻辑，提高安全性；  全网统一的认证授权方式，去凭证，减少攻击面；  为每个应用建立唯一的全局应用身份标识，提供服务调用全链路溯源能力，及可问责能 力（accountability）。使用可信身份服务构建敏感数据下发通道 安全Sidecar 的认证能力中依赖密钥等敏感信 息，在参考社区SDS方案的基础上，实现敏感 信息的管理及安全下发通道。  用户将密钥等信息通过CRD方式提交至K8s， 通过K8s的RBAC方式控制访问权限  拓展Citadel Watch 密钥相关的CR，筛选后 下发至对应的Citadel Agent节点  安全Sidecar 与 Citadel Agent 采用基于UDS 通信的G

的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服 务网格越来越难以理解和管理。 • 它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以 及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、 访问控制和端到端认证等。什么是 Istio • Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有 负载均衡、服务间认证、监控等功能，而不需要对服务的代码做任 何改动。 • 想要让服务支持 流量的自动负载均衡。 • 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行 为进行细粒度控制。 • 可插入的策略层和配置 API，支持访问控制、速率限制和配额。 • 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟 踪。 • 通过强大的基于身份的验证和授权，在集群中实现安全的服务间通 信。坑 • Gitlab • external_url • Outbound requests(Allow

• 解决如何微服务的问题 • 解决微服务化后带来的问题 温饱问题 • 计算资源的快速分配 • 基本的监控 • 快速部署 • 易于分配的存储 • 易于访问的外围（负载均衡） • 服务注册和发现 致富问题 • 认证和授权 • 智能路由 • 流量管理 • 服务降级 • … • 微服务拆分原则 • 业务API设计 • 数据一致性保证 • 可扩展性考虑 • …Kubernetes对于微服务的支撑 能，如动态负 载服务发现、负载均衡、TLS终止、HTTP/2 & gRPC流量代理、熔断、健康检查等功能。 • Mixer 翻译过来是混音器，Mixer负责在整个Service Mesh中实施访问控制和使用策略。Mixer是一个可扩展组 件，内部提供了多个模块化的适配器(adapter)。 • Pilot 翻译过来是领航员，Pliot对Envoy的生命周期进行管理，同时提供了智能路由（如A/B测试、金丝雀部

路线4的折衷方式 - 在k8s还没有铺开前，先吃下非k8s下Sidecar模式快速落地的红利（路线2） - 然后避开非k8s下继续演进的大坑，回归长期目标（路线1） ü 好处（和路线2一样） • 在k8s未铺开前，先向前迈进一步，避免卡壳 ü 缺点 • 存在少量的投资浪费（不过和拿到的红利相比是值得的） ü 存在变数 • 是Sidecar模式的Service Mesh普及快？还是k8s普及快 ü 部署在K8s上 Service Mesh (Istio模式) 部署在K8s上 Service Mesh (Sidecar模式) 应用终极形态 应用现状 1 1 1 2 4 4 背景1：早期未普及k8s，我们选择一边走路线4，一边准备终极形态 背景2：后期确认k8s的大方向，加上调研结果，放弃路线2 背景3：最近确认k8s将加快普及，启动路线1，会师路线4 第一步：k8s 全面铺开 第三步：接入 Mesh时代的客户端和寻址方式 服务发现 加密 负载均衡 请求路由 目标服务 的标识 序列化 链路追踪 故障注入 日志 监控 Metrics 熔断 限流 服务降级 前置条件检查 身份认证 密钥管理 访问控制 …… 下沉到 Service Mesh 轻量级客户端 传统 侵入式 客户端 客户端应该尽可能的轻薄通用: 实现简单，方便跨语言，减少升级可能 最简单，最通用，支持最广 泛的寻址方式方式是什么？

分配方式 内存资源 服务器资源 维持现有内存使用率与 服务器配置的最坏情况 实际需预留 600M内存22/24 数据平面兼容原有架构 对接原有系统 • 使用原有系统SDK、私有协议 直连访问 兼容未升级服务 • Proxy Agent支持以原有通信 协议处理请求、发起调用23/24 总结与展望 实践感悟 • Service Mesh通过一种全新的架构理念，系统地解决了微服务领域的关键架构痛点

com/en/topics/microservices/what-is-a-service-mesh 流量控制、监控8/39 金融级网络安全 Part 1： 为什么需要Service Mesh? 身份标识/访问控制 Service （client） Sidecar Sidecar Service （server） mTLS 服务鉴权 全链路可信、加密 零信任网络9/39 io/docs/concepts/what-is-istio/11/39 Part 2： 在当下『路口』的思考 Greenfield vs Brownfield Greenfield • 绿地，未开发过的土地 • 全新的项目/新系统 图片来源：https://faasandfurious.com/90 Brownfield • 棕地，已开发/污染过的土地 • 成熟的项目/遗留系统12/39

TCP √ 路由控制：提供简单的路由能力 √ 负载均衡：支持 RR、权重、一致性 Hash 等 √ 流量复制：不提供 × 故障转移：继承 Nginx 的 Failover 机制 √ 安全 访问控制：主要依靠中间件 × 中间件 治理控制 熔断降级：主要依靠中间件 中间件 限流：速率限制 √ 中间件 资源隔离：主要依靠中间件 中间件 故障注入：不提供 × 超时控制、重试、重写、重定向等：继承 超时控制、重试、重写、重定向等：继承 Nginx 的 timeout 机制 √ 监控/故障诊断 链路追踪：主要依靠中间件 APM APM 性能监控：主要依靠中间件 APM APM 遥感数据：主要依靠中间件 APM APM 访问日志：主要依靠日志平台 日志平台 日志平台6/24 Service Mesh 为严选带来了哪些架构收益 • 历史包袱：现有的服务在不改造的情况下引入了服务治理能力 • 大大降低了中间件的研发投 流量复制：Envoy 自带 √ 故障转移 √ 安全 访问控制：RBAC vs Mixer √ 治理控制 熔断降级 √ 限流 √ 中间件 资源隔离 √ 故障注入 √ 超时控制、重试、重写、重定向等 √ 监控/故障诊断 链路追踪：主要依靠中间件 APM APM 性能监控：主要依靠中间件 APM APM 遥感数据：主要依靠中间件 APM APM 访问日志：主要依靠日志平台 日志平台 日志平台11/24

Service Mesh Service Mesh Control Plane API Gateway：应用网关逻辑 • 使用不同端口为不同租户提供访问入口 • 租户间的隔离和访问控制 • 用户层面的访问控制 • 按用户的API访问限流 • API访问日志和计费 Service Mesh：统一的微服务通信管理 • 服务发现 • 负载均衡 • 重试，断路器 • 故障注入 • 分布式调用跟踪

我们最好进行过 载保护，防止大量请求涌入击垮系统。 • 服务限流其实是指当系统资源不够，不足以应对大量请求，即系统资源与访问量 出现矛盾的时候，我们为了保证有限的资源能够正常服务，因此对系统按照预设 的规则进行流量限制或功能限制的一种方法。 • 限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行 限速来保护系统，一旦达到限制速率则可以拒绝服务或进行流量整形。 • 限流无非 治理策略 & 高可用 • 微服务高可用设计手段 - 服务限流 • 固定、滑动时间窗口限流 • 适合微服务接口 • 选定的时间粒度上限流 • 令牌桶、漏桶限流 • 适合阻塞限流 • 超过最大访问频率后，请求阻塞等待或者直接拒绝（等待时间=0） 常用限 流算法25/总页数 治理策略 & 高可用 • 微服务高可用设计手段 - 服务限流 • 基于来源限流（from） • 系统标签 • 自定义标签 • 从手段看高可用 • 从架构看高可用 • 从硬件看高可用 • 从软件看高可用 • 从治理看高可用 本质35/总页数 写在最后 – 开源与社区 • 什么是开源？ • 事物规划为可以公开访问的，因此人们可以修改并分享。 • 也泛指一组概念：开源的方式！ • 如何参与开源？ • 开源能带来哪些好处？36/总页数 • Service Mesh 概述 • Consul作为注册中心在云环境的实践与应用