falm (Jason)

[上海] 薄荷科技 2018 诚聘 Ruby 工程师

falm — Sat, 03 Mar 2018 11:22:44 +0800

关于薄荷

薄荷是一家在健康领域领先的移动互联网公司，主要产品包括“薄荷”、“食物库”、“萤火虫”和“超模 25”。“薄荷”是减肥第一应用，长期位于 App Store 健康健美榜和各大 Android 应用市场健康或生活类应用前列，总用户已达数千万级别。“食物库”是食物营养第一应用，拥有中国最全的食物营养数据。详细介绍看这里薄荷系列 app。详细介绍看这里薄荷系列 app。

薄荷是国内较早使用 Ruby 的公司，从 2007 年开始所有的后端核心系统全部基于 Ruby 构建。随着系统规模不断增长，使用 Ruby 过程中遇到很多问题和挑战，甚至受到过很多质疑，但是我们没有放弃，迎难而上，经受住了考验，我们一直对 Ruby 充满了爱和信心。薄荷技术团队崇尚极客精神，热情参与 Ruby 社区各种活动，经常分享我们技术演进的各种经验教训。

薄荷的后端团队

工程师们在打牌

娃娃机 代码写累了，走抓个娃娃

分享活动

薄荷的后端团队活跃于各种技术分享会，并且还经常作为分享嘉宾，分享一下薄荷在 Ruby 方面的使用经验。 上海 Ruby 线下活动 2016 年 5 月 21 日 SH ❤ Ruby 聚会 (薄荷主办)

薄荷工程师@RubyConfChina

RubyConfChina 2016

RubyConfChina 2017

薄荷后端团队在做什么

2018 年我们会有很多大动作，所以希望更多的 Ruby 小伙伴加入，薄荷的后端基本下面这四件事情。

设计和构建自动化服务系统，提供薄荷服务效率。
利用机器学习帮助薄荷 App 屏蔽广告和垃圾信息，给用户智能推荐健康知识
针对薄荷现有系统继续数据分析，统计和数据埋单
为薄荷 App 及 H5 应用开发 API 接口。

关于职位

我们希望你是有 1~3 年的后端开发经验（Ruby）工程师
熟练掌握 Ruby 和 Rails, 以及 Web 开发相关技术，追求极致用户体验；
编程基础良好，了解常见设计模式和编程最佳实践，追求优雅的代码；
热爱技术开发，有极客精神，参与过开源项目或常写技术博客加分哦！

加分项

Github 的开源项目比较活跃。
有自己的技术博客。
熟悉前端开发，有使用 React 的经验。

待遇

初中级职位 10~15k，高级职位 15~30k，上不封顶，每季度还可能有丰厚的绩效奖金。目前公司处于快速发展阶段，公司商业模式确定，营收稳健，并且已有顶尖美元风投基金加入（晨兴，SIG，DCM 和高通），前景可期。我们将把你视为伙伴，希望通过一起努力，能够提供超出你预期的回报。

工作环境

最后抛一下薄荷新办公室的照片，薄荷科技搬到世纪大道了，4 个线路的换乘站，陆家嘴中心位置，交通非常方便。

联系方式

最后快到碗里来，薄荷期待你的加入 E-mail: vincent(at)boohee.com

[RubyConfChina2017 话题分享] Ruby Web 实时通讯方案剖析 (资料和参会感受)

falm — Tue, 19 Sep 2017 20:59:20 +0800

首先非常感谢这次大会的组织者们（ @jasl @lgn21st @Rei @martin91 还有其他我不认识的小伙伴) 可以想象举办一个 500 人规模的技术大会，而且还要保持高质量是何其的不容易，谢谢你们。

其他讲师的分享

这里我先分享一下几个我印象比较深比较感兴趣的的讲师的演讲，（其他讲师的分享也很精彩，只不过有些并未涉猎）

nginx with ruby - @tylerdiaz

tylerdiaz 分享的主题的 mruby，据我了解是被广泛应用于日本的嵌入式开发领域。国内在这一块的应用没怎么听过，这也是 Ruby 社区近几年推的几个发展方向之一吧，国内的 Ruby 社区的路子相对来说没有那么宽。tylerdiaz 作为开场的英文演讲舞台风格非常好，尤其考虑到了我们英语可能听不懂听不清怕，刻意的把自己的语速降的很慢 (英文演讲的语速都比较快)。

异步编程奥德赛 - @dsh0416

之前队长有过多少次交流，在上海的分享会上也聊过关于异步编程的话题，midori 在我研究实时通讯的时候研究过它的源代码，本来是在我的分享上也准备了 midori 的介绍，不过后来看到队长的分享排在了我的前面，所以也就无所谓讲了，另外队长在台下和我说，这么多人的分享还是非常紧张的。不过他上台之后在聚光灯下，幽默风趣的演讲风格一点也看不出来紧张哈哈。

