Мікросервіси та спільні бібліотеки

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

Який найкращий спосіб ділитися кодом між різними мікросервісами. У нас є загальні допоміжні функції (обробка даних, ведення журналів, аналіз конфігурації тощо), які повинні використовуватися декількома мікросервісами.

Самі мікросервіси планують розробляти як окремі проекти (git repositories). Загальні бібліотеки також можуть бути розроблені як самостійний проект. Як я поділяю ці бібліотеки між мікросервісами?

Я бачу кілька підходів:

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

Я хотів би прочитати трохи більше про запропоновані підходи, найкращі практики, минулий досвід, перш ніж вирішити, як діяти далі. Чи є у вас якісь пропозиції чи посилання?

Ваш другий варіант, безумовно, шлях. Виділіть загальні бібліотеки та встановіть їх на локальний сервер PyPi.

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

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

Загальна схема полягає в тому, щоб встановити Дженкінса так, що коли ви натискаєте на майстер бібліотечного репо, він збирає пітон і автоматично завантажує його в репортаж PyPi. Після того, як ви напишете цей сценарій збірки, вам ніколи не доведеться турбуватися про упаковку бібліотек та завантаження їх вручну в PyPi. І за допомогою цієї опції всі оновлення бібліотеки будуть одразу доступні для їх можливого оновлення до інших мікросервісів.

Налаштувати власний сервер PyPi дуже просто. Мені подобається цей посібник

Не Python хлопець, але PyPi-сервер здається найкращим варіантом. Швидкий гуглінг дає вигляд, що це аналогічно тому, як Repo Nexus для банок Java Java.

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

Варіант 1 справді найгірший, вам ніколи не доведеться вручну боротися із залежностями. Це біль. У коледжі до того, як я знав про Мейвена, і коли я вважав, що Гіт занадто складний, ми все робили вручну - від злиття коду всіх до встановлення класових шляхів, до захоплення залежностей. Це був біль, я серйозно не хотів би, щоб хтось пережив навіть частину цієї неприємності, особливо в робочих умовах, де важлива ефективність.

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

Перш за все, розщеплення моноліту на мікросервіси завжди буде важким. Див. Децентралізоване управління даними - інкапсуляція баз даних у мікросервіси для отримання інформації про те, чому.

Однак, існує кілька рецептів, як зробити це відносно здорово. Один з них - http://12factor.net/ . Це сказало б, що ви повинні підтримувати кожну бібліотеку та програму незалежно, а потім чітко керувати залежностями. Якщо ви підете цим маршрутом, то я перейду до НАЙКРАЩОЙ рекомендую вам мати просту команду, яка оновлює всі залежності до того, що є поточним, і ви запускаєте її регулярно для кожної мікро-служби. Важливо провести процес розумного випуску, коли ви блокуєте версії бібліотек у виробництві. Однак ти дуже, справді , насправді не хочеш опинятися в положенні, коли залежності залежають, і ти не знаєш, що там.

Також зосередьтеся на тому, щоб зробити ваші резервні бібліотеки максимально щільними та зосередженими. Завжди буде природний потяг, щоб почати додавати матеріали до основних бібліотек для легкого обміну. Зробіть це, і ви швидко потягнете весь куля існуючих спагетті в спільні бібліотеки і ефективно повернетеся до безладу, який у вас зараз. Тому краще переправити інший спосіб.

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