踩坑实录 付铖 (花名:橙子) 酷家乐 技术专家1/25 从3D Mesh 到Service Mesh2/25 /01 /02 /03 实践进展 Istio的价值和问题 Knative的实践和瓶颈3/25 分享主题：字号 实践进展 /01 酷家乐在服务网格和FAAS方向上的实践进展汇总4/25 生产环境Istio稳定运行 酷家乐于2018年8月29日在国际站生产环 境开始全面使用Istio %15/25 Pilot、Mixer 性能瓶颈 Istio 的价值和问题16/25 总结 Istio 的价值和问题 • 已经可以稳定用在生产环境 • 工程架构收益 >> 性能资源损耗 • 根据组织和业务情况推广或改造，新旧体系可并存 • 超大规模应用，几个架构问题有待社区或业界解决17/25 分享主题：字号 Knative 的实践和瓶颈 /03 酷家乐在使用 Knative 作为 镜像源问题 • RevisionUnkown 状态(0.8版本) • Queue-proxy 内存增长(0.8版本) • Activator 重复创建并占用大量资源22/25 Knative 当前瓶颈 FAAS 实践进展 • 还未发布 Production-ready 版本 • Queue-proxy 过重 • 冷启动时间亟待优化 • 支持代码级更新？23/25 展望-推动组织变革

所有组件通过 apisever 交互 随着规模增大存储系统成为瓶颈 etcd 存在性能问题 apiserver etcd K8s 各组件 apiserver 元信息存储 etcd etcd 存在的问题 自研元信息存储 调优 etcd 参数 按照对象拆分 etcd 设计新的元信息存储 … 如何解决存储瓶颈？ KubeBrain 1. 大脑 2. 谐音科比 Kobe

最初的尝试：Gateway • 如右图，最初我们尝试用一个自研的 简单Gateway来提供统一的认证、授 权、限流、监控，但问题很快凸显出 来了： • Gateway是一个中心化的反向代 理，成为了微服务中的瓶颈，模 块流量会互相影响 • 大锅饭带来了复杂的配置管理， 渐渐难以为继 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作 • FreeWheel的痛点 扩展Mixer接入授权 注册Handler 扩展Mixer接入授权 • Mixer会直接影响整个Mesh的稳定性，因此替换时要做到尽可能稳妥 实践总结 • k8s/etcd 配置管理存在性能瓶颈： • 单一 resource 应控制在k级别，达到 10k 量级后响应可能会出现超 时导致配置读写状态异常，进而影响整个系统稳定性 实践总结 • Istio配置管理有局限性： • End

价值 效率（人越来越贵，算力越来越便宜） • 研发超过 10 人在 1 个代码冲突多 • 系统超过 5 个测试&上线协同代价大 • 数字化升级需要快速迭代 性能 • 单机成为性能瓶颈 可用性 • 单机成为可用性瓶颈 挑战 • 技术复杂度上升 • 运维成本上升 • 可定位性变差 • 快速迭代难以控制风险 阿里微服务解法和优势 MSE微服务引擎 Nacos Ingress（Envoy）

度量数据向全员 展示 ⚫ 能够检视指标的 趋势 方案与实施策略 - 研发过程度量与运营 研发度量指标体系 度量与反馈-持续改进 ⚫发现问题 对指标设置阈值，异常的数据告警 ⚫识别瓶颈 根据细化指标进一步确定问题的瓶颈，找到改进方法 ⚫改进跟踪 记录改进问题处理，并通过度量数据检视改进效果 转型背景 01 工具平台建设 02 试点项目实践 03 目录 CONTENTS 持续改进 04

被命中，只有部分参数被⽤到 参数按需 获取/更新 Storage 异步训练流⽔线和多级存储：提升性能，降低内存成本 � 问题： � Learner线程中参数拉取和参数更新对性能影响⼤ � 内存成为主要资源瓶颈。由于需要等待全部参数 就绪，Parameter Server难以利⽤速度慢的存储 介质 样本读取 样本解析 参数拉 取 训练 参数更新 查询Sparse Table 查询Dense 缺点：⽅案b需要量化训练 ⽆量同时⽀持四种⽅法 百度 阿⾥ ⽆量 问题： CV/NLP低频上线，常⽤的模型 压缩算法不适应推荐场景 思考： 线上服务 成本 训练任务 成本 内存是主要瓶颈 > Embedding table可以设计得更⼩么？Double Hashing Embedding Table与第⼀层fc可以看作低秩矩阵分解 亿 亿 512 512 9 9 原始矩阵

