zamia (imedal)

用 500 行 Golang 代码实现高性能的消息回调中间件

zamia — Sun, 24 Sep 2017 17:20:18 +0800

用 500 行 Golang 代码实现高性能的消息回调中间件

本文描述了如何实现一个消息回调中间件，得益于 golang 管道和协程的编程思想，通过巧妙的设计，只需要约 500 行代码就可以实现高性能、优雅关闭、自动重连等特性，全部代码也已经开源在 github/fishtrip/watchman。

问题

随着业务复杂度的增加，服务拆分后服务数量不断增加，异步消息队列的引入是必不可少的。当服务较少的时候，比如业务早期，很多时候就是一个比较大的单体应用或者少量几个服务，消息队列（之后写做 MQ，Message Queue）的使用方法如下：

发送端，直接连接 MQ，根据业务需求发送消息；
消费端，通过一个后台进程，通过长连接连接至 MQ，然后实时消费消息，然后进行相应的处理；

相对来说，发送端比较简单，消费端比较复杂，需要处理的逻辑比较多。比如目前我们公司使用的 sneakers 需要处理如下的逻辑：

消费端需要长连接，需要独立的进程实时消费消息（某些语言可能是一个独立的线程）；
消费消息之后，需要加载业务框架（比如 Sneakers 需要加入 Rails 环境执行业务代码）调用相关代码来消费消息；
MQ 无法连接时，需要自动重连，同时应用也需要能够优雅重启，不至于丢消息。
消费消息很可能处理失败，这个时候需要比较安全可靠的机制保证不能丢失消息，同时也要求能够过一段时间对消息进行重试，重试多次之后也需要能够对消息进一步做处理；

这个时候的系统架构一般如下：

而随着服务增多，如果每个需要消费消息的服务都部署一个这样的后台进程显然不够环保：

每个服务增加一个进程，增加了部署运维的成本；
对于队列的管理（创建、销毁、binding）以及消息重试机制，每个服务来自己负责的话，很容易造成标准不统一；
如果不同的服务是不同的语言、不同的框架，每个语言又都要实现一遍，会浪费不少开发资源；

那有没有更好的办法呢？

其中一般办法是打造一个全局的、高性能的消息回调中间件，中间件来负责队列的管理、消息的收发、重试以及出错处理，这样就不再需要每个服务去考虑诸如消息丢失、消息重试等问题了，基本解决了上面的缺点。具体这个消息回调中心应该具备哪些功能呢？

统一管理所有 MQ 队列的创建和消息监听；
当有消息接收到时，中间件调用相关服务的回调地址，因为回调中心负责所有的服务，该中间件必须是高性能、高并发的；
中间件应当具备消息重试的功能，同时重试消息的时候不应该丢失消息；
中间件应当具备「重连」和「优雅关闭」等基础功能，这样才能保证不丢消息；

这时候架构如下：

这样的话，每个服务的工作就变得轻量了很多。本文的目的就是来实现一版生产环境可用的消息回调中间件。当然，我们第一版的回调中心也不需要太多功能，有如下的限制：

整个重试流程需要 RabbitMQ 内置功能支持，所以暂时只支持 RabbitMQ；
目前只支持 HTTP 回调方式；

基本的需求有了，如何实现一个这样的消息回调中间件呢？

解决思路

开发语言选择

Golang 作为「系统级开发语言」，非常适合开发这类中间件。内建的 goroutine/channel 机制非常容易实现高并发。而作为 Golang 新手，这个项目也不复杂，很适合练手和进一步学习。

消息可靠性

关于重试和出错处理呢？我们从 Sneakers 的实现中借鉴了它的方法，通过利用 RabbitMQ 内置的机制，也就是通过 x-dead-letter 机制来保证消息在重试时可以做到高可靠性，具体可以参考前段时间我写的这篇文章。简单总结一下文中的思路：

消息正常被处理时，直接 ack 消息就好；
当消息处理出错，需要重试时，reject 消息，此时消息会进入到单独的 retry 队列；
retry 队列配置好了 ttl 超时时间，等到超时时，消息会进入到 requeue Exchange（RabbitMQ 的概念，用来做消息的路由）；
消息会再次进入工作队列，等待被下次重试；
如果消息的重试次数超过了一定的值，那么消息会进入到错误队列等待进一步处理；

这里面有两个地方利用了 RabbitMQ 的 Dead-Letter 机制：

当消息被 reject 之后，消息进入到该队列的 dead-letter Exchange，也就是重试队列；
当重试队列的消息，在超时时（队列设置了 ttl-expires 时长），消息进入该队列的 dead-letter Exchange，也就是重新进入了工作队列。

通过这种机制，可以保证在进行消息处理的时候，不管是正常、还是出错时，消息都不会丢失。关于这里进一步的细节可以参考上面的文章。

实现高并发

对于中间件，性能的要求比较高，性能也包含两个方面：低延迟和高并发。低延迟在这个场景中我们无法解决，因为一个消息回调之后的延迟是其他业务服务决定的。所以我们更多的是追求高并发。

如何获得高并发？首先是开发语言的选择，这类底层的中间件很适合用 Golang 来实现，为什么呢？因为回调中心的主逻辑就是不断回调各个服务，而各个服务的延迟时间中间件无法控制，所以如果想获得高并发，最好是使用异步事件这种机制。而借助于 Golang 内置的 Channel，既可以获得接近于异步事件的性能，又可以让整个开发变得简单高效，是一个比较合适的选择。

具体实现呢？其实对于一个回调中心来说，大概分成这么几个步骤：

获取消息：连接消息队列（目前我们只需要支持 RabbitMQ 即可），消费消息；
回调业务接口：消费消息之后，根据配置信息，不同的队列可能需要调用不同的回调地址，开始调用业务接口（目前我们只需要支持 HTTP 协议即可）；
根据回调结果处理消息：如果调用业务接口如果成功，则直接 ack 消息即可；如果调用失败，则 reject 此消息；如果超过最大重试次数，则进入出错处理逻辑；
出错处理逻辑：把原有消息 ack，同时转发此消息进入 error 队列，等待进一步处理（可能是报警，然后人工处理）；

通过消息这么一个「实体」可以把所有上面的流程串联起来，是不是很像 pipeline？而 pipeline 的设计模式是 Golang 非常推荐的实现高并发的方式。上面的每一个步骤可以看做一组协程（goroutine），他们之间通过管道通信，因此不存在资源竞争的情况，大大降低了开发成本。

而上面每个步骤可以通过设计不同的 Goroutine 模型来实现高并发：

获取消息：需要长连接 RabbitMQ，较好的实现方式是每个队列有独立的一组协程，这样队列之间的消息接受互相不会干扰，如果出现了繁忙队列和较闲的队列时，也不会出现消息处理不及时的情况；
回调业务接口：每个消息都会调用业务接口，但是业务接口的处理时长对于中间件来说是透明的。因此，这里最好的模型是每个消息一个协程。如果出现了较慢的接口，那么通过 goroutine 的内部调度机制，并不会影响系统的吞吐，同时 goroutine 可以支持上百万的并发，因此用这种模式最合适。
根据回调结果处理消息：这个步骤主要是要连接 RabbitMQ，发送 ack/reject 消息。默认我们认为 RabbitMQ 是可靠的，这里统一用同一组协程来处理即可。
出错处理逻辑：这里的消息量应该大大降低，因为多次失败（超过重试次数）的消息才会进入到这里。我们也采用同一组协程处理即可。

上面四个步骤，我们用了三种协程的设计模型，细化一下上面的图就是这个样子的。

实现

有了上面的设计过程，代码并不复杂，大概分为几部分：配置管理、主流程、消息对象、重试逻辑以及优雅关闭等的实现。详细的代码放在 github：fishtrip/watchman

配置管理

配置管理这部分，这个版本我们实现的比较简单，就是读取 yml 配置文件。配置文件主要包含的主要是三部分信息：

消息队列定义。要根据消息队列的配置调用 RabbitMQ 接口生成相关的队列（重试队列、错误队列等）；
回调地址配置。不同的消息队列需要不同的回调地址；
其他配置。如重试次数、超时等。

# config/queues.example.yml
projects:
  - name: test
    queues_default:
      notify_base: "http://localhost:8080"
      notify_timeout: 5
      retry_times: 40
      retry_duration: 300
      binding_exchange: fishtrip
    queues:
      - queue_name: "order_processor"
        notify_path: "/orders/notify" 
        routing_key:
          - "order.state.created"
          - "house.state.#"

我们使用 yaml.v2 包可以很方便的解析 yaml 配置文件到 struct 之中，比如对于 queue 的定义，struct 实现如下：

// config.go 28-38

type QueueConfig struct {
    QueueName       string   `yaml:"queue_name"`
    RoutingKey      []string `yaml:"routing_key"`
    NotifyPath      string   `yaml:"notify_path"`
    NotifyTimeout   int      `yaml:"notify_timeout"`
    RetryTimes      int      `yaml:"retry_times"`
    RetryDuration   int      `yaml:"retry_duration"`
    BindingExchange string   `yaml:"binding_exchange"`

    project *ProjectConfig
}

上面之所以需要一个 ProjectConfig 的指针，主要是为了方便读取 project 的配置，因此加载的时候需要把队列指向 project。

// config.go
func loadQueuesConfig(configFileName string, allQueues []*QueueConfig) []*QueueConfig {
    // ......
    projects := projectsConfig.Projects
    for i, project := range projects {
        log.Printf("find project: %s", project.Name)


        // 这里不能写作  queue := project.Queues
        queues := projects[i].Queues

        for j, queue := range queues {
            log.Printf("find queue: %v", queue)

            // 这里不能写作  queues[j].project = &queue 
            queues[j].project = &projects[i]
            allQueues = append(allQueues, &queues[j])
        }
    }
   // .......
}

上面代码中有个地方容易出错，就是在 for 循环内部设置指针的时候不能直接使用 queue 变量，因为此时获取的 queue 变量是一份复制出来的数据，并不是原始数据。

另外，config.go 中大部分逻辑是按照面向对象的思考方式来书写的，比如：

// config.go
func (qc QueueConfig) ErrorQueueName() string {
    return fmt.Sprintf("%s-error", qc.QueueName)
}
func (qc QueueConfig) WorkerExchangeName() string {
    if qc.BindingExchange == "" {
        return qc.project.QueuesDefaultConfig.BindingExchange
    }
    return qc.BindingExchange
}

通过这种方式，可以写出更清晰可维护的代码。

消息对象封装

整个程序中，在 channel 中传递的数据都是 Message 对象，通过这种对象封装，可以非常方便的在各种类型的 Goroutine 之间传递数据。

Message 类的定义如下：

type Message struct {
    queueConfig    QueueConfig // 消息来自于哪个队列
    amqpDelivery   *amqp.Delivery // RabbitMQ 的消息封装
    notifyResponse NotifyResponse // 消息回调结果
}

我们把 RabbitMQ 中的原生消息以及队列信息、回调结果封装在一起，通过这种方式把 Message 对象在管道之间传递。同时 Message 封装了众多的方法来供其他协程方便的调用。

// Message 相关方法
func (m Message) CurrentMessageRetries() int {}
func (m *Message) Notify(client *http.Client) *Message {}
func (m Message) IsMaxRetry() bool {}
func (m Message) IsNotifySuccess() bool {}
func (m Message) Ack() error {}
func (m Message) Reject() error {}
func (m Message) Republish(out chan<- Message) error {}
func (m Message) CloneAndPublish(channel *amqp.Channel) error {}

注意上面方法的接收对象，带指针的接收对象表示会修改对象的值。

主流程

主流程就是我们上面说的，通过 pipeline 的模式、把消息的整条流程串联起来。最核心的代码在这里：

// main.go
<-resendMessage(ackMessage(workMessage(receiveMessage(allQueues, done))))

上面每个函数都接收相同的管道定义，因此可以串联使用。其实每个函数的实现区别不大，不同的协程模型可能需要不同的写法。

下面是 receiveMessage 的写法，并进行了详细的注释。revceiveMessage 对每个消息队列都生成了 N 个协程，然后把读取的消息全部写入管道。

// main.go
func receiveMessage(queues []*QueueConfig, done <-chan struct{}) <-chan Message {

    // 创建一个管道，这个管道会作为函数的返回值
    out := make(chan Message, ChannelBufferLength)

    // WaitGroup 用于同步，这里来控制协程是否结束
    var wg sync.WaitGroup

    // 入参是队列配置，这个见下文传入的值
    receiver := func(qc QueueConfig) {
        defer wg.Done()

    // RECONNECT 标记用于跳出循环来重新连接 RabbitMQ
    RECONNECT:
        for {
            _, channel, err := setupChannel()
            if err != nil {
                PanicOnError(err)
            }

            // 消费消息
            msgs, err := channel.Consume(
                qc.WorkerQueueName(), // queue
                "",                   // consumer
                false,                // auto-ack
                false,                // exclusive
                false,                // no-local
                false,                // no-wait
                nil,                  // args
            )
            PanicOnError(err)

            for {
                select {
                case msg, ok := <-msgs:
                    if !ok {
                        log.Printf("receiver: channel is closed, maybe lost connection")
                        time.Sleep(5 * time.Second)
                        continue RECONNECT
                    }

                    // 这里生成消息的 UUID，用来跟踪整个消息流，稍后会解释
                    msg.MessageId = fmt.Sprintf("%s", uuid.NewV4())
                    message := Message{qc, &msg, 0}

                    // 这里把消息写到出管道
                    out <- message

                    message.Printf("receiver: received msg")
                case <-done:

                    // 当主协程收到 done 信号的时候，自己也退出
                    log.Printf("receiver: received a done signal")
                    return
                }
            }
        }
    }

    for _, queue := range queues {
        wg.Add(ReceiverNum)
        for i := 0; i < ReceiverNum; i++ {

            // 每个队列生成 N 个协程共同消费
            go receiver(*queue)
        }
    }

    // 控制协程，当所有的消费协程退出时，出口管道也需要关闭，通知下游协程
    go func() {
        wg.Wait()
        log.Printf("all receiver is done, closing channel")
        close(out)
    }()

    return out
}

里面有几个关键点需要注意。

每个函数都是类似的结构，一组工作协程和协作协程，当全部工作协程退出时，关闭出口管道，通知下游协程。注意 golang 中，对于管道的使用，需要从写入端关闭，否则很容易出现崩溃。
我们在每个消息中，记录了一个唯一的 uuid，这个 uuid 用来打日志，来跟踪一整条信息流。
因为可能出现的网络状况，我们要进行判断，如果出现了连接失败的情况，直接 sleep 一段时间，然后重连。
done 这个管道是在主协程进行控制的，主要用作优雅关闭。优雅关闭的作用是在升级配置、升级主程序的时候可以保证不丢消息（等待消息真的完成之后才会结束协程，整个程序才会退出）。

总结

得益于 Golang 的高效的表达能力，通过大约 500 行代码实现了一个稳定的消息回调中间件，同时具备下面的特性：

高性能。在 macbook pro 15 上简单测试，每个队列的处理能力可以轻松达到 3000 message/second 以上，多个队列也可以做到线性的增加性能，整体应用达到几万每秒很轻松。同时，得益于 golang 的协程设计，如果下游出现了慢调用，那么也不会影响并发。
优雅关闭。通过对信号的监听，整个程序可以在不丢消息的情况下优雅关闭，利于配置更改和程序重启。这个在生产环境非常重要。
自动重连。当 RabbitMQ 服务无法连接的时候，应用可以自动重连。

当然，我们团队目前还都是 golang 新手，也没有做太多的单元测试和性能测试，下一步可能会继续优化，完善测试工作，并且优化配置的管理，欢迎各位去 github 围观源码。

RabbitMQ / Sneakers 消息重试机制及源码简析

zamia — Mon, 04 Sep 2017 22:06:23 +0800

