Наверняка многие начинающие (но уверенные) разработчики слышали про микросервисную архитектуру, но ни разу не применяли её. В этой статье я доступным языком расскажу про то, где и как нужно применять микросервисную архитектуру и какие проблемы она может решить
Какие архитектуры бывают
Чаще всего онлайн-проекты делятся на две архитектуры - монолитную и микросервисную.
- При монолитной архитектуре, проект представляет из себя один целый проект, хранящийся в одной директории, имеющий одну кодовую базу и все процессы в нём выполняются зависимо друг от друга;
- При микросервисной архитектуре, проект может быть разбит на несколько маленькиих под-проектов (сервисов), которые в связке друг с другом образуют один общий проект. При этом самии эти "сервисы" могут быть реализованы на разных языках и использовать разные технологии. Эти "севисы" также могут распологаться на одном или разных серверах и соединены друг с другом по TCP и вышестоящих протоколах (в том числе HTTP);
Где применять монолитную архитектуру
Монолитная архитектура применяется в небольших по своему составу проектах. Там нет каких-либо сложных процессов, которые выполняются дольше нескольких секунд. Если речь идёт о HTTP-сервере, то все клиентские запросы выполняются за короткое время и сильно/долго не нагружают сервер.
Проекты на монолитной архитектуре делаются быстрее и в каком-то плане легче (что является большим плюсом при создании MVP). Но проект рано или поздно может стать большим, состоящим из сотен файлов исходного кода и поддерживать большой проект на монолитной архитектуре становится крайне сложно.
Плюс ещё проекты на монолитной архитектуре тяжело горизонтально масштабировать, потому что горизонтальное масштабирование в принципе представляет собой разбитие проекта на несколько разных серверов. Зато под вертикально масштабирование это самое то.
Где применять микросервисную архитектуру
Если при проектировании проекта подразумевается то, что он будет всегда расти и периодически в нём будут появляться новые фишки, то стоит при его разработке применить микросервисную архитектуру. Она подразумевает собой то, что проект будет разделён на разные составляющих, которые будут работать в связке друг с другом. При этом эти составляющие могут разрабатываться разными командами программистов, у которых могут быть даже разные стеки разработки.
Пример применения микросервисной архитектуры
Загрузка видео на YouTube. Все же хоть раз в жизни загружали видео на YouTube. Давайте разберём, что там происходит:
- Выбираем файл с видео, который хотим загрузить;
- Пока он загружается, можем указать название видео, описание, теги и т.д.;
- Когда файл с видео загрузился, мы должны немного подождать, пока он обработается
Что в это время происходит под капотом YouTube (примерно):
- Есть обработчик HTTP-запроса, который принимает файл на загрузку и сохраняет его в определённую директорию на сервере. Разумеется там происходит валидация входящих данных и авторизация запросов, но мы эти моменты опустим - нас интересует только то, что происходит с самим видео. В базе данных YouTube уже создаётся запись о новом видео и в браузер ответом на запрос прилетает ID видео;
- Есть обработчик HTTP-запроса, который обрабатывает информацию о видео (название, описание, теги и т.д.);
- Тут самое интересное: когда получена вся необходимая информация от пользователя и файл с видео загружен, то видео ставится в очередь на обработку. Это происходит в фоне, не в рамках выполнения HTTP-запроса. YouTube должен конвертировать видео в нужный формат (mp4), а также сделать версии файла с видео в разных качествах (360p, 720p, 1080p и т.д.). Разумеется работа с видео занимает много времени и мощностей серверов, поэтому эту задачу надо ставить в очередь.
Очередь задач в микросервисной архитектуре
Если мы делаем HTTP-сервер (REST API), важно любыми способами добиться того, чтобы сервер отвечал клиенту моментально. Если в обработчике запроса прописана тяжёлая задача (например конвертация видео-файла), то её нужно вынести в микросервис, а сервер должен сразу ответить клиенту статусом 202 (мол "принято, ожидайте").
При этом задача для микросервиса ставится в очередь (ну потому что нельзя гарантировать то, что микросервис прямо сейчас свободен и готов принять задачу). Саму очередь вы можете реализовать как хотите. Например можно записывать задачи для микросервиса в базу данных (или в Redis, или в любое другое место), а сам микросервис будет брать задачи из БД и выполнять их.
Сам же микросервис может быть расположен на том же или другом сервере. Он может принимать задачи в лайвтайме и сам их для себя планировать, либо же, как описано выше, вы сами записываете задачи для микросервиса и он берёт их сам. Микросервис берёт для себя задачи и по порядку их выполняет.
Микросервис может быть реализован как угодно, на каком угодно языке и на любом фреймворке. Его задача - брать задачи и выполнять их. После выполнения задач их можно помечать как готовые. В случае с YouTube, микросервис может сообщить основному серверу мол "задача выполнена" и сделать необходимые изменения в БД, а сервер уже пришлёт уведомление пользователю мол "ваше видео успешно загружено и обработано".
Кроме того, ничего не мешает запустить несколько одинаковых микросервисов, чтобы они выполняли задачи в параллели, чтобы в итоге список задач был выполнен быстрее.
Проекты на микросервисной архитектуре очень легко горизонтально масштабируются. Чаще всего, вам для этого нужно просто расселить микросервисы по разным серверам и настроить связь друг с другом. При необходимости сделать балансировку, отказоустойчивость и репликацию