Какие ключевые решения и практики вы применяете при создании проекта на микросервисной архитектуре?

Да ты послушай, что за дичь творится в мире архитектуры! Сидишь такой, проектируешь систему, а тебе говорят: "Слушай, давай на микросервисы!" И ты такой: "Окей, хуй с горы, давайте". А потом оказывается, что это не просто так, бахнуть пару аннотаций. Это, блядь, целая философия, где доверия ебать ноль между компонентами.

Вот смотри, как я это делаю, чтобы не накрыться медным тазом на первой же нагрузке.

1. Границы сервисов — это святое. Тут главное — не накосячить с разделением. Берёшь Domain-Driven Design (DDD) и режешь домен, как пирог на дне рождения алкаша — чтоб каждый кусок был самостоятельный и другим в тарелку не лез. Сервис заказов (Order Service) — он про заказы. Сервис оплаты (Payment Service) — он про бабки. И чтобы у каждого была своя, блядь, база данных, святая святых. Никакого прямого доступа к чужой! Только через API или события, а то получится пиздопроебина, а не архитектура.

2. Как сервисы болтают между собой. Тут два пути, и оба с подводными камнями.

• Синхронно (REST/gRPC): Когда ответ нужен прям щас, например, "а есть ли этот товар вообще, ёпта?". Для этого ставишь API Gateway (типа Kong), который будет рулить трафиком и спрашивать "ты кто такой, а?". Волнение ебать, когда он ложится, но это уже другая история.
• Асинхронно (Event-Driven): А вот это, дружок, наше всё. Сервис сделал дело — выпустил событие в мир (типа OrderPlaced), кинул его в Apache Kafka или RabbitMQ, и похуй. Другие сервисы подписались, получили, обрадовались. Платежку отправили, нотификацию. Связь слабая, отказоустойчивость — овердохуища.

  # Вот смотри, как в Symfony событие в Кафку пихнуть
  # config/packages/messenger.yaml
  framework:
  messenger:
      transports:
          kafka_transport: 'kafka://kafka-broker:9092'
      routing:
          'AppMessageOrderPlacedEvent': kafka_transport

3. Данные и транзакции, или где твоя консистентность, чувак? Забудь про распределённые транзакции (2PC) — это путь в никуда, ядрёна вошь. Вместо них используешь Saga Pattern. Представь: платежка отвалилась. Сервис оплаты не орёт на всех, а спокойно так публикует событие PaymentFailed. Сервис заказов его ловит и помечает заказ как "отменён, сорян". Все довольны, кроме клиента. Для скорости чтения иногда заводишь отдельные Read Models (в том же Elasticsearch), которые копят данные из событий. Хитрая жопа, но работает.

4. Наблюдаемость. Без этого — нихуя не увидишь. Ты должен видеть ВСЁ. Иначе когда всё ебнется, ты будешь как слепой кот, сука.

• Логи: Не размазанные по сотне машин, а в одну кучу, в ELK-стек. И чтобы у каждого лога был correlation_id, как ниточка в лабиринте.
• Метрики: Сколько отвечал, сколько упал — всё в Prometheus, а на красивых графиках в Grafana. Удивление пиздец, когда видишь, как всё тормозит.
• Трейсинг: Запрос пошёл гулять по сервисам? Jaeger или Zipkin покажут его полный маршрут, чтобы ты знал, на ком именно повесить всех собак.

5. Инфраструктура — чтоб не бздеть при каждом деплое. Kubernetes — наш царь и бог. Каждый сервис в своём Docker-контейнере. Настройки — не внутри, а снаружи, в Vault или ConfigMap'ах. Обязательно настраиваешь Health Checks, чтобы кубер знал, кто жив, а кто прикидывается. И паттерны Circuit Breaker с Retry — это как подушка безопасности, когда один сервис решил, что он сегодня не в духе.

И главный вывод, который больно даётся: Микросервисы — это не потому что модно или техника крутая. Это, блядь, в первую очередь для людей, для команд, чтобы они друг другу не мешали. Начинаешь всегда с аккуратного монолита. А режешь его на части только тогда, когда реально появляется причина — масштаб или отдельные команды, которые уже готовы друг другу глотки перегрызть. А то так и до мартышлюшки недалеко.