Sneakers 重试机制及源码简析

Sneakers 是基于 RabbitMQ 的高性能后台任务处理系统，可以方便的对接 RabbitMQ 来解决各种异步消息通信的问题。而异步消息的处理中，为了做到系统的稳定性，任务的重试机制就非常重要，本文简单介绍一下 Sneakers 如何基于 RabbitMQ 内部的机制来实现任务的重试机制的。

为什么使用 Sneakers

当系统变的越来越大的时候，一般的处理方式是按照产品线、或者按照层次进行服务化的拆分。随着公司的服务越来越多，服务之间的通信也会越来越多。除了各种同步（http、rpc 等）的通信之外，还有很多异步通信的场景，比如以订单举例：

订单创建成功之后，通知消息系统，需要发送邮件/短信给用户；
订单支付成功之后，通知工单系统，创建工单用于跟进用户；
订单完成之后，通知财务系统，需要给供应商转账了；

这种系统之间的通信，同时又不需要同步进行的操作，使用消息队列就比较合适，目前大鱼使用的是 RabbitMQ。

同时，使用消息队列之后，也需要一个靠谱的任务处理机制来实时监听消息，保持和消息队列的长连接，一旦有消息到达，就可以开始执行某个任务，本文中 Sneakers 就是这样的一个 Gem。

同时，消费消息的时候难免需要重试，比如上面的例子中，如果收到消息时，邮件服务器无法连接、工单系统创建工单失败、财务系统可能挂掉，那么这时应该怎么处理呢？一般来说，处理方式是这样的：

遇到错误时，等待一定的时长，然后重试；
下次重试时，如果仍然失败，继续等待下次重试；
重试 N 次之后，如果仍然失败，那么直接进入垃圾消息队列，等待人工处理（比如发送报警给工程师）；

背景介绍的差不多了，本文主要要讲的是 Sneakers 如何利用 RabbitMQ 内部提供的 x-dead-letter（死信机制）的机制聪明的进行任务的重试机制的。

Sneakers 的重试机制简析

如果不深入思考，可能觉得一个消息处理系统的重试机制应该很简单，比如读取一条消息，然后处理，如果有异常，则把消息重新发送一遍即可。但是这样有几个问题：

读取消息之后，如果 worker 崩溃了，那是不是这条消息就丢了呢？
处理消息时，如果有异常，worker 怎么知道这是第一次异常还是 N 次异常之后呢？如何记录这个重试次数？因为业务上一般重试 N 次之后仍旧失败，就没必要再次重试了，直接报警人工处理即可。
如果把消息重新发送一遍，这时如果消息发送失败，那么是不是这条消息也就永远丢失了呢？

那么 Sneakers 是怎么处理这个问题的呢？它很聪明的利用 x-dead-letter 来处理重试问题。

X-Dead-Letter 机制指的是：

队列中的消息可以被『Dead-Lettered』，也就是说，当下面的情况发生的时候消息会被重新投递到另外一个队列：

消息被 reject，同时 requeue = false；

消息的 ttl 超时时；

队列中的消息数超出队列的最大长度限制；

Sneakers 内部借助这个机制实现了消息的重试，同时保证了消息不会丢失以及高性能，它是如何实现的呢？

概览图

直接上我画的这个 RabbitMQ + Sneakers 内部处理机制的消息流转图：

上面这个图中：

exchange - 业务 Ex，业务消息投递到这个 Ex；
work-queue - 业务队列，任务都在这个队列处理；

初始化

在初始化阶段，Sneakers 会直接在工作队列之外自动创建一系列的 Exchange（用 X 标记）和队列（用 Q 标记）：

worker_queue-retry(X) - 工作队列的死信目的地；
worker_queue-retry(Q) - 绑定了上面这个 Exchange 的队列；同时，它的死信会投递到 worker_queue-retry-requeue；
worker_queue-error(X) - 如果达到最大重试次数，会把消息投递到这个 Ex；
worker_queue-error(Q) - 绑定了上面这个 Ex；
worker_queue-retry-requeue(X) - 工作队列会绑定到这个 Ex，也就是说这个 Ex 的所有消息会投递到工作队列。

消息处理阶段

在消息处理阶段，用文字来描述一下上图中的流程就是这样子的：

正常消息进入 exchange 这个交换器（Ex)；
worker-queue 会接收到这个消息，然后 Sneakers 的 worker 会来消费消息；
worker 一切正常的时候，直接 ack 消息即可（这是正常流程，图中没有体现）；
如果 worker 执行出错，首先判断是否到最大重试次数；
到达最大重试次数，直接把消息投递到 worker_queue-error 这里即可；
如果没有到达最大重试次数（也就是需要消息重试），那么直接 reject 消息即可。

其实到这里，Sneakers 内部的代码逻辑就结束了，是不是还挺简单的。而事实上 reject 消息之后，RabbitMQ 内部会做下面的逻辑：

消息被投递到 worker_queue-retry(X)，然后 worker_queue-retry(Q) 会接受到这个消息；
worker_queue-retry(Q) 的消息并没有谁会去主动消费，直到消息的 TTL 到期，然后消息被投递到死信 Ex；
消息被投递到 worker_queue-requeue(X)，然后这个 Ex 的消息直接投递到工作队列；
工作队列的消息然后就可以等待被消费，也就是一次重试的完成。

这样实现的好处

这样通过 RabbitMQ 和 Sneakers 的配合，就完成了整个消息的重试机制。这么实现的好处至少有下面几点：

在整个重试过程中，消息不会丢失。不管是 reject 也好，还是 RabbitMQ 内部的 ttl 超时也好，都是可靠的消息投递过程。
Sneakers 的代码实现逻辑非常简单，基本上只需要在出错时判断是否到最大重试次数，然后 reject 或者投递到 error 队列即可。
很好的利用了 ttl 的机制，可以配置消息的重试时间。

是不是也挺简单的？看看代码中如何实现的吧。

Sneakers 源码简析

其实经过上面的分析就能看出来，代码实现其实是非常简单的。我们分两个阶段看，一个是初始化阶段创建各种 Exchange 和队列，一个是消息处理阶段，调用 perform 函数通过捕获异常来做对应的处理。

（下面的代码来自于 sneakers 2.5.0 版本）

初始化

初始化过程就是上面说的建各种队列：

# lib/sneakers/handlers/maxretry.rb
# class Maxretry#initialize

retry_name = @opts[:retry_exchange] || "#{@worker_queue_name}-retry"
error_name = @opts[:retry_error_exchange] || "#{@worker_queue_name}-error"
requeue_name = @opts[:retry_requeue_exchange] || "#{@worker_queue_name}-retry-requeue"
retry_routing_key = @opts[:retry_routing_key] || "#"

# 这里是创建各种 Exchange
@retry_exchange, @error_exchange, @requeue_exchange = [retry_name, error_name, requeue_name].map do |name|
    @channel.exchange(name, :type => 'topic', :durable => exchange_durable?)
end

# 绑定重试队列，注意 x-dead-letter-exchange 和 x-message-ttl 参数
@retry_queue = @channel.queue(retry_name, :durable => queue_durable?,
    :arguments => {
    :'x-dead-letter-exchange' => requeue_name,
        :'x-message-ttl' => @opts[:retry_timeout] || 60000
   })
@retry_queue.bind(@retry_exchange, :routing_key => '#')

# 绑定 error 队列 和 error Ex
@error_queue = @channel.queue(error_name, :durable => queue_durable?)
@error_queue.bind(@error_exchange, :routing_key => '#')

# 注意这里，直接把 worker-queue 和 requeue-exchange 绑定
queue.bind(@requeue_exchange, :routing_key => retry_routing_key)

消息处理阶段

消息处理阶段的逻辑基本都在 handler_retry 函数中，直接贴代码，删了一些日志语句，也加了一点注释。

def handle_retry(hdr, props, msg, reason)
    num_attempts = failure_count(props[:headers]) + 1

    if num_attempts <= @max_retries
      # 还不到最大重试次数时，reject 消息，消息会进入到队列的 x-dead-letter-exchange，也就是 worker_queue-retry(X)
      @channel.reject(hdr.delivery_tag, false)
    else
      # 到达了最大重试次数，就直接把消息发送到 error Exchange 即可
      data = {...).to_json # 这里省略了一些代码
      @error_exchange.publish(data, :routing_key => hdr.routing_key)

      # 然后正常 ack 消息，消息会从 work-queue 消失。
      @channel.acknowledge(hdr.delivery_tag, false)
    end
end

上面这个 failture_count 怎么实现的呢？其实是利用了 RabbitMQ 的特性。RabbitMQ 中，每当消息被「dead-lettered」，在消息的头 x-death 中会详细记录消息死亡的计数信息，大概长这个样子：

我们看看 Sneakers 中的实现：

def failure_count(headers)

    if headers.nil? || headers['x-death'].nil?
      # 看看有没有相关信息
      0
    else
      # 把 x-death 中的相关信息找到，这里要比对 queue 的值
      x_death_array = headers['x-death'].select do |x_death|
        x_death['queue'] == @worker_queue_name
      end

      # 不同 RabbitMQ 版本做了兼容，直接读 count 或者读数组的条目数
      if x_death_array.count > 0 && x_death_array.first['count']
        x_death_array.inject(0) {|sum, x_death| sum + x_death['count']}
      else
        x_death_array.count
      end
    end
end

总结

Sneakers 的重试机制代码虽然非常简单，但是通过利用 RabbitMQ 本身的机制，很完美的解决了 RabbitMQ 消息重试的问题。但是也有下面的一些问题：

对 RabbitMQ 有一定的侵入性，无端增加了非常多的 Exchange 和 Queue，看着有点乱；
通过 ttl 的方式，无法实现阶梯式的重试时间递增，如期望重试间隔是 10s/100s/1h/2h/10h 这样子；

总体来说，Sneakers 这种解决重试的机制仍然是不错的机制，利用中间件本身的特性、加上少量的代码即可实现可靠的消息重试。

欢迎讨论~

Rails 最佳实践 - 定时任务

zamia — Wed, 18 Jan 2017 15:41:12 +0800

开发 Rails 项目中难免遇到一些需要做定时任务的情况，比如每天晚上去跑一些简单的统计，定时更新一下缓存等等情况，虽然是一个简单的事情，可是随着时间的推动，一个项目中的定时任务可能会很多，比如目前我们有一个项目，定时任务有上百条，已经非常的难以管理和容易出问题了。因此，本文简单总结了一些关注点帮助大家理解和规范定时任务的写法。

先简单介绍一下定时任务，定时任务是指那些周期性执行或者某些时刻固定执行的任务，一般来讲大家都熟悉 Linux 系统的 crontab 配置文件，这里面就是常见的定时任务了。Rails 环境下，最简单的定时任务直接利用 rake 或者 rails runner 执行一个命令，然后把命令放到 crontab 配置文件中即可。

对于那些一次性执行的任务，大家都知道应该使用 Job 系统来完成，但是有时候有那种延期执行的任务，这个我个人觉得也不是定时任务应该负责的范畴，一般的 Job 系统，比如 delayed job、sidekiq 等也都提供延时执行的功能，直接使用这些就可以了。所以本文主要指那种周期性执行的任务。

定时任务的职责

就跟一个 Class、一个 method 一样，先确定职责是比较重要的一件事。那么定时任务系统的职责是什么呢？

最初级的做法是直接在 rake task 里面写一通逻辑，直接把任务的主逻辑放在这里。这样的话有一个最明显的问题是难以测试，大家可以 google 一下相关的方案，可以解决，但是较繁琐。

稍好一点的做法是把业务逻辑封装在一个 Service 里面，然后在 task 里面去调用这个 Service。至少这样的话可以解决掉测试的问题。但是这样做还是有一个问题，就是错误处理的问题。一般 task 中的业务逻辑还相对比较复杂，当这个 task 出错了怎么办呢？比如使用 crontab 来执行某个任务，任务出错时一般可能就是记录日志，再根据错误日志做个报警而已。可是很多时候任务的错误处理需要更及时、同时也属于业务逻辑的一部分，由报警系统处理再反馈给业务系统显然很不合理。

所以，目前社区内比较推荐的做法是把定时任务作为一个调度器（scheduler）而存在，定时任务只是一个调度器，真正的业务逻辑都是封装在 Job 中。比如下面这种方式：

# lib/tasks/some_task.rake
task some_task: :environment do
    SomeJob.perform_async # 调用 Sidekiq 的 Job 来异步执行
end

这样的话整个定时任务的代码非常简单，只是充当一个调度器（scheduler）的功能，同时通过使用异步任务的形式还获得了下面的好处：

任务有重试机制。一般的 Job 都可以很简单的配置重试机制，保证了最终 Job 一定会被成功执行。即使有 bug，修复上线之后无需维护，下次重试的时候就可以正常完成任务，非常方便。
任务有更实时的错误处理机制。比如大鱼内部有一种 Job，在多次重试失败之后需要更改某个 ActiveRecord 的状态为 fail。这种情况通过 Job 的形式就非常方便了。

比如 Job 大概长这样（拿 Sidekiq 举例）：

# app/jobs/some_job.rb

class SomeJob
  include Sidekiq::Workder

  sidekiq_retries_exhausted do |job, e|
    process_failure_job(job, e)
  end

  def perform
    # 正常业务逻辑
  end

  def process_failure(job, error)
    # 多次重试失败后的处理逻辑
  end
end

总之，定时任务书写的时候应该是轻量级的，最好是与 Job 系统联合使用，定时任务只是作为一个调度器，Job 系统来真正执行业务逻辑。

定时任务的部署

rails 社区中大家使用最多的部署方案就是 whenever + linux crontab 方案了，这种方案简单来说也没太问题，简单易用。但是随着项目的复杂度增加，我不太推荐这种部署方案，主要基于以下理由：

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

一个 web 应用也期望都以一个或多个无状态的进程来运行的形式来运行，从这个角度上来讲，也应该以一个独立进程来运行 cron 任务，而不是依赖于系统的 cron 组件。

那么有没有好的方案呢，其实方案有挺多的，都可以解决问题，比如：

还有一类是 Job 系统的插件形式，但是也可以以独立进程来运行，我没有实践过，应该也差不多：

下面以 crono 来例简单示例一下定时任务的写法，也非常简单。

# Gemfile
gem 'crono', '~> 1.1', '>= 1.1.2'

# config/cronotab.rb
class HourlyPerformSomething
    def perform
        SomeModel.pending.each {|s| SomeJob.perform_async(s.id) }
    end
end

Crono.perform(HourlyPerformSomething).every 1.hour

执行时：

bundle exec crono RAILS_ENV=production

总结

简单总结下就是下面的 2 条吧：

优先把定时任务当做调度器使用，主要业务逻辑通过 Job 系统来完成。特别是不要在 rake 任务中写执行大量的业务逻辑，会造成难以测试、无法重试和错误处理的问题。
优先使用独立的进程来管理定时任务，而不是依赖于 Linux 系统的 crontab。这样的好处是更具有移植性、更易运维。

欢迎讨论~

Rails 最佳实践之配置管理

zamia — Sun, 15 Jan 2017 00:28:16 +0800

大家日常开发 Rails 项目的过程中一定会遇到些配置项（Configuration)，随着配置越来越多，总归需要管理起来，那么如何管理这些配置呢？本文期望梳理一下，找到一个较好的解决方案。

（其实是我们自己项目中的配置文件非常多且乱，所以力图找到一个好的方法来管理，从最终效果来看，这种方法应该是比较合理的，拿来跟大家分享。）

先放结论：

应用配置统一使用 settings.yml 来管理；
每一个资源配置（数据库、redis、第三方 API）使用独立的配置文件管理；
资源配置中的敏感信息要使用环境变量管理；

如果不太理解的话可以往下看，如果项目中已经这么做了，不用浪费时间~

