赞👍，解释的很专业。

你说的慢连接的问题目前我们是从规范上来限制，对于执行时间长的请求，一律扔到 sidekiq 这类任务系统里面去处理，http 请求快速返回。

cony 我也去看看，目前重连我实现的也比较原始；golang dep 我也想用，不过看着还没有正式发版，就先用 glide 了。

你说的是同一回事，每个服务自带一套消息处理机制，具体的实现基本上就是独立的进程（像 sneaker）或者 java 服务里面单开一套线程池。

确实是个不大的改动，但是服务多了之后确实是一个实实在在的问题。这样做之后，每个服务只需要关注自己的实现就可以了。

我们也是用 sneaker，但是考虑一下每个服务（十多个）都配一套 sneaker 就显得没有必要了；另外，我们也有一些 java 的服务，也要配置一个类似于 sneaker 的东西。有了回调中心之后，sneaker 就可以不再使用了，实现相关的回调接口就可以了。当然回调接口中可以再把工作丢给 sidekiq 也行。

任何问题都是基于特定场景，考虑一下有 10 个服务、甚至上百个服务的情况，是每个服务带一套消息处理的机制、还是设计一个回调中心？

可能是 Rails 5 的问题，这篇文章对应的是 Rails 3，没有这个问题啊

对，这个限制是 RabbitMQ 的限制，有属性变化会出错，但是 queue 的绑定关系可以随时修改，也够用了

应该是 css 的问题，我记得 pdfkit 必须把所有的 css 打成 一个 文件

通过 Message TTL 和 Queue 的 ttl 结合实现递增式的重试机制，赞~

不过 Sneakers / Hutch 和 RabbitMQ 业务队列使用 topic 或 direct 没有关系，业务队列是 topic 模式还是 direct 模式取决于它是如何定义的，大鱼目前是使用了一个 rake task 提前定义好所有的业务队列，也全部都是 topic 模式。

nginx 是可以不丢连接平滑升级 nginx 二进制文件的，这个做的非常成熟了。 建议看看文档：http://nginx.org/en/docs/control.html

招聘 +1： https://ruby-china.org/topics/31726

#10 楼 @kgen 大家对于移植和运维的理解不同吧

#7 楼 @kgen crontab 当然很可靠，但是不用的理由请看原文：

1. crontab 方案每一条任务都是独立的，都需要完整加载整个 Rails 运行环境，而 Rails 运行环境相对是比较耗资源的。想象一下每次几十个、上百个定时任务不停的启动停止，系统的负载可想而知。
2. crontab 本身是系统的组件，这种方案需要依赖于系统的组件，在很多 production 环境下可能没有 crontab 组件，比如运行在 heroku 上，比如运行在 docker 上。

另外，通过把定时任务转换成 scheduler 来使用，尽量避免把 cron 任务变成一个『高强度』的东东。

当然，最终用什么还是要根据自己的需求和实际情况来就行了，每个方案都有自己的优劣吧

#3 楼 @Rei crontab 当然是最健壮的~ 主要还是挑选适合自己的方案吧，这种最佳实践也都有局限性，『没有银弹』

#13 楼 @gihnius 这个看起来很不错

#11 楼 @lithium4010 还是看具体的使用场景

#6 楼 @lithium4010 哦，我们并没有使用 perform_in，我们使用 crono + Job

#4 楼 @lithium4010 我们现在系统就是这么做的，回头写篇文章解释一下。主要好处就是可以利用 Job 本身的重试机制、错误处理机制，而 Cron 本身很简洁，只是一个触发器。

不推荐这么做，还是用应该更合适的工具做适合的事情。推荐的做法是用定时任务（crontab、rufus-scheduler、crono）来做一个调度器，具体的事情还是有 Job 系统来完成

#2 楼 @huacnlee 敏感信息还是很有必要使用 ENV 来管理的。应用配置的话方法管理方式很多

#7 楼 @hiveer 主要是敏感信息使用 Env 有一些好处，至于 Settings 还是自己写一个 initializer 确实区别不大

一直在想有什么 topic 是对社区的小伙伴们有帮助的，大鱼的系统主要是基于 ruby on rails 的，我们用到了很多有意思的技术，有的相对也比较深入了，但是都比较散，讲起来大家可能也不是很感兴趣，所以准备讲一下如何维护一个时间超长的 rails 项目，里面也会穿插讲一些创业过程中的问题。

报名主题演讲：如何维护一个 4 年的 rails 项目？

内容包括：

• 一个 rails 项目 4 年的不断变得复杂的发展过程；
• 发展过程中遇到了哪些问题；
• 这些问题是如何被解决的？

大概内容主要包括自动化测试、service、项目分拆、代码审查 等等~

免费赞助场地，三元桥大鱼咖啡~ 欢迎各位来坐坐

赞 @nainc stubs 和 mock 那段写的不错，但是感觉还没有抓到本质的点～回头我也看看

赞！ 感觉 retry 的时候调用的 record 可能还是老的对象，得再测试一下~

#5 楼 @ruby_sky 当然，如果当做 module 的话，按正常的 ruby way 使用用就行了；rails 的 concern 一般 用于 model 间的业务共享；而且用 module 并不能解决 view-model 的问题，完全两码事~

#1 楼 @qinfanpeng 多谢~

#2 楼 @ruby_sky concern 主要用来在 model 之间共享逻辑，跟这个要解决的是两个问题。另外，concern 本身也是不推荐大量使用的，concern 采用了 mixin 的方式，一旦代码量增大，也容易导致不少问题。

#2 楼 @coderek 其实 ruby 的也算轻量了，不然可以看看 java 世界，还要区分 checked exception 和 unchecked exception，直接晕掉。 异常最重要的是合理使用，不能过度，也肯定避免不了不用

#1 楼 @taojay315 rails 里面是这样的，一般用 rescue_from 来统一捕获部分异常然后进行处理，不过这个不是这篇文字讲的重点。 异常当然不应该抛给最终用户，抛异常的时候关心抛出合适的异常即可，至于是谁来捕获，就需要来看具体的业务逻辑了，一般是上层捕获下层的异常，直接处理掉或者进行转译再抛出。