2024年 RubyConf China day two

前篇：2024年 RubyConf China day one

目录：

主题一、过纯中 — 如何实施与二次开发开源项目管理工具 OpenProject
主题二、黄江文 — 高效定位：Web 应用的排查技巧
主题三、袁志鹏 — Ruby profiler 大盘点、Vernier 原理与应用
主题四、Hegwin — 元编程在测试框架里的应用

主题一、过纯中 — 如何实施与二次开发开源项目管理工具 OpenProject

市场现状

• 项目管理软件是一个红海市场
  • 国际产品：Jira、Asana、Trello…
  • 国内产品：
    • 飞书（内存占用4.5G）
    • Teambition
    • Notion
    • TATD（费用高，不支持定制）

Open Project 优势

• 开源领先，具有强大公司支持
• 产品特点：
  • 功能完整、可靠、UI 美观
    • 全自动 CI 测试
    • Github / Gitlab集成
    • 完整的微软 Project 功能支持
    • 采用和 Github 一样的 primer view components （Fork）
  • API 和数据库开放性强
    • API 采用Grape，专业的 OpenAPI 3.0 Specification 实现框架
    • 数据库使用PG，随便读写，安装插件
    • 所有代码均提供，不像 unleash 之类的，开源版本有删减

技术架构与限制

• 技术栈：Rails、Angular、Grape（API支持OpenAPI 3.0）
• 限制：
  • ⽤户上⼿成本⾼
    • 仅支持 markdown 格式
    • 不支持切换主题色调
    • UI 的交互偏向老用户和操作效率
  • 插件需与主程序合并一起部署才能正常工作
  • 受 GPL v3 保护，修改需开源（不过插件可使用不同 License ，甚至闭源）

客户案例分析

• 主要客户：德国内政府、华为、上海汽轮机、天华建筑设计
• 天华建筑设计选择 Open Project 原因：用户多；项目多，需私有化部署；存在定制需求

发展趋势

• SaaS模式在国内面临挑战：
  • 中小企业订阅增长缓慢
  • 大型企业倾向私有化部署
• 二次开发服务模式可能更适合中国市场
• 期待成为项目管理工具的默认选择

主题二、黄江文 — 高效定位：Web 应用的排查技巧

背景

• 生产事故无法完全避免，高效排查至关重要
• 当前挑战：架构复杂（多K8s集群、多区域）、第三方供应商增多、团队扩大、变更频繁

事故响应

• 恢复服务
  • 评估严重程度，严重的问题则 Escalate
    • 错误率、影响范围评估
    • 事故：经济损失、损失名誉、信任
    • 最高级事故P0 发到 “1 Hot” Slack Channel
  • 初步定位问题、恢复服务
    • 大忌：急于找根本原因、改代码修复
    • 恢复服务方法
      • 回滚：如果发生事故的主要原因是因为变更（APM 查看 changes by Service 板块）
      • 扩容：API 排队时间过长，可考虑扩容。注意避免压垮下游：DB、Vendor（难恢复）
      • 重启
      • 服务降级：丢弃请求过长的请求、增加缓存过期时间、关闭低优先级服务
• 排查技巧
  • 5个why
    • 链路上哪个组件有问题
    • 是否正常工作
    • 错误率多少
    • 为什么出现问题
    • 组件做了什么
  • APM Metric 板块查看主机、Container、DB指标是否正常
  • Database Monitoring
    • Load = IO + CPU + Network + Lock + IPC
    • Latency（平均延迟）、Throughout（吞吐量）、缓存 Shared Buffer Hit + Read
    • Explain Plans

集成 APM（App Performance Monitoring），可快速排查问题

• Changes by Service 可以查看近期修改
• Latency = Queue + DB + Redis + External HTTP + Ruby
• 对比不同版本的性能变化
• Trace 工具回答以下问题
  • 涉及哪些服务
  • 哪部分有问题
  • 哪部分慢
  • 每个服务做什么：DB、External call
• 一站式 Dashboard 工具
• Showcase（例子）
  • 问题：有个 DB 查询时慢时快
  • 先查看响应时间的查询数量比例分布，查看严重程度
  • 查看DB到应用的延迟，查询计划、Metrics，看 Query 有没有性能问题
  • 查看 一站式 Dashboard： 5 mins 缓存 TTL => 每五分钟 DB Query 时间突增（即缓存失效导致查询缓慢）
  • 解决方法：添加任务每分钟更新缓存，避免缓存丢失

自动化

• 分解流程
  • 检查整条链路各个服务
    • 列出各个服务
    • 检查各个服务是否健康
  • 查错误日志
    • 从报告提取关键词
    • 搜索日志
  • 分析错误日志
• 好处
  • 响应更及时
  • 规模化
  • 不容易遗漏

核心原则

先恢复服务，再排查根因

主题三、袁志鹏 — Ruby profiler 大盘点、Vernier 原理与应用

性能分析工具分类

• Profiler：性能分析
• Benchmark：基准测试
• Trace：数据流向与进度检查
• Metric：统计延迟、并发数等指标

Profiler 工具分成三大类

1. CPU 分析（时间占比）
   tracing or sampling：

   • 对所有方法的调用开始和结束进行拦截并记时
     • 工具：speedscope.app
   • 一般不会拦截对所有方法，而是仅拦截关键调用：
     • 基于 alias_method、prepend、delegator 和 rack moddleware
       • 工具：opentelemetry、newelic、elastic-apm
   • 定期获取调用栈快照，统计每一帧出现的次数
     • 基于 ruby 的 sigaction、setitimer 或 sleep、rb_postpond_job_register_one、rb_proile_frames
       • 相关 gem：stackprof、vernier（vernier 要求 ruby 3.2 及以上）
     • 从其他进程读取 ruby 进程的内存结构
       • 相关 gem：rbspy

2. 内存分析（内存分配和回收占比）

   • 基础分析工具：ruby-prof、memory_profiler
   • 对象留存分析：
     • memory_profiler
     • allocation_trace
     • ruby_memprofiler_prof
     • vernier
   • GC分析（次数、时间）：gvl-tracing、vernier

3. 并发分析（GVL 等待占比）

   • 监听 ruby 进程的开始、暂停、恢复事件
     • 工具：gvl-tracing、gvltools 等

综合分析工具

• rack-mini-profile
• app_profiler
• sentry
• derailed_benchmark（用例：加载依赖项时是否很占用时间、内存）
• test-prof

工具选择建议

一般推荐使用 APM 工具，更直观

主题四、Hegwin — 元编程在测试框架里的应用

如何完成测试单元执行（可查看 TestCase 源码）

• ruby 核心钩子方法

  • method_missing 方法
  • included：注意区别于 rails 中的 included 方法
  • inherited：继承类时执行。用例：计算有多少类继承了当前类

  • method_added：当定义一个方法是执行

    • 应用：Thor 命令行开发框架

    

• 测试方法的注册原理

  • 通过类继承实现命令注册
  • 使用 method_added 钩子捕获方法定义
  • 记录测试方法的文件位置信息和方法名
  • 程序退出时执行测试（通过 at_exit）
  • 测试运行的结果作为 exit 的一个编码返回

• TestCase 类中 method_added 方法的实现细节

  • 使用常量存储测试集合
  • 检测重复定义的方法
  • 记录测试失败位置
  • 添加匿名类，封装隔离了一些代码，执行 at_exit

• 尝试：自定义TestCase基类