配置的简单分类

先把如何管理放在一边，看看配置都包括哪几个类别：

Rails 基础配置 (Framework Configuration) 比如 Rails 需要配置 session store 的地址、asset host、action mailer 等等，这些配置都集中在 /config/application, 不同的环境放在 config/environments下面。
应用配置（Application Configuration) 比如分页时每页的条数，开发环境数据不多，每页 10 条，线上环境需要 50 条。那这个分页条目就是简单的一项配置了。还有一些比如开关类的配置，临时加一个开关，到了固定的时候开启某些功能，都属于典型的应用配置。
资源配置（Resource Configuration） Rails 项目本身应该是无状态的（Stateless），所有的资源都应该独立通过配置的形式体现。比如数据库就是一种资源（Resource），像 Redis、ElasticSearch 都可以认为是一种资源。另外，我们把第三方服务也称为资源，比如项目中需要访问第三方 API，那么这个 API 我们也认为是一种资源。

Rails 的基础配置无需多说，大家应该都很熟悉了，基本上 Rails 都已经做好了样例，按照样例配置就可以了。比如 config/application.rb 可能会有这些东西：

config.autoload_paths += Dir["#{config.root}/app/utilities/"]
config.i18n.default_locale = "zh-CN"
config.active_job.queue_adapter = :sidekiq
config.time_zone = 'Beijing'

所以下面直接说说应用配置和资源配置。

应用配置

简单版本

最常用的方法其实是在 config 目录下面写一个 settings.yml 的文件，比如：

# config/settings.yml
default: &default
    page_size: 10
    enable_some_feature: false

development:
    <<: *default

production:
    <<: *default
    page_size: 100
    enable_some_feature: true

然后添加一个 initializer 来加载它：

# config/initializer/load_settings.rb
$settings = YAML.load_file("#{Rails.root}/config/settings.yml")[Rails.env].symbolize_keys

# use config in somewhere
logger.debug $settings[:page_size)

config_for 版本

Rails 4.2 以后也提供了简单的方法来加载配置：

# config/application.rb
$settings = config_for(:settings)

使用 config_for 可以自动加载对应 RAILS_ENV 的配置，还可以加载 ERB 内容，所以尽量使用 config_for 来加载配置。

但是上面两种方法本质差不多，也可以这样用，不过稍微也有一些不方便的地方：

使用不太方便，都是字符串做 key，如果使用 symblolized_keys 的话又不支持级联；
手动加载时不能使用 ERB，比如加载环境变量等。

使用 gem - railsconfig/config

这个 gem 稍微升级了一下，做了方便使用的改动，比如自动支持多环境、支持 ERB、支持『.』调用，还可以多级调用。使用也比较简单，一看文档即知。

# Gemfile
gem 'config'

# 执行下面的命令，会生成一些模板
# rails g config:install

# 调用时
logger.debug Settings.some_config.other_config

这个 Gem 使用起来很方便，所以我们推荐应用配置均使用 setting.yml，不同的环境的文件放到 settings 目录，这些内容并不包含敏感信息，因此可以放心的 checkin 到 git 库中。

config/settings.yml
config/settings/production.yml
config/settings/development.yml
config/settings/test.yml

资源配置

资源配置会稍微麻烦一些，先说下什么是资源。以下内容来源于 12factor:

把后端服务 (backing services) 当作附加资源。
后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库，消息/队列系统，SMTP 邮件发送服务，以及缓存系统。
类似数据库的后端服务，通常由部署应用程序的系统管理员一起管理。除了本地服务之外，应用程序有可能使用了第三方发布和管理的服务。
12-Factor 应用不会区别对待本地或第三方服务。对应用程序而言，两种都是附加资源，通过一个 url 或是其他存储在配置中的服务定位/服务证书来获取数据。

因为后端服务通常由系统管理员（运维同学）来统一管理，运维架构对于开发工程师来讲可能是透明的，比如一个数据库地址，可能是一组集群，管理员只会提供一个入口的 vip 而已。

明白了什么是资源之后，我们就把资源相关的配置也分为两类：

非敏感信息，一般也是开发工程师可以感知的信息。比如一个 API 的地址；
敏感信息，一般不对开发工程师开放。比如一个 API 的认证信息；

resource.yml.example 的方式管理

对于资源类的配置，Rails 默认的做法是采用 resource.yml，但是在 git 库中使用 resource.yml.example 的形式。

比如 rails 项目产生开始就会产生一个 database.yml.example，一般我们通过修改这个文件，然后 copy/move 一份 database.yml 出来使用。

这种方式有几个问题，12factor 也有详细描述；

随着资源越来越多，这类的 yml 越来越多，管理起来比较麻烦；
每次添加一个资源都添加 yml 的方式很容易漏掉，导致敏感文件加入了 git 库；
跟语言绑定，无法跨语言使用等；

使用 yml + 环境变量来管理资源类配置

虽然 12factor 中推荐应用配置存储在环境变量中，但是我们更近一步，只把资源配置中的敏感信息存储在环境变量中，而非敏感信息仍旧存储在 yml 中。

这样的话配置的目录大概是这样：

# 配置相关目录结构
rails-app
  config
    mongo.yml
    redis.yml
    rabbitmq.yml
    mail_api.yml
.env

一个资源的配置文件大概是这样：

# mongo.yml
default: &default
  host: ENV["MONGO_HOST"]
  port: ENV["MONGO_PORT"]
development:
  <<: *default
  database: mongo_development
production:
  <<: *default
  database: mongo_production

.env 文件大概是这样子的：

# .env 文件
MONGO_HOST=127.0.0.1
MONGO_PORT=27017

通过结合 yaml 文件和 env 文件，资源的配置被分割为敏感信息和非敏感信息，所有的 yml 都可以安全的 checkin 到 git 库中，而 .env 文件是在部署的时候由运维工程师通过使用一些自动化工具来部署到线上环境。

因为 .env 文件在 rails 环境中无法做到自动加载，因为我们还需要一个 gem 来辅助：

# Gemfile
gem 'dotenv-rails', require: 'dotenv/rails-now'

通过使用 dotenv 这个 Gem，可以做到很方便的自动加载 .env 文件，它甚至可以自动根据 Rails Env 来加载 .env.production 这样的配置，不过我们不需要这个功能，只需要一个 .env 就可以了。

然后就可以很方面的加载资源类的配置了：

# config/application.rb 中添加
config.redis = config_for(:redis)

# 在 config/initializer/load_redis.rb 中就可以使用了:
$redis = Redis.new(Rails.configuration.redis)

另外，如果资源类文件较多，也可以把所有的资源类的配置统一放在一个目录下，这样就更清晰了。

# config/application.rb

# 所有的资源配置放在 config/resources 下面
config.redis = config_for("resources/redis")

这样就基本完成了，这样使用 yml + env 的方式的好处包括：

所有的 yml 都可以安全的 checkin 到 git 库中了，里面不再包含敏感信息；
一些非敏感的字段在 yml 中给开发工程师来集中管理，这样 env 变量就比较少了；
部署的时候线上只需要一个 .env 就可以搞定所有的资源类的配置了；比如 capistrano 只需要 link 这一个文件即可。

总结

虽然配置管理是一个小事情，但是随着项目越来越复杂，调用的第三方服务越来越多，如果不好好进行规划，配置比较混乱，同时也容易出现安全事故（安全无小事啊！）

总结一下：

应用配置，我们通过 config 这个 gem，统一存储在 settings.yml 中，通过 Settings 对象来调用。
资源配置，基本的资源配置统一存储在 config/resource.yml 中，通过 config_for 来加载；
资源配置，敏感类信息通过存储在 .env 文件中，在部署时由运维进行管理，dotenv 来加载到 ENV 变量中；

以上~欢迎讨论和吐槽

Draper 使用帮助 (即 draper README 翻译)

zamia — Sun, 28 Feb 2016 18:27:43 +0800

本来想写一篇小文章来解释 decorator 的使用，发现 draper 这个 gem 的 readme 写的很赞，不只是说明了 gem 的使用，还清晰的解释了为什么要使用 decorator，什么情况下使用 decorator，所以花了几个小时翻译了一下，方便喜欢看中文的同学~

rails 本身的 helper 的主要问题是全局命名空间以及调用不方便，draper 使用了 decorator 设计模式，通过面向对象的方法来对原有的 model 进行封装。这个 gem 也非常强大，如果是一个生命期较长的 rails 项目的话，强烈推荐使用 draper 来封装 model 的 view 逻辑来代替 helper。

发现翻译文章比写一篇还累啊~~

============== 我是分割线 ============

Draper: View Models for Rails

Draper 使用『面向对象』的方式，给 Rails 添加了独立的视图层。

在不使用 Draper 的情况下，类似功能只能通过添加一个 helper 或者给 model 添加一堆逻辑来实现，而使用 Draper 之后，通过对视图逻辑进行封装，使代码组织更清晰，也更易于测试。

为什么使用装饰器？

比如你的应用中有一个 Article 模型，使用 Draper 之后，可以创建一个对应的 ArticleDecorator，这个 decorator 封装了 model 对象，并且只封装了视图相关的逻辑。在 controller 中，在传递给 view 层之前，我们可以先装饰一下 article 模型：

# app/controllers/articles_controller.rb
def show
  @article = Article.find(params[:id]).decorate
end

这样在 view 层使用装饰过的 model 和直接使用 model 基本上没有任何区别。但是，任何时候，如果你开始在 view 中写一堆逻辑、或者你想写一个 helper 方法的时候，就可以通过在 decorator 中实现一个方法来代替。

下面的例子演示了如何把一个 helper 方法转成 decorator 方法。假如目前有一个 helper 方法长这样：

# app/helpers/articles_helper.rb
def publication_status(article)
  if article.published?
    "Published at #{article.published_at.strftime('%A, %B %e')}"
  else
    "Unpublished"
  end
end

这样写完就会觉得很别扭，publication_status 的命名空间是全局的，它在所有的 controllers 和 views 中均可以调用。然后，过了一段时间，当你想实现一个 Book 对象的 publication status 的时候，并且要求 book 的日期格式跟 article 不一样。怎么整？

两个办法。要么通过传入参数的类型来判断对象的类型（Ruby 并不是静态类型的语言，所以需要在函数体来判断），然后实现不同的逻辑；要么把这个方法拆成两个方法，book_publication_status 和 article_publication_status。随着项目不断变大，需要持续添加方法到全局的命名空间，调用的时候也必须记住所有的函数名。额，ugly……

这时候，需要使用面向对象的思维。假如你不知道 rails 有个东西叫 helper，你可能想着能这样调用就好了：

<%= @article.publication_status %>

假如没有 decorator，那么就得在 Article 模型中实现这个 publication_status 这个方法，但是这个方法呢，本身又属于视图逻辑，并不属于模型层的逻辑。

所以，更好的方法呢，是实现一个 decorator：

# app/decorators/article_decorator.rb
class ArticleDecorator < Draper::Decorator
  delegate_all

  def publication_status
    if published?
      "Published at #{published_at}"
    else
      "Unpublished"
    end
  end

  def published_at
    object.published_at.strftime("%A, %B %e")
  end
end

在 publication_status 方法内，我们使用了 published? 方法，这个方法从哪来的？其实它是在 Article 中定义的。得益于 delegate_all 调用，Article 中的方法可以无缝的在这个 decorator 中使用。

decorator 有一些别名，比如 "presenter"，"exhibit"，"view model"，也有直接叫 "view" （这样的命名约定下，Rails 中的 views 应该叫 templates）的。不管叫什么，使用面向对象编程来代替 helper 这种面向过程编程，都是非常棒的方法！

综合来说，遇到下面这些情况时，Decorators 尤为合适：

格式化复杂的数据显示给用户；
实现模型对象中常用的展示逻辑时，比如由 first_name 和 last_name 合并生成 name 这种情况；
封装一些对象的属性，比如把 url 属性变成一个超链接。

安装（Installation）

添加 Draper 到 Gemfile:

gem 'draper', '~> 1.3'

然后在应用的根目录下执行 bundle install 即可。

如果是从 0.x 的版本中升级而来，主要的变更在 wiki 中有详细说明。

实现装饰器（Writing Decorators）

Decorators 继承自 Draper::Decorator，一般放入 app/decorators 目录，并且命名保持和相应的模型一致：

# app/decorators/article_decorator.rb
class ArticleDecorator < Draper::Decorator
# ...
end

生成器

引入 draper gem 之后，当使用 rails 生成一个 controller 时：

rails generate resource Article

也会自动生成一个 decorator，非常方便！！

如果 Article 模型已经存在的话，也可以直接执行：

rails generate decorator Article

来创建一个 ArticleDecorator。

调用 Helper 方法

一般的 rails helper 方法还是不可避免的要使用，不管是 rails 内置的 helper，还是 app 内自定义的 helper，通过 h 对象即可调用：

class ArticleDecorator < Draper::Decorator
  def emphatic
    h.content_tag(:strong, "Awesome")
  end
end

嗯，如果觉得总是写一个 h. 很麻烦，可以在 Decorator 类中添加：

include Draper::LazyHelpers

那么会自动 mixin 很多 helper 方法，也就不再需要写 h. 了。

（注意：capture 方法必须通过 h 或者 helpers 来调用）

调用 model 中的方法

当 decorator 中需要调用 model 中的方法时，除了下面会提到的 delegation 的方式，任何时候都可以通过 object 对象（或者 model 对象）来调用。

class ArticleDecorator < Draper::Decorator
  def published_at
    object.published_at.strftime("%A, %B %e")
  end
end

使用装饰器（Decorating Objects）

单个对象的装饰

好，现在写完一个装饰器了，如何使用呢？最简单的办法是调用 model 的decorate 方法：

@article = Article.first.decorate

这种方式通过命名约定来自动推断应该使用哪个装饰器类。假如需要更灵活的使用，比如使用 ProductDecorator 装饰了一个模型 Widget，可以直接调动装饰器类：

@widget = ProductDecorator.new(Widget.first)
# or, equivalently
@widget = ProductDecorator.decorate(Widget.first)

集合的装饰

装饰集合中的所有对象

如果要装饰一个对象的集合，可以一次性装饰所有的对象：

@articles = ArticleDecorator.decorate_collection(Article.all)

假如集合是一个 ActiveRecord 查询，也可以直接这样使用：

@articles = Article.popular.decorate

注意： 在 Rails 3 中，.all方法返回的是一个数据，所以不能使用 Article.all.decorate 这种方法。但是，Rails 4 中，.all 方法返回的是一个 query 对象，所以可以用这种方法。

装饰集合本身

如果想给一个集合本身添加一些方法（比如，用于分页），那么可以继承 Draper::CollectionDecorator ：

# app/decorators/articles_decorator.rb
class ArticlesDecorator < Draper::CollectionDecorator
  def page_number
    42
  end
end

# elsewhere...
@articles = ArticlesDecorator.new(Article.all)
# or, equivalently
@articles = ArticlesDecorator.decorate(Article.all)

Draper 使用 decorate 方法来装饰每个对象，你也可以通过覆盖集合装饰器的 decorator_class 方法来改名，或者传递一个 :with 参数给构造器。

使用分页

有些分页的 gem 会添加一些方法到 ActiveRecord::Relation，比如 Kaminari 的 paginate 方法需要集合实现 current_page, total_pages, and limit_value 这些方法。为了导出这些方法给一个集合类的装饰器，可以把这些方法 delegate 到 object 对象：

class PaginatingDecorator < Draper::CollectionDecorator
  delegate :current_page, :total_pages, :limit_value, :entry_name, :total_count, :offset_value, :last_page?
end

这里的 delegate 是 Active Support 中的 delegate 方法是相同的，除了参数 :to 是可选的，不传递时默认 delegate 到 :object 对象。

will_paginate 需要下面这些方法被 delegate :

