如何在Ruby中编写微服务？

【编者按】本文做者为 Pierpaolo Frasa，文章经过详细的案例，介绍了在Ruby中编写微服务时所需注意的方方面面。系国内 ITOM 管理平台 OneAPM 编译呈现。

最近，你们都认为应当采用微服务架构。可是，又有多少相关教程呢？咱们来看看这篇关于用Ruby编写微服务的文章吧。

人人都在讨论微服务，但我至今也没见过几篇有关用Ruby编写微服务的、像样的教程。这多是由于许多Ruby开发人员仍然最喜欢Rails架构（这没什么很差，Rails自己也没什么很差，可是Ruby能够作到的事还有不少呢。）

因此，我想出一份力。让咱们先来看看如何在Ruby中编写和部署微服务。

想象一下这个场景：咱们须要编写一个微服务，其职责是发邮件。它收到的信息以下：

{  
  'provider': 'mandrill',  
  'template': 'invoice',  
  'from': 'support@company.com',  
  'to': 'user@example.com',  
  'replacements': {    
  'salutation': 'Jack',    
  'year': '2016'
  }
}

它的任务是替换掉模板中的某些变量，而后把发票邮件发送至user@example.com。（咱们用mandrill做为邮件API的供应商，使人忧伤的是，mandrill即将要中止服务了。）

这个例子很是适合使用微服务，由于它很小，并且只关注某个功能点，接口也定义得很清晰。所以，当咱们在工做中决定要重写邮件基础结构时，咱们就会这样作。

若是咱们有一个微服务，咱们须要找到一个方法，向它发送一些信息。也就是传递消息队列的方法。有许许多多可选的消息系统，你能够随便选择一个本身喜欢的。咱们这里选取的是RabbitMQ，由于：

• 它很普及，并且是按照标准（AMQP）来编码的。

• 它已与多种语言绑定，所以很是适合多语言环境。我喜欢用Ruby来编写应用（也以为它比其余的语言更好），但我并不认为目前Ruby适用于全部的问题，也不认为未来会是这样。所以，咱们也有可能须要用Elixir编写一个发送邮件的应用（写起来也不会很困难）。

• 它很是灵活，能够适应各类工做流 – 能够适应简单的在后台处理消息队列的工做流（这是本文的重点讨论对象），也能够适应复杂的消息交换工做流（甚至是RPC）。网站上有许多的例子。

• 经过浏览器便可访问它的管理员面板，这面板很是有用。

• 它拥有有许多托管解决方案（你能够在你最喜欢的包管理器中找资源，从而进行开发）。

• 它是用Erlang编写的，Erlang的程序员们很好地处理了并发问题。

用RabbitMQ 把消息放入队列中很是简单，就像下面这样：

require 'bunny'
require 'json'

connection = Bunny.new
connection.start
channel = connection.create_channel
queue = channel.queue 'mails', durable: true

json = { ... }.to_json
queue.publish json
connection.close

bunny是RabbitMQ的标准gem，当咱们不传任何项给Bunny.new时，它会假设RabbitMQ有标准的证书，是在localhost:5672上运行的。而后咱们（通过一系列设置）链接到一个名为“mails”的消息队列。若是这个队列还不存在，系统会建立这个队列；若是已存在，系统会直接链接。接着咱们能够直接对这个队列发布任何消息（例如，咱们上面的发票消息）。在这里咱们使用JSON，但事实上，你可使用任何你喜欢的格式（BSON、Protocol Buffers，或者随便啥），RabbitMQ并不关心。

如今，咱们已经解决了producer端，但咱们仍然须要一个应用接受并处理消息。咱们使用的是snearkers。sneakers是围绕RabbitMQ的一个压缩gem。若是你想要作一些后台处理，它会把你最可能要用到的RabbitMQ的子集暴露给你，可是底层仍是RabbitMQ的。有了sneakers（sneakers是受到sidekiq启发而来的），咱们能够设置一个“worker”去处理咱们的消息发送请求：

require 'sneakers'
require 'json'
require 'mandrill_api/provider'

class Mailer
  include Sneakers::Worker
  from_queue 'mails'
  
  def work(message)
    puts "RECEIVED: #{message}"
    option = JSON.parse(message)
    MandrillApi::Provider.new.deliver(options)
    ack!
  end
end