为 Ruby 设计一款 AOT - @psvr

这个工具做的很实用，我之前的工作中就是有一个将 Rails 项目打包发布的需求，当时考虑的还是使用 JRuby 打成一个 Jar 包进行处理，现在有这种解决方案，可以解决很多的现实问题。

金数据是如何鉴黄的 - @warmwind

金数据使用 SVM 做鉴黄的分享非常棒，近些年的技术发展的方向，Ruby 社区现在也开始关注机和实践机器学习了，薄荷其实也在广告过滤上面应用了机器学习不过使用的是贝叶斯方法。

机器学习入门 - @ihower
ihower 的分享作为机器学习的 101 非常不错，我之前对深度学习是没有什么了解的，其实在之前吃饭交流的时候，ihower 就已经给我们讲了一下关于深度神经网络的相关知识，可以说收获颇丰。

我的分享 - Ruby Web 实时通讯方案剖析

报名讲师的契机是在大会征集题目开始后，@vincent就和我说，我们要不要把最近这大半年在 Ruby Web 实时通讯上面的研究和实践给大家分享一下，（其实今年 3 月份的时候，Ruby 上海活动的时候分享了一下）这样我们才真正的把之前涉及到的关于 web 实时通讯的演讲的方案，重新整理，有些还不是很透彻的地方，有重新温习。最后整理出一份比较完整的介绍 RubyWeb 实时通讯方案的分享。

我自己的分享感觉语速和节奏没有控制好，有一有要讲的东西没表达出来，虽然我经常在公司内部做分享，但是十几二十人和 500 人还是比不了的。还有当@bhuztez 说出成功人士才跑 benchmark 之后压力山大，我的分享里面有六个 benchmark🤣。

Ruby Web 实时通讯方案剖析 Slides

下面内容是摘取自我在薄荷内部分享的关于实时通讯的四篇文章：

一 Hijacking API VS『native』Websocket

hijacking api 是在 Rack 1.5 是被加入的功能，因为 Rack API 本身无法支持想 http streaming websocket 这两长连接的请求，但是这个 API 是在 Rack 1.x 的临时方案，基本上不会再 Rack 2.0 中出现。

native websocket 这里的 native 是指定由 application server 提供内置的 websocket 功能，通过对外暴露 on_message on_open 这些回调接接口来进行请求处理，而不是像 hijacking API 通过直接暴露 socket io 对象。

