@heroyct 那现在核心是 "让一人负责基础设施" 的部署, 小团队没有问题, 再大一点的团队可能会有基础设施的构建权限或者基础设施的变化的问题.

terraform destroy 的存在心里还是很怕的, 基础设施越大这个担心越可怕, 所以如果有 Terraform Collaboration for Everyone 将 terraform 的最后执行在类似 github 那样允许的 merge 操作会放心很多. 有时候不是故意, 而是运维会"手抖 + tab 补全", 然后整个基础设施就全部通过 API destroy 掉了 - -||

我在测试部署 DO 的时候, terraform plan/apply 很便捷, terraform destroy 很恐怖....

虽然 destroy 指令 让我很恐怖, 但现在使用 terraform 我觉得时机非常不错, terraform 开源到现在 Infrastructure as Code 的概念在现在的不同公用云已经很多都落地并且成熟. 大多数云厂商都为 hashicorp/terraform 提供了自己 API 的兼容 resource, 这使得 Infrastructure as Code 的范围扩张可以扩张得很广:

• 基础使用的服务器 (AWS, Alicloud, TencentCloud, HuaweiCloud, 青云, DO, vultr, Linode ....)
  • VPC, 防火墙, ssh key ... (只要对应公有云有 API, 并提供 terraform 的 resource 支持)
• 网络上的 DNS (cloudflare, dnsimple ...)
• 对象存储 (AWS S3, S3 compatible ...) ...

可以想象一下, 所有程序运营的基础设施无论是服务器还是中间件, 都可以通过 terraform 的 code 来定义, 再利用 ansible (或者其官方的 Packer) 来解决服务器本身的初始化构建问题. 项目越大, 这套管理方法带来的收益越高.

所以推荐 terraform 还是很赞的!

terraform apply vs terraform destroy 都得考虑, 团队上的话需要考虑好 terraform destroy 的问题, 所以有了 Terraform Collaboration for Everyone

利用 dokku 或者 flynn 部署 rails +pg 是一件非常愉悦的事情

我感觉 Mike Perham 在不断试错吧, Ruby sidekiq 成功后, 现在一直不断寻找新的突破口. 他也在不断的折腾: crystal 版本的 sidekiq, golang 实现的 inspeqtor 再到现在 golang 实现的 faktory.

虽然现在也不太愿意使用 faktory, 但在已经稳定的 一个人的公司 仍然这样不断创新也挺佩服.

另外, 对于不同系统之间的异构系统, 也有太多方案可选择了. 比如复杂一点就上 RabbitMQ 了.

@pathbox 我的理解是这个设计将下面几项单独出来:

1. 与 RabbitMQ 之间的沟通独立出来负责与 MQ 之间的连接/重连的问题
2. 将所有的任务看做 MQ 中的 Message, 负责 Message 的 成功/失败重试/死亡队列 的问题.(这个详细可参考 Sidekiq 的机制)

这个设计优势会体现在使用不同的语言, 都需要使用与 MQ 之间交互, 并且大家都需要 "合理的重试机制", 保证只要消息没有成功处理, 就停留在 MQ 中. 但劣势也很明显, 每一个任务都需要具体的服务执行方提供一个结果 成功否 返回. 现在的方案中是 HTTP 的同步方案. 虽然 Golang 的 goroutine 能支撑起连接数, 但是这样的同步回调机制对服务执行方的接入会有场景限制, 那些执行时间特别长的应该不太愿意接入(想象一个 http 请求连着 5 分钟等返回). 如果考虑将这个中间件设计成为一个与外部系统异步交互的方式, 使用端应该更乐意接入.

从另外一个角度来考虑, RabbitMQ 本身是作为多个服务之间使用消息传递解耦而存在的中间件, 如果可以将这些 "重用" 的机制以扩展或者插件的方式实现到现有语言(java, ruby, golang) 与 RabbitMQ 交互的代码中, 也不失为一种方案. 这样少一层抽象少一层理解.

@zamia ruby 和 golang 配合很是强大 提供两个 tips:

• golang 中与 RabbitMQ 的重连问题可以考虑 cony, issue 这是个常见问题, 但 golang 的 amqp 不支持, 就类似 ruby 的 amqp 不支持, 但上层的 bunny 支持. 我们一个后端每天跑着 100w 级别任务, 服务于 MQ 连接大概 100ms, 持续稳定的运行.
• golang 的 Package Manager 可以考虑 golang dep, glide 也官方宣布等着 dep 发布. dep 将现有代码和 gopkg.yml 计算双方的依赖进入 vendor 的方案更适合 golang 这个语言的特性一些.

