Практический пример декомпозиции монолитного PHP приложения
Введение
Стоит отметить, что сам по себе монолит не является антипаттерном и может отлично работать (и часто работает) при определенных условиях, обычно - когда он выбран осознанно. Но чаще всего монолитная архитектура в проекте не потому, что люди её выбрали, а потому что проект в неё естественно эволюционировал.
Прежде всего, давайте проясним, что мы имеем в виду под "декомпозицией монолита". Какая наша конечная цель? Какие могут быть бизнес-цели, побуждающие инженеров решать эту проблему?
Медленная скорость разработки. Это происходит из-за высокой связанности (coupling) кода, что включает в себя:
слишком запутанный код (есть важная разница между сложным (complex) и запутанным (complicated) кодом).
части кода слишком зависимы друг от друга, что приводит к более высокой вероятности возникновения конфликтов и повышает сложность построения надлежащего CI\CD процесса.
технологические сдвиги (например, обновление библиотек или миграция на другой фреймворк) почти невозможны из-за высоких временных затрат.
Монолит как единая точка отказа является бизнес-риском.
Горизонтальное масштабирование приложения становится более сложным.
Учитывая вышеизложенное, мы можем сказать, что нашей конечной целью является переход к более совершенной архитектуре приложения для увеличения скорости разработки и масштабируемости, а также снижения инфраструктурных рисков.
Теперь, когда мы определили проблему и цель, давайте разработаем высокоуровневый план.
Описание приложения
В качестве примера я буду использовать приложение для доставки еды. Для простоты оно не будет содержать какой-либо реальной бизнес-логики, но будет включать несколько обращений между сервисами и к базе данных. Суть приложения проще понять по следующей диаграмме:
Типичный flow следующий: customer делает заказ (create order), совершается обращение к restaurant service, и если заказ принят, то создается сущность доставки (delivery) и ожидается курьер. Когда курьер найден, он производит действия с доставкой через цепочку изменений статуса (change delivery status): courier_assigned -> courier_delivering -> successful. Таким образом, у нас есть три сервиса (customer, courier, restaurant), а также база данных, где хранятся orders и deliveries. В первоначальном состоянии, приложение выглядит как монолит с лишь минимальным разделением на сервисы посредством классов.
Ссылка на репозиторий с исходным кодом приложения: https://github.com/ilyachase/monolith-decoupling-example
Высокоуровневый план
Теперь проясним то, что именно мы называем «связанным кодом» в контексте монолитной архитектуры:
Не смотря на то, что в нашем коде присутствует разделение на так называемые service classes, они взаимодействуют друг с другом посредством прямых вызовов методов.
Более того, даже если мы изменим способ взаимодействия сервисных классов друг с другом, мы все равно не сможем извлечь, потому что он использует классы других сервисов напрямую (через ключевое слово
use).Наконец, все service classes имеют доступ ко всем данным в базе, а значит, нет границ между ними с точки зрения данных.
В реальных приложениях, даже если мы концептуально понимаем необходимые изменения для разделения сервисов, для этого требуется много усилий. Поэтому процесс миграции должен быть итеративным и предсказуемым. С этой целью мы внедрим дополнительный шаг перед переходом к реальными сервисам - превратим наш монолит в модульный монолит.
Для этого введем определение модуля. Мы будем называть часть нашего кода модулем тогда и только тогда, когда он будет удовлетворять двум условиям:
Разделение кода. Модули не используют классы других модулей напрямую. Когда модулю необходимо вызвать другой модуль, используется service client.
Разделение данных. Каждый модуль использует собственную базу данных.
Разберем подробнее:
Модули не используют классы других модулей напрямую. Чтобы обеспечить соблюдение этого правила, мы будем использовать библиотеку под названием Deptrac. Это несложно: создается конфигурационный файл (по умолчанию
deptrac.yaml), в нем определяются модули и далее используется исполняемый файл библиотеки для проверки соблюдения границ. Чаще всего, запуск этого файла добавляется в CI\CD (GitHub actions или что-то подобное). Важно, чтобы данная проверка была обязательной (required).Когда одному модулю необходимо вызвать другой модуль, используется service client. Идея проста: рефакторинг монолита сразу в сервисную архитектуру - обычно слишком большой скачок, поэтому мы сначала подготовим код, используя sub-requests вместо реальных HTTP-запросов. Service client - это всего лишь вспомогательный класс, который формирует запрос, отправляет его в соответствующий модуль и возвращает ответ. Мы рассмотрим его реализацию чуть позже.
Каждый модуль использует собственную базу данных. В зависимости от вашего приложения вы можете выбрать разные паттерны баз данных, и «database per service» является лишь одним из них. Мы будем использовать его в нашем примере, потому что он один из самых распространенных.
Учитывая вышесказанное, давайте рассмотрим этапы миграции архитектуры:
На последнем этапе мы не будем реализовывать полноценную event-driven архитектуру с event streams, bounded context models, outbox pattern и т.д. (поэтому, он под звездочкой). Однако, мы изменим способ коммуникации сервисов на асинхронные сообщения, т.к. это типично для приложений, претерпевающих такого рода эволюцию архитектуры, а значит, стоит рассмотреть это в реализации.
Реализация
Прежде чем мы начнем, не могу не подчеркнуть важность покрытия тестами. Конкретная реализация тестов выходит за рамки данной статьи, но в реальных приложениях первым шагом перед любыми архитектурными изменениями должно быть создание слоя тестов, который работают на near-HTTP уровне (например, Application tests в Symfony), или настоящие e2e тесты.
Переход от big ball of mud к modular monolith
Группировка файлов
Для начала, нам необходимо определить границы между частями нашего приложения. Они довольно очевидны в нашем примере (Customer, Restaurant и Courier), но на практике в реальных приложениях можно полагаться либо здравый смысл, либо на Domain Driven Design как более продвинутый подход. Не стоит делать слишком маленькие сервисы в начале, потому что это влечет за собой более высокий maintenance cost. Из статьи от Google:
We recommend that you create larger services instead of smaller services until you thoroughly understand the domain.
Когда границы определены, первым шагом будет группировка файлов в соответствующие директории, пока без распутывания зависимостей (as is). Давайте посмотрим на текущую файловую структуру:
src/
Controller/
CourierApiController.php
CustomerApiController.php
Dto/
ChangeDeliveryStatusRequest.php
CreateOrderRequest.php
Entity/
Delivery.php
Order.php
Restaurant.php
Repository/
DeliveryRepository.php
OrderRepository.php
RestaurantRepository.php
Service/
CourierService.php
CustomerService.php
RestaurantService.phpМы создадим новый уровень директорий, репрезентирующий наши модули, а файлы, принадлежность к модулям которых не очевидна, переместим в каталог Common:
src/
Customer/ <-- module level directory
Controller/
CustomerApiController.php
Dto/
CreateOrderRequest.php
Entity/
Order.php
Repository/
OrderRepository.php
Service/
CustomerService.php
Restaurant/ <-- module level directory
Entity/
Restaurant.php
Repository/
RestaurantRepository.php
Service/
RestaurantService.php
Courier/ <-- module level directory
Controller/
CourierApiController.php
Dto/
ChangeDeliveryStatusRequest.php
Entity/
Delivery.php
Repository/
DeliveryRepository.php
Service/
CourierService.php
Common/
Exception/
EntityNotFoundException.phpСовет: если ваша IDE поддерживает PSR namespaces, она поможет вам исправлять ссылки на классы при их перемещении. Например, PhpStorm поддерживает его из коробки, если вы синхронизируете настройки IDE с Composer.
Также нам придется немного подправить конфиги Symfony для поддержки нашей новой структуры:
# config/packages/doctrine.yaml
naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware
auto_mapping: true
mappings:
- App:
+ App\Courier:
+ is_bundle: false
+ dir: '%kernel.project_dir%/src/Courier/Entity'
+ prefix: 'App\Courier\Entity'
+ alias: App\Courier
+ App\Customer:
is_bundle: false
- dir: '%kernel.project_dir%/src/Entity'
- prefix: 'App\Entity'
- alias: App
+ dir: '%kernel.project_dir%/src/Customer/Entity'
+ prefix: 'App\Customer\Entity'
+ alias: App\Customer
+ App\Restaurant:
+ is_bundle: false
+ dir: '%kernel.project_dir%/src/Restaurant/Entity'
+ prefix: 'App\Restaurant\Entity'
+ alias: App\Restaurant
# config/routes.yaml
-controllers:
+courier_controllers:
resource:
- path: ../src/Controller/
- namespace: App\Controller
+ path: ../src/Courier/Controller/
+ namespace: App\Courier\Controller
+ type: attribute
+customer_controllers:
+ resource:
+ path: ../src/Customer/Controller/
+ namespace: App\Customer\Controller
type: attributeСовет: в реальных приложениях этот шаг можно разделить на несколько небольших PR, поскольку технически он представляет собой простое перемещение файлов и изменение конфигурации. Таким образом, процесс станет более итеративным и предсказуемым.
Разделение баз данных
Когда файлы сгруппированы по директориями, следующим шагом является разделение базы данных. В случае нашего приложения довольно очевидно, каким будет разделение:
База
customer, которая будет содержать таблицуorder.База
restaurant, которая будет содержать таблицуrestaurant.База
courier, которая будет содержать таблицуdelivery.
В реальных приложениях зачастую не так просто определить границы баз данных - может потребоваться больше усилий и времени чтобы решить, какие таблицы относятся к каким модулям. Однако вне зависимости от масштаба приложения, техническая часть остается прежней — суть в том, чтобы выполнить так называемую «горячую миграцию» (hot migration) каждой таблицы по очереди: в коде конфигурируется ещё одно подключение к базе данных, и запись происходит в оба хранилища, одновременно, а чтение - только из старой. Параллельно нам нужно разработать и запустить скрипт для переноса существующих данных из старой базы в новую. В этой статье мы не будем останавливаться на деталях реализации горячей миграции (это заслуживает отдельной статьи), но типичный алгоритм следующий:
Найти в коде места использования переносимой таблицы.
Для чтения оставить старое соединение.
Для записи (вставка, изменение, удаление) отправлять запросы в обе базы данных.
Тем временем разработать и запустить скрипт, который перенесет существующие данные из старой базы в новую.
После завершения миграции, зарелизить финальный PR, который будет использовать только новое соединение и для записи, и для чтения.
На последнем этапе можно удалить старую таблицу.
Моменты, которые следует учитывать:
Joins. Поскольку мы перемещаем таблицы в отдельные базы, операция
JOINмежду ними больше не будет возможна. Такие места придется переписывать в отдельные запросы.Foreign keys. СУБД больше не сможет обеспечить консистентность внешних ключей, поскольку таблицы находятся в отдельных базах данных. Если ваш продукт опирается на такую логику, ее придется реализовать на уровне кода приложения. Стоит отметить, что в highload проектах часто приходится отказываться от внешних ключей, поскольку у них есть свои проблемы.
Transactions. После того, как таблицы разделены по нескольким базам данных, СУБД больше не сможет покрывать операции с такими таблицами транзакциями. В зависимости от бизнес-логики, такие транзакции придется либо удалить, либо переписывать, используя что-то вроде saga pattern.
Оставляя в стороне технические детали горячей миграции, давайте рассмотрим, как будет выглядеть разделение базы данных в нашем приложении. Во-первых, нам нужно ввести отдельные Entity managers и connections:
# config/packages/doctrine.yaml
doctrine:
dbal:
- url: '%env(resolve:DATABASE_URL)%'
-
- # IMPORTANT: You MUST configure your server version,
- # either here or in the DATABASE_URL env var (see .env file)
- #server_version: '15'
-
- profiling_collect_backtrace: '%kernel.debug%'
+ connections:
+ courier:
+ url: '%env(resolve:COURIER_DATABASE_URL)%'
+ customer:
+ url: '%env(resolve:CUSTOMER_DATABASE_URL)%'
+ restaurant:
+ url: '%env(resolve:RESTAURANT_DATABASE_URL)%'
orm:
- auto_generate_proxy_classes: true
- enable_lazy_ghost_objects: true
- report_fields_where_declared: true
- validate_xml_mapping: true
- naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware
- auto_mapping: true
- mappings:
- App\Courier:
- is_bundle: false
- dir: '%kernel.project_dir%/src/Courier/Entity'
- prefix: 'App\Courier\Entity'
- alias: App\Courier
- App\Customer:
- is_bundle: false
- dir: '%kernel.project_dir%/src/Customer/Entity'
- prefix: 'App\Customer\Entity'
- alias: App\Customer
- App\Restaurant:
- is_bundle: false
- dir: '%kernel.project_dir%/src/Restaurant/Entity'
- prefix: 'App\Restaurant\Entity'
- alias: App\Restaurant
+ entity_managers:
+ courier:
+ report_fields_where_declared: true
+ validate_xml_mapping: true
+ connection: courier
+ mappings:
+ App\Courier:
+ is_bundle: false
+ dir: '%kernel.project_dir%/src/Courier/Entity'
+ prefix: 'App\Courier\Entity'
+ alias: App\Courier
+ customer:
+ report_fields_where_declared: true
+ validate_xml_mapping: true
+ connection: customer
+ mappings:
+ App\Customer:
+ is_bundle: false
+ dir: '%kernel.project_dir%/src/Customer/Entity'
+ prefix: 'App\Customer\Entity'
+ alias: App\Customer
+ restaurant:
+ report_fields_where_declared: true
+ validate_xml_mapping: true
+ connection: restaurant
+ mappings:
+ App\Restaurant:
+ is_bundle: false
+ dir: '%kernel.project_dir%/src/Restaurant/Entity'
+ prefix: 'App\Restaurant\Entity'
+ alias: App\Restaurant
# .env
###> doctrine/doctrine-bundle ###
-DATABASE_URL="mysql://root:${MYSQL_ROOT_PASSWORD}@db:3306/delivery_service?serverVersion=8.0.33&charset=utf8mb4"
+COURIER_DATABASE_URL="mysql://root:${MYSQL_ROOT_PASSWORD}@db:3306/courier_service?serverVersion=8.0.33&charset=utf8mb4"
+CUSTOMER_DATABASE_URL="mysql://root:${MYSQL_ROOT_PASSWORD}@db:3306/customer_service?serverVersion=8.0.33&charset=utf8mb4"
+RESTAURANT_DATABASE_URL="mysql://root:${MYSQL_ROOT_PASSWORD}@db:3306/restaurant_service?serverVersion=8.0.33&charset=utf8mb4"
###< doctrine/doctrine-bundle ###
# config/doctrine_migrations_courier.yaml
+migrations_paths:
+ 'CourierMigrations': 'src/Courier/Migrations'
# config/doctrine_migrations_customer.yaml
+migrations_paths:
+ 'CustomerMigrations': 'src/Customer/Migrations'
# config/doctrine_migrations_restaurant.yaml
+migrations_paths:
+ 'RestaurantMigrations': 'src/Restaurant/Migrations'
# migrate command example: doctrine:migrations:migrate -n --em courier --configuration config/doctrine_migrations_courier.yamlПосле этого, мы сможем использовать их по необходимости в коде, например:
# src/Customer/Service/CustomerService.php
public function __construct(
private RestaurantService $restaurantService,
private CourierService $deliveryService,
- private EntityManagerInterface $entityManager
+ private EntityManagerInterface $customerEntityManager
) {
}
...
+ $this->customerEntityManager->persist($newOrder);
+ $this->customerEntityManager->flush();
Наконец, нам необходимо отрефакторить relations между entities, поскольку теперь они хранятся в отдельных базах данных и управляются разными entity managers. Самый простой способ это сделать - начать использовать значения напрямую, например:
# src/Courier/Entity/Delivery.php
namespace App\Courier\Entity;
-use App\Customer\Entity\Order;
use App\Courier\Repository\DeliveryRepository;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Serializer\Annotation\Groups;
#[ORM\Entity(repositoryClass: DeliveryRepository::class)]
class Delivery
{
public const STATUS_NEW = 'new';
@@ -28,9 +28,9 @@
#[Groups(['api'])]
private ?string $status = null;
- #[ORM\OneToOne(cascade: ['persist', 'remove'])]
- #[ORM\JoinColumn(nullable: false)]
- private ?Order $RelatedOrder = null;
+ #[ORM\Column(name: 'related_order_id')]
+ private ?int $relatedOrderId = null;
public function getId(): ?int
{
@@ -49,14 +49,14 @@
return $this;
}
- public function getRelatedOrder(): ?Order
+ public function getRelatedOrderId(): ?int
{
- return $this->RelatedOrder;
+ return $this->relatedOrderId;
}
- public function setRelatedOrder(Order $RelatedOrder): static
+ public function setRelatedOrderId(int $relatedOrderId): static
{
- $this->RelatedOrder = $RelatedOrder;
+ $this->relatedOrderId = $relatedOrderId;
return $this;
}Как видите, разделение баз данных уже подталкивает наш код в направлении модульности. Это поможет нам в следующих шагах.
Полный пример кода после этого шага можно увидеть здесь.
Имплементация границ модулей
После того, как файлы перемещены в соответствующие директории, и база данных разделена, мы можем начать имплементировать более строгие границы между модулями. Для этого мы будем использовать библиотеку под названием Deptrac: определим в конфигурационном файле deptrac.yaml модули, а затем с помощью исполняемого файла vendor/bin/deptrac будем проверять соблюдение границ между ними. Это поможет нам в двух случаях:
Когда файлы только перемещены в соответствующие директории, мы можем определить модули в
deptrac.yamlи запустить исполняемый файл deptrac, чтобы увидеть полный список зависимостей и спланировать работу по их рефакторингу.Когда зависимости отрефакторены, мы можем закоммитить файл
deptrac.yamlи добавить вызов исполняемого файла deptrac в CI\CD, чтобы предотвратить появление новых зависимостей.
Давайте посмотрим, как это выглядит на практике. Во-первых, определим наши модули в deptrac.yaml:
parameters:
paths:
- ./src
layers:
- name: Common
collectors:
- type: directory
value: src/Common/.*
- name: Courier
collectors:
- type: directory
value: src/Courier/.*
- name: Customer
collectors:
- type: directory
value: src/Customer/.*
- name: Restaurant
collectors:
- type: directory
value: src/Restaurant/.*
ruleset:
Courier:
- Common
Customer:
- Common
Restaurant:
- CommonПосле запуска vendor/bin/deptrac мы получим отчет о зависимостях между нашими модулями:
Для разрешения данных зависимостей мы добавим service clients и DTO в наш код. Это будет что-то вроде SDK для наших модулей, который мы поместим в папку Common. Смысл в том, чтобы иметь слой, где мы определяем способ взаимодействия между модулями, что в дальнейшем позволит нам легче менять этот самый способ. Для начала им будут являться прямые вызовы функций, а в дальнейшем станут HTTP-запросы и асинхронные сообщения. Также, при необходимости модуль Common позже можно будет перенести в отдельный репозиторий и использовать в качестве библиотеки Composer.
Для реализации service clients мы будем использовать фичу Symfony под названием sub-requests которая позволит нам отправлять запросы по существующим роутам внутри приложения без запросов по сети. Идея не уникальна - например, в Node.js существует аналогичный подход с использованием mcollina/fastify-undici-dispatcher.
Стоит отметить один нюанс - sub-requests имеют небольшой оверхед по сравнению с прямыми вызовами методов. Однако, чтобы он стал хоть сколько-нибудь заметным, нужно совершать sub-requests тысячи раз в цикле, а если мы вспомним, что эти вызовы позже станут HTTP-запросами, где оверхед будет намного больше, иногда даже полезно заранее заметить такие места и отрефакторить их.
Теперь давайте введём базовый класс для всех service clients:
# src/Common/Client/AbstractSymfonyControllerResolvingClient.php
<?php
declare(strict_types=1);
namespace App\Common\Client;
use App\Common\Exception\BadPayloadException;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\HttpKernelInterface;
use Symfony\Component\Serializer\Encoder\JsonEncoder;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\Serializer\Serializer;
abstract class AbstractSymfonyControllerResolvingClient
{
public const IS_INTERNAL_REQUEST_ATTRIBUTE_KEY = 'is-internal-request';
protected readonly Serializer $serializer;
public function __construct(
private readonly HttpKernelInterface $httpKernel,
) {
$encoders = [new JsonEncoder()];
$normalizers = [new ObjectNormalizer()];
$this->serializer = new Serializer($normalizers, $encoders);
}
protected function sendServiceRequest(
string $uri,
array $query = [],
array $requestBody = [],
string $method = Request::METHOD_GET
): Response {
foreach ([$query, $requestBody] as $payload) {
$this->validatePayload($payload);
}
$request = new Request(
query: $query,
request: $requestBody,
content: json_encode($requestBody, JSON_THROW_ON_ERROR),
);
$request->setMethod($method);
$request->server->set('REQUEST_URI', $uri);
$request->attributes->set(self::IS_INTERNAL_REQUEST_ATTRIBUTE_KEY, true);
return $this->httpKernel->handle($request, HttpKernelInterface::SUB_REQUEST);
}
private function validatePayload($data): void
{
foreach ($data as $item) {
if (is_array($item)) {
$this->validatePayload($item);
} elseif (!is_scalar($item) && !is_null($item)) {
throw new BadPayloadException();
}
}
}
}Вы можете заметить метод validatePayload. Его цель - запретить передачу нескалярных аргументов внутри запроса. Несмотря на то, что в случае с sub-requests это ещё будет работать, полезно добавить эту проверку сейчас, чтобы обеспечить плавный переход к HTTP-запросам в дальнейшем.
Кроме того, поскольку мы добавляем новые роуты Symfony стандартным способом, они автоматически доступны для внешних запросов, чего мы не хотим. Для этого создадим специальный Event handler:
# src/Common/EventListener/HideInternalApiListener.php
<?php
declare(strict_types=1);
namespace App\Common\EventListener;
use App\Common\Client\AbstractSymfonyControllerResolvingClient;
use Symfony\Component\EventDispatcher\Attribute\AsEventListener;
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
#[AsEventListener(event: 'kernel.request')]
class HideInternalApiListener
{
public function onKernelRequest(RequestEvent $event): void
{
$serviceApiUrlPattern = '/service-';
$comparisonResult = strncmp($event->getRequest()->getPathInfo(), $serviceApiUrlPattern, mb_strlen($serviceApiUrlPattern));
if (0 !== $comparisonResult) {
return;
}
$secretKey = $event->getRequest()->attributes->get(AbstractSymfonyControllerResolvingClient::IS_INTERNAL_REQUEST_ATTRIBUTE_KEY);
if (true !== $secretKey) {
throw new NotFoundHttpException();
}
}
}Он проверяет URI запроса и, если он начинается с /service- и не имеет специального request attribute, возвращает 404.
Теперь давайте добавим первый service client:
# src/Common/Client/RestaurantServiceClient.php
<?php
declare(strict_types=1);
namespace App\Common\Client;
use App\Common\Dto\Order;
use App\Common\Dto\Restaurant;
use RuntimeException;
class RestaurantServiceClient extends AbstractSymfonyControllerResolvingClient
{
public function getRestaurant(int $restaurantId): ?Restaurant
{
$response = $this->sendServiceRequest('/service-restaurant/restaurants/'.$restaurantId);
if (404 === $response->getStatusCode()) {
return null;
}
if (200 !== $response->getStatusCode()) {
throw new RuntimeException('Unexpected response code');
}
return $this->serializer->deserialize($response->getContent(), Restaurant::class, 'json');
}
public function acceptOrder(Order $orderDto): bool
{
$response = $this->sendServiceRequest(
uri: '/service-restaurant/order/actions/accept',
requestBody: $this->serializer->normalize($orderDto),
method: 'POST'
);
if (200 !== $response->getStatusCode()) {
throw new RuntimeException('Unexpected response code');
}
return $this->serializer->decode(data: $response->getContent(), format: 'json');
}
}И используйте его вместо прямого вызова сервиса:
# src/Customer/Service/CustomerService.php
readonly class CustomerService
{
public function __construct(
- private RestaurantService $restaurantService,
- private CourierService $deliveryService,
- private EntityManagerInterface $entityManager
+ private RestaurantServiceClient $restaurantServiceClient,
+ private CourierServiceClient $courierServiceClient,
+ private EntityManagerInterface $customerEntityManager
) {
}
public function createOrder(CreateOrderRequest $createOrderRequest): int
{
- if (!($restaurant = $this->restaurantService->getRestaurant($createOrderRequest->getRestaurantId()))) {
+ if (!($restaurant = $this->restaurantServiceClient->getRestaurant($createOrderRequest->getRestaurantId()))) {
throw new EntityNotFoundException();
}
$newOrder = (new Order())
- ->setRestaurant($restaurant)
+ ->setRestaurantId($restaurant->getId())
->setStatus(Order::STATUS_NEW);
- if ($this->restaurantService->acceptOrder($newOrder)) {
+ $this->customerEntityManager->persist($newOrder);
+ $this->customerEntityManager->flush();
+
+ $orderDto = new OrderDto($newOrder->getId(), $newOrder->getStatus(), $newOrder->getRestaurantId(), $newOrder->getDeliveryId());
+
+ if ($this->restaurantServiceClient->acceptOrder($orderDto)) {
$newOrder->setStatus(Order::STATUS_ACCEPTED);
- $newDelivery = $this->deliveryService->createDelivery($newOrder);
- $newOrder->setDelivery($newDelivery);
+ $newDelivery = $this->courierServiceClient->createDelivery($orderDto);
+ $newOrder->setDeliveryId($newDelivery->getId());
} else {
$newOrder->setStatus(Order::STATUS_DECLINED);
}
- $this->entityManager->persist($newOrder);
- $this->entityManager->flush();
+ $this->customerEntityManager->persist($newOrder);
+ $this->customerEntityManager->flush();
return $newOrder->getId();
}
}Готово! Таким образом, мы сократили количество зависимостей из отчета Deptrac, с 15 до 11. Это пример итеративного разрешения зависимостей, при котором мы пошагово формируем границы между сервисами. Остальные зависимости в нашем приложении разрешаются тем же образом. В реальных приложениях обычно требуется больше сил на решение того, что поместить в папку Common — например, exceptions общего характера, DTO, helpers и т. д. Если есть сомнения, как правило, можно добавить чуть больше классов в этот неймспейс, а затем переместить в соответствующий сервис.
После того, как все зависимости отрефакторены, имеет смысл закоммитить файл конфигурации deptrac.yaml и добавить шаг в вашем CI\CD, в котором будет проверяться отстутствие новых зависимостей.
Полный пример кода после этого шага можно увидеть здесь.
Переход от modular monolith к service-oriented architecture
После того, как модули разделены, переход к сервисам является довольно тривиальным. Ради примера я просто скопировал содержимое всего приложения в отдельные каталоги, затем удалил ненужные модули из исходного кода и исправил пару конфигов. Вот окончательная структура:
courier-service/ <-- Separate service level (complete Symfony application)
src/
Courier/ <-- Single module inside an application
...
customer-service/
src/
Customer/
...
deployment <-- Infrastructure configurations (e.g. Nginx config)
restaurant-service/
src/
Restaurant/
...
.env
docker-compose.override.yml
docker-compose.yml
Dockerfile
LICENSE
Makefile
README.mdНет смысла перечислять все мелкие изменения в файлах конфигурации, но выделю ключевые моменты. Для начала, конфигурация Nginx для такой структуры:
# deployment/nginx/default.nginx
map $request_uri $upstream {
default invalid;
~^/api/customer/ customer-service;
~^/api/courier/ courier-service;
~^/api/restaurant/ restaurant-service;
}
upstream customer-service {
server customer-service:9000;
}
upstream courier-service {
server courier-service:9000;
}
upstream restaurant-service {
server restaurant-service:9000;
}
server {
listen 80 default_server;
root /usr/share/app/$upstream/public;
location /api/ {
try_files $uri /index.php$is_args$args;
}
location ~ ^/index\.php(/|$) {
fastcgi_pass $upstream;
fastcgi_split_path_info ^(.+\.php)(/.*)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /usr/share/app/public$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT /usr/share/app/public;
internal;
}
location ~ \.php$ {
return 404;
}
error_log /var/log/nginx/error.log;
access_log /var/log/nginx/access.log;
}Вы можете увидеть отдельные upstreams для каждого сервиса, а также блок выбора upstream на основе URI запроса.
Во-вторых, поскольку мы переходим от sub-requests к реальным HTTP-запросам, нам необходимо добавить symfony/http-client в наши сервисы, а затем скорректировать базовый класс service clients, сами service clients и контроллер API сервиса:
# restaurant-service/src/Common/Client/AbstractSymfonyControllerResolvingClient.php
-abstract class AbstractSymfonyControllerResolvingClient
+abstract class AbstractHttpClient
{
- public const IS_INTERNAL_REQUEST_ATTRIBUTE_KEY = 'is-internal-request';
-
protected readonly Serializer $serializer;
public function __construct(
- private readonly HttpKernelInterface $httpKernel,
+ private readonly HttpClientInterface $client,
+ #[Autowire('%api.secret.key%')]
+ private readonly string $apiSecretKey,
) {
$encoders = [new JsonEncoder()];
$normalizers = [new ObjectNormalizer()];
@@ -32,22 +33,23 @@
array $query = [],
array $requestBody = [],
string $method = Request::METHOD_GET
- ): Response {
+ ): ResponseInterface {
foreach ([$query, $requestBody] as $payload) {
$this->validatePayload($payload);
}
- $request = new Request(
- query: $query,
- request: $requestBody,
- content: json_encode($requestBody, JSON_THROW_ON_ERROR),
+ return $this->client->request(
+ $method,
+ 'http://nginx/api/'.$this->getServiceName().$uri,
+ [
+ 'query' => $query,
+ 'body' => $this->serializer->serialize($requestBody, JsonEncoder::FORMAT),
+ 'headers' => [
+ 'Content-Type' => 'application/json',
+ 'X-Api-Secret' => $this->apiSecretKey,
+ ],
+ ]
);
-
- $request->setMethod($method);
- $request->server->set('REQUEST_URI', $uri);
- $request->attributes->set(self::IS_INTERNAL_REQUEST_ATTRIBUTE_KEY, true);
-
- return $this->httpKernel->handle($request, HttpKernelInterface::SUB_REQUEST);
}
private function validatePayload($data): void
@@ -60,4 +62,6 @@
}
}
}
+
+ abstract protected function getServiceName(): string;
}
# courier-service/src/Common/Client/CustomerServiceClient.php
-class CustomerServiceClient extends AbstractSymfonyControllerResolvingClient
+class CustomerServiceClient extends AbstractHttpClient
{
public function changeOrderStatus(int $orderId, string $newOrderStatus): void
{
@@ -23,4 +23,9 @@
throw new RuntimeException('Unexpected response code');
}
}
+
+ protected function getServiceName(): string
+ {
+ return 'customer';
+ }
}
# customer-service/src/Customer/Controller/ServiceApiController.php
+#[Route('/api/customer')]
class ServiceApiController extends AbstractController
{
#[Route('/service-customer/orders', methods: 'POST')]Поскольку мы ушли от sub-requests, то больше не можем использовать request attributes Symfony для защиты наших внутренних запросов. Необходим какой-то другой механизм. Для простоты я добавил секретный ключ, который отправляется вместе с запросом, а затем проверяется в том же HideInternalApiListener:
# courier-service/config/services.yaml
parameters:
+ api.secret.key: '%env(API_SECRET_KEY)%'
# courier-service/.env
+API_SECRET_KEY=539afcb6-1897-4204-a552-f2c7b8fc35d2
# customer-service/src/Common/EventListener/HideInternalApiListener.php
#[AsEventListener(event: 'kernel.request')]
-class HideInternalApiListener
+readonly class HideInternalApiListener
{
+ public function __construct(
+ #[Autowire('%api.secret.key%')]
+ private string $apiSecretKey,
+ ) {
+ }
+
public function onKernelRequest(RequestEvent $event): void
{
- $serviceApiUrlPattern = '/service-';
+ $serviceApiUrlPattern = '/api/customer/service-customer/';
$comparisonResult = strncmp($event->getRequest()->getPathInfo(), $serviceApiUrlPattern, mb_strlen($serviceApiUrlPattern));
if (0 !== $comparisonResult) {
return;
}
- $secretKey = $event->getRequest()->attributes->get(AbstractSymfonyControllerResolvingClient::IS_INTERNAL_REQUEST_ATTRIBUTE_KEY);
- if (true !== $secretKey) {
+ $apiSecret = $event->getRequest()->headers->get('X-Api-Secret');
+ if ($this->apiSecretKey !== $apiSecret) {
throw new NotFoundHttpException();
}
}Конечно, это не production-ready код, но достаточно в качестве примера. Лучшим подходом была бы реализация JWT для аутентификации внутренних запросов.
Полный пример кода после этого шага можно увидеть здесь.
Переход от service-oriented к event-driven architecture
В этой части мы изменим нашу архитектуру, чтобы она стала ближе к event-driven. Я специально использую такую формулировку, потому как уже говорилось раньше, мы не будем сильно углубляться в данную архитектуру (это выходит за рамки статьи). Вместо этого мы сосредоточимся на практических изменениях, необходимых для перехода от прямых вызовов service API к асинхронным сообщениям.
Необходимые изменения станут более понятными, если мы взглянем на следующие sequence диаграммы:
Этот flow мы превратим в следующую (я выделил места, которые станут асинхронными):
То же самое касается действия «Change delivery status»:
Чтобы сделать межсервисную связь асинхронной в этом flow, требуется лишь небольшое изменение:
Шаги реализации включают в себя следующее:
Введение async broker и consumers в нашу инфраструктуру.
Создание message-классов в нашем неймспейсе
Commonи соответствующие им message handlers.Использование message bus вместо service client для межсервисной коммуникации.
А теперь шаг за шагом. Сначала нам нужно установить компонент Symfony Messenger: composer require symfony/messenger symfony/amqp-messenger
Затем настроить его:
# other services have the same configuration except queue name and routing
framework:
messenger:
serializer:
default_serializer: messenger.transport.symfony_serializer
transports:
async:
dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
options:
queues:
restaurant-service: ~
buses:
default.bus:
default_middleware:
enabled: true
allow_no_handlers: trueДобавить async broker и consumers:
# docker-compose.yml
+ amqp-broker:
+ image: rabbitmq:3
+ restart: unless-stopped
...
+ courier-consumer:
+ build:
+ context: .
+ working_dir: /usr/share/app
+ restart: unless-stopped
+ command: bin/console messenger:consume async -vv
+ volumes:
+ - ./courier-service/:/usr/share/app
// consumers for the rest 2 services are added the same way
...Существует несколько способов использования asynchronous brokers, но мы будем использовать fanout exchange (который создается Symfony по умолчанию, если не указано другое) и queue per service. Таким образом, мы имеем ряд преимуществ:
Producers отправляют сообщения в broker без необходимости указывать routing key и не зная, кто именно получит сообщение. Благодаря этому наши сообщения больше похожи на events, чем на background tasks, что уменьшает связанность сервисов.
Каждый сервис всегда получает все события и реагирует соответствующим образом. Ничего страшного, если сервис не умеет обрабатывать некоторые сообытия — сообщения можно игнорировать, а в случае необходимости, всегда можно дописать логику и начать реагировать на такие события.
Наконец, мы можем создать наше первое сообщение и изменить способ взаимодействия наших сервисов:
# customer-service/src/Common/Message/OrderCreated.php
<?php
declare(strict_types=1);
namespace App\Common\Message;
use App\Common\Dto\Order as OrderDto;
readonly class OrderCreated
{
public function __construct(private OrderDto $order)
{
}
public function getOrder(): OrderDto
{
return $this->order;
}
}
// all messages should be part of the "Common" namespace of each service
// in our case, for the sake of the example, we just copy it
// but in real application, it can (and should) be a package
# restaurant-service/src/Restaurant/MessageHandler/OrderCreatedHandler.php
<?php
declare(strict_types=1);
namespace App\Restaurant\MessageHandler;
use App\Common\Message\OrderAccepted;
use App\Common\Message\OrderCreated;
use Symfony\Component\Messenger\Attribute\AsMessageHandler;
use Symfony\Component\Messenger\MessageBusInterface;
#[AsMessageHandler]
readonly class OrderCreatedHandler
{
public function __construct(private MessageBusInterface $messageBus)
{
}
public function __invoke(OrderCreated $message)
{
// for the sake of the example, let's assume for now that the order can always be served
$this->messageBus->dispatch(new OrderAccepted($message->getOrder()));
// alternatively, we could dispatch this instead based on our business logic:
// $this->messageBus->dispatch(new OrderDeclined());
}
}И теперь мы изменим код и начать использовать сообщения вместо вызова service clients:
# customer-service/src/Customer/Service/CustomerService.php
namespace App\Customer\Service;
-use App\Common\Client\CourierServiceClient;
use App\Common\Client\RestaurantServiceClient;
use App\Common\Dto\Order as OrderDto;
use App\Common\Exception\EntityNotFoundException;
+use App\Common\Message\OrderCreated;
use App\Customer\Dto\CreateOrderRequest;
use App\Customer\Entity\Order;
use Doctrine\ORM\EntityManagerInterface;
+use Symfony\Component\Messenger\MessageBusInterface;
readonly class CustomerService
{
public function __construct(
private RestaurantServiceClient $restaurantServiceClient,
- private CourierServiceClient $deliveryServiceClient,
- private EntityManagerInterface $customerEntityManager
+ private EntityManagerInterface $customerEntityManager,
+ private MessageBusInterface $messageBus,
) {
}
@@ -36,17 +37,11 @@
$orderDto = new OrderDto($newOrder->getId(), $newOrder->getStatus(), $newOrder->getRestaurantId(), $newOrder->getDeliveryId());
- if ($this->restaurantServiceClient->acceptOrder($orderDto)) {
- $newOrder->setStatus(Order::STATUS_ACCEPTED);
- $newDelivery = $this->deliveryServiceClient->createDelivery($orderDto);
- $newOrder->setDeliveryId($newDelivery->getId());
- } else {
- $newOrder->setStatus(Order::STATUS_DECLINED);
- }
-
$this->customerEntityManager->persist($newOrder);
$this->customerEntityManager->flush();
+ $this->messageBus->dispatch(new OrderCreated($orderDto));
+
return $newOrder;
}Готово! Остальные места взаимодействия изменяются тем же способом. После этого мы можем отправить запрос в эндпойнт «Create order» и наблюдать, как сообщения действительно отправляются всем сервисам:
Также это видно в наших логах:
customer-service_1 | Matched route "app_customer_customerapi_createorder".
customer-service_1 | Request: "GET http://nginx/api/restaurant/service-restaurant/restaurants/2"
restaurant-service_1 | Matched route "app_restaurant_serviceapi_getrestaurant".
customer-service_1 | Sending message App\Common\Message\OrderCreated with async sender using Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpTransport
customer-consumer_1 | Received message App\Common\Message\OrderCreated
customer-consumer_1 | No handler for message App\Common\Message\OrderCreated
customer-consumer_1 | App\Common\Message\OrderCreated was handled successfully (acknowledging to transport).
courier-consumer_1 | Received message App\Common\Message\OrderCreated
courier-consumer_1 | No handler for message App\Common\Message\
courier-consumer_1 | App\Common\Message\OrderCreated was handled successfully (acknowledging to transport).
restaurant-consumer_1 | Received message App\Common\Message\OrderCreated
restaurant-consumer_1 | Sending message App\Common\Message\OrderAccepted with async sender using Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpTransport
restaurant-consumer_1 | Message App\Common\Message\OrderCreated handled by App\Restaurant\MessageHandler\OrderCreatedHandler::__invoke
restaurant-consumer_1 | App\Common\Message\OrderCreated was handled successfully (acknowledging to transport).
restaurant-consumer_1 | Received message App\Common\Message\OrderAccepted
restaurant-consumer_1 | No handler for message App\Common\Message\OrderAccepted
restaurant-consumer_1 | App\Common\Message\OrderAccepted was handled successfully (acknowledging to transport).
customer-consumer_1 | Received message App\Common\Message\OrderAccepted
courier-consumer_1 | Received message App\Common\Message\OrderAccepted
customer-consumer_1 | Message App\Common\Message\OrderAccepted handled by App\Customer\MessageHandler\OrderAcceptedHandler::__invoke
customer-consumer_1 | App\Common\Message\OrderAccepted was handled successfully (acknowledging to transport).
courier-consumer_1 | No handler for message App\Common\Message\DeliveryCreated
courier-consumer_1 | Message App\Common\Message\OrderAccepted handled by App\Courier\MessageHandler\OrderAcceptedHandler::__invoke
courier-consumer_1 | Sending message App\Common\Message\DeliveryCreated with async sender using Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpTransport
...Кроме того, после всех изменений мы можем заметить, что как courier, так и restaurant сервису больше не нужны service clients, поскольку им не нужно напрямую взаимодействовать с другими службами. Наш код стал чуточку чище!
Полный пример кода после этого шага можно увидеть здесь.
Заключение
В этой статье мы рассмотрели трансформацию архитектуры приложения в несколько этапов. Начиная с монолита, переходя на модульный монолит, затем отдельные сервисы и заканчивая событийно-ориентированной архитектурой. Мы сосредоточились на технических деталях такого перехода.
Однако стоит отметить, что в реальных приложениях будет гораздо больше работы, больше edge cases и принятия решений. Поэтому я предлагаю рассматривать эту статью не как руководство к действию, а как практический пример, показывающий, что этот процесс может (и должен) быть итеративным и предсказуемым. Самой большой проблемой таких архитектурных изменений часто является не само изменение, а обоснование и построение надлежащего процесса, который позволяет инженерам и другим вовлеченным сторонам верить в успех и сохранять фокус. Надеюсь, эта статья дает хотя бы отдаленное понимание как это может выглядить.
Спасибо за внимание и удачи!