HijackingAPI 和『native』websocket 的主要区别就是两种方式使用 reactor 和事件循环的数量。Hijacking API 是从 Server 中获取 socket，这就意味着应用程序需要自己监听 socket 的事件，因为这时候 server 已经忽略了这个 socket. 也就是说你需要自己在应用程序中管理你的 socket，再启动一个 reactor，一个事件循环器和线程池。使用 hijacking API 同时也需要应用程序自己去管理 socket 的 output buffer ( IO#write 和 read 在 network buffer 已满的时候，只能做部分写入或读取，application server 为处理 HTTP 请求的时候就已经内置该功能了，所以你又要为 websocket 在来实现一套）。

同样 websocket 协议的处理也是需要应用程序自己处理的（当然如果 server 和应用程序都没有使用 C 扩展或其他来加速处理协议的话，也无所谓）

总结下来没有使用 hijacking API 的“native”websocket 可以用少的代码和资源获得更好的性能，并且所有的事件和网络处理都可以集中一个模块还中，而 hijacking API 的实现需要在 server 和应用程序中各自实现一套。

二 Understanding Midori

注：本文基于 em-midori v0.4.1 版本所写

Midori从 web 框架的角度去看，它是一种类 Sinatra 式的 Web 开发框架，不同点就是它是基于事件循环模式的异步 web 框架，这样它真正要对标的就是 async_sinatra 这里的异步框架。与 sinatra 一样，midori 不是一个全栈式的 MVC 框架，当前版本强调的是通过 DSL 来到达简洁易用，快速构建 API 系统的 web 框架。

从 em-midori 开始 midori 底层使用的 I/O 库是 EventMachine，并且是用 EventMachine 事件循环库。后期的 midori 该为使用 nio4r 来作为底层支持，使用它的原因是 nio4r 的开发支持，稳定性和特性要比 EM 好。midori 的路由解析器使用了 sinatra 出品的 Mustermann，在这方面我觉得是做的比较好的，使用业界成熟的经过考验的组件，有助于提高框架的稳定性和实用性，并且在路由匹配功能上使用深度优先搜索算法，加快路由速度。

结构

大体上来说 midori 的架构是建立在 fiber 和 nio4r 之上，也是框架本身宣传的特点异步框架，那么底层就要使用支持异步的框架。Midori 是使用自制生态的 Muraski 组件来使用 nio4r 的，而 nio4r 底层又是使用 libev 网络库实现 I/O 能力的。

Midori 框架启动和接收请求的执行流程：

Runner

Midori 的启动器Midori::Runner的内部使用了 Ruby 标准库的 TCPServer 来启动 web 服务，在将端口 i/o 对象通过 EventLoop 注册到 nio4r 的监听器上，当有 socket 数据通过 I/O 端口发送过来后，就会执行回调函数，调用Midori::Connection来处理请求。

class Midori::Runner
  ...
  def start
    return false if running? || EventLoop.running?
    @logger.info "Midori #{Midori::VERSION} is now running on #{bind}:#{port}".blue
    @server = TCPServer.new(@bind, @port)
    EventLoop.register(@server, :r) do |monitor|
      socket = monitor.io.accept_nonblock
      connection = Midori::Connection.new(socket)
      connection.server_initialize(@api, @logger)
    end
    async_fiber(Fiber.new do
      @before.call
    end)
    EventLoop.start
    nil
  end
  ...
end

EventLoop

整个事件循环和监听 I/O 的 nio4r 都被封装在了 Muraski 组件中。其核心代码就是支持 I/O 事件回调函数和启动事件循环。

module EventLoop
  class << self
    def register(io, interest=(:rw), &callback)
      config if @selector.nil?
      if @queue[io.to_i].nil?
        @queue[io.to_i] = Array.new
        config if @selector.nil?
        @selector.register(io, interest)
        @ios[io] = { callback: callback }
      else
        @queue[io.to_i] << [io, interest, callback]
      end
      nil
    end

    def start
      return if running?
      @stop = false
      until @stop
        config if @selector.nil?
        @selector.select(0.2) do |monitor| # Timeout for 0.2 secs
          @ios[monitor.io][:callback].call(monitor)
        end
      timer_once
      end
      @stop = nil
    end
  end
end

Connection & Server

当 EventLoop 注册的回调函数被调用后，从框架的角度就是一个连接被建立一个请求被接受，那么接下来就需用 Connection 去处理连接，在 Connection 的内部非常有意思的是，其主要职责就是再注册一个事件循环器来持续监听建立起来的 socket 连接，剩下的处理请求的数据是交由 mixin 的 Server 模块处理。

class Midori::Connection
  include Midori::Server
  def listen(socket)
    EventLoop.register(socket, :rw) do |monitor|
      @monitor = monitor
      if monitor.readable?
        receive_data(monitor)
      end
      if monitor.writable?
        if !@data == ''
          monitor.io.write_nonblock(@data)
          @data = ''
        elsif @close_flag
          close_connection
        end
      end
    end
  end
end

这样分解的作用就是，Midori 是作用一个同事支持短连接和 websocket 长连接的 web 框架，底层的应用服务器部分也是要自己处理的（因为没有使用 Rack)。那么对一个长连接的数据不是在 socket 建立和就发送过来的，而是会持续不断的发送和接受直到连接关闭，所以 Midori 在主事件循环监听 I/O 端口外，还内嵌了事件循环监听特定 socket 连接。

Fiber

Midori 中 Fiber 使用的最大用途其实是在 midori-contrib 的数据库驱动中，以 mysql2 为例 midori 利用元编程打开了 mysql2 的 I/O 查询部分，使用 Fiber 在 I/O 阻塞的时候挂起，等 I/O 返回时候恢复。

socket = MYSQL_SOCKETS[conn.socket]
await(Promise.new do |resolve|
  count = 0
  EventLoop.register(socket, :rw) do
    if (count == 0)
      # Writable
      count += 1
      conn.query(sql,
        database_timezone: timezone,
        application_timezone: Sequel.application_timezone,
        stream: stream,
        async: true)
    else
      # Readable
      begin
        EventLoop.deregister(socket)
        resolve.call(conn.async_result)
      rescue ::Mysql2::Error => e
        resolve.call(PromiseException.new(e))
        next
      end
    end
  end
end)

http 请求和 websocket 也都是通过 Fiber 作为执行单元来执行。但是 Fiber 在这里并没有起到什么实质性的作用 fiber 被创建后就直接被执行了，期间也没有挂起调度。它可能是要在 Midori 未来的版本中会有特殊的用途，目前的版本是完全可以使用 proc 对象替代的。

