Проектирование микросервиса29.06.2015 17:33

В предыдущей публикации я писал о плюсах использования микросервисной архитектуры. Сейчас же хочу описать процесс создания одного полезного микросервиса. Забегая вперед, скажу, что будет еще одна «микросервисная» статья, посвященная печальному результату погони за технологией, а не за смыслом.

Задача


В тестовом заданий от компании Wheely мне предстояло реализовать аутентификацю через код в смс-сообщении. Суть процесса в следующем:

  1. Пользователь совершаете какое-либо действие.
  2. Для подтверждения этого действия генерируется код.
  3. Код отправляется в СМС-сообщении.
  4. Пользователь указывает ключ.
  5. Ключ проверяется на соответствие.


Результатом должно было стать самостоятельное приложение, которое выполняет задачи, обозначенные в пунктах 2, 3 (только имитация), 5. Пины становятся не актуальны через 2 минуты после генерации. Все остальное на мое усмотрение.
a5b05eb9726a494dad4e8326cf4c4841.jpg
Я выполнял подобную задачу (с разной степенью проработки) уже дважды, однако оба раза в качестве монолитного сервиса, стараясь использовать те технологии, которые уже были в проекте. В этом же задании было указано, что особое внимание при проверке будет уделено именно моему выбору инструментов.

Набросок


Итак, я пишу микросервис, который будет взаимодействовать с основным приложением клиента через REST API. В основе сервиса два главных компонента: создание пина и его проверка.
95e22b40e32742b2b6d80ffa4d7b8f82.jpg
Пунктирной рамкой выделены компоненты, отвечающие за взаимодействие сервиса с основным приложением.

Инструменты


База данных
Здесь стоит обратить внимание на малый вес и непродолжительность хранения записи пина. Также стоит ориентироваться на обработку большого количества кодов.

Идеально под эти условиях подходит супербыстрая БД REDIS, так как кроме скорости у нее есть еще и замечательная опция expire, которая задает срок хранения записи. Благодаря этой маленькой опции мы избавляемся от кода, обслуживающего функцию «просрочки», а также не загружаем дорогую память нашей БД бесполезной информацией.

Веб-приложение
Нам нужен REST, не нужны вьюхи и избыточный (в данном случае) набор «хелперов», который предлагают многие фреймворки. Sinatra в данном случае очень хороший вариант: легковесный DSL под веб.

Проект


В данной главе я расскажу именно о микросервисных особенностях разработки и очень поверхностно опишу принцип работы компонентов приложения. Если у читателей возникнет интерес к процессу разработки самого сервиса, то я постараюсь подготовить для этого отдельную публикацию.

Сначала определимся, какие параметры будут бегать внутри нашего сервиса:

  1. api_token — ключ приложения;
  2. operation_id — уникальный код операции;
  3. phone — номер телефона;
  4. code — n-значный код подтверждения.


Теперь пропишем алгоритм работы компонентов.Создаем пин

  1. Отправляем запрос: 
    POST 'https://test.dev/api/v1/pins', api_token: 'zx..d', operation_id: 'cs12', phone: '79..1'

  2. Проверяем доступ по api_token.
  3. Генерируем уникальный код и добавляем запись в базу (SET pins:$operation_id $code).
  4. Отправляем сообщение с кодом.
  5. Возвращаем ответ.


Проверяем

  1. Отправляем запрос: 
    POST 'https://test.dev/api/v1/pins/cs12/check', api_token: 'zx..d', code: '2213'

  2. Проверяем доступ по api_token.
  3. Сверяем полученный код и код, который хранится в связке с операцией → в случае успеха удаляем запись из базы.
  4. Возвращаем ответ.

Генерируем ответы
В данном случае оба наших компонента будут возвращать одинаковые по структуре ответы в формате JSON.

Успех: 

{ 'result' => 0, 'message' => 'success' }


Неудача: 

{ 'result' => 1, 'message' => 'fail', 'errors' => ['string_1', 'string_2'] }


Итоги


Отлично, наше приложение принимает данные, обрабатывает их и возвращает ответ. Можно считать, что оно состоялось как микросервис :)

Плюсы:

  • Основное приложение остается компактным.
  • Оптимально для внедрения (меньше часа).
  • Повышается стабильность. Всю систему проще обслуживать и покрывать тестами. Также уход микросервиса в оффлайн никак не влияет на работу нашего продукта, так как он просто переключается на запасной аналогичный сервис.


Минусы:

  • Задержка при общении через REST API.
  • Дополнительные ресурсы на деплой.


Закончить эту публикацию мне хочется на положительной ноте, так как в данном случае результат оправдал все ожидания. Однако, сразу хочу предупредить читателя, что микросервисная архитектура подходит далеко не для всего. Но это уже совсем другая история.

© Habrahabr.ru