Микросервисы и общие библиотеки

9

Мы разрабатываем систему на основе независимых микросервисов (подключенных через шину RabbitMq). Код будет (по крайней мере для первых компонентов) написан на python (как python2, так и python3). У нас уже есть монолитное приложение, реализующее некоторую бизнес-логику, которую мы хотим реорганизовать как микросервисы и расширить. Один вопрос, который меня беспокоит:

Каков наилучший способ обмена кодом между различными микросервисами. У нас есть общие вспомогательные функции (обработка данных, ведение журнала, анализ конфигурации и т. Д.), Которые должны использоваться несколькими микросервисами.

Сами микросервисы будут разрабатываться как отдельные проекты (git-репозитории). Общие библиотеки также могут быть разработаны как самостоятельный проект. Как я могу поделиться этими библиотеками между микросервисами?

Я вижу несколько подходов:

скопируйте версию библиотеки, которая требуется для каждого микросервиса, и обновите при необходимости
освободить общие библиотеки для внутреннего PyPi и перечислить эти библиотеки как зависимости в требованиях микросервиса
включить хранилище библиотеки как подмодуль git

Я хотел бы прочитать немного больше о предлагаемых подходах, лучших практиках, прошлом опыте, прежде чем принять решение о том, как действовать дальше. У вас есть предложение или ссылка?

python microservices

— blueFast
источник

Я не очень хорошо разбираюсь в микросервисах (моя компания недавно начала делать что-то подобное), чтобы ответить, но вот ссылка на презентацию о том, почему то, что вы описываете, является красным флагом и может привести к «распределенному монолиту» , Микросервисы не должны иметь общих библиотек. На самом деле они должны обмениваться данными только между четко определенными API, такими как Swagger (теперь он называется Open API ).

— Капитан Мэн

@CaptainMan: Конечно, но допустим, у вас есть эта простая функция: fib(n)(реализация ряда Фибоначчи). Вы не хотите повторять эту реализацию в каждом микросервисе. Это принадлежит utilsбиблиотеке (версионной, для функций и исправлений). Это не распределенный монолит, это просто слой общей функциональности. Мой вопрос, как обрабатывать этот уровень на уровне реализации?

— BlueFast

Наши микросервисы имеют общие библиотеки, чтобы обеспечить одинаковый обмен данными со всеми другими микросервисами в нашей системе. Я не уверен, как можно было бы сделать это с не-общими библиотеками; Как минимум, всем потребуются некоторые библиотеки манипуляций с XML / JSON / etc. Я еще не смотрел эту презентацию, но вы имели в виду более конкретное значение «общей библиотеки», чем то, о котором я думаю?

— Ixrec

1

@ jeckyll2hide Мы используем C ++, но наша инфраструктура для этого примерно эквивалентна вашему второму пункту: отдельный репозиторий, каждый объявляет свои зависимости, стандартная система сборки, которая знает, как найти эти зависимости во время сборки и т. д.

— Ixrec

1

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

— Капитан Мэн

5

Ваш второй вариант, безусловно, путь. Разбейте общие библиотеки и установите их на свой локальный сервер PyPi.

Вариант 1 ужасен, потому что усовершенствования библиотек будет трудно распространить среди тех, кто может их использовать.

Вариант 3 аналогичен варианту 1.

Обычный шаблон заключается в настройке Jenkins так, что когда вы нажимаете на master для репозитория библиотеки, он выполняет сборку Python и автоматически загружает его в репозиторий PyPi. После того, как вы напишете этот скрипт сборки, вам больше не придется беспокоиться об упаковке библиотек и загрузке их вручную в PyPi. И с этой опцией все обновления библиотеки будут мгновенно доступны для возможного обновления на другие микросервисы.

Настроить свой собственный сервер PyPi очень просто. Мне нравится это руководство

— Томми
источник

1

Я согласен, что вариант 2 является лучшим, но вариант 3 с подмодулями имеет гораздо больше общего с вариантом 2, чем с вариантом 1.

— 8bittree

@ 8bittree: да, вариант 3 аналогичен варианту 2, но наличие git-сервера («центрального» удаленного) является механизмом распространения пакетов. С одной стороны, он использует git для чего-то, что не предназначено для (управления зависимостями), с другой стороны, он уменьшает количество компонентов (нет необходимости в частном PyPi)

— blueFast

2

Не Python парень, но сервер PyPi кажется лучшим вариантом. Быстрое поиск в Google создает видимость, что это аналогично наличию репозитория Nexus для Java-файлов команды.

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

Вариант 1 действительно худший, вам никогда не придется вручную разбираться с зависимостями. Это боль. В колледже до того, как я узнал о Maven, и когда я подумал, что Git слишком сложен, мы делали все вручную, от объединения кода каждого пользователя до настройки путей к классам и получения зависимостей. Это была боль, я бы серьезно не хотел, чтобы кто-то пережил хотя бы небольшую часть этой проблемы, особенно в рабочей среде, где важна эффективность.

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

— Капитан человек
источник

1

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

Тем не менее, есть несколько рецептов, как сделать это относительно разумно. Одним из них является http://12factor.net/ . Можно сказать, что вы должны поддерживать каждую библиотеку и приложение независимо, а затем явно управлять зависимостями. Если вы пойдете по этому пути, то я НАСТОЯТЕЛЬНО рекомендую вам иметь простую команду, которая обновляет все зависимости до текущей, и вы регулярно запускаете ее для каждого микросервиса. Важно иметь нормальный процесс выпуска, при котором вы блокируете версии библиотек в работе. Однако вы действительно, действительно , действительно не хотите находиться в положении, когда зависимости устаревают, и вы не знаете, что там происходит.

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

— btilly
источник

0

Вы должны быть в состоянии обойтись без сервера, указав непосредственно из файла зависимостей пакета Python на частные репозитории GitHub, содержащие библиотеки. Пипенв и Поэт оба поддерживают это, я полагаю.

— Dogweather
источник