module Midori::Server
  def receive_data(monitor)
    lambda do
      async_fiber(Fiber.new do
        begin
          _sock_domain, remote_port, _remote_hostname, remote_ip = monitor.io.peeraddr
          port, ip = remote_port, remote_ip
          @request.ip = ip
          @request.port = port
          data = monitor.io.read_nonblock(16_384)
          if @request.parsed? && @request.body_parsed?
            websocket_request(StringIO.new(data))
          else
            @request.parse(data)
            receive_new_request if @request.parsed && @request.body_parsed?
          end
        rescue => e
          close_connection
          @logger.warn "#{@request.ip} - - #{e.class} #{e.backtrace.join("\n")}".yellow
        end
      end)
    end.call
  end
end

最后

Midori 作为一个年轻的 Ruby Web 框架站在巨人的肩膀上，做出了不错的性能，而且是国人所做，所以应当支持和鼓励，但是客观的说在目前国内的 Ruby 生产实践中，依然是以 Rails 为核心的全栈式 web 框架为主流，类似 sinatra 或其他的异步框架，市场份额非常少而且 Midori 现在发布稳定的正式版。另外从性能角度看 Midor 上随有优势，但按照 roadmap v2.0 版本，要支持 MVC 和 http2，在性能上难免有所下降。

造轮子容易，用轮子难，所以希望 Midori 项目能够改进不足，补齐文档，多加宣传。主厨推荐 (Omakase) 吃了这么多年，是不是该换换口味了。

三 Reactor & I/O 多路复用

I/O 多路复用

当应用程序（用户线程或进程）发送监听端口的系统调用后，内核会在自身不断的轮询给端口看看是否有网络数据到了（socket 套接字）如果有数据到了，就会通知刚才的用户线程，在这个阶段 I/O 还是阻塞的，但是不同点就是它在发送监听系统调用的时候是可以监听多个套接字的，这也就是在同一个路径是复用了 I/O，剩下其他的部分和 I/O 阻塞都是差不多的，别小看这点改进，在多路复用情况下，select 系统调用在 64bit 系统上可以切换处理 2048 个 socket，这样的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。

那么我们常用的 libevent 框架，它的底层就是使用了这个这些 I/O 多路复用的系统调用，包括 select epoll poll 和 kqueue，（这里说一下 libevent 是跨平台的事件驱动系统函数库，主要作用就是抹平了，不同操作系统对于 I/O 多路复用系统调用函数的不同 API，（就是统一 API) )

epoll 和 kqueue 是这个模型上的 select 和 poll 的升级版，目前最流行使用（包括 nginx nodejs) 主要区别就是 select 在它监听的所有 socket(fd) 有任意一个有数据返回了，内核就会将所有的 fd 都复制会用户线程中，然后再由 select 去遍历看看到底是哪一个 fd 有数据了，最后再处理请求。而 epoll 是使用了一个 callback 的机制，在它监听的每一个 fd 上都有一个 callback，当内核收到数据后，就会使用有数据的 fd 的 callback 通知 epoll，具体是哪一个 fd 有了数据，然后在处理特定的请求，这样的好处就是可以有效减少 fd 集合在内核和用户空间之间的复制操作。

reactor

是一种服务器端的事件驱动模式，服务处理程序使用解多路分配策略，底层是一种 I/O 的多路复用，I/O 同步非阻塞它的是有以下几个部分组成：

事件源 input 输入具体可以是 Linux 上的 fd(file description) windows 上的 socket。
event demultiplexer 事件多路分发机制。它是使用操作系统提供的 I/O 多路复用机制实现的，select epoll 这都是操作系统上的 I/O 多路复用系统调用函数。它的处理过程是需要，先在分发器上注册具体的事件源，然后等待 reactor 通知触发特定的事件源对用的事件处理器。
reactor 反应器是事件管理器，
事件处理器

EventMachine 实际上在事件驱动模型上就是根据 reactor 模式实现的，上面介绍了它的工作原理，我们再看看它的优点：

响应快，不必为单个同步时间所阻塞，虽然 Reactor 本身依然是同步的
编程相对简单，可以最大程序避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销
可扩展性，可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源
可复用性，Reactor 框架本身与具体事件处理逻辑无关，具有很高的复用性

四 - 使用 C 提高 Web 实时性能 - Iodine

iodine 是支持 rack 的，事件驱动并发框架，作为 plezi 的底层库，基本上 I/O，多线程，pub/sub 都是使用 iodine 来实现的

Websockets

