Представь, что ты строишь дом. Можно сделать всё в одном большом помещении — кухня, спальня, туалет — всё вместе. А можно разделить на отдельные комнаты. Микросервисы — это как отдельные комнаты в программировании. Каждая делает своё дело и не мешает другим. В этой статье мы разберёмся, как подружить PHP с микросервисами, и почему это может быть проще, чем кажется.

Что такое микросервисы простыми словами

Микросервисная архитектура — это подход, когда большое приложение разбивается на маленькие независимые сервисы. Каждый сервис отвечает за свою задачу: например, один занимается авторизацией, другой — оплатой, третий — отправкой уведомлений. Они общаются друг с другом по сети (обычно через HTTP или очереди).

PHP для этого подходит отлично, особенно современные версии (7.4+ и 8.x). Фреймворки вроде Laravel, Symfony или Slim позволяют быстро создать лёгкий сервис. Главное — не пытаться запихнуть всё в один монолит, а думать модульно.

Правило: Один микросервис — одна ответственность. Если сервис начинает делать больше одной вещи (например, и авторизацию, и рассылку писем), значит, пора его делить.

Когда стоит переходить на микросервисы на PHP

Не надо делать микросервисы ради микросервисов. Если у тебя маленький проект — хватит и монолита. Но есть признаки, что пора:

  • Команда разработчиков растёт, и все постоянно конфликтуют в одном репозитории.
  • Одна часть приложения падает, и из-за этого не работает всё сразу.
  • Тесты выполняются часами, потому что нужно проверять весь проект.
  • Разные части приложения требуют разного стека технологий (например, где-то нужна очередь, а где-то — быстрый ответ).

PHP отлично подходит для создания лёгких сервисов. Например, можно взять микрофреймворк Slim и написать сервис для обработки заказов:


use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Slim\Factory\AppFactory;

require __DIR__ . '/vendor/autoload.php';

$app = AppFactory::create();

// Эндпоинт для получения заказа
$app->get('/orders/{id}', function (Request $request, Response $response, array $args) {
    $orderId = $args['id'];
    // Здесь логика получения заказа из БД
    $data = ['id' => $orderId, 'status' => 'processed'];
    $response->getBody()->write(json_encode($data));
    return $response->withHeader('Content-Type', 'application/json');
});

$app->run();

Вот и всё — у тебя есть микросервис. Он слушает запросы, возвращает JSON. Просто, правда?

Как микросервисы общаются между собой

Самый популярный способ — через HTTP-запросы (REST или GraphQL). Один сервис отправляет GET или POST запрос другому и получает ответ. Но есть нюанс: если сервис временно недоступен, запрос упадёт. Поэтому используют паттерн Circuit Breaker (предохранитель) — если сервис не отвечает, запрос не отправляется повторно какое-то время.

Другой способ — очереди сообщений (RabbitMQ, Redis, Kafka). Сервис кладёт задачу в очередь, а другой сервис её забирает и обрабатывает. Это надёжнее, но сложнее в настройке.

Вот пример отправки сообщения в RabbitMQ на PHP с помощью библиотеки php-amqplib:


require_once __DIR__ . '/vendor/autoload.php';

use PhpAmqpLib\Connection\AMQPStreamConnection;
use PhpAmqpLib\Message\AMQPMessage;

$connection = new AMQPStreamConnection('localhost', 5672, 'guest', 'guest');
$channel = $connection->channel();

$channel->queue_declare('order_queue', false, true, false, false);

$data = json_encode(['order_id' => 123, 'action' => 'process']);
$msg = new AMQPMessage($data, ['delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT]);
$channel->basic_publish($msg, '', 'order_queue');

echo " [x] Sent '{$data}'\n";

$channel->close();
$connection->close();

А вот как получить это сообщение (воркер):


$callback = function ($msg) {
    echo ' [x] Received ', $msg->body, "\n";
    // Обработка заказа
    $msg->ack();
};

$channel->basic_consume('order_queue', '', false, false, false, false, $callback);

while ($channel->is_consuming()) {
    $channel->wait();
}

Очереди — это надёжно, но добавляют сложности. Для начала хватит и HTTP.

Таблица: сравнение HTTP и очередей для микросервисов

Критерий HTTP (REST/GraphQL) Очереди (RabbitMQ, Kafka)
Скорость отклика Синхронный — быстрый ответ Асинхронный — ответ может быть отложенным
Надёжность Низкая — при падении сервиса запрос теряется Высокая — сообщение сохраняется до обработки
Сложность Низкая — легко настроить Высокая — нужно разбираться с брокером
Подходит для Запросов, где нужен мгновенный ответ (например, получение данных) Фоновых задач (рассылка писем, обработка платежей)

Выбирай HTTP для простых вещей, очереди — когда важна надёжность.

Лайфхаки для работы с микросервисами на PHP

Вот несколько советов, которые сэкономят тебе нервы:

  • Используй контейнеризацию (Docker). Каждый микросервис — отдельный контейнер. Это упрощает развёртывание и тестирование.
  • Не храни сессии в сервисах. Сессии — это состояние, а микросервисы должны быть stateless (без состояния). Используй JWT-токены или внешнее хранилище (Redis).
  • Логируй всё. Когда сервисов много, понять, где ошибка, сложно. Централизованное логирование (ELK, Graylog) — спасение.
  • Документируй API. Используй OpenAPI (Swagger) для REST или GraphQL-схемы. Без документации через месяц никто не вспомнит, что делает сервис.
Лайфхак: Если не уверен, нужен ли микросервис — начни с монолита, но сразу выдели границы модулей. Когда станет тесно, вынеси модуль в отдельный сервис. Это называется «модульный монолит».

Заключение: что в итоге

Микросервисы на PHP — это не страшно. Главное — не усложнять там, где можно обойтись простотой. Начни с одного сервиса, добавь второй, когда почувствуешь боль. Используй HTTP для начала, потом переходи на очереди. И не забывай про Docker и логи.

PHP отлично справляется с ролью лёгкого сервиса — современные фреймворки дают всё необходимое. А если ты боишься, что PHP медленный, вспомни: для большинства задач скорость не критична, а вот время разработки — да.

Пробуй, ошибайся, исправляй — и у тебя всё получится.

Студия WNDER