delegate :current_page, :per_page, :offset, :total_entries, :total_pages

装饰相关联的对象

当主模型被装饰时，可以自动装饰相关联的对象。比如，Article 模型有一个相关的对象 Author 时：

class ArticleDecorator < Draper::Decorator
  decorates_association :author
end

当 ArticleDecorator 装饰一个 Article 时，draper 会自动使用 AuthorDecorator 来装饰 Author 对象。

装饰 Finders

还可以在 decorator 中调用 decorate_finders 方法：

class ArticleDecorator < Draper::Decorator
  decorates_finders
end

这样，当在 decorator 调用 finder 类方法时，可以直接返回一个装饰过的对象：

@article = ArticleDecorator.find(params[:id])

什么时候使用装饰器？

理论上，装饰器是和它所装饰的对象行为上是很接近的，所以，看起来在 controller 的 action 方法一开始就装饰这个对象，然后一直使用这个装饰器对象就行了。

别这么干！

因为，装饰器本质上就是为了给 view 层使用的，所以只应该在 view 层使用装饰器。先准备好 model，然后在最后一刻开始装饰它们，然后紧接着在 view 中使用它们。这样的话，就避免了很多尝试修改装饰器对象而导致的诸多隐患。

为了让装饰器对象只读，draper 也提供了 decorates_assigned 方法给 controller。它添加了一个 helper 方法，会自动返回一个装饰过后的对象：

# app/controllers/articles_controller.rb
class ArticlesController < ApplicationController
  decorates_assigned :article

  def show
    @article = Article.find(params[:id])
  end
end

decorates_assigned :article这个语句基本上等同于：

def article
  @decorated_article ||= @article.decorate
end
helper_method :article

也就是说，只需要在 views 中调用 article 方法（取代常用的 @article 对象），就可以直接得到一个装饰后的 @article 对象。而在 controller 中，可以继续使用 @article 变量来进行各种逻辑操作，比如 @article.comments.build 可以创建一个 comment。

测试 (Testing)

Draper 支持 Rspec，MiniTest::Rails 以及 Test::Unit，并且生成 decorator 的时候会自动创建一些测试用例。

Rspec

spec 测试文件一般放在 spec/decorators 中。如果放在另外一个目录，那么需要使用 type: :decorator来标记它们。

在 controller 测试中，可能会想判断一个实例变量是否被正确的装饰了。可以使用下面这些 matchers 来判断：

assigns(:article).should be_decorated

# 或者，下面这样可以显式的指定装饰器类
assigns(:article).should be_decorated_with ArticleDecorator

另外，model.decorate == model，所以，添加 decorator 之后，已经写好的 specs 应该仍然可以通过测试。

Spork 用户

在 spec_helper.rb 文件中的 Spork.prefork 段，需要添加下面的代码：

require 'draper/test/rspec_integration'

独立测试装饰器

在测试中，Draper 会创建一个 view 的上下文环境来存取 helper 方法。默认情况下，Draper 会创建一个 ApplicationController，然后在 view 的上下文中使用它。假如你想通过测试每一个组件来加入测试，那么可以通过添加下面的代码到 spec_helper 或者类似文件中来删除这种依赖：

Draper::ViewContext.test_strategy :fast

这样的话，装饰器就不再能够存在应用的 helper 方法，如果需要有选择的引入一些 herlper 方法，可以传递一个 block 给这个方法：

Draper::ViewContext.test_strategy :fast do
  include ApplicationHelper
end

Stub 路由相关的 helper

假如需要写一些依赖于 routes helper 的装饰器方法，那么可以 stub 这些路由，而无需引入 Rails。

假如你在使用 Rspec，minitest-rails 或者 minitest 中 Test::Unit 语法，那么可以直接使用 helpers 对象在你的测试中，因为这些测试是继承自 Draper::TestCase。假如你在使用 minitest 的 spec 语法，并且没有使用 minitest-rails，可以显式的引入 Draper 的 helpers：

describe YourDecorator do
  include Draper::ViewHelpers
end

然后，就可以使用你熟悉的方式来 stub 一些路由的 helper 方法了（下面的例子使用了 Rspec 的 stub 方法）：

helpers.stub(users_path: '/users')

高级使用技巧（Advanced Usage）

共享装饰器方法

可能会遇到多个装饰器都有类似方法的情况，因为装饰器就是一个 Ruby 对象，所以完全可以使用常用的 Ruby 的技巧来共享相关功能。

比如，Rails 控制器中，一般的 Controller 都是继承自 ApplicationController，可以在装饰器的实现中也使用类似技巧：

# app/decorators/application_decorator.rb
class ApplicationDecorator < Draper::Decorator
# ...
end

然后，让所有的装饰器都继承自这个 ApplicationDecorator，不再直接继承自Draper::Decorator：

class ArticleDecorator < ApplicationDecorator
  # decorator methods
end

只 delegate 指定的方法

当装饰器调用 delegate_all 的时候，所有被调用的方法如果没有在装饰器中定义，那么都会委托至原有的 model 对象。这样有点过度了~

所以如果想严格控制哪些方法可以在 view 中被调用，那么可以只 delegate 部分方法到 model 中：

class ArticleDecorator < Draper::Decorator
  delegate :title, :body
end

我们省略了参数 :to ，这样的话，默认委托至 object 对象。

也可以选择委托至其他对象：

class ArticleDecorator < Draper::Decorator
  delegate :title, :body
  delegate :name, :title, to: :author, prefix: true
end

这样，在 view 的模板中，假如 @article 已经被装饰过，那么可以像下面这样使用：

@article.title # 返回 the article's `.title`
@article.body  # 返回 the article's `.body`
@article.author_name  # 返回 the article's `author.name`
@article.author_title # 返回 the article's `author.title`

传递上下文

假如需要传递额外的数据给装饰器，可以在创建装饰器的时候，使用一个 context 参数来传递数据。比如：

Article.first.decorate(context: {role: :admin})

传递给 :context 参数的数据，在装饰器中可以通过 context 方法来获取。

假如使用了 decorates_association，那么主模型的上下文数据会传递给相关的对象。也可以覆盖这个 :context 参数：

class ArticleDecorator < Draper::Decorator
  decorates_association :author, context: {foo: "bar"}
end

或者，如果希望修改主模型的上线文数据，可以使用 lambda 表达式：

class ArticleDecorator < Draper::Decorator
  decorates_association :author,
    context: ->(parent_context){ parent_context.merge(foo: "bar") }
end

指定装饰器类

当使用 decorates_association时，Draper 使用 decorate 方法来装饰每一个关联对象，假如想使用一个不同的类来装饰，可以使用 with参数：

class ArticleDecorator < Draper::Decorator
  decorates_association :author, with: FancyPersonDecorator
end

如果是一个集合的关联（比如 has_many），可以传递一个 CollectionDecorator 的子类，这样的话会装饰整个集合；或者传递一个 Decorator 的子类，这样的话会装饰每一个集合内的对象。

限定 association 的范围

如果期望被装饰的关联对象被排序、限定个数或者其他限定，可以传递 :scope 参数给 decorates_association，这样的话，这个方法会在对象装饰之前被调用：

class ArticleDecorator < Draper::Decorator
  decorates_association :comments, scope: :recent
end

代理类方法

如果想代理类方法给模型类，包括使用 decorates_finders 的时候，Draper 必须要知道具体的模型类是什么。默认情况下，Draper 默认你的装饰器被命名为 SomeModelDecorator，然后会代理所有的未知方法给 SomeModel。

如果，命名不符合约定，Draper 无法推导出相应的模型类，则需要显式的调用 decorates 方法：

class MySpecialArticleDecorator < Draper::Decorator
  decorates :article
end

这仅仅当需要代理类方法的时候才需要。

使模型可以被装饰

模型对象通过 mixin Draper::Decoratable 模块来获得 decorate 方法，这个行为默认在 ActiveRecord::Base 和 Mongoid::Document 中被引入。

所以如果你使用了其他 ORM（包括 3.0 版本之前的 Mongoid），或者想装饰普通的 Ruby 对象，那么需要显式的 include 这个模块。

贡献者

Draper was conceived by Jeff Casimir and heavily refined by Steve Klabnik and a great community of open source contributors.

核心开发者

Jeff Casimir (jeff@jumpstartlab.com)
Steve Klabnik (steve@jumpstartlab.com)
Vasiliy Ermolovich
Andrew Haines

Ruby 异常处理最佳实践

zamia — Thu, 25 Feb 2016 19:29:00 +0800

『异常处理』是个比较容易忽视的话题，特别是 ruby/rails 圈，很多写了很久代码的同学恐怕都没有怎么写过异常处理的代码。实际上，异常处理还是挺重要的，想写出『健壮』的代码，必须得了解清楚异常的机制以及异常处理的最佳实践。

关于异常处理，问题无非是下面几个，并且各个高级语言的异常处理大同小异，使用上没有太大区别：

异常是为了解决什么问题而出现的？
异常都有哪些类型？分别应该怎么应对？
什么时候需要使用异常？什么时候需要捕获异常？
使用异常的最佳实践有哪些？

这篇文章并不会说明 ruby 异常的语法啊使用啊什么的，只是尝试回答上面的问题，期望让大家对异常有一个更深入的认识，不过我自己对异常的认识也没有那么深刻，所以有不对的地方，欢迎指出。

另外，文后的参考文章中都讲的很不错，推荐阅读。

为什么要使用异常（Exception）？

有些语言本身不提供异常机制，比如 C 语言，那么方法/函数之间的通信一般是用错误码（error code）来实现（可以自行 google 一下 error code vs exception），后来慢慢的高级语言中的 Exception 才成为标配。一般新的特性的出现总是为了解决某些问题的，Exception 解决了什么问题，或者说它带来了哪些好处？

Exception 可以附带更多的信息

错误码一般是全局预定义好的一批，然后进行一些归类，系统中所有的函数统一使用这些错误码，函数出现异常的时候使用错误码来告知调用方有异常出现。每一个错误码对应一个唯一的信息。

而异常这种方式本质上是一个类/对象，那么异常本身就可以被继承、被封装，也可以添加自己的方法，自己的属性，所以它的信息量就会更大、更灵活；
Exception 处理是跳跃式的

这个应该是最重要的特性，支持异常处理的语言中，异常被抛出之后，程序的运行逻辑直接跳到相应的 catch 这个异常的地方继续执行。这中间可能经过了多次的函数调用，但是并不影响异常的执行。

这条规则的好处在于，不用所有的函数都要考虑去捕获异常，只要在某个清楚知道如何处理改异常的地方去处理就好了。
Exception 的机制很清晰的独立了异常处理的代码和正常的业务逻辑

因为 throw/catch 的机制，所以可以很清晰的独立开异常处理的逻辑和正常的业务逻辑，这个比较容易理解。

什么时候应该使用异常？

新手一般很难搞清楚异常到底是怎么定义的，什么情况下应该算是『异常』？是不是每遇到一个什么错误都应该抛一个异常？

首先，异常一般指下面三种情况：

程序错误

也就是程序写的有问题，比如 java 中最常见的 NullPointerException, ruby 中的 ZeroDivisionError、NoMethodError 等等。

这类错误一般不用去捕获，一旦发生时让程序挂起即可。通过一些测试和 debug，找到相应的问题修正代码逻辑即可。比如 NullPointerException，那么通过计算或者处理下标，把下标控制在 size 的范围内即可。
调用方式不正确导致的错误

每一个函数/类/URL，某种程度上，都可以理解为是一种 API，是调用方和实现方的接口。如果调用方传入了不符合约定的参数，就会导致错误发生。比如典型情况，参数需要一段 XML，但是传入的参数并不是一个有效的 xml，就会导致一个异常发生。

这种情况下，最好的处理方式是告知调用方哪里出错了，这样 client 就可以去重试。可以通过异常机制处理，也可以通过简单的 if/else 去处理。
运行时资源出现异常

这种是最多的情况，一般需要处理的异常大多是这种情况。比如网络调用时网络不通了、申请内存时系统没有内存了，都属于『运行时资源异常』的情况。

这时一般是通过抛异常的形式，由底层抛出异常，在业务层重新封装并提供合适的信息，最终由上层去处理。

使用异常的最佳实践

使用异常的最佳实践不太好总结，其实只有是两个问题最重要：

我要不要抛一个异常？
要不要捕获某个异常？

所以，在编码的时候，每当需要 raise 或者 catch 一个异常，就可以想想这两个问题，然后用下面的原则来判断，相信会得到更好的答案。

什么时候抛一个异常？

参数校验可以提前做，避免不必要的异常

比如在用户注册时，可能手机号已经被注册过了，昵称被占用了，这种情况很有可能发生，一般情况下直接使用参数校验，然后返回给客户端即可，无需使用异常。

这种情况，属于上面的参数错误，这种情况一般通过参数的校验，提前返回效果更好。
有时候应该属于正常的业务逻辑，不应该使用异常

比如电商系统中，预订某件商品的时候一定会遇到库存不足的情况，这种情况应该先判断库存是否足够，库存不足的时候直接返回即可。这种情况一般是不需要使用异常来进行处理的。

这种处理方式也更接近于 ruby 的哲学，比如 java 中数组越界会提示 NullPointerException，但是 ruby 中直接返回 nil，表示没有这个值。
编程错误，一般需要 raise 异常

比如常见的父类的虚函数，一般也会在父类中定义一个接口：
```
class Parent
    def foo
        raise NotImplementedError, "need implementation in child class"
    end
end

class Child
    def foo
        "bar"
    end
end
```
这种时候，如果写程序的时候调用了父类的 foo 函数，直接抛出异常。
框架内的某些特殊约定，使用异常才能完成某项功能

比如：

* rails 事务中，需要抛出异常，事务才会回滚； * sneaker 中，需要抛出异常，消息才不会被消费，然后可以重试；

发生资源异常时，一般业务层需要『转译』异常

日常工作中，我们很少需要写很底层的库，而资源类的异常一般是比较底层的库抛出的，比如网络异常、文件系统异常、内存异常、锁异常等。对于日常写的更多的业务层的代码，一般会把这类异常进行转译（把原来的异常封装一下，更换为一个新的类）。这样的好处在于可以提供更多的信息，也可以更好的对类做分层（上层的代码只会依赖于紧邻的下一层）。

一个简单的例子来自于 rails/active_record 的源码，我们知道 ar 封装了很多读取数据库的 API，比如下面的代码在数据库连接不可用的时候会抛出异常：
```
class Order < ActiveRecord::Base
end

# 此时，数据库挂掉的话，调用 find 会发生什么？
o = Order.find(12345)
```
异常打出的提示是这样的：

ActiveRecord::StatementInvalid: Mysql2::Error: Lost connection to MySQL server during query: SELECT orders.* FROM orders WHERE orders.id = 5 LIMIT 1

可以很明显的看到，Mysql2 gem 抛了一个异常，ActiveRecord 对它进行了『转译』。

不过 ruby 不支持异常的直接封装，所以转译的时候只能把 message 给封装进来。下面是 rails 的实现：
```
# active_record/connection_adapters/abstract_adapter.rb，省略了部分代码
def log(sql, name = "SQL", binds = [])
  @instrumenter.instrument(....) { yield }
rescue Exception => e
  message = "#{e.class.name}: #{e.message}: #{sql}"
  exception = translate_exception(e, message) # 转译异常
  exception.set_backtrace e.backtrace # 存储 backtrace
  raise exception
end

def translate_exception(e, message)
  # override in derived class
  ActiveRecord::StatementInvalid.new(message)
end
```

不过什么时候抛出异常，争议也比较多，最基本的前提是在一个系统内保持一致的行为。如果约定某些情况下抛出异常，那么整个系统都应该抛出异常。

什么时候需要捕获异常？