iodine 处理 websocket 的方式与其他 Rack based 的 server 有所不同，它没有使用 rack.env 的 hijack API 来截获 websocket upgrade 请求，而是使用 C 扩展在 Ruby 处理请求之前，就在 socket 上判断是否为 websocket upgrade 请求然后，再执行 websocket parser（在 Ruby 之前运行所以不受 GIL 的影响，parser 是 CPU 密集操作如果有 GIL 的话多个 I/O 请求需要排队执行 parser）最后设置 rack.env[websocket.upgrade?] 变量后面的 rack app 自行判断如何处理 websocket upgrade 请求。

PubSub

iodine 底层使用了 facil.io 库提供原生的 pub/sub 支持，同时也可以通过 Redis 进行扩展，iodine 的 RedisEngine 支持 redis 单机和集群两种模式。并且Iodine::PubSub::RedisEngine的 Redis 客户端是异步非阻塞的客户端。

require 'uri'
# 使用Redis 作为pub/sub queue
uri = URI(ENV["REDIS_URL"])
Iodine.default_pubsub = Iodine::PubSub::RedisEngine.new(uri.host, uri.port, 0, uri.password)
# 非阻塞Redis Client 发送命令使用block 回调
Iodine.default_pubsub.send("CLIENT LIST") { |reply| puts reply }

GIL & Lock

Iodine 使用里多线程（pthread) 处理一些可以并行执行的任务（例如协议解析）因有共享资源处理，所以 iodine 使用了 spin-locks，在处理锁的问题上，得益于应用使用同一个 reactor, 服务器可以检查资源锁的状态，然后重新调整安排其他任务的执行，最大化利用资源。多线程并行执行因为在 C 层面使用 pthread 处理，所以在事件转移到上层的应用程序之前，内部的处理都是不受 GIL 的影响的。

参考资料

支撑 ActionCable 的底层库
 I/O 模型
 Unix 网络编程
 Websocket / Upgrade support proposal

Ruby 3 Guilds 并发模型

falm — Mon, 17 Oct 2016 14:44:18 +0800

文本为翻译 Olivier Lacan 在其博客上发布的关于 Ruby 3 Guilds 介绍的文章。我对内容上做了适当的调整，这里给大家分享一下，翻译水平有限，见谅了。

英文原文地址：http://olivierlacan.com/posts/concurrency-in-ruby-3-with-guilds/

在 Ruby Kaigi 2016 大会上，Ruby VM 和 GC 的作者 Koichi Sasada 为 Ruby 3 提出了一个新的并发模型。

我们都知道 Ruby 提供了线程去实现并发，但是 MRI 并不能让 Ruby 的代码并行的运行。Koichi 致力于解决 Ruby 并行中，遇到的各种挑战，包括可变对象，竞态条件和线程间同步，最终他提出了一个新的并行并发机制，称为 Guilds。

并发的目标

如果你对并发和并行不太了解，可以先阅读一下这篇文章：并发与并行的区别。

为 Ruby3 提出 Guilds 的基本前提是，保证与 Ruby2 兼容的情况下实现并行，考虑到 GIL 限制了并行，所以要尝试通过使用快速对象共享和特殊结构对象，来实现共享可变对象。

实现并发在目前的 Ruby 版本中是一件很困难的事情，这因为程序员需要手动的管理线程，确保不会出现竞态条件。通用的做法是在线程中引入『锁』，像 Ruby 就提供了线程互斥锁，但它或多或少违反了并行的初衷，『锁』容易使程序变慢，而且不当使用的话，很可能使得并发程序比相同的同步程序还要慢。

Guilds 工作原理

在Koichi的允许下，我为了让它更好理解，就对他的提案做了适当的缩减。

Guild 是基于现有的线程 (thread) 和纤程 (fiber) 实现的。它至少由一个线程组成，并且该线程至少由一个纤程组成。不同 Guild 中的线程可以并行运行，而相同 Guild 中的线程不能。一个 Guild 不能对其他 Guild 中的对象进行读写。

同一个 Guild 中的不同线程不能并行运行，这是因为 Guild 存在一个叫 GGL(Giant Guild Lock) 的锁，它是用来确保线程是先后运行的，而不同 Gulid 的线程是可以并行运行的。

你也可以认为 Ruby 2.x 的程序，就相等于是存在一个 Guild 的程序。

Guilds 间通信

不同 Guild 间不可以相互读写可变对象，这保证了 Guild 并发运行时，不会因为并发读写而引发问题。

不过，Guild 可以通过Guild::Channel 提供的接口，将对象复制或移动到其他的 Guild 中。

Guild::Channel-transfer(object)可以将一个对象深度拷贝到目标 Guild 中。

同样也可以使用，Guild::Channel中的transfer_membership(object)将一个对象完全移动到其他的 Guild 中。

一旦对象被移动到新的 Guild 后，如果原来持有该对象的 Guild 再对它进行访问，将会抛出异常。

