nomadv0.5.3引入了参数化作业，作为作业框架，可以使用可配置参数按需调度。这些作业的行为类似于函数，封装逻辑并允许调用者命名作业并提供适当的参数。NomadDispatch将这些"函数调用"视为未来或承诺，从而可以轻松地为视频转码、图像大小调整、发送电子邮件或进行帐单汇总等操作构建可伸缩的处理管道。这篇博客文章探讨了使用新的Nomad分派特性来使用流行的开源工具ffmpeg构建视频转码服务。解决这个问题的传统方法通常涉及到工作队列、调度、容量规划和故障处理的许多不同组件。由于它的设计，Nomad可以自动处理这些问题，从而可以专注于最小的作业定义和视频转码服务的业务逻辑。»背景大多数应用程序都有同步请求/响应组件，但许多应用程序也有异步后台处理来执行。一些常见的例子包括发送电子邮件、计费聚合、处理用户内容和通知移动设备。这些进程通常被卸载到异步系统的原因是它们的延迟或处理时间超过了正常请求的时间。例如，您不希望在呈现HTML页面之前等待电子邮件发送，也不希望在web服务器上加载可以在专用资源上运行的作业。处理异步或后台处理的一个非常常见的模式是工作队列。在这个模型中，生产者提交给一个集中的工作队列。此队列充当缓冲区，直到使用者出列并执行处理。下面的图表展示了这种常见的体系结构。这种模式允许分离生产者和消费者，使消费者能够随着工作量的增加或减少而伸缩。生产者可以是任何应用程序，但它们通常对延迟敏感，比如web或API服务器，在请求的生命周期内，它们不能执行长时间运行的处理。相反，生产者将要在后台处理的工作负载与请求一起在带外排队。队列本身通常由RabbitMQ或apachekafka等工具表示。队列负责缓冲工作，直到有足够的资源可用于处理。重要的是，队列提供持久性，以在重新启动、失败或部分中断中生存，并且具有至少一次传递语义的保证。这意味着，如果在处理过程中向使用者传递了失败的消息，则工作将交给另一个使用者，直到成功完成。使用者负责从队列中取出工作、执行相关处理、确认完成、处理取消以及执行任何清理或失败处理。消费者执行的实际工作取决于用例，但一些常见的示例包括发送电子邮件、进行帐单汇总或加密数据。生产者-消费者模型已经存在了很长时间，但是与这种模式相关联的一些挑战。最大的问题是队列本身。为了有用，工作队列必须具有容错性和高可用性。大多数队列都是复杂的有状态服务，这使得它们在操作上很复杂。其次，处理工作的使用者通常需要包含数百行的样板文件，以便与队列系统集成，并处理诸如并发、取消、清理或故障处理之类的事情。最后，人类必须决定消费者的数量——如果有太少的消费者来处理工作，队列将很长，但是如果有太多的消费者来处理工作，集群中就有浪费或未充分利用的资源。Nomad调度和参数化作业大大简化了生产者-消费者模型。Nomad充当一个工作队列，动态地调度消费者，以避免浪费资源和抽象出消费者经常需要的样板文件。如果我们退一步来研究问题空间，就会发现调度程序是正确的解决方案。调度器可以充当队列，而不是依赖于集中式队列，它能够权衡更复杂的策略，比如优先级，并具有内置的故障处理支持。新的参数化作业和Nomad调度功能使组织能够用高可用性、容错性和经过战斗测试的解决方案来取代复杂的排队系统。Nomad已经展示了运行一百万个并发容器的能力，它是这个代码转换服务的一个很好的候选对象。»参数化作业Nomad参数化作业看起来与常规的Nomad作业非常相似，但还包括一个额外的参数化节。包含此节将作业从可执行作业更改为用于分派的作业脚手架。作业"代码转换"{type="批处理"数据中心=dc1"]元{输入=""profile="小"}#将作业标记为可分派的新"参数化"节。在这个#例如，有两个元数据（见上文）。"输入"#参数是必需的，但"profile"参数是可选的和默认值#如果在分派作业时未指定，则设置为"小"。参数化{需要meta_=输入"]meta_可选=配置文件"]}任务"tc"{driver="执行"配置{命令="转码.sh"args=${NOMAD_META_INPUT}"，"${NOMAD_META_PROFILE}"]}环境{"S3_BUCKET"="存储桶名称"}资源{cpu=1000内存=256}模板{destination="本地/s3cfg.ini文件"#这个示例使用硬编码的凭证，但它是一个实际的生产作业#文件应使用Vault集成提取机密。数据=监测评估"44011499"由"B36185任务调度"触发分配"c42def90"已创建：节点"cedb0204"，组"tc"评估状态已更改："待定"->"完成"==>评估"44011499"fi