Контейнерное приложение - шаблон дизайна

Question

Я работаю над контейнеризацией нескольких приложений, имеющих следующую структуру на высоком уровне: -

1. Чтение из БД / Файловая система
2. Извлечение данных или выполнениенекоторый синтаксический анализ (бизнес-логика)
3. Запишите сжатые данные в хранилище данных.

Давайте назовем эти 3 шага как s1, s2 и s3.

Что такоелучший способ найти баланс между повторным использованием кода и чрезмерной сложностью решения?Другими словами, каков наилучший шаблон / практика проектирования для реализации такого рода решений, которые являются общепринятыми в отрасли?

Некоторые подходы, которыми я мог бы заняться, следующие: -

1. Отдельные модули для каждого приложения по одному контейнеру, имеющие s1, s2 и s3 как часть одного и того же кода.
   • Преимущества : Простая и компактная база кода.Нет связи между процессами и модулями
   • Ограничение : повторное использование кода отсутствует
2. Отдельные модули для каждого приложения, причем каждый модуль имеет 3 контейнера, выполняющих отдельные функции какs1, s2 и s3.
   • Преимущества : Повторное использование кода.
   • Ограничение : Межпроцессное взаимодействие может увеличить задержку обработки.
3. Отдельная группа групп для s1, s2 и s3 говорит, что sg1, sg2 и sg3 соответственно работают независимо.С точки зрения приложения, мы создаем новый модуль, который общается с указанными 3 группами модулей, чтобы выполнить работу.
   • Преимущества : Повторное использование кода.
   • Ограничение : Межпроцессное взаимодействие может увеличить задержку обработки.Кроме того, поддержание групп стручков является дополнительной нагрузкой.Увеличение сложности

Просьба предложить любую другую альтернативу, если подходит.

Answer 1

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

Если компоненты ваших приложений уже слабо связаны, вы можете выбрать архитектуру типа микросервисов.Например, вы можете извлечь общую логику s1 , s2 и s3 для всех приложений в отдельные микросервисы, упаковав каждое из них как образ контейнера,и запускайте их в Kubernetes как стручки (один контейнер на стручок, управляемый Развертыванием).Ядром каждого приложения будет его собственный «микросервис», упакованный в виде образа контейнера и развернутый в Kubernetes как модули, управляемые с помощью Deployment.Эти «основные» модули будут затем использовать службы, предоставляемые клиентскими модулями s1 , s2 и s3 .Это будет соответствовать подходу 3 в вашем списке.

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

---

Резюме

Если у вас много общей логики в ваших приложениях, тогда подход 3 имеет смысл, чтобы избежать дублирования кода.Также это обеспечивает лучшую гранулярность для масштабирования.Группами модулей управляют ресурсы развертывания, которые вы будете использовать в любом случае, даже если вы развертываете каждое приложение как один модуль, так что это не накладные расходы.

Если общая логика не так уж велика, то подход 1самое простое решение.