咱们必须明确从哪一个队列读取消息（即“mails”），以及consume消息的work方法，咱们先解析消息（以前咱们已经说过用JSON格式–可是再说明一次，你能够选择任何格式，RabbitMQ或者sneakers并不关心格式问题）。接着咱们把消息散列传给一些内部的实际工做的类。最后，咱们必须通知系统消息已收到，不然RabbitMQ就会把消息从新放回队列中。若是你想拒绝某条消息，或者作别的操做，snearkers的wiki中有方法。为了掌握状况，咱们还在里面加入了日志功能（稍后咱们会解释为何日志为标准输出）。

可是一个程序不能只有一个类。因此咱们须要建起一个项目结构–这个对于Rails开发人员来讲是比较陌生的，由于一般咱们只须要运行rails new，而后全部的东西都设置好了。在此处我想多扩展一下。咱们的项目树完成之后差很少是这样的：

.
├── Gemfile
├── Gemfile.lock
├── Procfile
├── README.md
├── bin
│   └── mailer
├── config
│   ├── deploy/...
│   ├── deploy.rb
│   ├── settings.yml
│   └── setup.rb
├── examples
│   └── mail.rb
├── lib
│   ├── mailer.rb
│   └── mandrill_api/...
└── spec
    ├── acceptance/...
    ├── acceptance_helper.rb
    ├── lib/...
    └── spec_helper.rb

这当中有一部分是能够自我说明的，例如Gemfile(\.lock)?以及readme。咱们也不用过多的解释spec文件夹，只须要知道，照惯例咱们在这个目录下放了两个helper文件，一个（spec_helper.rb）用于进行快速单元测试，另外一个（acceptance_helper.rb）用于验收测试。验收测试须要设置更多东西（例如，模拟真实的HTTP请求）。lib文件夹也跟咱们的主题不太相关，咱们能够看到里面有一个lib/mailer.rb（这就是咱们上面定义的worker类），剩下的一个文件是专门针对个性服务的。examples/mail.rb文件是示例邮件的编队代码，如同上文中的同样。咱们能够随时用它发起手动测试。如今我想着重讨论一下config/setup.rb文件。这是咱们一般在一开始就会加载的文件（即便是在spec_helper.rb）。因此咱们并不须要它作太多事情（不然你的测试就会变得很慢）。在咱们的例子中，它是这样的：

require 'bundler/setup'

lib_path = File.expand_path '../../lib', __FILE__
$LOAD_PATH.unshift lib_path

ENVIRONMENT = ENV['ENVIRONMENT'] || 'development'

require 'yaml'
settings_file = File.expand_path '../settings.yml', __FILE__
SETTINGS = YAML.load_file(settings_file)[ENVIRONMENT]

if %w(development test).include? ENVIRONMENT
  require 'byebug'
end

这里最重要的就是设定加载路径。首先，咱们引入bundler/setup，由此咱们能够经过gem的名称来引入各个gem。接着，咱们把服务的lib文件夹加入加载路径。这意味着咱们能够作不少事，例如引入mandrill_api/provider，它能够从<project_root>/ lib/mandrill_api/provider中找到。咱们之因此这样作，是由于你们都不喜欢相对路径。请注意，咱们没有在Rails中使用自动加载。咱们也没有调用Bundler.require，由于这样会引入Gemfile当中的全部gem。这意味着你得本身明确调用你须要的依赖项（gem或者是lib文件）（我以为这样挺好的）。

另外，我挺喜欢Rails的多环境。在上面的例子中，咱们是经过UNIX环境变量ENVIRONMENT来加载的。咱们还须要进行一些设置（例如RabbitMQ链接选项，或者是咱们服务所使用的某些API的密钥）。这些应当依赖于环境，因此咱们加载了一个YAML文件，而后把它变成了全局变量。

最后，这样的代码能够保证在开发和测试的过程当中，只要提早引入，你随时能够加入byebug（Ruby 2.x的debug工具）。若是你担忧速度问题的话（它确实须要花点时间），你能够把它拿掉，须要的时候再放进来，或者是加入一个猴子补丁：

if %w(development test).include? ENVIRONMENT
  class Object
    def byebug
      require 'byebug'
      super
    end
  end
end

如今，咱们有了一个worker类，和一个大体的项目结构。咱们只须要通知sneakers运行worker便可，这是咱们在bin/mailer里所作的：

