В нашей компании мы переходим от огромного монолитного приложения к архитектуре микросервиса. Основными техническими драйверами для этого решения были необходимость иметь возможность масштабировать услуги независимо и масштабируемость разработки - у нас есть десять команд схватки, работающих в разных проектах (или «микро-службах»).Как работать с общим состоянием в архитектуре микросервиса?
Процесс перехода является плавным, и мы уже начали извлекать выгоду из преимуществ этих новых технических и организационных структур. Теперь, с другой стороны, есть главный момент боли, с которым мы боремся: как управлять «состоянием» зависимостей между этими микросервисами.
Приведем пример: один из микросервисов касается пользователей и регистраций. Эта услуга (давайте назовем ее X) несет ответственность за сохранение информации о личности и, таким образом, является основным поставщиком идентификаторов пользователей. Остальные микросервисы сильно зависят от этого. Например, существуют некоторые службы, ответственные за информацию профиля пользователя (A), разрешения пользователя (B), группы пользователей (C) и т. Д., Которые полагаются на эти идентификаторы пользователей и, следовательно, существует потребность в поддержании некоторой синхронизации данных между этими службами (т.е. служба A не должна иметь информацию для пользователя, не зарегистрированного в сервисе X). В настоящее время мы поддерживаем эту синхронизацию, уведомляя изменения состояния (например, новые регистрации) с помощью RabbitMQ.
Как вы можете себе представить, есть many Xs: многие «основные» службы и многие более сложные зависимости между ними.
Основная проблема возникает при управлении различными средами dev/testing. Каждая команда (и, следовательно, каждая служба) должна пройти через несколько окружений, чтобы добавить код в живую: непрерывная интеграция, интеграция в группы, приемочные испытания и живая среда.
Очевидно, что нам нужны все службы, работающие во всех этих средах, чтобы проверить, что система работает в целом. Теперь это означает, что для тестирования зависимых сервисов (A, B, C, ...) мы должны не только полагаться на сервис X, но и на его состояние. Таким образом, нам нужно как-то поддерживать целостность системы и хранить глобальное состояние &.
Наш текущий подход к этому - получение моментальных снимков всех БД из живой среды, что делает некоторые преобразования для сокращения и защиты конфиденциальности данных и распространения их во всех средах перед тестированием в конкретной среде. Очевидно, это огромные накладные расходы, как организационно, так и в вычислительных ресурсах: у нас есть десять непрерывных интеграционных сред, десять интеграционных сред и одна среда приемочного тестирования, которые все нужно «обновить» с помощью этих общих данных из живой и последней версии кода часто.
Мы изо всех сил пытаемся найти лучший способ облегчить эту боль. В настоящее время мы оцениваем два варианта:
- использованием Докер-подобных контейнеров для всех этих услуг
- имеет две версии каждой службы (один предназначенный для развития этой службы и друг с другом в песочнице, чтобы использоваться остальные команды в их развитие & интеграционного тестирования)
Ни одно из этих решений облегчить боль общих данных между службами. Мы хотели бы знать, как некоторые другие компании/разработчики решают эту проблему, поскольку мы считаем, что это должно быть общим в архитектуре микросервисов.
Как вы, ребята, это делаете? У вас также есть эта проблема? Любая рекомендация?
Извините за подробные объяснения и большое спасибо!
Когда вы говорите _store глобальное и когерентное состояние_, вы имеете в виду то же состояние, что и живая система или какое-то синтетическое состояние? Как я вижу, у вас есть несколько уровней интеграции, где каждый из них ориентирован на конкретный микросервис. – neleus
В идеале микросервис не должен зависеть от другого (а также от его состояния, как указано в @Eugene), но только по четко определенному договору связи. Основным преимуществом такого разложения является независимая доставка. Каждая служба может быть развернута независимо, и это верно для любого уровня среды (для каждой команды, постановки или живого выступления). С этой точки зрения каждая среда может поддерживать собственную реализацию контракта (контрактов). Для разработчиков и командных сред это могут быть сервисные эмуляторы (эмулятор X в вашем примере). Он может быть похож на ваш _sandbox_, Im не уверен. – neleus
Подводя итог.Идея состоит в том, что вам не нужно поддерживать живое состояние во всех средах, потому что большинство из них им не нужны. Единственное исключение - постановка. – neleus