Мы разобрали с тобой, что такое балансировщик и какие есть способы распределения нагрузки. Теперь наш монолит может жить на нескольких серверах, и в случае отказа какого-то сервера у нас есть второй, третий — и так далее.
Многие стремятся делать микросервисы, но это далеко не всегда выигрышная стратегия. Смотри, AirBnb, GitHub, Uber — все эти компании начинали с монолитов, потому что это элементарно проще и быстрее. А уже в процессе бурного роста, когда появилась необходимость делить зоны ответственности между командами, они начали выделять отдельные сервисы.
Если у тебя небольшая компания или стартап, 10 раз подумай, прежде чем выносить всё в отдельные сервисы.
А теперь давай посмотрим на конкретные плюсы монолитов.
- Меньшее время отклика (Response Time) и низкая задержка (Latency): в монолитном приложении все компоненты находятся в одном процессе или на одном сервере, что минимизирует сетевые задержки при взаимодействии между ними.
- Оптимизация через компиляцию: при компиляции нативного кода в байт-код он становится более оптимальным. В процессе работы виртуальная машина (VM) может выполнять агрессивные оптимизации, ускоряя работу приложения.
Теперь перейдем к микросервисам. И здесь, прежде всего, стоит еще раз сказать, что для большой корпорации с разными продуктами и целями микросервисы и правда круто подходят.
Давай глянем на часть плюсов.
- Разделение ответственности и изоляция доменов.
В современном мире системы могут иметь много функциональных областей, которые необходимо развивать и внедрять с различной периодичностью.
Domain-Driven Design (DDD) — подход, при котором системы разделяются на домены, каждый из которых имеет свою изоляцию и ответственность. Это повышает надежность и упрощает разработку. И микросервисы как раз позволяют это сделать.
- Быстрый деплоймент и CI/CD.
Микросервисы позволяют быстрее внедрять изменения благодаря независимому развёртыванию каждого сервиса. В итоге проблемы с одним сервисом не влияют на весь сайт, и для разных сервисов можно использовать параллельные конвейеры CI/CD
- Разделение баз данных.
Каждый микросервис может иметь свою собственную базу данных, что повышает устойчивость и скорость системы: сервисы не имеют прямого доступа к базам данным других сервисов, а база данных оптимизируется под конкретные нужды сервиса.
- Устранение проблем монолитов.
В монолите изменения в одном модуле могут непредсказуемо повлиять на другие части системы.
И да, с монолитом обычно не требуется сложный вид балансировки, так как даже при наличии 2+ instances все запросы будут разбрасываться балансировщиком на инстансы и не более.
Тут ты спросишь: вот есть схема на картинке. А другие способы балансировки существуют? И когда вообще стоит их применять? →
И я отвечу: они есть. Но для использования более сложных способов нам потребуется изучить инструмент, без которого не обходится ни одна большая компания.
Этот инструмент — API Gateway (он же API-шлюз). Он настолько важен и популярен, что есть в Kubernetes, в виде отдельных систем (Kong) и в виде сервисов на Java (Spring Cloud Gateway). В общем, это прямо must have для дальнейшего проектирования. Сейчас расскажу, что он делает.