Mikrousługi i biblioteki współdzielone

9

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?

blueFast
źródło
Sam nie jestem wystarczająco dobrze zaznajomiony z mikrousługami (moja firma niedawno zaczęła robić coś podobnego), aby odpowiedzieć, ale tutaj jest link do prezentacji, dlaczego to, co opisujesz, jest czerwoną flagą i może prowadzić do „rozproszonego monolitu” . Mikrousługi nie powinny wymagać bibliotek współdzielonych. Naprawdę powinny komunikować się tylko między dobrze zdefiniowanym interfejsem API, takim jak Swagger (teraz nazywany Open API ).
Captain Man
@CaptainMan: Jasne, ale powiedzmy, że masz tę prostą funkcję: fib(n)(implementacja serii Fibonacciego). Nie chcesz powtarzać tej implementacji w każdej mikrousługie. Należy do utilsbiblioteki (w wersji, dla funkcji i poprawek błędów). To nie jest rozproszony monolit, to tylko warstwa wspólnej funkcjonalności. Moje pytanie dotyczy sposobu obsługi tej warstwy na poziomie wdrożenia?
blueFast
Nasze mikrousługi mają wspólne biblioteki, aby mieć pewność, że rozmawiają z wszystkimi innymi mikrousługami w naszym systemie w ten sam sposób. Nie jestem pewien, jak byłoby to możliwe w przypadku bibliotek nieudostępnionych; co najmniej każdy potrzebowałby bibliotek do manipulacji XML / JSON / etc. Nie obejrzałem jeszcze tej prezentacji, ale czy miałeś na myśli bardziej szczegółowe znaczenie „wspólnej biblioteki” niż to, o którym myślę?
Ixrec
1
@ jeckyll2hide Używamy C ++, ale nasza infrastruktura do tego odpowiada mniej więcej drugiemu punktowi: osobne repo, każdy deklaruje swoje zależności, standardowy system kompilacji, który wie, jak znaleźć te zależności w czasie kompilacji itp.
Ixrec
1
Czuję się jak manekin, twoje pytanie tak naprawdę nie dotyczy mikrousług udostępniających biblioteki, to naprawdę pytanie o to, jak udostępnić biblioteki zespołu zespołowi. Wiem o tym wystarczająco dużo, aby opublikować odpowiedź.
Captain Man

Odpowiedzi:

5

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

Tommy
źródło
1
Zgadzam się, że opcja 2 jest najlepsza, ale opcja 3 z podmodułami ma znacznie więcej wspólnego z opcją 2 niż opcja 1.
8bittree 15.04.16
@ 8bittree: tak, opcja 3 jest podobna do opcji 2, ale posiadanie serwera git („centralnego” pilota) jest mechanizmem dystrybucji pakietów. Z jednej strony używa git do czegoś, czego nie ma na myśli (zarządzanie zależnościami), z drugiej strony zmniejsza liczbę komponentów (nie wymaga prywatnego PyPi)
blueFast 18.04.2016
2

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).

Kapitanie Człowieku
źródło
1

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.

btilly
źródło
0

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.

Dogweather
źródło