В нашей компании мы переходим от огромного монолитного приложения к архитектуре микросервиса. Основными техническими драйверами для этого решения были необходимость иметь возможность масштабировать услуги независимо и масштабируемость разработки - у нас есть десять команд схватки, работающих в разных проектах (или "микро-службах" ).
Процесс перехода является плавным, и мы уже начали извлекать выгоду из преимуществ этих новых технических и организационных структур. Теперь, с другой стороны, есть основная проблема боли, с которой мы боремся: как управлять "состоянием" зависимостей между этими микросервисами.
Приведем пример: один из микро-сервисов касается пользователей и регистрации. Эта услуга (позвольте ей позвонить Х) несет ответственность за сохранение идентификационной информации и, таким образом, является основным поставщиком идентификаторов пользователей. Остальные микросервисы сильно зависят от этого. Например, существуют некоторые службы, ответственные за информацию профиля пользователя (A), разрешения пользователя (B), группы пользователей (C) и т.д., Которые полагаются на эти идентификаторы пользователей и, следовательно, существует потребность в поддержании некоторой синхронизации данных между этими службами (т.е. служба A не должна иметь информацию для пользователя, не зарегистрированного в сервисе X). В настоящее время мы поддерживаем эту синхронизацию, уведомляя изменения состояния (например, новые регистрации) с помощью RabbitMQ.
Как вы можете себе представить, существует много Xs: множество "основных" сервисов и множество более сложных зависимостей между ними.
Основная проблема возникает при управлении различными средами dev/testing. Каждая команда (и, следовательно, каждая служба) должна пройти через несколько окружений, чтобы добавить код в живую: непрерывная интеграция, интеграция в группы, приемочные испытания и живая среда.
Очевидно, нам нужны все службы, работающие во всех этих средах, чтобы проверить, что система работает в целом. Теперь это означает, что для тестирования зависимых сервисов (A, B, C,...) мы должны не только полагаться на сервис X, но и на его состояние. Таким образом, нам нужно как-то поддерживать целостность системы и хранить глобальное и согласованное состояние.
Наш текущий подход к этому - получение снимков всех БД из живой среды, что делает некоторые преобразования для сокращения и защиты конфиденциальности данных и распространения их во всех средах перед тестированием в конкретной среде. Очевидно, это огромные накладные расходы, как организационно, так и в вычислительных ресурсах: у нас есть десять непрерывных интеграционных сред, десять интеграционных сред и одна среда приемочного тестирования, которые все нужно "обновить" с помощью этих общих данных из живой и последней версии кода часто.
Мы изо всех сил пытаемся найти лучший способ облегчить эту боль. В настоящее время мы оцениваем два варианта:
- использование докереподобных контейнеров для всех этих сервисов.
- с двумя версиями каждой службы (одна предназначена для разработки этой службы и одна другая как песочница, которая будет использоваться остальными командами при их тестировании на разработку и интеграцию).
Ни одно из этих решений не облегчает боль обмена данными между службами. Мы хотели бы знать, как некоторые другие компании/разработчики решают эту проблему, поскольку мы считаем, что это должно быть общим в архитектуре микросервисов.
Как вы, ребята, это делаете? У вас также есть эта проблема? Любые рекомендации?
Извините за длинное объяснение и большое спасибо!