Source HBase (0.90.3) Advanced Region Balancing 25000 82000 查询数/秒 揑入记录数/秒 HBase写入性能讨论 写入时的性能瓶颈： • 客户端 • 使用Write buffer减少RPC • 避免频繁创建HTable对象 • 如果可以，关闭WAL • Region负载丌均衡：要让写均匀分布到所有的region 启用压缩已减少HDFS数据量，可提高读性能 Region Server迚程配置大内存（>16G） 每个Region Server拥有的region数量<300 优化表结构设计，防止少数几个region成为瓶颈 • 一个简单的经验公式：每台region server纯写入时高负载应能 达到>1万条记录/秒（每记录200字节） 英特尔Hadoop功能增强 － 跨数据中心大表 虚拟大表

数据一体机 存储架构 存算一体: 调整困难、只能满 足一定的吞吐量要 求 存算分离: 自动调整、拓展能 力强，满足更大吞 吐量 存储自动扩缩容 手工填加机器， 手工同步 完全自动化 高性能 存在性能瓶颈 类似日志方式的顺 序写，性能高 易用程度 封闭体系，集成各 类优秀能力较差 集成能力强，多模 态接口，兼容各类 协议 可用性、稳定性 需要强大的旁路运 维能力 简化运维、自动化 容量和故障转移 云原生数据库其特点，使得应用场 提供更细力度（目录）的监控能力； • 提供更多维度的监控指标：读写时延、读写频率、IO 分布等指标； 3. 性能要求 • 在大数据计算场景同时大量应用访问存储的需求很高，这样对存储服务带来的性能需求成为应用运行效率的关键瓶颈 具体需求： • 底层存储服务提供更加优异的存储性能服务，优化 CPFS、GPFS 等高性能存储服务满足业务需求； • 容器编排层面：优化存储调度能力，实现存储就近访问、数据分散存储等方式降低单个存储卷的访问压力。

高级存储管理 � VMware vStorage VMFS � 缺少集成的群集文件系统 高 I/O 扩展性 � 直接驱动程序模型 � 宿主操作系统中存在 I/O 瓶颈 主机资源管理 � 网络通信调整，存储 I/O 优先级， 按虚拟机的资源共享 � 缺少类似功能 性能增强 � AMD RVI、大型内存页面、 通用 4 路 vSMP、VMI 地表明，在高度虚拟化的环境中，即使每台物理主机支持的用户和虚拟机总数增加，VMware ESX 也能实现高性能吞吐。 VMware ESX 能够达到多快？100,000 IOPS 甚至更高！ I/O 是虚拟环境中最重要的性能瓶颈之一，但是即使 I/O 资源占用量最大的应用程序也可以 在 VMware ESX 上快速运行。因此，最终用户不会知道其应用程序是从虚拟环境提供的，而 且他们通常不会觉察到任何延迟或开销。VMware

消息发送超时，通常客户端的日志如下： 客户端报消息发送超时，通常第一怀疑的对象是 RocketMQ 服务器，是不是 Broker 性能出现了抖动，无法抗住当前的量。 那我们如何来排查 RocketMQ 当前是否有性能瓶颈呢？ 首先我们执行如下命令查看 RocketMQ 消息写入的耗时分布情况： cd /${USER.HOME}/logs/rocketmqlogs/ grep -n 'PAGECACHERT' store store.log | more 输出结果如下所示： RocketMQ 会每一分钟打印前一分钟内消息发送的耗时情况分布，我们从这里就能窥 探 RocketMQ 消息写入是否存在明细的性能瓶颈，其区间如下： 本文来自『中间件兴趣圈』公众号，仅作技术交流，未授权任何商业行为。 1.17 消息发送常见问题与解决方案 < 158  [<=0ms] 小于 0ms，即微妙级别的。  [0~10ms] 10ms 小。  于 50ms 的个数。 其他区间显示，绝大多数会落在微妙级别完成，按照笔者的经验如果 100-200ms 及 以上的区间超过 20 个后，说明 Broker 确实存在一定的瓶颈，如果只是少数几个，说明这 个是内存或 pagecache 的抖动，问题不大。 通常情况下超时通常与 Broker 端的处理能力关系不大，还有另外一个佐证，在 RocketMQ broker 中还存在快速失败机制，即当