Блог

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

Наша цель: разработать интеграцию, которая позволит нашей устаревшей системе взаимодействовать с нашими новыми облачными приложениями.

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

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

Какой был бы наилучший способ достичь этого?

Делаем ли мы:

1. Должны ли все наши облачные приложения «подключаться» к нашему единому брокеру в облаке и получать сообщения в режиме паба / суб?
2. Создайте выделенные очереди для каждого из наших облачных приложений, и пусть наши облачные приложения считывают эти сообщения непосредственно из своей очереди.

Я понимаю, что мой вопрос немного высокоуровневый, поскольку он относится к системному дизайну, но в то же время я надеюсь, что он также достаточно специфичен. Любой ввод или обратная связь будут приветствоваться.

Я бы настоятельно рекомендовал вам сделать шаг назад и разработать стратегию вашей архитектуры, прежде чем принимать решения о технической инфраструктуре:

1. БИЗНЕС: Определите различные поддомены («компоненты») из вашего устаревшего приложения и новых облачных приложений и их относительную важность: ядро, поддержка, общие. Таким образом, вы будете определять приоритеты того, что следует перенести из устаревшего.
2. КОМАНДА: Если вы управляете более чем одной командой (возможно, в вашем случае устаревшими или облачными командами?), Убедитесь, что команды согласованы с поддоменами (обратный маневр Конвея), чтобы свести к минимуму трудности при совместной работе.
3. СВЯЗЬ: определите отношения между различными поддоменами: кто является восходящим, нисходящим, каковы контракты взаимодействия?

ЗАТЕМ вы можете начать рассматривать «подключение» и различные варианты инфраструктуры для подключения ваших компонентов на основе ваших технических требований: синхронный, асинхронный и т.д. И вернемся к вашему первоначальному вопросу в случае асинхронного подключения: через посредника очереди сообщений или нет?

На этих слайдах объясняется более подробно: Визуализация социотехнических архитектур с помощью контекстных карт.

И если этот тип подхода к архитектуре вам подходит, взгляните на процесс моделирования начального проектирования, управляемого доменом, со многими другими подробностями.