这里我们就知道了，Guild 是不能在没有复制或移动的情况下共享可变对象的，还有一点非常重要，那就是不可变对象（immutable objects）在『深度冻结』（意思是被该对象引用的对象也是冻结不可变的）的情况下是可以直接在多个 Guild 间共享的。

下面这个例子，展示可变和不可变对象的区别：

# 像整数，这样的数值类型，默认就是不可变的，而哈希不是。
mutable = [1, { "key" => "value" }, 3].freeze

# 而如果 数组实例及其引用的，字符串和哈希的实例都进行冻结，
# 就会得到一个"深度冻结" 的不可变对象。
immutable = [
  "bar".freeze,
  { "key" => "value".freeze }.freeze
].freeze

使用方法

在 Koichi Sasada 的研究中，他给出了几个关于如何使用 Guilds 的例子，我在这里将其中最小的，关于使用 Guild 并行计算『斐波那契』的例子进行了简化进行展示。

def fibonacci(n)
  return n if n <= 1
  fibonacci( n - 1 ) + fibonacci( n - 2 )
end

guild_fibonacci = Guild.new(script: %q{
  channel = Guild.default_channel

  while(n, return_channel = channel.receive)
    return_channel.transfer( fibonacci(n) )
  end
})

channel = Guild::Channel.new 
guild_fibonacci.transfer([3, channel])

puts channel.receive

Guild 对比线程的优势

在线程中，我们很难判别出，哪些可变对象已经被共享了。而 Guilds 禁止可变对象的共享，转而提供一个简单的方式去共享不可变对象，而且 Koichi 计划，通过使用『特殊数据结构』来共享可变对象，『特殊数据结构』会自动隔离有风险的可变代码。

当然，使用 Guilds 相较于线程来说，有些繁琐，这也是需要有取舍的。

性能

我的理解是，目前 Guilds 的"C"实现仅有 400 行代码，虽然该实现现阶段还不能用，但 Koichi 展示了，运行多个 Guilds 相比于运行单个 Guilds 在斐波那契例子上的性能优势。

在双核的 Linux 虚拟机上运行 Window 7，Koichi 观察到以下结果：

这也许不能代表，现实场景中大部分 Ruby 应用会得到性能上的提升，但我还是等不及想知道，Guilds 在RubyBench上的测试结果。

总结

Guilds 是一种面向 Ruby 的，简单易用并且安全的并发方式，非常希望 Koichi Sasada 和 Ruby 核心团队能在之后，分享更多关于 Guilds 的信息。

我对 Guilds 中移动和复制对象的方法的命名，有一些小看法，因为Guild::Channel. transfer(object)看上去更像是交换的意思，而结果仅仅是对象的深度拷贝，我相信transfer_copy(object)或是更简单的copy(object) 更加适合。还有transfer_membership(object) 移动对象的方法，可以简化命名为channel.transfer(object) 。当然了这些方法的命名也不会是一成不变的。

我非常期望，Ruby 核心团队能够将这个新功能，作为实验性质的可选功能发布出去，这样 Ruby 社区就能参与进去帮助改进和测试。还可以让我们在 2020 年的 Ruby3 版本之前，就使用上这个新特性。Guilds 将会对 Ruby 在并发友好性上，做出了积极的影响。

聊一聊 ActionCable 背后的技术

falm — Mon, 11 Jul 2016 10:49:44 +0800

Rails5 中引入的可以实现实时通讯的新功能，ActionCable，可以说是这个版本的 Rails 的重大特性之一，ActionCable 底层究竟是如何进行通讯，本文就来聊一聊这些相关的技术。

WebSocket

简单的说，websocket 是一个基于 TCP 的应用层协议，使用 http 协议建立连接，并且能够通过一个已经建立的连接，进行双向的通讯，也就是不仅仅能够从客户端发送信息到服务器端，服务端还可以推送信息到客户端，而且这一切的是建立在一个连接中进行的，有了它我们就不需要再使用，polling 或 long polling 做轮询信息了。

它的通讯过程是，通过向 http 头添加特定信息，然后发送到服务器，如果服务器能够支持 websocket 的话，就会识别出 http 头中关于 websocket 的信息，并且升级 http 连接为 websocket 连接并返回，一个同样包含 websocket 头信息的 http response，这样下来，客户端和服务器的连接就已经建立了，直到一方关闭连接。

请求：


GET /cable HTTP/1.1
Host: example.com:3000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

应答：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

