JRuby + Ratpack = Love

Многие разработчики на 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/

ссылка на оригинал статьи https://habrahabr.ru/post/314726/