Ruby环境下使用semver跟踪发货算法迭代的方案选型咨询

现有两种方案的优劣势对比 #

• 独立Gem封装方案
  • 优势：算法逻辑和Rails主应用完全解耦，依托RubyGems的语义化版本规则和独立仓库权限管控，可避免主应用的其他开发误改算法逻辑，版本溯源清晰，适合需要全局统一算法版本的场景
  • 劣势：单版本特性决定无法支持多版本并行A/B测试，每次版本迭代需要升级Gem、重新部署主应用，灰度测试成本极高
• 单类多方法方案
  • 优势：多版本共存成本极低，A/B测试、灰度切换只需要调用对应方法即可，无需重新部署
  • 劣势：缺乏强版本约束，放在体量庞大的Rails项目中很容易出现方法命名混乱、旧版本逻辑被误改、版本和订单关联记录错误等人为问题，直接影响数据有效性

更优的混合实现方案 #

推荐采用Gem封装+内部多版本模块隔离的方案，同时兼顾两种方案的优势，规避缺陷，具体实现逻辑如下：

• 保留独立Gem的封装形式，算法逻辑完全和Rails主应用解耦，Gem仓库设置独立权限，仅负责算法迭代的开发可修改
• Gem内部每个算法版本对应独立的命名空间模块，完全隔离不同版本的逻辑，比如WarehouseAllocator::V1::Calculator、WarehouseAllocator::V2::Calculator，禁止跨版本调用依赖，避免迭代新版本时影响旧版本逻辑
• Gem对外暴露统一的调用入口，支持传入版本号调用对应逻辑，同时内置版本合法性校验，示例核心代码：

module WarehouseAllocator
  # 整个Gem的发布版本，和内部算法版本解耦
  GEM_VERSION = '1.4.0'
  # 支持的算法版本列表，新增版本时更新即可
  SUPPORTED_ALGORITHM_VERSIONS = %w[v1 v2 v3]

  def self.calculate_warehouse(order, algorithm_version: 'v2')
    unless SUPPORTED_ALGORITHM_VERSIONS.include?(algorithm_version.to_s.downcase)
      raise ArgumentError, "不支持的仓库分配算法版本: #{algorithm_version}"
    end
    calculator = Object.const_get("WarehouseAllocator::#{algorithm_version.upcase}::Calculator").new
    result = calculator.execute(order)
    # 返回结果自带实际执行的版本号，避免Rails侧传参和实际执行不一致
    { warehouse_id: result, algorithm_version: algorithm_version }
  end
end

• Rails侧调用时，A/B测试只需要给不同分组的订单传入对应的版本参数，直接取返回结果中的algorithm_version写入订单的对应数据库字段即可，完全避免人为传参错误导致的数据问题
• 新增算法版本时，只需要在Gem内新增对应版本的独立模块、更新支持版本列表，发布新版本Gem即可，旧版本逻辑完全封存不会被改动

额外优化建议 #

• 可以在Gem的统一入口处内置轻量的埋点钩子，自动上报每个版本的调用次数、执行耗时、分配结果分布等指标，无需在Rails主应用中重复开发埋点
• 如果后续不同算法版本需要依赖不同的第三方包，可以将不同版本逻辑封装为Gem内的独立插件，按需加载依赖，避免Gem整体过于臃肿

内容的提问来源于stack exchange，提问作者AELSchauer