上面的请求和应答头中 upgrade: websocket代表着这是一个 websocket 的连接请求，Sec-WebSocket-Key 和 Sec-WebSocket-Accept，是用于确认服务器是否真的，能够出来 websocket 请求的验证方式，过程是，服务器端介绍到 websocket-key 后，通过组合magic string，之后再进行 SHA-1 和 base64 编码，然后以 Sec-WebSocket-Accept 返回给客户端，客户端接受到后验证正确，这就表明服务器真正的可以处理 websocket 请求了。

如何使用 Websocket

ActionCable 本身可以作为一个单独的服务，绑定到单独的端口上运行，也可以与 rails 一起在同一个端口上一起启动运行，这是因为它实际上是一个处理 websocket 的 rack app。

单独启动的 ActionCable Server，先加载 Rails 环境，然后再运行的 rack app。

# cable/config.ru
require ::File.expand_path('../../config/environment', __FILE__)
Rails.application.eager_load!

run ActionCable.server

与 Rails 一同启动的时候，是通过挂载 ActionCable.server 到指定的 PATH 上。

# actioncable/lib/action_cable/engine.rb
    initializer "action_cable.routes" do
      config.after_initialize do |app|
        config = app.config
        unless config.action_cable.mount_path.nil?
          app.routes.prepend do
            mount ActionCable.server => config.action_cable.mount_path, internal: true
          end
        end
      end
    end

不管是，单独端口启动的 ActionCable，或是与 Rails 一同启动的。它们实际都是用 rack up 作为统一入口的。

# actioncable/lib/action_cable/connection/base.rb
# Called by Rack to setup the server.
def call(env)
  setup_heartbeat_timer
  config.connection_class.call.new(self, env).process
end

call 方法中第一是，每个三秒发送一个心跳包到客户端，已确定连接是否还可用，第二行就是初始化 action-cable 自己的连接类，执行响应。

# actioncable/lib/action_cable/connection/base.rb
def process #:nodoc:
  logger.info started_request_message

  if websocket.possible? && allow_request_origin?
    respond_to_successful_request
  else
    respond_to_invalid_request
  end
end

首先输出日志表示请求已经接受，然后判断请求是否为 websocket，并且判断 HTTP_ORIGIN 是否允许。

# actioncable/lib/action_cable/connection/base.rb
def respond_to_successful_request
  logger.info successful_request_message # 输出日志：成功升级连接为 Websocket
  websocket.rack_response # 调用 websocket对象，返回websocket响应。
end

走到这一步，服务器端的连接已经确认是可以继续 websocket 通讯了，但是与客户端的握手还没有完成，还需要发送一个，验证服务器端接受并有能力处理 websocket 的信息给客户端。

可以从下面看出来，action-cable 使用了Websocket-driver 这个 Gem 来完成 websocket 的通讯工作。


# actioncable/lib/action_cable/connection/web_socket.rb
require 'websocket/driver'

module ActionCable
  module Connection
    # Wrap the real socket to minimize the externally-presented API
    class WebSocket
      def initialize(env, event_target, event_loop, client_socket_class, protocols: ActionCable::INTERNAL[:protocols])
        @websocket = ::WebSocket::Driver.websocket?(env) ? client_socket_class.new(env, event_target, event_loop, protocols) : nil
      end

      def possible?
        websocket
      end

      def alive?
        websocket && websocket.alive?
      end

      def transmit(data)
        websocket.transmit data
      end

      def close
        websocket.close
      end

      def protocol
        websocket.protocol
      end

      def rack_response
        websocket.rack_response
      end

      protected
        attr_reader :websocket
    end
  end
end

# actioncable/lib/action_cable/connection/client_socket.rb

module ActionCable
  module Connection
    class ClientSocket
      def initialize(env, event_target, event_loop, protocols)
        ············
        @driver = ::WebSocket::Driver.rack(self, protocols: protocols)
        @driver.on(:open)    { |e| open }
        @driver.on(:message) { |e| receive_message(e.data) }
        @driver.on(:close)   { |e| begin_close(e.reason, e.code) }
        @driver.on(:error)   { |e| emit_error(e.message) }
        ············
      end
    end
  end
end

那么接下来就不得不讲一讲，websocket-driver 这个 Gem 了。

websocket-driver

简单的说，websocket-driver 是一个利用，EventMachine，来读写 socket-io 对象的驱动器。使用了它的 API 就可以很轻松的实现 websocket-server。

websocket-driver 提供了一个基于 rack 的接口，action-cable 就是使用这个接口进行通讯的。下面的代码通过一个 socket 代理对象，初始化一个 driver，然后再向客户端发送一段信息。这里最重要的地方就是，被传入的 socket 代理对象，它必须能够响应三个方法，env，url，和write，分别是告诉 driver 向哪个 URL，如何发送信息。这里的 env 返回的就是 rack app 的 env 变量，webscoket-driver 实际上就是利用 Rack hijacking API 来实现获取 socket-io 对象进行读写的，所以 action-cable 基于 websocket-driver 就代表着像 webrick 这类不支持 full hijacking API 的应用程序服务器，也不能支持 action-cable。