这个原则上就比较简单了，只有在『你有能力处理的时候才去捕获异常』，否则就不要去捕获。

如果再细节一点的话，可能下面的一些原则可以帮助写出更健壮的程序：

不要直接吞掉异常

就是 rescue 之后什么也不错，事实上，这种情况还经常出现。如果真觉得应该在这一层捕获异常，那么至少打点日志吧。（有了日志，运维同学才可以监控、可以报警啊喂）
```
begin
    do(something)
rescue => e
    Rails.logger.error("something is wrong: #{e.message}")
    Rails.logger.debug e.backtrace.join('\n')
end
```
尽量捕获更细节的异常，不要直接捕获 Exception 这种顶级异常

也就是上面的原则，能处理什么异常就捕获什么异常。异常机制的最终目的是进行某种程度的 recovery，所以只对自己能处理的异常进行捕获即可。
异常也是普通的类，所以也应纳入到分层体系中去

也就是上面提到的『转译』异常，比如在业务层，可能需要对异常进行封装，然后由上层来捕获。而不是直接由上层的代码直接捕获底层的异常。

一般来说，资源类的错误是在实现层去触发，在中间层进行转译，然后在上层进行捕获和处理。

异常的使用本身就有一些争议，但是日常工作中肯定避免不了使用异常，所以还是要对异常有一定的理解的，异常也能帮助大家写出更健壮的程序~

以上。

参考文章

Rails 中乐观锁与悲观锁的使用

zamia — Sat, 06 Feb 2016 17:25:00 +0800

简介

只有有资源的争用就少不了使用各种锁，包括关系数据库中使用的悲观锁和乐观锁，分布式系统中的分布式锁（比如使用 zoo keeper 或者 redis 等实现），MRI ruby 中也存在 GIL(global intepreter lock)，mongodb 中也存在全局锁、database-level 锁和 collection-level 锁等等。

本文主要讲我们日常开发中很大可能会用到的两种锁：

悲观锁。悲观锁采用相对保守的策略，在资源争用比较严重的时候比较合适。悲观锁在事务开始之前就去尝试获得写权限，事务结束后释放锁；也就是说对于同一行记录，只有一个写事务可以并行；
乐观锁。乐观锁是在提交事务之前，大家可以各自修改数据，但是在提交事务的时候，如果发现在这个过程中，数据发生了改变，那么直接拒绝此次事务提交。乐观锁适合在资源争用不激烈的时候使用。

Rails 提供了很好用的 API 来帮助开发者分别去使用这两种锁，写起来很简单（写完之后我都怀疑写这篇文章是否有必要了，大家随意看看），不过对于一些新手同学可能有帮助。

悲观锁

常用场景

一般对于资源的争用都可以使用悲观锁，比如电商系统中涉及到订单的部分，比如用户支付完成后可能会同时有多条支付成功的通知（做过支付的都知道一般有同步通知和异步通知），比如订单改价的同时可能用户正在支付等等，对于这种会对订单状态发生改变的操作，我们内部一般对这种操作都做加锁处理。

使用

rails 的 API 文档中有详细的说明：

# select * from accounts where id=1 for update
Account.lock.find(1)
# 注意，这种最终会导致一个行锁

# select * from accounts where name = 'shugo' limit 1 for update
Account.where("name = 'shugo'").lock(true).first
# 注意，这里可不是行锁，这里会是一个表锁

注意上面的区别，mysql innodb 里面，对于 "select * from where xxx for update" 的情况，是会锁住整张表的，所以最好不要这样来用。Rails 也提供了一个很方便的方法 with_lock 来锁住单个记录，并且内嵌在事务之中。下面代码中的两段是等价的：


account = Account.find(1)
Account.transaction do
    account.lock!
    account.balance -= 100
    account.save! 
end

# 和下面是等价的

account.with_lock do
    account.balance -= 100
    account.save!
end

乐观锁

常用场景

悲观锁出错概率小，因为一旦获得锁，其他进程会堵塞，但是也导致速度会受影响，系统开销比较大，不利于并发。乐观锁适用于资源竞争不是那么多的地方，这样系统的开销较小，速度也比较快。

乐观锁本质上算是一个利用多版本管理来控制并发的技术，如果事务提交之后，数据库发现写入进程传入的版本号与目前数据库中的版本号不一致，说明有其他人已经修改过数据，不再允许本事务的提交。所以，使用乐观锁之前需要给数据库增加一列 :lock_version，Rails 会自动识别这一列，像数据库提交数据的时候自动带上。另外，乐观锁是默认打开的，如果要关闭，需要配置一下。

在大鱼系统中，库存管理是使用乐观锁的，我们的流量没那么大，不太可能多个用户同时预订同一个住宿的同一个间夜，概率比较小，所以目前是使用乐观锁来实现的。如果抛异常，那么还可以进行重试。

使用

记得使用前添加 lock_version 的字段给相应的表，其他的就是自动的了，如果事务提交失败，那么 Rails 会抛一个 ActiveRecord::StaleObjectError 的异常。

比如，下面这段代码会进行重试：

retry_times = 3

begin
    @order.with_lock do
        @order.set_paid!
    end
rescue ActiveRecord::StaleObjectError => e
    retry_times -= 1
    if retry_times > 0
        retry
    else
        raise e
    end
rescue => e
    raise e
end

需要注意的地方

一般，使用锁的时候和事务同时使用，所以 with_lock 是用的比较多的，而且尽量使用行锁而不是表锁。
另外，也注意异常的处理，需要使用那些会抛异常的方法；
对于乐观锁，还需要注意如果是前端操作频繁，那么还需要把 lock_version 写入到 form 表单中，否则起不到锁的作用，这里讲的很详细了

以上~ （发现这篇没什么内容，不过我记得最初大家写的时候也经常犯错，算是一个总结吧）

参考

Nginx + Rails 下如何进行文件的安全下载？

zamia — Thu, 04 Feb 2016 15:22:47 +0800

问题

一般常见的文件下载有两类需求：

公开的文件下载，比如 rails 的 assets、或者用户上传的一些可以公开的文件，比如自己的头像；
较隐私的文件下载，使用场景也不少，比如某些企业后台上传的用户认证资料；

前一类需求 rails 中比较容易实现，一般直接把用户上传的文件存储目录直接放在 /public/some/dir 中，然后按照日期或者 ID 之类的做个目录结构也就够用了。

对于后一类场景，具体的需求有两点：

必须经过用户认证和授权，检查认证和权限之后才能访问文件；这个就是典型的业务层需要处理的，也就是 app server(rails 层) 需要实现的；
保证速度，不能给 app server 过多负担。这个是 web server 擅长做的，比如 nginx 可以使用系统的 sendfile 功能可以直接从文件系统发送至网络层，可以少 2 次的内存 copy；web server 也可以做一些缓存等等；

根据上面的需求，文件的安全下载实现起来稍微麻烦一点，不过根据『这么通用的需求一定有现成的解决方案』的原则，其实配置和使用起来还是比较简单的，这篇小文就总结下使用 nginx 和 rails 配合、利用 X-Accel（一般也称作 X-Sendfile）来实现隐私文件的安全下载。

底层原理和实现

这是典型的 web server 和 application server 互相配合的过程，内部的访问过程这篇文章也讲的比较清楚，下面的总结更详细一些，补充了一些源码和日志，能帮助大家彻底搞清楚整个过程。

浏览器访问一个地址，比如 /download/files/123，这个地址对应一个需要验证权限的文件；
```
GET /download/files/123 HTTP/1.1
```
nginx 收到这个请求之后根据路由配置，把请求转发到 rails。

nginx 转发的时候根据配置，添加上两个参数，转发给 rails。后端 rails 服务器会根据这两个参数来对 response body 进行修改，后面会提到。
```
GET /download/files/123 HTTP/1.0
X-Forwarded-For: 127.0.0.1
X-Sendfile-Type: X-Accel-Redirect
X-Accel-Mapping: /var/www/fishtrip/private=/private
```
上面的参数 X-Sendfile-Type 告知后端 nginx 支持什么样的参数（像 apache、lighttpd 支持的参数名称不同）；参数 X-Accel-Mapping 告知后端应该怎么样做文件名称的 mapping。

rails 收到这个请求之后，正常流进某个 controller#action，经过业务代码的判断之后，找到这个 url 对应的真正的文件名，然后使用 sendfile 发送文件。

def show
    pic = File.find params[:id]
    send_file pic.path, type: "image/jpeg", disposition: 'inline'
end

其实在整个过程中，rails 的背后是 Rack::Sendfile 这个 middleware 在工作。看看它的源码中的 call 函数的实现：

# File rack/lib/rack/sendfile.rb
case type = variation(env)
when 'X-Accel-Redirect'
 path = F.expand_path(body.to_path)
 if url = map_accel_path(env, path)
   headers['Content-Length'] = '0'
   headers[type] = url
   body = []
 else
   env['rack.errors'].puts "X-Accel-Mapping header missing"
 end
when ...
end
# some code here

可以看到这个 middleware 吧 content-length 置为 0，把 body 置空，返回给前端一个计算过 mapping 的 url。

其中的函数 map_accel_path 是 private 函数，长这样：