#!/usr/bin/env ruby
require_relative '../config/setup'
require 'sneakers/runner'
require 'logger'
require 'mailer'
require 'httplog'

Sneakers.configure(
  amqp: SETTINGS['amqp_url'],
  daemonize: false,
  log: STDOUT
)
Sneakers.logger.level = Logger::INFO
Httplog.options[:log_headers] = true

Sneakers::Runner.new([Mailer]).run

请注意这是可执行的（看看开头的#!），因此咱们无需ruby命令，能够直接运行。首先，咱们加载设置文件（在这得使用一个相对路径），接着加载其余的须要的东西，包括咱们的邮件worker类。

这里比较重要的是配置sneakers：amqp参数会接受一个针对RabbitMQ链接的URL，这能够从设置中加载而来。咱们能够通知sneakers在前台运行，并记录日志为标准输出。接着，咱们给sneakers一个worker类的数组，让sneakers运行这个数组。一样咱们也须要一个带有日志的库，这样咱们能够动态观察状况。httplog gem会记录下全部向外发送的请求，这对于与外部API通讯来讲很是有用（在这咱们也让它记录下HTTP headers，但这不是默认设置）。

如今运行bin/mailer ，就会变成下面这样：

... WARN: Loading runner configuration...
... INFO: New configuration:
#<Sneakers::Configuration:0x007f96229f5f28 ...>
... INFO: Heartbeat interval used (in seconds): 2

可是实际的输出其实要冗长的多！

若是你让它继续运行，而后在另外一个终端窗口中运行咱们上面的编队脚本，就会获得下面的结果：

... RECEIVED: {"provider":"mandrill","template":"invoice", ...}
D, ... [httplog] Sending: POST
https://mandrillapp.com:443/api/1.0/messages/send-template.json
D, ... [httplog] Data: {"template_name":"invoice", ...}
D, ... [httplog] Connecting: mandrillapp.com:443
D, ... [httplog] Status: 200
D, ... [httplog] Response:
[{"email":"user@example.com","status":"sent", ...}]
D, ... [httplog] Benchmark: 1.698229061003076 seconds

（这里也是简化版本！）

这里的信息量至关大，特别是开始的部分，固然，此后你能够根据须要去掉部分日志。

以上给出了基本的项目结构，此外还要作什么呢？呃，还有个困难的部分：部署。

在部署微服务（或者，整体来讲，部署任何应用程序）时，要注意许多事项，包括：

• 你会想把它作成守护进程（即让它在后台运行）。咱们能够在上面设置sneakers的时候就作好这点，但我倾向于不那样作——开发过程当中，我但愿能看到日志输出，而且能够用CTRL+C来杀死进程。

• 你会想要一份合理的日志。所谓合理，是指确保日志文件最后不会填满硬盘，或者变得巨大无比以致于须要花一生的时间去检索它（例如：循环日志）。

• 你会但愿在你由于某个缘由重启服务器，或者程序莫名程序崩溃时，它都能从新启动。

• 你会但愿有一些标准化的命令，在你须要的时候用来启动/中止/重启程序。

你能够在Ruby中靠本身作到这些，但我以为有更好的方案：利用一些现成的东西来处理这些任务，即你的操做系统（sidekiq的创造者Mike Perhammm也赞成个人见解）。对咱们来讲，这就意味着使用systemd，由于这就是在咱们的服务器（以及大部分现在的Linux系统）上运行的程序，但我不想在这引起口水战。Upstart或者daemontools可能也能够。

“部署微服务时，你得考虑不少事情。”来自@Tainnor
点击前往Tweet

要用systemd来运行咱们的微服务，须要建立一些配置文件。这能够手工完成，但我更愿意使用一款叫作foreman的工具来作。有了foreman，咱们能够指定全部须要在Procfile中运行的进程：

mailer: bin/mailer

这里咱们只有一个进程，但你能够指定多个。咱们指定了一个叫“mailer”的进程，它将运行bin/mailer这个可执行文件。foreman的好处体如今，它能够把这一配置文件导出到许多初始化系统中，包括systemd。例如，从这个简单的Procfile，它能建立出不少文件；正如我刚才所说，咱们能够在Profile中指定多个进程，多个这样的文件能够指定一个依赖层级。层级的顶短时一个mailer.target文件，它依赖于一个mailer-mailer.target文件（而若是咱们的Procfile当中有多个进程，mailer.target则会依赖于多个子target文件）。mailer-mailer.target文件又依赖于mailer-mailer-1.service（这类文件也能够有多个，咱们只须要将线程并发度的值明确设定为大于1便可）。最后的文件看起来是这样的：

