Мы разрабатываем систему на основе независимых микросервисов (подключенных через шину RabbitMq). Код будет (по крайней мере для первых компонентов) написан на python (как python2, так и python3). У нас уже есть монолитное приложение, реализующее некоторую бизнес-логику, которую мы хотим реорганизовать как микросервисы и расширить. Один вопрос, который меня беспокоит:
Каков наилучший способ обмена кодом между различными микросервисами. У нас есть общие вспомогательные функции (обработка данных, ведение журнала, анализ конфигурации и т. Д.), Которые должны использоваться несколькими микросервисами.
Сами микросервисы будут разрабатываться как отдельные проекты (git-репозитории). Общие библиотеки также могут быть разработаны как самостоятельный проект. Как я могу поделиться этими библиотеками между микросервисами?
Я вижу несколько подходов:
- скопируйте версию библиотеки, которая требуется для каждого микросервиса, и обновите при необходимости
- освободить общие библиотеки для внутреннего PyPi и перечислить эти библиотеки как зависимости в требованиях микросервиса
- включить хранилище библиотеки как подмодуль git
Я хотел бы прочитать немного больше о предлагаемых подходах, лучших практиках, прошлом опыте, прежде чем принять решение о том, как действовать дальше. У вас есть предложение или ссылка?
источник
fib(n)(реализация ряда Фибоначчи). Вы не хотите повторять эту реализацию в каждом микросервисе. Это принадлежитutilsбиблиотеке (версионной, для функций и исправлений). Это не распределенный монолит, это просто слой общей функциональности. Мой вопрос, как обрабатывать этот уровень на уровне реализации?Ответы:
Ваш второй вариант, безусловно, путь. Разбейте общие библиотеки и установите их на свой локальный сервер PyPi.
Вариант 1 ужасен, потому что усовершенствования библиотек будет трудно распространить среди тех, кто может их использовать.
Вариант 3 аналогичен варианту 1.
Обычный шаблон заключается в настройке Jenkins так, что когда вы нажимаете на master для репозитория библиотеки, он выполняет сборку Python и автоматически загружает его в репозиторий PyPi. После того, как вы напишете этот скрипт сборки, вам больше не придется беспокоиться об упаковке библиотек и загрузке их вручную в PyPi. И с этой опцией все обновления библиотеки будут мгновенно доступны для возможного обновления на другие микросервисы.
Настроить свой собственный сервер PyPi очень просто. Мне нравится это руководство
источник
Не Python парень, но сервер PyPi кажется лучшим вариантом. Быстрое поиск в Google создает видимость, что это аналогично наличию репозитория Nexus для Java-файлов команды.
Действительно, пока он развертывается в каком-то центральном хранилище (в офисе / команде), с которым может работать ваш предпочтительный инструмент управления зависимостями (чтение и развертывание), это хороший вариант.
Вариант 1 действительно худший, вам никогда не придется вручную разбираться с зависимостями. Это боль. В колледже до того, как я узнал о Maven, и когда я подумал, что Git слишком сложен, мы делали все вручную, от объединения кода каждого пользователя до настройки путей к классам и получения зависимостей. Это была боль, я бы серьезно не хотел, чтобы кто-то пережил хотя бы небольшую часть этой проблемы, особенно в рабочей среде, где важна эффективность.
Вариант 3, вероятно, будет работать нормально, но он не имеет никаких реальных преимуществ по сравнению с локальным PyPi (кроме того, что может быть проще в настройке, но преимущества реальной системы управления зависимостями намного лучше).
источник
Прежде всего, разбить монолит на микросервисы всегда будет сложно. См. Децентрализованное управление данными - инкапсуляция баз данных в микросервисы, чтобы понять почему.
Тем не менее, есть несколько рецептов, как сделать это относительно разумно. Одним из них является http://12factor.net/ . Можно сказать, что вы должны поддерживать каждую библиотеку и приложение независимо, а затем явно управлять зависимостями. Если вы пойдете по этому пути, то я НАСТОЯТЕЛЬНО рекомендую вам иметь простую команду, которая обновляет все зависимости до текущей, и вы регулярно запускаете ее для каждого микросервиса. Важно иметь нормальный процесс выпуска, при котором вы блокируете версии библиотек в работе. Однако вы действительно, действительно , действительно не хотите находиться в положении, когда зависимости устаревают, и вы не знаете, что там происходит.
Также сосредоточьтесь на том, чтобы сделать ваши вспомогательные библиотеки максимально тесными и целенаправленными Всегда будет естественная тяга, чтобы начать добавлять материал в основные библиотеки для легкого обмена. Сделайте это, и вы быстро вытяните весь шарик существующих спагетти в общие библиотеки и эффективно вернетесь к тому беспорядку, который у вас есть сейчас. Поэтому лучше переоценить другой способ.
источник
Вы должны быть в состоянии обойтись без сервера, указав непосредственно из файла зависимостей пакета Python на частные репозитории GitHub, содержащие библиотеки. Пипенв и Поэт оба поддерживают это, я полагаю.
источник