def map_accel_path(env, file)
  if mapping = env['HTTP_X_ACCEL_MAPPING']
    internal, external = mapping.split('=', 2).map{ |p| p.strip }
    file.sub(/^#{internal}/i, external)
  end
end

其实就是根据 nginx 传入的 X-Accel-Mapping 参数把实际的地址替换成一个 mapping 地址。

所以，这样也就不难猜测我们自己写的 action 里面的 sendfile 的实现了，sendfile 只需要实现一个支持 to_path 调用的对象即可。去 Rails 中看看它的实现：

# File actionpack/lib/action_controller/metal/data_streaming.rb
def send_file(path, options = {}) #:doc:
 # 省略一些代码
 self.status = options[:status] || 200
 self.content_type = options[:content_type] if options.key?(:content_type)
 self.response_body = FileBody.new(path)
end

里面的 FileBody 类就支持 to_path 调用；

所以，经过 Rails 和 Rack::Sendfile 的配合，rails 返回给 nginx 的就是一个没有 body，只有 headers 的 response，长下面这个样子（来源于 nginx 的 debug 日志，略去了部分内容）：

http proxy header: "Content-Disposition: inline; filename="abc.jpg""
http proxy header: "Content-Transfer-Encoding: binary"
http proxy header: "Content-Type: image/jpeg"
http proxy header: "Content-Length: 0"
http proxy header: "X-Accel-Redirect: /private/files/abc.jpg"

nginx 收到 rails 返回的数据之后，会检查 X-Accel-Redirect 参数的值，然后内部再根据 location 的配置进行内部跳转，找到真正的文件地址（需要配置，见下文），并且调用操作系统的 sendfile 接口，直接返回给用户。

这个就是整个文件安全下载的过程了，这个过程涉及到 nginx - rails - Rack::Sendfile - nginx 的这么一个过程，看起来有点复杂。实际上我们使用的时候配置起来还是比较简单的。

实现和配置

配置主要是两部分，nginx 和 rails 的部分，如果使用 capistrano 部署线上服务，因为涉及到软链的问题，所以配置略有不同。

nginx

根据上面的原理部分的描述，nginx 的配置也分为两个部分：

跳转后端时参数配置

set $app_root /var/some/dir;

location /download {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Sendfile-Type X-Accel-Redirect;
        proxy_set_header X-Accel-Mapping "$app_root/private=/private";

        proxy_set_header Host $http_host;
        proxy_redirect off;
        expires off;

        proxy_pass http://backend;
}

这个配置的作用是 nginx 在把请求转发给 rails 后端的时候添加 X-Senfile-Type 和 X-Accel-Mapping 参数；

收到后端回复后内部地址的配置
```
location /private {
        internal;
        alias $app_root/private;
}
```
这个配置的作用是 nginx 收到 rails 后端返回的值时可以正确找到文件的实际地址；

rails

rails 的配置就更简单了，添加一句话即可：

config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'

capistrano

capistrano 的部署使用了软链的方法，所以上面 nginx 配置的地方，需要添加一个正则即可。这样后端 rails 就可以正常的去 mapping 了（也就是 Rack::Sendfile 里面的 map_accel_path 是支持正则的）：

proxy_set_header X-Accel-Mapping "$app_root/releases/\d{14}/private=/private";

如果实际部署情况跟这个不一致，只要走类似的方法就行了，你懂的~

总结

虽然文件的安全下载是一个小功能，而且现在文件的云存储很多（大鱼也迁移到了云存储上...），但是通过这里例子也可以看看 web server 和 application server 是如何配合工作的，反向代理的很多功能也都是类似机制完成的。

通过这个例子也可以了解一下 rack 的工作机制，可以看到如果通过简单的代码来实现一个相对复杂的功能。

以上~

参考文章

开源一个小 gem，帮助更好的集成 fis3 和 rails

zamia — Wed, 20 Jan 2016 19:51:48 +0800

开源一个小 gem，帮助更好的集成 fis3 和 rails

之前公司的前端 js、css 都挺乱的，最近随着前端架构师的加入，开始梳理前端工程。由于 asset pipeline 本身的一些限制（主要是无法做到 js 的模块化加载），比来比去，我们选择了 fis 的前端编译方案 http://fis.baidu.com，好处主要有两个：

前端 js 模块化开发，js 模块可以动态 require、按需加载；
就近原则封装组件，可以把同一个组件的 js、css、模板文件放在同一个子目录。

引入 FIS 之后，如何跟 rails 集成呢，我们也试了好几种方案：

由 fis 来编译 js、css 以及 .html.erb 文件，然后把编译好的文件再被 layout 引用。

简单描述起来还不太好说明白，因为要给每个资源打上动态的 hash 串，所以这种方案中，把 html 也给编译了；然后让 rails 再去 render 这个 html。整个流程比较复杂，难以理解和维护。
由 fis 来编译 js、css 文件。然后生成 map.json 文件，rails 读取 map.json 文件解析之后，由 helper 来解析地址。

这个方案的好处是理解容易，前后端不需要互相影响开发。

这个方案其实也是 asset pipeline 的基本原理，也是 webpack-rails 的基本原理。现在社区很少有把 fis 和 rails 结合起来用的团队，所以我们开发了一个小 gem 来完成这个功能：

https://github.com/fishtrip/fis3-rails

基本上这个 gem 就做两件事：

解析 map.json 文件，存储资源文件路径和编译后的地址；
由 helper 来根据资源文件名来 render 出正确的资源；

但是，主要注意的是，因为 FIS 中 javascript 文件是可以引用一个 css 文件的，所以我们又写了一个 helper 解决这样的问题（这一点类似 webpack）。

所以 fis3-rails 一共提供了三个 helper：

调用某个 fis js 资源时调用 fis3_javascript_tag，如：
```
<%= fis3_javascript_tag('js/mobile/base') %>
```
调用某个 fis css 资源时调用 fis3_stylesheet_tag，如：
```
<%= fis3_stylesheet_tag('css/mobile/base') %>
```
因为 fis 中的 js 文件也可能导致 css 产生，所以使用 js 时也需要同时调用 fis3_stylesheet_tag_by_js，如：
```
<%= fis3_stylesheet_tag_by_js('js/mobile/base') %>
```

时间仓促，也是简单实现，但是目前大鱼的线上已经开始在使用了，目前来看，还比较稳定。

如果有 rails 团队想引入 fis3，欢迎各位交流和指教~

Rails 路由 - 解决多子域名问题

zamia — Sun, 15 Nov 2015 14:56:21 +0800

rails 多子域名问题

Rails 项目发展到较大规模的时候、或者为了其他各种原因，一定会遇到多子域名的问题。目前网上的很多资料只是简单的介绍了利用 constraints 进行操作的方法，并没有系统的解决多子域名实操的时候会遇到的各种问题。比如：

多个子域名下，路由和控制器的设计？
多个 routes 文件如何拆分？
url helper 使用的时候的注意事项？

这篇文章算是对上述问题进行的一个较深入的总结和实操，请阅读之前需要 Rails 路由先有个大概的了解，期望大家读完之后对 Rails 路由理解的更加深入。

多子域名问题解决

constraint 是基础

Rails 提供了 constraints 方法来对一组路由进行限制，比如官方文档（Rails 3.2）中提供的例子：

constraints(:id => /\d+\.\d+/) do
  resources :orders
end

上面的例子中只有 /posts/123.456 这样的 id 是允许的，而 "/posts/123" 就是无效的。这也是 constraint（限制）的意思。

那么，根据这个思路，我们可以限制一组路由只在某个子域名下生效，也就达到了多子域名的目的：

constraints :subdomain => "m" do
  resources :orders # mobile下
end
constraints :subdomain => "www" do
  resources :orders # pc下
end

另外，不要在 routes 文件里面 hard code 一些配置，因为一般不同的环境的子域名可能不一样，比如你的测试环境可能需要 alpha.m.example.com 这样的域名，而正式环境才是 m.example.com 这样的域名。我们稍微修改的好一点（示例代码也要写好啊，否则新手容易跟着画瓢）：

### config/environments/development.rb
config.mobile_subdomain = "m"
config.main_subdomain = "www"

### config/routes.rb
constraints :subdomain => Rails.configuration.mobile_subdomain do
  resources :orders
end
constraints :subdomain => Rails.configuration.main_subdomain do
  resources :orders
  # 下面是其他路由，比如
  resources :users
end

但是这样显然是不 work 的（手册跟实际工作是有差距的），因为 constraints 只是做了『限制』，路由指向的 controller 并不会改变，也就是说上面的 mobile 子域名中的 orders 也是同样指向了 ::OrdersController 这个控制器，实际工作中，我们一般是期望 m.example.com/orders 路由指向 ::Mobile::USersController 这个控制器的。

那应该如何解决呢？这个时候就需要使用 scope 了。

先提下 namespace

scope 日常不太常使用，因为大家一般都是使用 namespace 就够了，比如最常见的写法：

namespace :admin do
  resources :orders
end

这样会把 /admin/orders 路由指向 ::Admin::PostsController，很方便吧？

scope 来解决

但是在子域名环境下，这样是达不到目的的。因为我们期望 "m.example.com/orders" 能指向 ::Mobile::OrdersController，那么该如何搞呢，这个时候就需要 scope 了。scope 提供了比较 namepace 更细粒度的控制参数，完全可以满足我们的需求。

下面的代码来自于官方文档，稍微翻译了下：

### 把 url "/posts" (不包含/admin前缀) 指向Admin::PostsController
scope :module => "admin" do
  resources :posts
end 

### 把 posts相关路由添加 "/admin/" 前缀
scope :path => "/admin" do
  resources :posts
end

### 修改 url helper，用 +sekret_posts_path+ 替代 +posts_path+
scope :as => "sekret" do
  resources :posts
end

所以，这三个参数是可以独立使用的，那么上面提到的子域名的问题的解决方案也就有了：

constraints :subdomain => Rails.configuration.mobile_subdomain do
  scope module: 'mobile' do 
    resources :orders
  end
end
constraints :subdomain => Rails.configuration.main_subdomain do
  resources :orders
end

这样的话，mobile 子域名下的/orders 会路由到 "::Mobile::OrdersController"，目标达成！

优化一下

这样好像还不够好，这样写有一个小小的问题，就是你在 mobile 下面引用一个 url helper 的时候，比如：

### app/mobile/orders/show.html.erb
<%= link_to order_path(@order), order.id %>

读代码的人比较难以直观的知道这个 order_path 是指的哪个域名下的 url，而且如果多个子域名下有 url 路径重复的话，一旦写错，rails 不会提示错误，只有访问的时候才会报错。所以，最好给 scope 加一个 as 参数，把 mobile 下的 url helper 独立出来：

### 添加as参数会修改url helper
constraints :subdomain => Rails.configuration.mobile_subdomain do
  scope module: 'mobile', as: 'mobile' do 
    resources :orders
  end
end

### 调用的时候
<%= link_to mobile_order_path(@order), order.id %>

namespace 和 scope 其实是一个东西

其实事实上，看 rails 源码可以看到，namespace 只不过是包装了一层，底层完全是用 scope 来实现的：

### File actionpack/lib/action_dispatch/routing/mapper.rb, line 679
def namespace(path, options = {})
  path = path.to_s
  options = { :path => path, :as => path, :module => path,
              :shallow_path => path, :shallow_prefix => path }.merge!(options)
  scope(options) { yield }
end

子域名的问题到这里应该已经基本说清楚了，下面讲讲其他容易遇到的问题。

rails routes 文件拆分

一旦你有了多个子域名，可能你的 routes 文件开始变大很难维护了，这个时候把 routes 文件拆分是一个好主意。

routes 文件拆分有两个办法，一种是 rails 内建的，但是 Rails4 已经移除了，一种是不受 rails 版本影响的方法。

这篇英文的文章写得挺清楚了，下面简单说一下。

修改 rails 路径配置参数

通过修改 "config/routes" 配置来解决：

config.paths["config/routes"] += Dir[Rails.root.join('config', 'routes','*.rb')]

如果对加载顺序有依赖（最好别依赖），可以一个文件一个文件的加载：

config.paths["config/routes"] = %w(
      config/routes/admin.rb
      config/routes/api.rb
      config/routes.rb
    ).map { |p| Rails.root.join(p) }

利用 instance_eval

利用 instance_eval 来加载其他路由文件即可：

Example::Application.routes.draw do
  def draw(routes_name)
    instance_eval(File.read(Rails.root.join("config", "routes", "#{routes_name}.rb")))
  end

  # subdomain
  draw :mobile
  draw :api

  ### 下面正常写其他路由就可以了
  resources :users
end

这样把其他 routes 文件放在 config/routes/ 目录下即可。

多个子域名下的_path 和_url 的使用

主要提一个 *_path 和 *_url 的区别，虽然一个是相对地址、一个是绝对地址，但是单个域名下，其实区别不大，所以很多人都是随手用。

但是一旦有了多个子域名，如果还是随手混用就会导致很多问题。所以，多个子域名下应该注意下面的几个约定：

除非必要，只用 *_path

多个子域名下，大部分的内链还是在子域名内部的，所以尽量使用*_path 来引用 url。如果不是的话，请考虑产品设计的是否合理、是否本子域名下也需要一个独立的 url 来满足需求。
如果使用 *_url，那么一定要加上子域名的参数

如果在跨域名访问的情况下（或者是 mailer 中），使用 *_url 的时候一定要加上 subdomain 的参数：
```
<%= link_to mobile_users_path(subdomain: Rails.configuration.mobile_subdomain), users.nickname %>
```
使用 url helper，而不是字符串来代表地址。

这一点，初级的 rails 工程师很容易犯，觉得写一个字符串非常简单，干嘛还要搞一个 url helper？可是一旦使用字符串表达 url，一旦需要重构代码、升级产品的时候基本上代码是不可维护的，这时候只能默默流泪了。

javascript 代码中引用 url

这种情况也不少，可以使用 data-url 的形式，如：

### 这样
<div data-url="<%= mobile_users_path %>"></div>
### 或者这样
<%= content_tag :div, :'data-url' => mobile_users_path do %>
  some content
<% end %>

差不多就是这样

好，差不多就是这样，希望在多子域名的问题上对大家有帮助，欢迎大家提意见~

广告时间：大鱼自助游还在招 ror 工程师哦，初高级均可，欢迎直接抛简历给我。

[北京] 大鱼自助游坐标三元桥招聘 Ruby 开发工程师&数据分析工程师

zamia — Thu, 29 Oct 2015 14:52:41 +0800

大鱼招聘爱旅行的攻城狮!!!!!!

Hi! 这里大鱼自助游。

大鱼自助游 (www.fishtrip.cn) 自上线一直致力于为中国人提供最优质的出境自由行服务。才不要做第二个 TripAdvisor 或者 Booking.com

大鱼要打造前所未有的个性化海外自由行产品交易平台，提供最具当地特色的住宿。

过去一年大鱼做了这些事情：

• 发布了全国第一款办证类 App「入台证神器」 • 成功开拓了台湾、日本站 • 通过强大的后台与上千家中小供应商实现对接 • 推出大鱼 • 旅行猎人计划并取得巨大反响

未来我们希望做的事情：

• 将大鱼做成一个世界性的出境游交易平台，为各国旅游者精选值得信赖有品质保证的特色住宿 • 我们的口号是：只推荐特色住宿 (=ﾟωﾟ) ノ • 和我们一起从住宿开始体验世界吧：）

#大鱼能给你什么

• 开放的互联网创业环境 • 释放潜力、爆发小宇宙的平台 • 富有竞争力的薪资和贴心的住房补贴 • 厨艺高超的阿姨准备的午餐和下午茶 • 只是每天抢饭的场面略凶残，请准备好 • 成为大鱼 • 旅行猎人的机会 • 边旅行边赚钱 • 为大鱼在世界各地开疆拓土

大鱼搬家了，从南三环的温馨小宅搬到了东三环的“工业朋克风”办公室，欢迎大家来办公区前厅的大鱼咖啡聊一聊

必须有图有真相↓

关于我们

如果你好奇这是怎样的一群人，一两句话确实挺难概括的，你最好亲自来看看。

这里有 Google、百度、微软出来的大牛，也有毕业不久的新鲜人。水瓶、双子、天蝎居多，不羁放纵爱自由。

我们时常仰望星空，却不忘脚踏实地。相信成大事者，心中必有爱。爱创业、爱互联网，更爱旅行。认识我们：http://www.fishtrip.cn/about_us 所以你想加入我们一起来做一点有趣的事情吗？

Ruby

10k-20k 北京经验 1-3 年本科及以上全职

职位描述

◇ 岗位职责

（1）参与大鱼网站的架构设计，以及各个后端模块的开发；

（2）承担大鱼网站的后端开发和维护工作。

◇ 任职要求

（1）大学本科及以上学历，1 年以上相关工作经验；

（2）熟悉互联网产品和服务的开发过程，有至少一门动态语言或脚本语言的开发经验，对互联网后端技术架构有基本的理解；

（3）认可创业团队氛围，有上进心与自我驱动力，能够承受一定的工作压力。

◇ 加分项

（1）对前端技术如 css/html/javascript 等有一定了解；

（2）有电商行业开发经历；

（3）对开源、技术分享、敏捷开发感兴趣；

（4）全栈工程师。

数据分析工程师

10-30k 北京应届生或者有工作经验皆可，本科及以上全职

◇ 岗位职责

（1）负责大鱼数据爬取、数据采集以及数据整理等工作。

◇ 任职要求

（1）大学本科及以上学历，1 年以上相关工作经验（优秀应届生亦可）；（2）能够熟练使用 Python 或 Ruby 语言，并有过项目经验；（3）能够熟练使用 html、css、javascript 前端语言；（4）拥有独立思考能力，并对于钻研问题充满兴趣；（5）具有较好的理解沟通能力，工作积极主动，有团队合作精神，责任心强；（6）认可创业团队氛围，有上进心与自我驱动力，能够承受一定的工作压力。

◇ 加分项

（1）熟悉 rails 架构者优先；（2）有电商行业开发经历者优先；（3）全栈工程师优先

简历发送至：- hr@fishtrip.cn 标题：姓名 + 职位+Ruby China

[北京] 大鱼自助游诚招 ruby 工程师&数据分析工程师

zamia — Tue, 30 Jun 2015 14:36:53 +0800

Hi! 这里大鱼自助游。

大鱼自助游 (www.fishtrip.cn) 自上线一直致力于为中国人提供最优质的出境自由行服务。才不要做第二个 TripAdvisor 或者 Booking.com, 大鱼要打造前所未有的个性化海外自由行产品交易平台，提供最具当地特色的住宿。

【过去一年大鱼做了这些事情】

【未来我们希望做的事情】

将大鱼做成一个世界性的出境游交易平台，为各国旅游者精选值得信赖有品质保证的特色住宿。我们的口号是：只推荐特色住宿 (=ﾟωﾟ) ノ

和我们一起从住宿开始体验世界吧：）

【大鱼能给你什么】

【关于我们】

如果你好奇这是怎样的一群人，一两句话确实挺难概括的，你最好亲自来看看。

这里有 Google、百度、微软出来的大牛，也有毕业不久的新鲜人。水瓶、双子、天蝎居多，不羁放纵爱自由。

我们时常仰望星空，却不忘脚踏实地。相信成大事者，心中必有爱。爱创业、爱互联网，更爱旅行。

认识我们：http://www.fishtrip.cn/about_us

所以你想加入我们一起来做一点有趣的事情吗？

大鱼特意来这里寻找这样的小伙伴

初级/高级 Ruby 工程师

10k-30k 北京应届生或有工作经验均可本科及以上全职

职位描述

◇ 岗位职责

（1）参与大鱼网站的架构设计，以及各个后端模块的开发；

（2）承担大鱼网站的后端开发和维护工作。

◇ 任职要求

（1）大学本科及以上学历，1 年以上相关工作经验，应届生也行；

（2）熟悉互联网产品和服务的开发过程，有至少一门动态语言或脚本语言的开发经验，对互联网后端技术架构有基本的理解；

（3）认可创业团队氛围，有上进心与自我驱动力，能够承受一定的工作压力。

◇ 加分项

（1）对前端技术如 css/html/javascript 等有一定了解；

（2）有电商行业开发经历；

（3）对开源、技术分享、敏捷开发感兴趣；

（4）全栈工程师。

数据分析工程师

10-30k 北京应届生或者有工作经验皆可，本科及以上全职

◇ 岗位职责

（1）负责大鱼数据爬取、数据采集以及数据整理等工作。

◇ 任职要求（1）大学本科及以上学历，1 年以上相关工作经验（优秀应届生亦可）；

（2）能够熟练使用 Python 或 Ruby 语言，并有过项目经验；

（3）能够熟练使用 html、css、javascript 前端语言；

（4）拥有独立思考能力，并对于钻研问题充满兴趣；

（5）具有较好的理解沟通能力，工作积极主动，有团队合作精神，责任心强；

◇ 加分项（6）熟悉 rails 架构者优先；

（7）有电商行业开发经历者优先；

（8）全栈工程师优先

大鱼搬家了，从南三环的温馨小宅搬到了东三环的“工业朋克风”办公室，欢迎大家来办公区前厅的大鱼咖啡聊一聊

简历发送方法

简历请发送至 hongdi@fishtrip.cn 格式：姓名 + 应聘职位 + 渠道

感谢各位：）

我们等你！

[北京] 大鱼自助游诚聘 Ruby 工程师

zamia — Fri, 15 May 2015 20:44:50 +0800

Hi! 这里大鱼自助游。

过去一年大鱼做了这些事情：

• 发布了全国第一款办证类 App「入台证神器」 • 成功开拓了台湾、日本站 • 通过强大的后台与上千家中小供应商实现对接 • 推出大鱼 • 旅行猎人计划并取得巨大反响 •发布了旅行猎人专属 App「大鱼旅行猎人」

未来我们希望做的事情：将大鱼做成一个世界性的出境游交易平台，为各国旅游者精选值得信赖有品质保证的特色住宿。我们的口号是：只推荐特色住宿 (=ﾟωﾟ) ノ

和我们一起从住宿开始体验世界吧：）

【关于我们】

如果你好奇这是怎样的一群人，一两句话确实挺难概括的，你最好亲自来看看。

这里有 Google、百度、微软出来的大牛，也有毕业不久的新鲜人。水瓶、双子、天蝎居多，不羁放纵爱自由。

我们时常仰望星空，却不忘脚踏实地。相信成大事者，心中必有爱。爱创业、爱互联网，更爱旅行。

认识我们：http://www.fishtrip.cn/about_us 所以你想加入我们一起来做一点有趣的事情吗？

大鱼特意来 Ruby China 找这样的人

【Ruby on Rails 工程师】10K~20K • 参与大鱼网站的架构设计，以及各个后端模块的开发； • 承担大鱼网站的后端开发和维护工作。

• 1 年以上相关工作经验； • 熟悉互联网产品和服务的开发过程，有至少一门动态语言或脚本语言的开发经验，对互联网后端技术架构有基本的理解； • 认可创业团队氛围，有上进心与自我驱动力，能够承受一定的工作压力。 • 对前端技术如 css/html/javascript 等有一定了解； • 有电商行业开发经历； • 对开源、技术分享、敏捷开发感兴趣； • 全栈工程师优先。

大鱼也想从 Ruby China 试一试找这样的人

【前端工程师】10K~20K • 负责大鱼网站的前端开发，与 UI 设计师、产品经理、交互设计师一起，实现易用、好用的互联网旅游产品； • 负责开发和维护公司移动端（H5）的开发； • 负责前端框架的选型和开发，制定前端开发规范； • 开发易维护、可复用的各种前端组件。

• 2 年以上相关工作经验； • 深入理解 Javascript 和 CSS 等前端技术，对 HTML5 有一定了解； • 具有良好的团队协作能力、沟通能力与学习能力，热爱技术，喜欢钻研； • 移动互联网/电子商务行业经验优先； • 经验丰富，带过前端工程团队优先； • 对产品和交互有兴趣者优先。

【Android/iOS 工程师】10K~20K • 负责开发和维护大鱼的移动客户端，包括 Android、iOS 以及平板应用。

• 1 年以上相关工作经验； • 1～3 个移动设备客户端产品的开发及上线； • 学习能力较强，对移动端的技术或产品有浓厚兴趣； • 计算机基础知识扎实，对移动端应用的整体架构有一定把握能力； • 具备较好的团队协助能力，乐于分享和交流； • 有 HTML5 或者桌面软件开发经验者优先； • 有 Linux/C/Java 开发经验者优先。

【PHP 工程师】10K~20K • 负责开发大鱼项目中各类产品需求，对已知的线上问题快速定位与修复； • 参与大鱼核心业务模块系统分析、设计、开发； • 负责根据大鱼不同应用需求，优化系统设计和前台表现，不断提升系统效能和安全性。

• 2 年以上相关工作经验； • 精通 PHP，能够深入理解 PHP 面向对象编程设计理念，并且熟悉 MVC 开发框架，有 PHP 实践经验； • 精通 LAMP 架构，熟练应用 Shell/JavaScript/Mysql 等技术； • 具有较好的理解沟通能力，工作积极主动，有团队合作精神，责任心强； • 认可创业团队氛围，有上进心与自我驱动力，能够承受一定的工作压力。 • 具有旅游行业相关系统开发经验者优先； • 有团队管理经验者优先。

大鱼能给你什么

• 开放的互联网创业环境 • 舒适的人体工程学座椅，一把好椅子真的很重要 • 除霾装置已到位，让办公室变得空气清新 • 释放潜力、爆发小宇宙的平台 • 富有竞争力的薪资和贴心的住房补贴 • 厨艺高超的阿姨准备的午餐和下午茶，只是每天抢饭的场面略凶残，请准备好 • 大鱼咖啡员工专属优惠，花更少的钱喝更纯正的咖啡 • 员工生日特别福利，HR 为你挑选特别的生日礼物 • 年假带薪病假不用讲，修生养息假也请好好利用 • 成为大鱼 • 旅行猎人的机会，边旅行边赚钱 • 为大鱼在世界各地开疆拓土

推荐有奖

成功推荐你身边的朋友加入大鱼，将获得往返台北机票及三晚住宿！这么好的事情，走过路过不要过错啊喂！

大鱼搬家了，从南三环的温馨小宅搬到了东三环的“工业朋克风”办公室，欢迎大家来办公区前厅的大鱼咖啡聊一聊

必须有图有真相↓

欢迎发送简历至 hr@fishtrip.cn 或 medal@fishtrip.cn

感谢各位：）

我们等你！

Rails 中的事务处理

zamia — Mon, 04 May 2015 22:30:05 +0800

发现大鱼团队中不少同学对 Rails 中事务的使用不当，发现这篇文章不错，花一点时间翻译了一下，希望对各位有用~

Rails 中的事务

翻译自：http://markdaggett.com/blog/2011/12/01/transactions-in-rails/

使用事务的原因

事务用来确保多条 SQL 语句要么全部执行成功、要么不执行。事务可以帮助开发者保证应用中的数据一致性。常见的使用事务的场景是银行转账，钱从一个账户转移到另外一个账户。如果中间的某一步出错，那么整个过程应该重置。这个例子的伪码如下：

ActiveRecord::Base.transaction do
  david.withdrawal(100)
  mary.deposit(100)
end

Rails 中，通过 ActiveRecord 对象的类方法或者实例方法即可实现事务：

Client.transaction do
  @client.users.create!
  @user.clients(true).first.destroy!
  Product.first.destroy!
end

@client.transaction do
  @client.users.create!
  @user.clients(true).first.destroy!
  Product.first.destroy!
end

可以看到上面的例子中，每个事务中均含有多个不同的 model。在同一个事务中调用多个 model 对象是常见的行为，因为事务是和一个数据库连接绑定在一起的，而不是某个 model 对象；而同时，也只有在对多个纪录进行操作，并且希望这些操作作为一个整体的时候，事务才是必要的。

另外，Rails 已经把类似 #save 和 #destroy 的方法包含在一个事务中了，因此，对于单条数据库记录来说，不需要再使用显式的调用了。

触发事务回滚

事务通过 rollback 过程把记录的状态进行重置。在 Rails 中，rollback 只会被一个 exception 触发。这是非常关键的一点，很多事务块中的代码不会触发异常，因此即使出错，事务也不会回滚。比如下面的写法：

ActiveRecord::Base.transaction do
  david.update_attribute(:amount, david.amount -100)
  mary.update_attribute(:amount, 100)
end

因为 Rails 中，#update_attribute 方法在调用失败的时候也不会触发 exception，它只是简单的返回 false，因此必须确保 transaction 块中的函数在失败时会抛异常。正确的写法是这样的：

ActiveRecord::Base.transaction do
  david.update_attributes!(:amount => -100)
  mary.update_attributes!(:amount => 100)
end

注意，Rails 中约定，带有叹号的函数一般会在失败时抛异常。

同时，我也看到一些代码中，在事务块中使用了 #find_by 方法，实际上，find_by 等魔术方法当找不到记录的时候会返回 nil，而 #find_ 方法在找不到记录的时候会抛出一个 ActiveRecord::RecordNotFound 异常。比如下面的例子：

ActiveRecord::Base.transaction do
  david = User.find_by_name("david")
  if(david.id != john.id)
    john.update_attributes!(:amount => -100)
    mary.update_attributes!(:amount => 100)
  end
end

发现上面的逻辑错误了吗？nil 对象也有一个 id 方法，导致记录没有被找到的错误被隐藏了。同时，由于 find_by 也不会抛出异常，因此下面的代码被错误的执行了。这就意味着，有的时候在某些场景下，我们需要人工抛异常。因此这段代码因此改成下面的形式：

ActiveRecord::Base.transaction do
  david = User.find_by_name("david")
  raise ActiveRecord::RecordNotFound if david.nil?
  if(david.id != john.id)
    john.update_attributes!(:amount => -100)
    mary.update_attributes!(:amount => 100)
  end
end

当错误出现时，事务本身会回滚，同时异常也会在外层抛出。因此，你的调用方必须考虑 catch 这个异常，并进行相应的处理。

有一个特殊的异常，ActiveRecord::Rollback，当它被抛出时，事务本身会回滚，但是它并不会被重新抛出，因此你也不需要在外部进行 catch 和处理。

何时使用嵌套事务？

错误使用或者过多使用嵌套异常是比较常见的错误。当你把一个 transaction 嵌套在另外一个事务之中时，就会存在父事务和子事务，这种写法有时候会导致奇怪的结果。比如下面来自于 Rails API 文档的例子：

User.transaction do
  User.create(:username => 'Kotori')
  User.transaction do
    User.create(:username => 'Nemu')
    raise ActiveRecord::Rollback
  end
end

上面提到，ActiveRecord::Rollback 不会传播到上层的方法中去，因此这个例子中，父事务并不会收到子事务抛出的异常。因为子事务块中的内容也被合并到了父事务中去，因此这个例子中，两条 User 记录都会被创建！

可以把嵌套事务这样理解，子事务中的内容被归并到了父事务中，这样子事务变空。

为了保证一个子事务的 rollback 被父事务知晓，必须手动在子事务中添加 :require_new => true 选项。比如下面的写法：

User.transaction do
  User.create(:username => 'Kotori')
  User.transaction(:requires_new => true) do
    User.create(:username => 'Nemu')
    raise ActiveRecord::Rollback
  end
end

事务是跟当前的数据库连接绑定的，因此，如果你的应用同时向多个数据库进行写操作，那么必须把代码包裹在一个嵌套事务中去。比如：

Client.transaction do
  Product.transaction do
    product.buy(@quantity)
    client.update_attributes!(:sales_count => @sales_count + 1)
  end
end

事务相关的回调

上面提到 #save 和 #destroy 方法被自动包裹在一个事务中，因此相关的回调，比如 #after_save 仍然属于事务的一部分，因此回调代码也有可能被回滚。

因此，如果你希望代码在事务外部执行的话，那么可以使用 #after_commit 或者 # after_rollback 这样的回调函数。

事务陷阱

不要在事务内部去捕捉 ActiveRecord::RecordInvalid 异常。因为某些数据库下，这个异常会导致事务失效，比如 Postgres。一旦事务失效，要想让代码正确工作，就必须从头重新执行事务。

另外，测试回滚或者事务回滚相关的回调时，最好关掉 transactional_fixtures 选项，一般的测试框架中，这个选项是打开的。

常见的事务反模式

单条记录操作时使用事务
不必要的使用嵌套式事务
事务中的代码不会导致回滚
在 controller 中使用事务

[北京 | 互联网 | 出境游] 大鱼诚招 Ruby 攻城狮

zamia — Thu, 12 Mar 2015 16:03:48 +0800

Hi! 这里大鱼自助游。

过去一年大鱼做了这些事情：

和我们一起从住宿开始体验世界吧：）

【关于我们】

如果你好奇这是怎样的一群人，一两句话确实挺难概括的，你最好亲自来看看。

这里有 Google、百度、微软出来的大牛，也有毕业不久的新鲜人。水瓶、双子、天蝎居多，不羁放纵爱自由。

我们时常仰望星空，却不忘脚踏实地。相信成大事者，心中必有爱。爱创业、爱互联网，更爱旅行。

认识我们：http://www.fishtrip.cn/about_us 所以你想加入我们一起来做一点有趣的事情吗？

大鱼特意来 Ruby China 找这样的人

【Ruby on Rails 工程师】10K~20K • 参与大鱼网站的架构设计，以及各个后端模块的开发； • 承担大鱼网站的后端开发和维护工作。

大鱼也想从 Ruby China 试一试找这样的人

【Android/iOS 工程师】10K~20K • 负责开发和维护大鱼的移动客户端，包括 Android、iOS 以及平板应用。

大鱼能给你什么

推荐有奖

成功推荐你身边的朋友加入大鱼，将获得往返台北机票及三晚住宿！这么好的事情，走过路过不要过错啊喂！

大鱼搬家了，从南三环的温馨小宅搬到了东三环的“工业朋克风”办公室，欢迎大家来办公区前厅的大鱼咖啡聊一聊

必须有图有真相↓

欢迎发送简历至 hr@fishtrip.cn 或 medal@fishtrip.cn

感谢各位：）

我们等你！

[北京诚聘] [互联网 | 旅游 | 创业] 一条大鱼在等你，工程师们是时候在春天活动活动啦

zamia — Wed, 28 Jan 2015 14:17:18 +0800

Hi! 这里大鱼自助游。

大鱼自助游 (www.fishtrip.cn) 自上线一直致力于为中国人提供最优质的出境自由行服务。

才不要做第二个 TripAdvisor 或者 Booking.com, 大鱼要打造前所未有的个性化海外自由行产品交易平台，提供最具当地特色的住宿。

过去一年大鱼做了这些事情：

• 发布了全国第一款办证类 App「入台证神器」 • 成功开拓了台湾、日本、帕劳、巴西站 • 通过强大的后台与上千家中小供应商实现对接 • 推出大鱼 • 旅行猎人计划并取得巨大反响

未来我们希望做的事情：

将大鱼做成一个世界性的出境游交易平台，为各国旅游者精选值得信赖有品质保证的特色住宿。

我们的口号是：只推荐特色住宿 (=ﾟωﾟ) ノ

【关于我们】

如果你好奇这是怎样的一群人，一两句话确实挺难概括的，你最好亲自来看看。

这里有 Google、百度、微软出来的大牛，也有毕业不久的新鲜人。水瓶、双子、天蝎居多，不羁放纵爱自由。

我们时常仰望星空，却不忘脚踏实地。相信成大事者，心中必有爱。爱创业、爱互联网，更爱旅行。

认识我们：http://www.fishtrip.cn/about_us 所以你想加入我们一起来做一点有趣的事情吗？

大鱼在找这样的人

【Ruby on Rails 工程师】10K~20K • 参与大鱼网站的架构设计，以及各个后端模块的开发； • 承担大鱼网站的后端开发和维护工作。

【Android/iOS 工程师】10K~20K • 负责开发和维护大鱼的移动客户端，包括 Android、iOS 以及平板应用。

大鱼能给你什么

• 开放的互联网创业环境 • 释放潜力、爆发小宇宙的平台 • 富有竞争力的薪资和贴心的住房补贴 • 厨艺高超的阿姨准备的午餐和下午茶， • 只是每天抢饭的场面略凶残，请准备好 • 成为大鱼 • 旅行猎人的机会， • 边旅行边赚钱， • 为大鱼在世界各地开疆拓土

推荐有奖

成功推荐你身边的朋友加入大鱼，将获得往返台北机票及三晚住宿！这么好的事情，走过路过不要过错啊喂！

欢迎你到北京南三环和我们聊聊，

也可以发送简历至 hr@fishtrip.cn

感谢各位：）

我们等你！

[北京] 大鱼自助游诚聘前端 /Ruby/iOS/Android 工程师

zamia — Tue, 11 Nov 2014 17:47:31 +0800

坐在世界 500 强格子间里的你，是不是也想做做真正喜欢的事情？过着朝九晚五安逸生活的你，改变世界的梦想还在吗？是时候走出你的舒适圈了吧？

讨厌低效率！讨厌阿谀奉承！讨厌复杂的人际关系！

如果你也不安现状，追求不一样的生活；

如果你也心中有爱，脚踏实地，也时而仰望星空；

如果你也极度热爱互联网，热爱创业，热爱旅行；

你，就是大鱼在找的人。

关于大鱼

大鱼致力于为中国人提供最优质的出境自由行服务，大鱼不要做第二个 tripadvisor 或者 booking.com, 大鱼要打造前所未有的海外旅游产品在线交易平台。

是的，大鱼正在用互联网思维颠覆传统行业。

关于你未来的小伙伴

• 开放平等，高压有 (dou) 爱 (bi) 的氛围 • 有 Google、百度、微软出来的大牛， • 也有毕业不久的新鲜人 • 80 后为主，不拒绝 70 后，不歧视 90 后 • 水瓶、双子、天蝎居多， • 不羁放纵爱自由 • 他们的真面目是……http://www.fishtrip.cn/about_us

大鱼在找这样的人

Ruby on Rails 工程师 2~3 名薪资范围在 8K ~ 20K，根据能力可再面谈，从初学者到高手大牛我们都需要；基础要求是 1 年以上工作经验，编程基础扎实，乐于学习，开放的心态；全栈工程师优先，如果你懂底层、乐于学习业务、也能写前端那就更好了！

前端工程师 1~2 名薪资范围在 8K ~ 20K，期望经验比较丰富，能给大鱼的前端带来更多经验，以后能够带领前端团队；基础要求是 2 年以上前端经验，对 javascript、html5、css 等有较深的理解；如果你对产品和交互感兴趣，或者带过前端团队那就更匹配了；

Android/iOS 工程师各 1 ~ 2 名薪资范围 10K ~ 20K，根据您的资历面谈，工程师或者经验丰富的工程师均可；基础要求是 1 年以上移动端工作经验，完整经历过至少一个 App 的开发设计和上线；如果您懂产品、对移动端有强烈的兴趣更好；

大鱼能给你什么

推荐有奖

成功推荐你身边的朋友加入大鱼，将获得往返台北机票及三晚住宿！这么好的事情，走过路过不要过错啊喂！

欢迎你到北京南三环和我们聊聊，

也可以发送简历至 hr@fishtrip.cn

感谢各位：）

我们等你！

Rails 重构: 利用 Service 优化 Fat Model

zamia — Wed, 22 Oct 2014 01:01:15 +0800

Rails 重构：利用 Service 优化 Fat Model

给公司内部写的文章，分享出来，希望对大家有帮助。

本文主要说明什么时候需要重构 fat model，以及通过一个简单的案例来讲解如何一步步重构复杂的 model，把它变成扩展性良好的 service。

源起

在这篇文章 7 Patterns to Refactor Fat ActiveRecord Models 中，其中提到了一点，利用 Service 重构“Fat”Model。

原文中提到了几点需要重构成 service 的场景：

功能逻辑比较复杂
功能涉及到了多个 model 的时候
此功能会和外部系统交互
此功能并非底层 model 的核心责任，关联不大
此功能可能会有多种实现方式

上面的总结很好，但是也很模糊，比如到底什么样的功能算是复杂？涉及到多个 model 就应该优化成 service 吗？怎么样才叫做关联不大？

每个人的判断可能不太一样，对于一个 team 来讲，需要一个相对比较明确的约定来定义什么时候，你的业务逻辑需要重构层一个 service 了。目前大鱼的开发团队是这么简单约定的：

当 model class 中出现跨 model 的‘写’行为的时候

为什么是这样的约定？

因为一般出现了跨 model 的写的时候，说明你的业务逻辑比较复杂了，可以考虑封装成一个 service 来完成这件相对“独立”的功能；特别是如果 model 的回调中，出现了跨 model 的写，这种情况更应该避免，因为将来逻辑复杂时，很有可能回调的条件已不再满足了。

所以 service 的封装的粒度应该是比较明确的，那就是对于复杂的功能逻辑，如果同时又比较独立，将来有一定的可能性会扩展成一个 engine、甚至独立的组件（如 http api），那么显然是应该封装层 service 的，那么目前的一个“较好”的标准，就是如果 model 内部出现了跨 model 的“写”，应当考虑把这部分功能封装层 service，以便将来的扩展。

问题场景

案例实现的是电商中常见的“常用联系人”的功能，下面是一个简化的需求说明：

用户提交订单的时候，需要记录本订单使用的联系人姓名、电话、邮箱；每个订单需要存储一份；
订单提交后，系统需要把联系人信息记录在‘常用联系人’表中，供下次用户快捷填写；每个用户有多个’常用联系人‘
每个用户都有唯一的一份联系信息，每次订单提交后需要更新此信息；此信息会用在其他系统作为用户的标志；
常用联系人、订单联系人之间利用真实姓名进行弱关联，同一个名字认为是同一个用户

实现以及重构过程

基本的表结构

OrderContact 订单联系人表：跟订单是 1:1 的

order_id: integer
real_name: string
cellphone: string
email: string
***: 其他字段忽略

UserContact 常用旅客表：跟 User 是 N:1 的

user_id: integer
real_name: string
cellphone: string
email: string
***: 其他字段忽略

UserProfile 用户基本信息表，跟 User 是 1:1 的

user_id: integer
real_name: string
cellphone: string
email: string
****: 其他字段忽略

如果是你来实现这个需求，你会怎么写？hoho，请继续看下去吧！

# 最基本的几个关联关系
class User
  has_many :user_contacts
  has_one :user_profile
end
class Order
  has_one :order_contact
end
class UserContact
  belongs_to :user
end
class OrderContact
  belongs_to :order
end
class UserProfile
  belongs_to :user
end

第一次，常见 Rails 的写法

常见的 rails 的写法是，在 order_contact model 层添加 after_save 回调，分别去更新对应的 user_contact 和 user_profile 即可，写起来也会很快捷；

class OrderContact < ActiveRecord::Base
  belongs_to :order

  after_save :update_user_contact
  after_save :update_user_profile

  private
  def update_user_contact
    user_contact = order.user.user_contacts.by_real_name(real_name).first_or_initialize

    user_contact.email = self.email
    user_contact.cellphone = self.cellphone
    user_contact.real_name = self.real_name
    user_contact.save
  end
  def update_user_profile
    user_profile = order.user.user_profile

    user_profile.email = self.email
    user_profile.cellphone = self.cellphone
    user_profile.real_name = self.real_name
    user_profile.save
  end
end

class OrderController < ApplicationController
  def create
    # 创建订单的时候保存联系人信息
    @order = Order.create(params[:order])
    @order_contact = @order.create_order_contact(params[:order_contact])
  end
end

这样的写法有两个问题：

从当前的逻辑来看，所有的 order_contact 更新的时候都必须更新另外两个 model，可是可能马上需求就要变化。这种利用 callback 的写法，当需求变化的时候再改动就会比较困难，这个时候负责新功能的工程师需要理清楚原有的思路，并且必须陷入到 ActiveRecord 类中去；
例子中的 UserContact 类和 UserProfile 类，可能很快也会变化，这个时候直接在 order_contact 类中调用它们的 attribute=() 方法就显得很不合适了；至少这些类需要提供一个写接口，这样才能应对变化；

好，接下来就把上面两个缺点给重构掉：

重构一下，去掉回调

基本的策略是把 after_save 的回调，方法是在 controller 里面调用相关的方法了；然后我们要去掉直接在 model 里面去写另外一个 model 的逻辑，方法是让它提供相应的封装好的写接口；

提供封装好的写接口：

class OrderContact
  # 删除原有的 after_save 以及相关的方法
end
class UserContact
  def self.update_by_order_contact(user, order_contact)
    user_contact = user.user_contacts.by_real_name(real_name).first_or_initialize

    user_contact.real_name = order_contact.real_name
    user_contact.cellphone = order_contact.cellphone 
    user_contact.email = order_contact.email

    user_contact.save
  end
end

class UserProfile
  def self.update_by_order_contact(user, order_contact)
    user_profile = user.profile

    user_profile.real_name = order_contact.real_name
    user_profile.cellphone = order_contact.cellphone 
    user_profile.email = order_contact.email

    user_profile.save
  end
end

然后在 controller 里面直接调用

class OrderController < ApplicationController
  def create
    # 创建订单的时候保存联系人信息
    @order = Order.create(params[:order])
    @order_contact = @order.create_order_contact(params[:order_contact])

    # 调用写接口，更新user相关的信息
    UserProfile.update_by_order_contact(@order.user, @order_contact)
    UserContact.update_by_order_contact(@order.user, @order_contact)
  end
end

上面的代码利用类函数的方法把“写”代码移到了正确的类中，代码看起来清晰了一些，但是好像复杂性并没有降低，反而有点冗余了：

在 controller 中原来是自动调用，现在需要写独立的代码，以后将来又有了新的类，不只是 UserProfile 和 UserContact 呢？就得在很多地方多添加一行，比如新的类是 UserInfo，那在每个 controller 里面都必须都写一行；
静态函数里面其实隐含了一个需求，那就是更新常用联系人是根据真实姓名来更新的，在这一行里面提现：

user_contact = user.user_contacts.by_real_name(real_name).first_or_initialize

其实这个就是典型的业务逻辑了，显然也不应该放藏的这么深，将来也很难去维护。

那么，有没有更好的办法呢？

Service 出场，封装成 service

利用 service 的方法，我们把所有的业务逻辑抽离出来，把数据逻辑继续留在 model 层中；并且是把“更新用户信息”当做一个独立的小模块来实现，而现在这个 service 只提供一个接口，那就是根据 order_contact 来更新用户信息。

从这个角度看问题，我们创建 UserInfoService, 并且它的职责以及范围就很清楚了，继续往下改进：

model 层改成这个样子：

class UserContact < ActiveRecord::Base
  def update_by_order_contact(order_contact)
    self.real_name = order_contact.real_name
    self.cellphone = order_contact.cellphone 
    self.email = order_contact.email
    self.save
  end
end

class UserProfile < ActiveRecord::Base
  def update_by_order_contact(order_contact)
    self.real_name = order_contact.real_name
    self.cellphone = order_contact.cellphone 
    self.email = order_contact.email
    self.save
  end
end

新的 UserInfoService 只是一个简单的 ruby 类：

class UserInfoService
  def initialize(user)
    @user = user
  end

  def refresh_from_order_contact(order_contact)
    # 更新常用联系人
    user_contact = find_user_contact(order_contact.real_name)
    user_contact.update_by_order_contact(order_contact)

    # 更新用户个人信息
    @user.profile.update_by_order_contact(order_contact)
  end

  private
  def find_user_contact(real_name)
    @user.user_contacts.by_real_name(real_name).first_or_initialize
  end
end

新的控制器中代码的写法：

class OrderController < ApplicationController
  def create
    # 创建订单的时候保存联系人信息
    @order = Order.create(params[:order])
    @order_contact = @order.create_order_contact(params[:order_contact])

    # 调用写接口，更新user相关的信息
    UserInfoService.new(@order.user).refresh_by_order_contact(@order_contact)
  end
end

经过上面的改动，有没有感觉代码更清晰呢？这些写有下面几个好处：

把更新用户信息这个逻辑抽离，service 本身是可复用的，可以用在任何地方，包括 task；console 的调试等；
service 的接口很明确，就是根据 order_contact 更新用户的信息；如果以后有了新的需求，我们可以添加新的接口；如果原有的需求发生了变化，也可以修改目前的方法；都是很简单的。

总结

总结一下什么时候应该抽取 service:

当发生跨 model 的写的时候。这不是必然，但是可以认为是一个信号，表示你的业务逻辑开始变的复杂了。同时，当跨 model 的“写”都遵守了这个规则时，rails 的 model 层就会变成一个真正的 DAL（Data Access Layer），不再是混合了数据逻辑和业务逻辑的“Fat Model”；
一般来讲，callback 是要慎用的，特别是 callback 里面涉及到了调用其他 model、修改其他 model 的情况，这个时候就可以考虑把相关的逻辑抽成 service。

其他像文章最初提到的一些规则都比较模糊，需要经验丰富的工程师才能比较明确的判断，比如业务逻辑比较复杂、相对独立、将来可能会被升级成独立的模块的时候，这些需要一定的经验积累才比较容易判断。

service 的好处，基本上是抽象层独立的类之后的好处：

复用性比较好。因为是 ruby plain object，所以复用性上很简单，可以用在各种地方；
比较独立，可扩展性比较好。可以扩展 service，给它添加新的方法、修改原有的行为均可；
可测试性也会较好。

抽取 service 的本质是要把数据逻辑层和业务逻辑区别对待，让 model 层稍微轻一些；Rails 里面有 view logic、data logic、domain logic，把它们区别对待是最基本的，这样才能写出更清晰、可维护的大型应用来。

当然，上面的代码还有可以优化的空间，比如把 email、cellphone、real_name 作为一个结构体在各个接口之间传递，不过不是本篇关注的重点，就暂时不写了。

大概就是这些了，以上，欢迎指正。

[北京] 大鱼自助游诚聘 Ruby/ 前端 /Android/iOS 工程师

zamia — Mon, 20 Oct 2014 22:48:42 +0800

坐在世界 500 强格子间里的你，是不是也想做做真正喜欢的事情？过着朝九晚五安逸生活的你，改变世界的梦想还在吗？是时候走出你的舒适圈了吧？

讨厌低效率！讨厌阿谀奉承！讨厌复杂的人际关系！

如果你也不安现状，追求不一样的生活；

如果你也心中有爱，脚踏实地，也时而仰望星空；

如果你也极度热爱互联网，热爱创业，热爱旅行；

你，就是大鱼在找的人。

关于大鱼

大鱼致力于为中国人提供最优质的出境自由行服务，大鱼不要做第二个 tripadvisor 或者 booking.com, 大鱼要打造前所未有的海外旅游产品在线交易平台。是的，大鱼正在用互联网思维颠覆传统行业。

关于你未来的小伙伴

· 开放平等，高压有 (dou) 爱 (bi) 的氛围 · 有 Google、百度、微软出来的大牛， · 也有毕业不久的新鲜人 · 80 后为主，不拒绝 70 后，不歧视 90 后 · 水瓶、双子、天蝎居多， · 不羁放纵爱自由 · 他们的真面目是……http://www.fishtrip.cn/about_us

大鱼在找这样的人

大鱼能给你什么

· 开放的互联网创业环境 · 释放潜力、爆发小宇宙的平台 · 富有竞争力的薪资和贴心的住房补贴 · 厨艺高超的阿姨准备的午餐和下午茶， · 只是每天抢饭的场面略凶残，请准备好 · 成为大鱼 · 旅行猎人的机会， · 边旅行边赚钱， · 为大鱼在世界各地开疆拓土

推荐有奖

成功推荐你身边的朋友加入大鱼，将获得往返台北机票及三晚住宿！这么好的事情，走过路过不要过错啊喂！

欢迎你到北京南三环和我们聊聊，

也可以发送简历至 hr@fishtrip.cn 或 houmengnan@fishtrip.cn

感谢各位，我们等着你：）

[北京] 大鱼自助游招聘工程师 Ruby/ 前端 /iOS/Android

zamia — Wed, 23 Jul 2014 16:59:23 +0800

大鱼简介

大鱼是一家位于北京的互联网团队，官网是 www.fishtrip.cn 。我们致力于解决国内用户出境自由行中遇到的问题，通过提供最优质的境外自由行的服务，让用户直接找到当地的优质资源提供者，如民宿、体验活动、包车等，并且在大鱼上自由组装成自己的行程，提供一站式的自由行体验。大鱼目前开放了台湾、帕劳和巴西三个地区，接下来也马上会开放日本，敬请期待吧！

此次开放职位

Ruby on Rails 工程师 2~3 名薪资范围在 8K ~ 20K，根据能力可再面谈，从初学者到高手大牛我们都需要；基础要求是 1 年以上工作经验，编程基础扎实，乐于学习，开放的心态；全栈工程师优先，如果你懂底层、乐于学习业务、也能写前端那就更好了！

前端工程师 1~2 名薪资范围在 8K ~ 20K，期望经验比较丰富，能给大鱼的前端带来更多经验，以后能够带领前端团队；基础要求是 2 年以上前端经验，对 javascript、html5、css 等有较深的理解；如果你对产品和交互感兴趣，或者带过前端团队那就更匹配了；

Android/iOS 工程师 各 1 ~ 2 名薪资范围 10K ~ 20K，根据您的资历面谈，工程师或者经验丰富的工程师均可；基础要求是 1 年以上移动端工作经验，完整经历过至少一个 App 的开发设计和上线；如果您懂产品、对移动端有强烈的兴趣更好；

投递简历

mailto: hr@fishtrip.cn