В предыдущей публикации я писал о плюсах использования микросервисной архитектуры. Сейчас же хочу описать процесс создания одного полезного микросервиса. Забегая вперед, скажу, что будет еще одна «микросервисная» статья, посвященная печальному результату погони за технологией, а не за смыслом.
В тестовом заданий от компании Wheely мне предстояло реализовать аутентификацю через код в смс-сообщении. Суть процесса в следующем:
Результатом должно было стать самостоятельное приложение, которое выполняет задачи, обозначенные в пунктах 2, 3 (только имитация), 5. Пины становятся не актуальны через 2 минуты после генерации. Все остальное на мое усмотрение.
Я выполнял подобную задачу (с разной степенью проработки) уже дважды, однако оба раза в качестве монолитного сервиса, стараясь использовать те технологии, которые уже были в проекте. В этом же задании было указано, что особое внимание при проверке будет уделено именно моему выбору инструментов.
Итак, я пишу микросервис, который будет взаимодействовать с основным приложением клиента через API. В основе сервиса два главных компонента: создание пина и его проверка.
Пунктирной рамкой выделены компоненты, отвечающие за взаимодействие сервиса с основным приложением.
Здесь стоит обратить внимание на малый вес и непродолжительность хранения записи пина. Также стоит ориентироваться на обработку большого количества кодов.
Идеально под эти условиях подходит супербыстрая БД REDIS, так как кроме скорости у нее есть еще и замечательная опция expire, которая задает срок хранения записи. Благодаря этой маленькой опции мы избавляемся от кода, обслуживающего функцию «просрочки», а также не загружаем дорогую память нашей БД бесполезной информацией.
Нам нужен REST, не нужны вьюхи и избыточный (в данном случае) набор «хелперов», который предлагают многие фреймворки. Sinatra в данном случае очень хороший вариант: легковесный DSL под веб.
В данной главе я расскажу именно о микросервисных особенностях разработки и очень поверхностно опишу принцип работы компонентов приложения. Если у читателей возникнет интерес к процессу разработки самого сервиса, то я постараюсь подготовить для этого отдельную публикацию.
Сначала определимся, какие параметры будут бегать внутри нашего сервиса:
Теперь пропишем алгоритм работы компонентов.
В данном случае оба наших компонента будут возвращать одинаковые по структуре ответы. При успехе STATUS 200, в противном случае STATUS 403.
Отлично, наше приложение принимает данные, обрабатывает их и возвращает ответ. Можно считать, что оно состоялось как микросервис :)
Плюсы:
Минусы:
Закончить эту публикацию мне хочется на положительной ноте, так как в данном случае результат оправдал все ожидания. Однако, сразу хочу предупредить читателя, что микросервисная архитектура подходит далеко не для всего. Но это уже совсем другая история.
UPD.1. Перевел формат ответов с джейсона на статус-коды. За рекомендации и пояснения спасибо f0rk и smileonl.
Задача
В тестовом заданий от компании Wheely мне предстояло реализовать аутентификацю через код в смс-сообщении. Суть процесса в следующем:
- Пользователь совершаете какое-либо действие.
- Для подтверждения этого действия генерируется код.
- Код отправляется в СМС-сообщении.
- Пользователь указывает ключ.
- Ключ проверяется на соответствие.
Результатом должно было стать самостоятельное приложение, которое выполняет задачи, обозначенные в пунктах 2, 3 (только имитация), 5. Пины становятся не актуальны через 2 минуты после генерации. Все остальное на мое усмотрение.
Я выполнял подобную задачу (с разной степенью проработки) уже дважды, однако оба раза в качестве монолитного сервиса, стараясь использовать те технологии, которые уже были в проекте. В этом же задании было указано, что особое внимание при проверке будет уделено именно моему выбору инструментов.
Набросок
Итак, я пишу микросервис, который будет взаимодействовать с основным приложением клиента через API. В основе сервиса два главных компонента: создание пина и его проверка.
Пунктирной рамкой выделены компоненты, отвечающие за взаимодействие сервиса с основным приложением.
Инструменты
База данных
Здесь стоит обратить внимание на малый вес и непродолжительность хранения записи пина. Также стоит ориентироваться на обработку большого количества кодов.
Идеально под эти условиях подходит супербыстрая БД REDIS, так как кроме скорости у нее есть еще и замечательная опция expire, которая задает срок хранения записи. Благодаря этой маленькой опции мы избавляемся от кода, обслуживающего функцию «просрочки», а также не загружаем дорогую память нашей БД бесполезной информацией.
Веб-приложение
Нам нужен REST, не нужны вьюхи и избыточный (в данном случае) набор «хелперов», который предлагают многие фреймворки. Sinatra в данном случае очень хороший вариант: легковесный DSL под веб.
Проект
В данной главе я расскажу именно о микросервисных особенностях разработки и очень поверхностно опишу принцип работы компонентов приложения. Если у читателей возникнет интерес к процессу разработки самого сервиса, то я постараюсь подготовить для этого отдельную публикацию.
Сначала определимся, какие параметры будут бегать внутри нашего сервиса:
- api_token — ключ приложения;
- operation_id — уникальный код операции;
- phone — номер телефона;
- code — n-значный код подтверждения.
Теперь пропишем алгоритм работы компонентов.
Создаем пин
- Отправляем запрос:
POST 'https://test.dev/api/v1/pins', api_token: 'zx..d', operation_id: 'cs12', phone: '79..1'
- Проверяем доступ по api_token.
- Генерируем уникальный код и добавляем запись в базу (SET pins:$operation_id $code).
- Отправляем сообщение с кодом.
- Возвращаем ответ.
Проверяем
- Отправляем запрос:
POST 'https://test.dev/api/v1/pins/cs12/check', api_token: 'zx..d', code: '2213'
- Проверяем доступ по api_token.
- Сверяем полученный код и код, который хранится в связке с операцией -> в случае успеха удаляем запись из базы.
- Возвращаем ответ.
Генерируем ответы
В данном случае оба наших компонента будут возвращать одинаковые по структуре ответы. При успехе STATUS 200, в противном случае STATUS 403.
Итоги
Отлично, наше приложение принимает данные, обрабатывает их и возвращает ответ. Можно считать, что оно состоялось как микросервис :)
Плюсы:
- Основное приложение остается компактным.
- Оптимально для внедрения (меньше часа).
- Всю систему проще обслуживать и покрывать тестами.
- Гипотеза: повышается стабильность. Уход микросервиса в оффлайн никак не влияет на работу нашего продукта, так как он просто переключается на запасной сервис.
Минусы:
- Задержка при общении через API.
- Дополнительные ресурсы на деплой.
Закончить эту публикацию мне хочется на положительной ноте, так как в данном случае результат оправдал все ожидания. Однако, сразу хочу предупредить читателя, что микросервисная архитектура подходит далеко не для всего. Но это уже совсем другая история.
UPD.1. Перевел формат ответов с джейсона на статус-коды. За рекомендации и пояснения спасибо f0rk и smileonl.