[Unit]
PartOf=-.target

[Service]
User=mailer_user
WorkingDirectory=/var/www/mailer_production/releases/16
Environment=PORT=5000
Environment=PATH=
/home/deploy/.rvm/gems/ruby-2.2.3/gems/bundler-1.11.2:...
Environment=ENVIRONMENT=production
ExecStart=/bin/bash -lc 'bin/mailer'
Restart=always
StandardInput=null
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=%n
KillMode=process

具体细节并不重要。可是从上面的代码能够看出，咱们明确了用户、工做路径、开始运行服务的命令，也明确了每次遇到失效都应当重启，以及记录日志并添加到系统日志中。咱们也设定了一些环境变量，包括PATH。稍后我会再谈到这个。

有了这个，咱们以前想要的系统行为都实现了。如今它能够在后台运行了，而且每次遇到失效都会重启。你也能够经过运行sudo systemctl enable mailer.target让它在系统启动时就开始运行。至于标准输出的日志，会从新被写入系统日志。对于systemd来讲，也就是journald，一个二进制的日志记录器（所以转储的问题就再也不存在）。咱们能够经过如下的方式来检查咱们的日志输出：

$ sudo journalctl -xu mailer-mailer-1.service
-- Logs begin at Thu 2015-12-24 01:59:54 CET, end at ... --
Feb 23 10:00:07 ... RECEIVED: {"from": ...}
...

你能够赋予journalctl 更多的选项，例如，根据日期进行筛选。

为了让foreman生成systemd文件，咱们必须在部署中设置导出流程。不知道你是否用过Capistrano 2或Capistrano 3或者别的相似的工具（例如mina）。下面你会看到你可能须要的壳命令。最难的部分任务是如何正确设置环境变量。为了确保foreman能够在启动脚本中写出刚才的变量，咱们能够从所部署的项目根目录中运行下面的代码，从而把它们先放进一个.env文件：

$ echo "PATH=$(bundle show bundler):$PATH" >> .env
$ echo "ENVIRONMENT=production" >> .env

（在此我省略了PORT变量——这个变量是foreman自动生成的。咱们的服务也不须要它。）

接着咱们告诉foreman，在读取咱们刚刚建立的.env文件的这些变量时，把它们导出到systemd。

$ sudo -E env "PATH=$PATH" bundle exec foreman\
  export systemd /etc/systemd/system\
  -a mailer -u mailer_user -e .env

这条命令挺长的，但归根结底就是在运行foreman export systemd，同时指定了文件应该被放置到的目录（据我所知/etc/systemd/system是其标准目录）、运行该命令的用户、以及加载文件的环境。

而后咱们从新加载全部的东西：

$ sudo systemctl daemon-reload
$ sudo systemctl reload-or-restart mailer.target

接下来，咱们启用该服务，让它在服务器启动以后保持运行：

$ sudo systemctl enable mailer.target

此后，咱们的服务就能够在服务器上启动并保持运行，并准备接受发来的全部消息了。

笔者在本文中涵盖了不少方面，但我但愿能让大家看到编写和部署微服务背后的全景。显然，若是你真想本身掌握这些内容，还得深刻研究。但我想我已经告诉了你，有哪些技术能够研究。

咱们几个月前写了一个相似的邮件服务，到目前为止，咱们对结果都挺满意。邮件服务是相对独立的，有一个明肯定义的API，而且通过独立的严格测试，所以咱们相信它能达到咱们的预期。而其健全的重启机制对咱们来讲也像个交易熔断器——有些sidekiq工做程序偶尔会出bug，因而咱们只好经过添加monit来解决问题——能够充分使用操做系统自带的工具，感受好极了。

本文系 OneAPM 工程师编译整理。 OneAPM 能为您提供端到端的 Ruby 应用性能解决方案，咱们支持全部常见的 Ruby 框架及应用服务器，助您快速发现系统瓶颈，定位异常根本缘由。分钟级部署，即刻体验，Ruby 监控历来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客

原文地址：https://dzone.com/articles/writing-a-microservice-in-ruby