Ответ
Сервис — это общий термин для компонента, который предоставляет чётко определённую функциональность через API (например, сервис отправки email или расчёта налогов). Он может быть частью монолитной архитектуры.
Микросервис — это архитектурный стиль, где приложение состоит из множества небольших, независимо развёртываемых сервисов, каждый из которых:
- Инкапсулирует свою бизнес-домен (например, «Пользователи», «Заказы», «Оплата»).
- Имеет собственную базу данных, не разделяемую напрямую с другими сервисами.
- Общается через лёгкие механизмы (чаще HTTP/REST, gRPC, асинхронные сообщения).
- Может быть разработан на независимом технологическом стеке.
Пример сравнения:
- В монолите: Класс
OrderServiceвызывает методEmailSender::send()внутри того же процесса. - В микросервисах: Сервис
ordersпубликует событиеOrderCreatedв брокер сообщений (например, RabbitMQ), а независимый сервисnotificationsподписывается на это событие и отправляет email.
Главное отличие: Микросервис — это сервис, построенный по принципам слабой связанности и высокой автономности, что позволяет независимое масштабирование, развёртывание и отказоустойчивость.
Ответ 18+ 🔞
А, ну это классика, ёпта! Объясняю на пальцах, без этих ваших заумных буклетов.
Представь себе здоровенный, ебаный монолит. Это как старый совковый завод-гигант: в одном здании и литейный цех, и конвейер, и бухгалтерия, и столовая. Всё в одной куче. Вот внутри этого завода есть отделы — это и есть сервисы. EmailSender — это как служба доставки корреспонденции по заводу. Работает, но если завод встал на плановый ремонт, то и почтальон сидит без дела, жрёт печеньки. Всё в одном процессе, одна база данных на всех — общага, блядь.
А теперь смотри сюда, микросервисы — это когда этот ебучий завод разобрали нахуй и построили вместо него технопарк. Отдельный модный офис для «Заказов», через дорогу — склад «Товаров», в соседнем здании — call-центр «Оплаты». Каждый — самостоятельная контора.
- У каждой конторы своя, блядь, база данных. Склад не лезет в бухгалтерские проводки оплаты напрямую. Доверия ебать ноль, так сказать. Общаются они между собой не через внутренние телефоны (вызов метода), а через документооборот или курьеров — то есть HTTP или асинхронные сообщения в очередь.
- Развёртываются независимо. Захотел склад «Товаров» обновить стеллажи — пожалуйста, остальные работают. В монолите же чтобы гвоздь в столбовую забить, надо весь завод останавливать.
- Технологический пиздец (в хорошем смысле). Офис «Заказов» может быть на Python, склад — на Go, а «Оплата» — на Java 1.8, как будто на дворе 2015-й год. Главное, чтобы договора (API) между ними соблюдались.
Пример, чтобы совсем пиздец стало понятно:
- В монолите (старый завод): Менеджер из отдела
OrderServiceберёт трубку внутреннего телефона (вызывает метод) и орёт: «Вась, из почтовой службыEmailSender! Клиенту чек отправь, быстро!». Всё внутри одного здания. - В микросервисах (технопарк): Офис
ordersпечатает уведомление «Заказ №666 создан» и кладёт его в ящик «Исходящие» (публикует событиеOrderCreatedв RabbitMQ). Его вообще не ебёт, кто это прочитает. Отдельно, в зданииnotifications, курьер (подписчик) забирает эту бумажку из ящика «Входящие» и везёт клиенту email. Если сервис нотификаций сгорел, заказы всё равно будут создаваться, просто уведомления в очереди накопятся.
Короче, главная разница как между здоровенной дубиной и швейцарским ножом с кучей лезвий. Дубина (монолит) — простая, но если сломалась, ты просто с палкой. А нож (микросервисы) — гибкий, можно одно лезвие поточить, не трогая остальные, но если его роняешь, собирать полчаса по двору, ядрёна вошь. За автономность и масштабируемость платишь херовой сложностью взаимодействия.
