Заполнение данных в новый микросервис
Из твоей цитаты
не полагайтесь на выполнение синхронных запросов для этих данных. Вместо этого реплицируйте или распространяйте эти данные (только те атрибуты, которые вам нужны) в исходную базу данных службы, используя конечную согласованность.
Так что нет, не кажется разумным выполнять синхронный крупномасштабный импорт из одного хранилища данных в другое. По крайней мере, если принять во внимание то, что мы узнаем из книги. Выпуск нового сервиса не должен зависеть от данных, которые он не несет ответственности. Если данные уже есть в хранилище данных, то хорошо. Если нет, то он должен быть уверен, что в какой-то момент он у него появится. Весь смысл MS в том, что они могут появиться или исчезнуть в любой момент в течение срока службы системы.
В идеале новый сервис собирает данные по мере их поступления из существующей системы и сохраняет только нужные (помимо сгенерированных самим сервисом), даже если эти данные уже есть в чужой базе данных. Это "дублирование данных". Каждая служба может содержать данные (иногда только их фрагменты), которые уже существуют в других доменах (например, имя клиента может находиться во многих базах данных, каждая из которых управляется отдельной службой).
Новые услуги не должны рождаться на предпосылке, что конкретные услуги уже существуют. Это будет связывать и тянуть их навсегда на разных уровнях, не только на техническом уровне.
Автономия включает не только IPC (протоколы межпроцессного взаимодействия), но и ALM (управление жизненным циклом приложений). Использование синхронных вызовов может привести к тому, что вы запросите у другой команды новую функцию, которой у них нет. Представьте себе развертывание десятков или сотен сервисов в год. Это может повлиять на дорожную карту каждого, делая управление проектом невыносимым. Оставьте в покое управление продуктом.
Однако вполне разумно, что новым службам нужны (исторические) данные. Этого можно достичь разными способами. Можно транслировать своего рода событие newServiceRegistered, чтобы существующие сервисы могли отреагировать на это событие и передать данные. Как переместить эти данные без прямой связи между сервисами — еще одна проблема, которую необходимо решить. Я предполагаю, что это то, что книга представит в разделах, объясняющих integration events.
Это все теория, и она может соответствовать или не соответствовать вашим текущим потребностям и ожиданиям.
Если вы можете предоставить новой службе необходимые данные, не связывая службы между собой, скажем, с помощью скриптов, выполняемых один раз во время выпуска, ETLS и т. д., тогда все в порядке. Но имейте в виду, что по мере появления новых сервисов требуется больше таких сценариев, а создание сценариев для каждого хранилища данных и выполнение их из среды в среду может потребовать много работы и в конечном итоге повлиять на работу нескольких команд. . Выпуск нового сервиса — это не просто развертывание чего-то в дикой природе, вокруг этого события проходит целая церемония. Нередко команды разработчиков MS создают свои собственные инструменты для поддержки и управления сервисом. Если инфраструктура не предоставляет никакого механизма, то они должны его создать.
Цель всегда одна и та же: быть максимально автономным и независимым от других служб/команд/руководства.
Прикрепляю к посту несколько видео по теме: