По мотивам публикации «Проектирование микросервиса» я решил написать (и написал!) опенсорс для реализации двухфакторной аутентификации. На самом деле получилось два репозитория, которые обеспечивают весь «бэкграунд» второго фактора аутентификации и предоставляют удобную архитектуру для внедрения плюшек.



Отдельно отмечу, что первая часть может служить самостоятельным приложением. Оба сервиса работают через API.

Время от времени мне приходится внедрять отправку СМС-сообщений через разных провайдеров. Недавно я посмотрел на весь накопленный «опыт» и решил собрать из него гем. На данный момент есть поддержка СМС.ру, Кликателл, СмсУслуг и Нексмо.

Краткое описание гема и дополнительные ссылки ожидают вас под катом.

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

Задача

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

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

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

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

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

Подопытное приложение
Клиент просматривает список доступных квартир и бронирует их, также он может размещать на сервисе свои квартиры.

При классическом подходе для построения чаще всего выбирается фреймворк и внутри него реализуются компоненты. В случае с микросервисами для каждого компонента строится отдельное приложение и подбирается свой набор инструментов. Компоненты чаще всего взаимодействуют через REST API.

Компоненты: C — данные по квартирам (ядро), 1 — бронирование, 2 — оплата, 3 — логирование броней, 4 — размещение квартир, 5 — администрирование контента.

Обратите внимание, что перед созданием микросервисного приложения придется как следует продумать бизнес-логику и разбить приложение на самодостаточные компоненты. А теперь поговорим о том, почему микросервисы это круто.