Микросервисы завоёвывают мир, и наша компания не стала исключением. Однако в процессе внедрения этого подхода команда столкнулась с привычкой, с которой мы боремся до сих пор — использование базы данных для операций над данными другого сервиса в обход предоставляемого API. Ведь всегда проще заджойнить несколько таблиц и получить нужные данные, к тому же это очень производительно и быстро!

Надеюсь, что статья будет интересна командам, которые только начинают внедрение микросервисов.

Наш пример: мы создаем сервис по отправке данных из нашей системы во внешнюю. В процессе подготовки данных необходимо наши идентификаторы адресов привести к идентификаторам ФИАС. Для этого у нас есть еще один микросервис, который держит базу данных ФИАС в актуальности, создает и хранит привязки идентификаторов нашей адресной системы с ФИАС. Подъемом отправляемых данных занимается хранимая процедура. Перед отправкой нужно подменить наши адресные идентификаторы на ФИАС. Это можно сделать в двух местах: в хранимой процедуре базы данных (join нужных таблиц) и в коде сервиса отправки (используя api стороннего сервиса).

Использование базы данных:

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

Использование http api микросервиса:

• Разделение ответственности сервисов
  Буква S в аббревиатуре SOLID — принцип единственной обязанности. В случае изменения логики выборки или обработки данных, код меняется в одном единственном месте. Например, вместо того, чтобы удалять сущности из БД, мы начали помечать их как удаленные.
  
• Независимое хранение данных: при переносе БД с одного сервера на другой, не нужно вносить изменения в сервисы-клиенты
  Если понадобится изменить структуру таблиц БД, перенести БД на другой сервер, начать использовать другой тип базы данных (а почему бы и нет? мир не стоит на месте), тогда нужно будет вносить изменения во все сервисы-клиенты изменяемого сервиса. Очень часто за один подход не удается вспомнить всех клиентов и что-нибудь обязательно сломается…
• Больше контроля над приложением, возможность тестирования
  В коде приложения проще отлавливать неожиданное поведение, обрабатывать его. Взаимодействие со сторонним сервисом можно эмулировать, проводить юнит-тестирование модуля сбора данных.

Отдельно хочется сказать про производительность микросервисов — всё зависит от программиста. При обработке 1000 сущностей можно для каждой сущности вызывать метод api и тогда да — это будет долго. А можно сделать это один раз по всей 1000 — и это будет допустимо.
Это будет не так производительно как join в БД, но у всего есть своя цена.

Вывод: предпочтительно использование интерфейсов взаимодействия микросервиса (http api). В этом случае вы избавите себя от головной боли при изменении логики, изменении месторасположения данных и прочих «радостей» сопровождения.