@zamia 啊, 看到了. 可以自定义 exchange 的类型. 如果是这样, 那两者的区别就非常小了. sneakers 和 hutch 两者都很稳定. 就是 sneakers 的队列是真的有点多...

使用 hutch 的时候, 就是每次 Hutch 启动的时候都会去申请 Queue, Exchange, Consumer. 如果有变化, 就立马报错了.

Sneakers 和 Hutch 底层都是使用 bunny, 翻一下代码就可以看到其做了重连处理. session.rb, reader_loop.rb

Bunny 的底层使用的是 amq-protocol, 这一层只负责协议交互部分不负责重连的问题.

另外应用层的 Hutch, 工具层的 Bunny, 协议层的 amq-protocol 都是 michaelklishin 核心开发者.同一个作者对这一系列的抽象很漂亮.

• hutch
• bunny
• amq-protocol

@zamia 在研究多系统交互的时候发现了 RabbitMQ 和 Sneakers, 但 Sneakers 采取的是 direct 方式的 exchange 设计, 因为他走的是高并发设计所以利用 RabbitMQ 链接的多路复用机制, 创建很多的 Channel. 为高性能采用了 direct 方式, 对 rabbitmq 的使用而言舍弃了其灵活性很高的 topic 方式的 exchange. 另外一个 Ruby 领域的 RabbitMQ 队列 Gem Hutch 则是从 topic 的 exchange 出发设计.

• 如果是大量时间不长的小 event 事件的处理, Sneakers 比较合适.
• 如果是多系统之间的信息沟通, Hutch 比较合适. 因为 RabbitMQ 的 topic 类型的 exchange 可以很好的广播消息, 不同系统可以根据需要将自己的 Queue 绑定一个这个 Exchange 缓存消息.

我最后选择了使用 Hutch, 但因为 Hutch 本身不支持与 ActiveJob 的集成, 我就封装了一下 hutch-schedule, 为 Hutch 提供了:

• 参考 Sneakers 实现了 Hutch 级别的类似 AJ 的重试递增 Error Retry 机制
• 提供了 Hutch 与 AJ 的 Adapter 集成
• 延续 Hutch 本身的设计, 增加了延迟任务

异常重试

异常重试可以分为两类:

• 作为 ActiveJob 的后端: AJ 本身有异常处理的机制, 只要后端支持延迟推送消息处理即可.
• gem 自己的异常处理: 这个就类似上文中的 queue 身上的 ttl 机制了. 或者类似 Sidekiq 的异常处理.

如果使用 ActiveJob 作为后端任务队列, 那么这两层机制都是可以被应用到的. 首先是 AJ 的以后捕获处理, 如果 AJ 的超出异常了, Gem 自己的还可以再捕获一次进行重试.

RabbitMQ 的支持

对 RabbitMQ 也有两种消息重试机制:

• 一种是在 Queue 身上申明 x-message-ttl 以及 x-dead-letter-exchange 的死信机制.
• 一种是在 Message 身上的参数 expiration (per-message) 的 TTL 机制.

单一的死信机制无法达到阶梯式重试, 但和 TTL 结合起来就可以了.

`ttl message`  -> 'topic exchange' -> 'dead queue' ...wait... -> 'topic exchange' -> 'queue'
                                                   | ttl 触发死信机制, 重新投递 |

其他经验

现在的 Sidekiq, Sneakers, Hutch 三种都采用了最基本的线程池的方式处理, 他们相似的原理表示不会有数量级上的差距. 唯独 Sneakers 在线程池的实现上还有一层类似 puma 的多进程 + 多线程(supervisor), 这个会有优势.

对于 RabbitMQ 与 Redis 的区别, 如果纯粹是 background job, 其实 sidekiq + redis 这种 pull 方式更合适, 因为简单直接也高效. 但对于需要外部系统交互, 特别是与其他语言的异步解耦交互, RabbitMQ 所提供的消息中间件是很优势. (我现在是 Ruby 前端与 Golang 重后端之间通过 RabbitMQ 交互数据), 另外 RabbitMQ 是主动推送消息(可通过 prefetch 控制量), 在节点变多之后还承担了一个消息负载均衡投递的职责, 这个很省心.

https://mailcatcher.me/

#3楼 @hooooopo 那不就是 npm 吗 - -||