Микросервисы перестали быть экзотикой: Netflix и Amazon показали кейсы, Docker дошёл до продакшена, Kubernetes 1.8 вышел осенью. На волне интереса бизнес и госзаказчики просят «распилить монолит». Но распил ради распила превращает один сложный продукт в десяток сложных продуктов плюс хрупкую сеть между ними. Ниже – ошибки, которые мы чаще всего разбираем на проектах, и способы их обойти.

Неправильные границы сервисов

Главная ошибка – резать систему по техническим слоям, а не по бизнес-возможностям. Появляются «сервис базы», «сервис UI», «сервис логики», и любое изменение требований задевает сразу три команды. Граница должна совпадать с границей предметной области: биллинг, каталог, заявки, документооборот. Помогает Domain-Driven Design – выделяйте bounded context и режьте по нему.

Второй симптом – слишком мелкие сервисы. Двадцать наносервисов, которые не живут друг без друга, – это распределённый монолит: вся боль микросервисов без их преимуществ. Начинайте с крупных кусков и дробите по факту, когда видите реальную причину: разная нагрузка, разный темп изменений, разные команды.

Общая база данных и распределённые транзакции

Если десять сервисов ходят в одну схему PostgreSQL, вы не разделили систему – вы добавили сетевых вызовов поверх старого монолита. Каждый сервис должен владеть своими данными, а наружу отдавать их только через API или события. Да, это означает дублирование и денормализацию, и это нормально.

Отсюда вторая ловушка – попытка сохранить ACID-транзакции через границы сервисов. Двухфазный коммит на распределённой системе хрупок и медленно деградирует. Переходите к eventual consistency: применяйте паттерн Saga, идемпотентные обработчики и компенсирующие операции. Для асинхронного обмена ставьте брокер сообщений – Kafka или RabbitMQ и проектируйте на то, что сообщение придёт повторно или с задержкой.

Отдельно про данные о людях. Когда персональные данные размазаны по десяти базам, выполнить требование 152-ФЗ об удалении или уточнении становится тяжело, а с 2018 года прибавится и GDPR для тех, кто работает с гражданами ЕС. Заранее решите, какой сервис – владелец ПДн; мы разбирали это в материале про готовность к GDPR.

Эксплуатация важнее кода

Команды успевают написать сервисы, но не успевают научиться их обслуживать. Десять сервисов – это десять пайплайнов, десять наборов логов, десять точек обновления. Без централизованного логирования (ELK), трассировки запросов и метрик любой инцидент превращается в гадание, где именно сломалось.

Резко растёт и поверхность атаки: каждый сервис, очередь и контейнер – отдельный объект, который надо патчить. Регулярное управление обновлениями из необязательной гигиены становится критичным. Закладывайте в проект единый контур CI/CD, версионирование API и контрактные тесты между сервисами, иначе несовместимость всплывёт уже в продакшене.

И помните про сетевые границы: вызов соседнего сервиса может зависнуть или вернуть ошибку. Ставьте таймауты, ретраи с backoff и предохранители (circuit breaker). Это касается и интеграций с внешними системами – например, бэкендом для чат-ботов и NLU, где задержка ответа напрямую бьёт по пользователю.

Вывод

Микросервисы – не цель, а инструмент под конкретную проблему: независимый деплой, разный масштаб нагрузки, автономные команды. Если этих причин нет, хорошо модульный монолит дешевле и надёжнее. Если причины есть – режьте по бизнес-границам, разделяйте данные, проектируйте под отказы и сразу стройте эксплуатацию. Спланировать такой переход и наладить надёжный обмен между сервисами – это и есть задача системной интеграции.