JRuby + Ratpack = ❤️
Многие разработчики на Ruby знают как обстоят дела с асинхронным выполнением кода на имеющихся серверах.
Либо вы используете что-то на EventMachine, либо колдуете с Ruby: Concurrent, Celluloid.
В любом случае, это работает не сильно эффективно из-за GIL (ждем, надеемся и верим в Ruby 3).
Но есть реализации свободные от этой проблемы, одна из них поверх JVM — JRuby, где теже самые библиотеки будут чувствовать себя гораздо комфортней.
Много расписывать не буду, думаю все как минимум слышали про него.
Главной особенностью данной реализации является легкая интеграция с любой библиотекой на JVM.
Это открывает большой простор в выборе библиотек и готовых инструментов.
Так в мире Java есть библиотека, избавляющая нас от использования стандартной конкурентной Java модели на Executor, реализуя ее на акторах. Звать библиотеку Netty. Позже на ее основе были разработаны другие, например Ratpack.
Ratpack асинхронный веб сервер, под капотом находится Netty, следовательно достаточно эффективно работает с подключениями и в целом с IO, содержит в себе все необходимое для построения производительного сервера.
Поэтому используя возможности Ratpack, гибкость и простоту Ruby (JRuby), сделаем простейший сервис, который будет разворачивать нам короткие ссылки.
В интернете есть ряд примеров, но они заканчиваются на том как запустить все это и получить простой ответ.
Есть еще пример с подключением метрик (ссылка в конце), способ из документации абсолютно не пригоден для JRuby, так как приводится только для Groovy.
В данном примере рассмотрим:
- подключение библиотек
- создание сервера
- подключение метрик
- асинхронное выполнение запросов к внешним ресурсам
- тестирование нашего сервиса
- и зальем все это на heroku
Подключение библиотек
Каждый Ruby программист пользуется bundler, жизнь без него была грустна и полна плясок, грабель и других приключений.
В мире Java есть различные сборщики, которые подтянут указанные зависимости и соберут приложение, но это не Ruby way.
Так появился jbundler. Выполняет туже самую функцию что и bundler, но для Java библиотек, после чего при загрузке они становятся доступны из JRuby. Красота!
И так, нам нужно подключить Ratpack к нашему приложению. Достаточно будет только core, остальное мы пока не используем.
Gemfile:
source 'https://rubygems.org'
ruby '2.3.0', :engine => 'jruby', :engine_version => '9.1.2.0'
gem 'rake'
gem 'activesupport', '4.2.5'
gem 'jruby-openssl'
gem 'jbundler', '0.9.2'
gem 'jrjackson'
group :test, :development do
gem 'pry'
end
group :test do
gem 'rspec'
gem 'simplecov', require: false
end
Jarfile:
jar 'io.ratpack:ratpack-core', '1.4.2'
jar 'org.slf4j:slf4j-simple', '1.7.10'
В консоли выполняем
bundle install
bundle exec jbundle install
В дальнейшем добавим еще пару библиотек, но пока остановимся на этом.
Создание сервера
Загрузив все зависимости, создаем базовый сервер, проверим что все работает. Так как у нас нет Rack, то маршрутизацию будем делать используя штатные средства.
Для начала импортируем необходимые Java классы.
require 'java'
java_import 'ratpack.server.RatpackServer'
java_import 'ratpack.server.ServerConfig'
java_import 'java.net.InetAddress'
И объявим наш класс сервера:
module UrlExpander
class Server
attr_reader :port, :host
def self.run
new('0.0.0.0', ENV['PORT'] || 3000).tap(&:run)
end
def initializer(host, port)
@host = host
@port = port
end
def run
@server = RatpackServer.of do |s|
s.serverConfig(config)
s.handlers do |chain|
chain.get 'status', Handler::Status
chain.all Handler::Default
end
end
@server.start
end
def shutdown
@server.stop
end
private
def config
ServerConfig.embedded
.port(port.to_i)
.address(InetAddress.getByName(host))
.development(ENV['RACK_ENV'] == 'development')
.base_dir(BaseDir.find)
.props("application.properties")
end
end
end
Для нашего сервиса создали endpoint status, он позволит проверить жив ли сервер в принципе.
Метод handlers, принимает блок, в которой передается интерфейс Chain,
определяющий маршрутизацию. Для объявления status испольуем метод get, эквивалентный HTTP методу.
Вторым аргументом передается объект реализующий интерфейс Handler.
В нашем случае это модуль, в котором объявлен метод handle, принимающий текущий контекст.
Как видите все достаточно просто и понятно. Никаких трехэтажных фабрик, или чего-то подобного.
Собственно сам обработчик, просто ответим что все OK:
module UrlExpander
module Handler
class Status
def self.handle(ctx)
ctx.render 'OK'
end
end
end
end
Так же в Ratpack есть своя собственная реализация health check, но для нашего примера она избыточна.
Подключение метрик
Отслеживать статус нашего сервиса мы теперь можем, но хорошо бы еще узнать что с ним внутри, время ответа, количество запросов и другие показатели.
Для этого нам нужны метрики. Ratpack имеет интеграцию с Dropwizard, для этого нужно добавить в наш Jarfile пару пакетов и установить их
jar 'io.ratpack:ratpack-guice', '1.4.2'
jar 'io.ratpack:ratpack-dropwizard-metrics', '1.4.2'
Далее подключим его к нашему серверу. Выполняется это достаточно просто, достаточно лишь модифицировать несколько участков.
java_import 'ratpack.guice.Guice'
java_import 'ratpack.dropwizard.metrics.DropwizardMetricsConfig'
java_import 'ratpack.dropwizard.metrics.DropwizardMetricsModule'
java_import 'ratpack.dropwizard.metrics.MetricsWebsocketBroadcastHandler'
Зарегистрируем модуль в нашем Registry:
s.serverConfig(config)
s.registry(Guice.registry { |g|
g.module(DropwizardMetricsModule.new)
})
И загрузим его конфигурацию:
def config
ServerConfig.embedded
.port(port.to_i)
.address(InetAddress.getByName(host))
.development(ENV['RACK_ENV'] == 'development')
.base_dir(BaseDir.find)
.props("application.properties")
.require("/metrics", DropwizardMetricsConfig.java_class)
end
А еще мы хотим получать наши метрики через WebSocket, добавим handler для этого:
s.handlers do |chain|
chain.get 'status', Handler::Status
chain.get 'metrics-report', MetricsWebsocketBroadcastHandler.new
chain.all Handler::Default
end
Готово, так же можно подключить выгрузку метрик в консоль либо в StatsD. Так как для вывода у нас теперь есть WebSocket, добавим и страницу для отображения.
Схема стандартная, папка public, содержащая всю статику. Для отдачи ее пропишем дополнительный маршрут, указав имя папки и индекснового файла:
s.handlers do |chain|
chain.files do |f|
f.dir('public').indexFiles('index.html')
end
chain.get 'status', Handler::Status
chain.get 'metrics-report', MetricsWebsocketBroadcastHandler.new
chain.all Handler::Default
end
Асинхронное выполнение запросов к внешним ресурсам
Сервер у нас заводится, слушает указанный порт и отвечает на запросы. Далее добавим endpoint, который будет возвращать нам все url,
через которые проходит наша короткая ссылка. Алгоритм простейший, на каждом redirect сохраняем новый Location в массив, после чего возвращаем его.
s.handlers do |chain|
chain.get 'status', Handler::Status
chain.path 'expand', Handler::Expander
chain.all Handler::Default
end
Добавленный endpoint будет принимать как POST, так и GET запросы.
Если бы у нас был только блокирующий API, каждый запрос обрабатывался в своем потоке, ну как обрабатывался, 90% времени он бы ждал ответа от сервера,
т.к. полезных вычислений у нас минимум. Но к нашему счастью, Ratpack является асинхронным сервером и предоставляет полный набор компонентов,
в том числе асинхронный http клиент и Promise, какая асинхронщина без них.
И так, создадим для каждой исходной ссылки Promise, который при удачном завершении вернет нам массив Location.
Внутри же, запускаем GET по нашему URL и вешаем callback на получение нового Location от сервера.
Таким образом поместим в наш массив целевой URL и все промежуточные.
module UrlExpander
module Handler
class Expander < Base
java_import 'ratpack.exec.util.ParallelBatch'
java_import 'ratpack.http.client.HttpClient'
def execute
data = request.present? ? JrJackson::Json.load(request) : {}
Создаем HttpClient, которым будем собирать наши ссылки
httpClient = ctx.get HttpClient.java_class
Собираем все URL, переданные нам и если ничего нет, то сразу возвращаем Promise с пустой мапой.
urls = [*data['urls'], *data['url'], *params['url']].compact
unless urls.present?
return Promise.value({})
end
Создаем параллельные запросы по всем переданным ссылкам:
tasks = urls.map do |url|
Promise.async do |down|
uri = Java.java.net.URI.new(url)
locations = [url]
httpClient.get(uri) do |spec|
spec.onRedirect do |resposne, action|
locations << resposne.getHeaders.get('Location')
action
end
end .then do |_resp|
down.success(locations);
end
end
end
Дождавшись их выполнения собираем результат и возвращаем его:
ParallelBatch.of(tasks).yieldAll.flatMap do |results|
response = results.each_with_object({}) do |result, locations|
result.value.try do |list|
locations[list.first] = list[1..-1]
end
end
Promise.value response
end
end
end
end
end
В итоге получили цепочку из Promise, которая асинхронно выполнит наш код.
Тестирование нашего сервиса
Настало врем протестировать то, что написали. Тестировать будем через старый добрый rspec, но с нюансами. Т.к. мы используем Ratpack + Promise, то тестировать в отрыве от библиотеки не получится,
как-то эти Promise надо выполнять, т.е. нужен рабочий eventloop. Для этого подключим дополнительную JAR библиотеку из комплекта:
jar 'io.ratpack:ratpack-test', '1.4.2'
Данная библиотека позволяет организовать как тестирование запросов (создание тестового сервера), так и просто выполнение Promise.
Для последнего используется класс (ExecHarness)[https://ratpack.io/manual/current/api/ratpack/test/exec/ExecHarness.html], в документации он подробно описан и примеры легко переносятся на JRuby.
Мы же будем тестировать как выполняется наш GET запрос и воспользуемся (EmbeddedApp)[https://ratpack.io/manual/current/api/ratpack/test/embed/EmbeddedApp.html], который позволяет запустить тестовый сервер. Есть различные статические методы, для упрощения создания
под определенные случаи. Мы тестировать будем только наш обработчик, независимо от пути, поэтому создадим его следующим образом:
describe UrlExpander::Handler::Expander do
let(:server) do
EmbeddedApp.fromHandlers do |chain|
chain.all(described_class)
end
end
#...
end
И выполним проверку, что все работает как надо:
let(:url) { 'http://bit.ly/1bh0k2I' }
context 'get request' do
it do
server.test do |client|
response = client.params do |builder|
builder.put('url', url)
end .getText
response = JrJackson::Json.load(response)
expect(response).to be_present
expect(response).to be_key url
expect(response[url].last).to match /\/ya\.ru/
end
end
end
Метод test запускает выполнение и передает в блок экземпляр TestHTTPClient, с помощью которого выполняется запрос. Далее проверяем получаенный ответ. Как видите все достаточно просто.
В отличие от ExecHarness, EmbeddedApp на каждую проверку пересоздает сервер, в то время как ExecHarness запускает EventLoop лишь раз.
Поэтому лучше максимально отделять код от работы с Ratpack Context, чтобы можно было его независимо тестировать.
Запуск на Heroku
После того как все готово запустим наш проект на heroku. Данная процедура практически ничем не отличается от запуска обычного ruby сервиса.
Единственное отличие связано с тем, что нужно установить JAR библиотеки, а heroku не выполняет данную операцию автоматически.
Для этого делается маленький хак. В принципе он везде описан, но для целостности повторю его и здесь. В процессе сборки выполняется сборки статики в том числе, поэтому воспользуемся этим и добавим
следующй rake task:
task "assets:precompile" do
require 'jbundler'
config = JBundler::Config.new
JBundler::LockDown.new( config ).lock_down
JBundler::LockDown.new( config ).lock_down("--vendor")
end
Все, теперь при сборке, также будут установлены и указанные в Jarfile библиотеки.
Заключение
Как видите использовать Ratpack в связке с JRuby не так сложно, в то же время дает доступ ко всем возможностям JVM и Netty в частности.
На его основе можно собрать высокопроизводительный асинхронный сервер. Все это production ready, тестирование на Hello World показывает до 25k rps на EC2 c4.large в docker контейнере после прогрева.
Для прогрева выполялось порядка 30К запросов, на старте время плавает, но к окончанию уже стабильно.
При этом даже с достаточно сложной логикой время выполнения запроса составляет считанные милисекунды.
Это конечно зависит от задач, но даже просто замена Puma на Ratpack (тестировали для оценки времени), дало значительный прирост.
После полного рефакторинга и переосмысления кода и плотной оптимизацией на JVM, время сократилось на порядки. Так что кто ищет производительность Java и гибкость, скорость разработки Ruby, при этом есть наработанный код рекомендую посмотреть на эту пару.
Ссылки
- Github https://github.com/fuCtor/jruby_ratpack_example/
- Demo: https://jruby-ratpack-example.herokuapp.com/
- Пример вызова: https://jruby-ratpack-example.herokuapp.com/expand? url=http://bit.ly/1bh0k2I
- Еще один пример, из которого была взята страница с метриками и пример того как эти метрики в принципе подключить: https://github.com/jkutner/ratpack-jruby-example
- Ну и сам виновник: https://ratpack.io/