driver = WebSocket::Driver.rack(socket, options)
driver.text "I'm websocket server"

使用 rack hijacking API

require 'websocket/driver'
require 'eventmachine'

class WS
  attr_reader :env, :url

  def initialize(env)
    @env = env

    secure = Rack::Request.new(env).ssl?
    scheme = secure ? 'wss:' : 'ws:'
    @url = scheme + '//' + env['HTTP_HOST'] + env['REQUEST_URI']

    @driver = WebSocket::Driver.rack(self)

    env['rack.hijack'].call
    @io = env['rack.hijack_io']

    EM.attach(@io, Reader) { |conn| conn.driver = @driver }

    @driver.start
  end

  def write(string)
    @io.write(string)
  end

  module Reader
    attr_writer :driver

    def receive_data(string)
      @driver.parse(string)
    end
  end
end

Rack hijacking API

Rack hijacking API 是在 Rack 1.5 中引入的，hijack 即为劫持，听起来好想是挺危险的样子，不过其实只是名字而已，它实际上是通过支持 Rack 的应用程序服务器上，拦截下 client 端的请求和 server 的相应的 Rack 的 hijacking API 提供了两种模式：

全部劫持 (full hijacking)，在这个模式下应用对 socket 传输的数据有绝对的控制权，也就是应用程序服务器，将对 socket 的控制权移交给你应用程序本身去处理，通过这个特性我们就可以实现任意应用层协议的传输，比如 websocket 协议。当然这些也是有一个大前提的，就是如果你的应用程序服务器 (puma) 前端有反向代理 (nginx) 或者负载均衡器的话，应用程序只能通过 socket 传输它们两个支持的协议。
部分劫持 (partial hijacking)，而这个模式下应用程序可以在应用程序服务器设置完成 header 后，进行控制。 hijacking API 可以通过 Rack 的env变量访问，要想知道应用程序服务器是否支持 hajacking API，要通过 env['hijacking?']来判断，它会返回一个布尔值。

接下来我们就通过 full hijacking 来写一个能够同时处理 HTTP 请求和 websocket 请求的 rack app 下面的代码通过env['rack.hijack'].call来运行 full hijack，再使用env['rack.hijack_io']返回 socket 对象，然后我们就可以通过这个 socket 对象进行通信了。

#encoding: utf-8
require 'thread'

def websocket(env)
  env['rack.hijack'].call
  io = env['rack.hijack_io']
  begin
    start   = 'HTTP/1.1 101 Switching Protocols'
    headers = [start, 'Upgrade: websocket', 'Connection: Upgrade', '']
    io.write  headers.join("\r\n")
    io.write("\r\n")
    10.times do |i|
      io.write("Line #{i + 1}!\n")
      io.flush
      sleep 1
    end
  ensure
    io.close
  end
end

def http(env)
  ['200', {'Content-Type' => 'text/html'}, ['Normal HTTP']]
end

app = lambda do |env|
  if env['REQUEST_URI'] == '/cable' && env['HTTP_UPGRADE'] == 'websocket'
    websocket env
  else
    http env
  end
end

run app

上面的 Rack app 使用了两个方法分别处理，HTTP 和 websocket 请求，其中 webscoket 处理绑定在 '/cable'这个 URI 上。websocket 方法接受一个 rack env 变量，进行 websocket 处理，首先是运行 full hijack，然后再通过 socket 对象返回 websocket response header，这样就与客户端建立了 websocket 连接，并在连接上每个 1 秒发送一个消息，共 10 个。

这个例子中的 websocket 方法是不严谨的仅作为参考。首先是判断请求是否是 websocket 请求，再一个是 reponse header 中缺少对 websocket-key 进行加密，然后返回的 WebSocket-Accept。

使用 Puma 运行

$ puma app.ru
Puma starting in single mode...
* Version 3.4.0 (ruby 2.3.0-p0), codename: Owl Bowl Brawl
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:9292

首先发送一个常规的 HTTP 请求

$ curl -X GET -i -H "Cache-Control: no-cache" "http://localhost:9292"
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 11

Normal HTTP%

接下来在发送一个 websocket 请求：

通过 socket 对象连续发送 10 行数据后，关闭连接。

总结

ActionCable 最底层是一个利用 rack hijacking 和 EventMachine 的 Rack App，通过不断地使用 websocket-driver 和自身的抽象封装，在上层提供了一个非常好用的方法，与 rails server 也可以无缝的结合在一起。

原文地址