Mikrousługi i biblioteki współdzielone

Projektujemy system oparty na niezależnych mikrousługach (połączonych przez magistralę RabbitMq). Kod (przynajmniej dla pierwszych składników) zostanie napisany w python (zarówno python2, jak i python3). Mamy już aplikację monolitową implementującą logikę biznesową, którą chcemy refaktoryzować i rozszerzyć. Jedno pytanie, które mnie martwi, to:

Jaki jest najlepszy sposób udostępniania kodu między różnymi mikrousługami. Mamy wspólne funkcje pomocnicze (przetwarzanie danych, logowanie, parsowanie konfiguracji itp.), Z których musi korzystać kilka mikrousług.

Same mikrousługi zostaną opracowane jako osobne projekty (repozytoria git). Wspólne biblioteki można również opracować jako samodzielny projekt. Jak współdzielić te biblioteki między mikrousługami?

Widzę kilka podejść:

• skopiuj wersję biblioteki potrzebną dla każdej mikrousługi i zaktualizuj w razie potrzeby
• zwolnij wspólne biblioteki do wewnętrznego PyPi i umieść te biblioteki jako zależności w wymaganiach mikrousługi
• dołącz repozytorium biblioteki jako podmoduł git

Przed podjęciem decyzji o dalszym postępowaniu chciałbym przeczytać nieco więcej na temat sugerowanych podejść, najlepszych praktyk i wcześniejszych doświadczeń. Czy masz jakieś sugestie lub link?

Druga opcja to zdecydowanie najlepsza droga. Wydziel wspólne biblioteki i zainstaluj je na lokalnym serwerze PyPi.

Opcja 1 jest przerażająca, ponieważ ulepszenia bibliotek będą trudne do rozpowszechnienia wśród innych, którzy mogliby z niej skorzystać.

Opcja 3 jest podobna do opcji 1.

Częstym wzorcem jest konfigurowanie Jenkinsa, aby po naciśnięciu przycisku opanowania repozytorium biblioteki tworzy kompilację w języku Python i automatycznie przesyła ją do repozytorium PyPi. Po napisaniu tego skryptu kompilacji nigdy nie będziesz musiał martwić się pakowaniem bibliotek i ręcznym przesyłaniem ich do PyPi. Dzięki tej opcji wszystkie aktualizacje bibliotek będą natychmiast dostępne i będą mogły zostać uaktualnione do innych mikrousług.

Konfigurowanie własnego serwera PyPi jest bardzo łatwe. Podoba mi się ten przewodnik

Nie facet w Pythonie, ale serwer PyPi wydaje się najlepszą opcją. Szybkie googling daje wrażenie, że jest to analogiczne do posiadania repozytorium Nexusa dla słoików Java zespołu.

Naprawdę, dopóki jest ono wdrażane w jakimś centralnym repozytorium (w biurze / zespole), z którym wybrane narzędzie do zarządzania zależnościami może współpracować (czytać i wdrażać), jest to dobra opcja.

Opcja 1 jest naprawdę najgorsza, nigdy nie powinieneś ręcznie radzić sobie z zależnościami. To ból. W college'u zanim poznałem Mavena i kiedy myślałem, że Git jest zbyt skomplikowany, zrobiliśmy wszystko ręcznie, od scalenia kodu każdego, przez ustawienie ścieżek klas, aż po pobieranie zależności. To był ból, poważnie nie chciałbym, aby ktokolwiek przeszedł choć część tego problemu, szczególnie w środowisku pracy, w którym ważna jest wydajność.

Opcja 3 prawdopodobnie działałaby dobrze, ale nie ma żadnych rzeczywistych korzyści w stosunku do lokalnego PyPi (poza tym, że może być łatwiejsza w konfiguracji, ale zalety prawdziwego systemu zarządzania zależnościami są o wiele lepsze).

Przede wszystkim podzielenie monolitu na mikrousługi zawsze będzie trudne. Zobacz Zdecentralizowane zarządzanie danymi - kapsułkowanie baz danych w mikrousługach, aby dowiedzieć się, dlaczego.

To powiedziawszy, istnieje kilka przepisów na to, jak to zrobić względnie rozsądnie. Jednym z nich jest http://12factor.net/ . Powiedziałoby to, że powinieneś utrzymywać każdą bibliotekę i aplikację niezależnie, a następnie jawnie zarządzać zależnościami. Jeśli pójdziesz tą drogą, polecę MOCNIE, abyś miał proste polecenie, które aktualizuje wszystkie zależności do tego, co jest aktualne, i uruchamiasz je regularnie dla każdej mikro-usługi. Ważne jest, aby mieć rozsądny proces wydania, w którym blokujesz wersje bibliotek w produkcji. Jednak naprawdę, naprawdę , naprawdę nie chcesz być w sytuacji, w której zależności stają się przestarzałe i nie wiesz, co tam jest.

Skoncentruj się również na tym, aby biblioteki kopii zapasowych były tak zwarte i skoncentrowane, jak to możliwe. Zawsze będzie naturalny wysiłek, aby zacząć dodawać rzeczy do bibliotek podstawowych w celu łatwego udostępniania. Zrób to, a szybko wciągniesz całą kulkę istniejącego spaghetti do wspólnych bibliotek i skutecznie wrócisz do bałaganu, który masz teraz. Dlatego lepiej jest poprawić w inny sposób.

Powinieneś być w stanie przejść bez serwera, wskazując bezpośrednio z pliku zależności pakietu Python na prywatne repozytoria GitHub zawierające biblioteki. Uważam, że Pipenv i Poeta popierają to.