Когда объединять несколько приложений, чтобы упростить их интеграцию данных?

Question

Короткая версия:

У нас есть несколько команд, каждая из которых разрабатывает несколько приложений.Они должны поделиться некоторыми данными.Должны ли мы объединить эти приложения в одно большее, чтобы упростить интеграцию данных, или же мы должны разделить их и использовать какой-то механизм обмена данными / кэширования?

Более длинная версия:

Мыесть несколько команд, каждая из которых работает над набором приложений.Многие из этих приложений должны обмениваться данными.Одним из вариантов является использование асинхронного обмена сообщениями для создания единой системы записи, в которой происходят все записи, и передача этих данных любым другим системам, которые в них нуждаются.Эти системы будут хранить нужные биты данных в кэше только для чтения (в своей базе данных).

Преимущество этого макета в том, что одна система может взорваться, не влияя на другие системы.Это также облегчает отдельным командам работу над своими индивидуальными приложениями.Это облегчает планирование выпусков, меньшую базу кода для навигации и т. Д.

Другой вариант - решить, что эти приложения совместно используют слишком много данных, а также что накладные расходы от обмена сообщениями / кэширования слишком высоки.В этом случае вы можете решить объединить эти три приложения в одно большее приложение.Затем вы полностью устраните проблему интеграции данных, поскольку вы перенесете интеграцию на уровень обслуживания / транзакции отдельного модуля приложения.Другими словами, MyGiantApp все еще можно разделить (jar, контексты приложений и т. Д.) На различные модули, которые общаются друг с другом через API транзакционных сервисов другого модуля.В нашем случае мы будем использовать Spring почти как служебную шину с вызовом метода вместо веб-служб или асинхронного обмена сообщениями.

Хотя этот второй вариант упрощает интеграцию данных, он усложняет разработку.Теперь X командам приходится работать на одной кодовой базе.Это можно несколько ослабить, используя ветки, непрерывную интеграцию, отдельные библиотеки / контексты и т. Д., Но в конце концов это все еще один плачевный артефакт, который мы все строим.Кроме того, теперь ошибки одной команды могут легче распространяться на все приложение;одно приложение может выкинуть кучу.

Как вы решите, когда использовать решение № 1, а когда - решение № 2?

Answer 1

Привет - не уверен, что я отвечаю на точные вопросы, на которые вы хотите получить ответ - но это только начало;попросите разъяснений, если хотите, и я соответствующим образом обновлю свой ответ.

С точки зрения управления данными вы можете начать думать о Управление основными данными строк.Первая мысль, которая приходит на ум, заключается в том, что вам не нужны противоречивые справочные данные ;это предполагает, что вы используете один общий экземпляр данных - в качестве альтернативы вы можете иметь несколько копий, предполагая, что процессы управления и хранения вокруг этих данных предельно ясны.

С точки зрения интеграция , повторное использованиезависит от нефункциональных требований различных систем.Единый общий сервис позволяет легко управлять данными (в этом случае нужно беспокоиться только об одной копии), но это означает, что он может стать узким местом;Более того, применяется правило «самого слабого звена в цепочке» - как это повлияет, если общий сервис выйдет из строя?

Возможные варианты решения

Трудно понять, что делатьрекомендуется без дополнительной информации, но мои мысли таковы:

• Держите ваши три приложения отдельно.
• Используйте один общий сервис для общих данных.
• Доступ к общимданные могут передаваться через «службу» - это даст вам максимальный контроль и возможности.
• Общая служба может существовать как один экземпляр - или - у вас могут быть развернуты несколько экземпляров службы (но только один).экземпляр БД).

Ключевым моментом является то, что вы должны иметь возможность абстрагироваться от общего сервиса, не затрагивая другие приложения - в частности, вы не должны думать о создании приложения Uber.

Еще одна вещь - мысль о том, что существует одна «услуга» в деловом смысле, не исключает наличия множества способов технически разоблачить и потребить ее.

Answer 2

Я поместил это в отдельный ответ, поскольку его фокус сильно отличается от моего первого.

Звучит так, как будто вы все продумали и получилихорошее понимание вашей проблемы и решения.Позвольте мне еще раз ответить на ваш ключевой вопрос (который я считаю таковым) ...

Как бы вы решили ...

Вернуться к основам: начните с того, что вы знаете, чтобы быть правдой.
Проведите семинар по доске с соответствующими людьми из вашей команды (групп), в котором вам необходимо:

• Составить список соответствующих ограничений.
• Перечислите нежелательные результаты (одно большое неуправляемое приложение и т. Д.).
• Также рекомендуется, но, возможно, несущественно: определение рисков и потенциальных воздействий (как часть ограничений или нежелательных результатов).).
• Перечислите желаемые результаты (обмен данными, простое развертывание и т. Д.).
• Приоритетность желаемых и нежелательных результатов (очень важно), и не удивляйтесь, если они изменятся во времяход дебатов.

Этой информации должно быть достаточно, чтобы начать создавать основу для обсуждения и принятия решений.

Есть также некоторые дополнительные вещи, которые вы можете сделать перед этим.это мастерская (или как ее часть, в зависимости от политической и социальной динамики вашей ситуации).

• Определите цели системы - как в деловом, так и в архитектурном смысле.(подсказка: оба должны совпадать - или, по крайней мере, не конфликтовать).
• Если есть четкое видение для системы или вашего бизнеса, которое должно помочь (но имейте в виду, что этине всегда существует, а хорошие еще реже).
• Обратитесь к бизнес / стратегическим планам для систем, над которыми вы работаете - и рассмотрите рынок, тенденции и т. д. Что, по вашему мнению, может произойти сприложения в будущем?Архитектурный взгляд на будущее не - это то же самое, что YAGNI на уровне кода, и внимательное рассмотрение будущего может повлиять на решения, которые вы делаете сейчас.

Answer 3

Задумывались ли вы о параллелизме, транзакциях, ...

Я не знаю ваших требований, но кажется, что пришло время правильно решить эту проблему и использовать центральный «репозиторий» для управления вашими общими данными.