非侵入服务网格最早为2016年Linkerd。 • 2017年，Goole、IBM、Lyft发布Istio。Istio目前为服务网格的事实标准，并且是2019年Github增长最快的TOP 10开源 项目之一。目前最新为1.10版本。 Copyright © Huawei Technologies Co., Ltd. All rights reserved. Page 5 Envoy介绍 • Envoy采用C++实现， LibeventDispatcher 待清理对象 ListenerManager Listener Connection 创建 监听 socket 新连接 事件 连接 socket 数据传输 事件 L4处理 读写 延迟 删除 L7处理 阻塞 运行 ConnectionHandler 匹配 监听器 • Envoy启动时创建的Listener与工作线程绑定并启动监听 （向libevent注册Read 15001上监听器通过ORIGINAL_DST获取原始目标地址（服务的clusterIp），匹配业务监听器（不真正监听网络）地址并传递新建下游连接。 • 下游连接过滤器判断TLS，ALPN（应用协议名），HTTP版本后匹配到L4层http_connection_manager网络过滤器。 • http_connection_manager使用http codec解码http协议header/body/tailer等并触发回调函数。

Mixer会直接影响整个Mesh的稳定性，因此替换时要做到尽可能稳妥 实践总结 • k8s/etcd 配置管理存在性能瓶颈： • 单一 resource 应控制在k级别，达到 10k 量级后响应可能会出现超 时导致配置读写状态异常，进而影响整个系统稳定性 实践总结 • Istio配置管理有局限性： • Endpoint的配置管理有防抖动处理，即使集群中的部署变化再快， 也不会阻塞Istio • Istio其他配置管理没有防抖动处理（

宏观下的监控需求 链路总体展示 展示整个服务调用过程中链路上 每一个节点的服务状况，包括延 时、吞吐量等基本信息。 服务器总体展示 展示当前所有服务器的运行状况， 包括CPU、内存、网络、I/O读写 等信息 业务总体展示 展示当前业务相关数据的 从宏观上快速定位问题，在微观上找到问题根因的 监控方案问题二：现有的系统能否完全满足需求 现有系统如何满足运维需求Istio现有的监控体系

API稳定性问题：流量管理也仅仅是v1alpha3，用alpha特性发布 1.0的情况似乎比较罕见。 • 发布进度和质量：大版本以月计算的发布延迟，据我所知的 Release撤回发生了两次。 • 世纪难题：多出一层Sidecar造成的延迟。 • Pilot的性能，近几个版本一直在出问题。 • Mixer按照我个人的看法，API较为混乱，重构风险比较大Istio还用不用？ • 你要的是不是API网关？ 有完善的性能、功能测试方案。禁则 �������� ����� ����制定目标 • 集群环境申请：版本、开关、资源等。 • 功能性需求：本次试用中Istio需要提供的功能，再次强调：No Freestyle • 非功能需求：并发、成功率、响应时间等服务质量参数。 • 故障处理需求：故障预案。 • 影响范围分析。 • 选定测试版本：研读开放Issue以及Release Notes。测试方案部署 • Istio部署 根据性能和功能测试方案完成测试。 • 如果性能下滑，可以尝试扩张资源。 • 如果无法达成测试目标，建议取消——无侵入的好处就是可以撤 退。 • 评估关联服务的工作情况——尤其是重试、超时特性的应用切换演练 • 在测试版本和后备版本之间根据预案进行切换。 • 验证相关服务的工作状况。 • 最终保障试点上线 • 在通过测试验证和切换演练的过程之后，就可以将试用的网格应 用上线到生产 环境开始试运行了。和所有其他上线活动一样，在

生产环境Istio稳定运行 酷家乐于2018年8月29日在国际站生产环 境开始全面使用Istio 1.0.1 版本 486 天 服务范围 覆盖了不同业务链路的四十余个服务 40+ 服务 K8S安装环境 覆盖自建机房、IDC机房、云主机、海外云 服务等各种环境和不同的K8S版本 5 集群 服务网格实践进展5/25 Istio Community 服务网格实践进展6/25 Knative FAAS 实践进展 • 镜像源问题 • RevisionUnkown 状态(0.8版本) • Queue-proxy 内存增长(0.8版本) • Activator 重复创建并占用大量资源22/25 Knative 当前瓶颈 FAAS 实践进展 • 还未发布 Production-ready 版本 • Queue-proxy 过重 • 冷启动时间亟待优化 • 支持代码级更新？23/25

多服务联动时问题难以察觉 Ø ... 服务间通信的复杂性： Ø 网络延迟 Ø 消息序列化 Ø 不可靠的网络 Ø 异步机制 Ø ... 开发难 排错难 测试难 运维难 Ø 服务变得非常多 Ø 版本变得非常复杂 Ø 上线十分痛苦 Ø 排查问题更难 Ø 解决手段更复杂 Ø 学的东西更多 Copyright © 2021 Cloud To Go 为什么我们需要服务网格 - 业务上k8s带来的问题 直到找到故障位置 1. 流量告警 / 发现页面报错 2. 看图 3. 直接找到故障位置 Copyright © 2021 Cloud To Go 应用场景 - 灰度版本迁移 传统的版本升级方式 使用solarmesh的版本升级方式 1. 打好部署包 2. 等到半夜 3. 部署一个机器 4. 使用模拟的测试数据测试 1. 打好部署包即可部署 2. 用真实的数据测试 3. 挑个良辰吉日分配流量，宣布更新

Envoy不支持优雅关闭，需要通过金丝雀或蓝绿部署方式实现 Envoy优雅关闭实现方式讨论：#3307 #2920Pilot-Discovery——配置中心（PD） uv1版本和v2版本之间的区别 u建立缓存配置 u触发配置生效方式v1版本和v2版本之间的区别 V1 HTTP1 REST JSON/YAML 弱类型 轮询 SDS/CDS/RDS/LDS 奠定控制平面基础 V2 HTTP2 GRPC

/http_filters/http_fi lters ○ …. ● 自定义开发： ○ 静态预编译： ■ 将其他过滤器集成到Envoy的源代码中，并编译新的Envoy版本。 ■ 这种方法的缺点是您需要维护Envoy版本，并不断使其与官方发行版保持同步。 ■ 此外，由于Envoy是用C++实现的，因此新开发的过滤器也必须用C++实现。 ○ 动态运行时加载： ■ 在运行时将新的过滤器动态加载到Envoy代理中。

接管StatusPort监听（15021） 实现热升级 Implement Hot-Upgrade 9 实现热升级 Implement Hot-Upgrade 阿里云服务网格热升级完整流程 • 修改SidecarSet，指定新版本镜像 • SidecarSet将EmptyContainer替换为新Sidecar镜像，新Sidecar镜像启动 • 新Envoy进程与老Envoy交互，开始进行热重启流程 • 最大排水时间到达，SidecarSet

#IstioCon 架构介绍 Ø Mesh控制中心： ü 运维中心：基于Mesh的统一运维操作中心。 ü 配置中心：维护模块上下游拓扑，管理路由配 置、通信策略。 ü 上线中心：管理Mesh组件版本，统一上线入口。 l 核心组件 Ø 控制面板：Istio-Pilot组件，路由管理、通信 策略等功能 Ø 数据面板：envoy组件，流量转发、负载均衡 等功能. #IstioCon 收益