Wątek przeniesiony 2021-09-03 20:20 z Java przez furious programming.

Java, mikroserwisy, DRY

0

W ramach jednego mikroserwisu powinniśmy unikać duplikacji kodu. Ale w ramach kilku, nie powinniśmy tworzyć współdzielonych bibliotek między kilkoma mikroserwisami.

Czyli co:

  • powinniśmy wtedy duplikować kod
  • Zastanowić się czy te mikroserwisy nie powinny być jednym
  • czy jeszcze jakoś inaczej?
2

Tak na sucho, bez konkretnego kontekstu, objaśnienia domeny imho można napisać tylko to zależy.
Duplikacja kodu to nie jest największe zło świata jeżeli ma ona swoje powody ale też to czy n mikroserwisów nie powinno być jednym to już kwestia której nie da się rozstrzygnąć (tak jak ogólnie wyznaczania granic między mikroserwisami) bez znajomości domeny.

2
konradino898 napisał(a):

nie powinniśmy tworzyć współdzielonych bibliotek między kilkoma mikroserwisami.

O! A dlaczego? Prawie zawsze miałem współdzielone biblioteki między mikroserwisami. Albo z jakimiś utilsami, albo firmową nakładkę na generyczny framework

6

Sprawa jest prosta.
Oczywiście można, warto, a nawet należy współdzielić kod miedzy mikroserwisami.
Jakkolwiek powinno być to tak zrobione, aby działanie systemu nie było uzależnione od tego czy kod jest współdzielony. (Czyli, że w każdej chwili ktoś w jakimś serwisie może powiedzieć - mam gdzieś wasz kod, przepisuje wszystko na COBOLa i nie powinno to być problemem, jak długo nowy kod jest kompatybilny z zadanym API).
Samo API - dość częsty punkt programu - można publikować np. jako OpenAPI, proto itp. - w tym sensie, że współdzielimy specyfikację i każdy serwis - klient sobie na podstawie tego api generuje stuby do swojej technologii. (IMO przeważnie lepsze niż popularne wrzucanie client - jara, które nie dość, że narzuca javę, to jeszcze często konkretną technologię, zwykle zrypaną).

6

Ale w ramach kilku, nie powinniśmy tworzyć współdzielonych bibliotek między kilkoma mikroserwisami.

Całkowita nieprawda. Jeśli w każdym mikroserwisie masz validacje PESEL i NIP to powinieneś zrobic bibliotekę i pobierać ja przez jakieś lokalne repo Mavena.

0
jarekr000000 napisał(a):

Jakkolwiek powinno być to tak zrobione, aby działanie systemu nie było uzależnione od tego czy kod jest współdzielony. (Czyli, że w każdej chwili ktoś w jakimś serwisie może powiedzieć - mam gdzieś wasz kod, przepisuje wszystko na COBOLa i nie powinno to być problemem, jak długo nowy kod jest kompatybilny z zadanym API).

Czy to w praktyce nie ogranicza współdzielenia do jakichś prostych przypadków? Niby spoko jechać tym samym autobusem (współdzielony kod), ale do czasu, aż ktoś nie puści bąka (buga). Nie wszyscy oberwą, ale Ci na których trafi nie będą szczęśliwi.

3
yarel napisał(a):
jarekr000000 napisał(a):

Jakkolwiek powinno być to tak zrobione, aby działanie systemu nie było uzależnione od tego czy kod jest współdzielony. (Czyli, że w każdej chwili ktoś w jakimś serwisie może powiedzieć - mam gdzieś wasz kod, przepisuje wszystko na COBOLa i nie powinno to być problemem, jak długo nowy kod jest kompatybilny z zadanym API).

Czy to w praktyce nie ogranicza współdzielenia do jakichś prostych przypadków? Niby spoko jechać tym samym autobusem (współdzielony kod), ale do czasu, aż ktoś nie puści bąka (buga). Nie wszyscy oberwą, ale Ci na których trafi nie będą szczęśliwi.

To chyba najdziwniejsze uzasadnienie przeciwko wspólnemu kodowi jakie słyszałem. Przecież nikt nie używa tego kodu wspólnego dla własnego widzimisi tylko dlatego że i takjest potrzebny.
Załóżmy scenkę rodzajową, masz 10 mikroserwisów potrzebujących tej samej logiki, np walidacji:

  • Jeśli masz wspólny kod jest on napisany raz i 10 razy przetestowany w 10 mikroserwisach
  • Jeśli nie masz wspólnego kodu w każdym mikroserwisie masz osobną implementację przetestowaną tylko raz

Który przypadek jest bezpieczniejszy?
Który przypadek będzie łatwiej łatać i utrzymywać?
A jak masz 100 mikroserwisów?

2

@yarel:

Czy to w praktyce nie ogranicza współdzielenia do jakichś prostych przypadków? Niby spoko jechać tym samym autobusem (współdzielony kod), ale do czasu, aż ktoś nie puści bąka (buga). Nie wszyscy oberwą, ale Ci na których trafi nie będą szczęśliwi.

Taka historia: w moim pierwszym januszsofcie miałem ostrą scysje z programistami. Odkryłem, że wszystkie systemy sa zrobione tak, że jest dziesiątki plików JSP (skrypty javy), każdy zaczyna się od kilku tysięcy prawie tych samych skopiowanych funkcji bazowych (np, połączenie do bazy itp.). W ramach jednego systemu, wielokrotnie copy pastowany kod.
Zaproponowałem, żeby to wydzielić chociaż do jednego includowanego jsp i włączać do wszystkich plików. No i argument mamutów był nie do odparcia - przecież jak się ktoś pomyli w tym bazowym skrypcie to wszystkie strony serwisu nie będą działać... a przy copy-paste tylko kilka. Koniec bajki pierwszej.

W microserwisach jest problem raczej mentalny - ktoś kiedyś stwierdza, że to fajnie by wydzielić jakiś powtarzany kod - np. security, bo więcej serwisów z tego korzysta. OK.
Potem są jakieś zmiany w security, ale że jest jeden moduł, z którego wszyscy korzystają to nie ma problemu, są tam zmiany wrzucane i jest git.
Pewnego pięknego dnia chcesz coś zrobić w innej technologii i nagle się okazuje, że nikt już w zasadzie nie wie jak to zrobić, bo kluczowe elementy związane z security mają totalnie nieaktualną dokumentację. Przecież wszystko jest w jarze. Jar zmusza cię do korzystania z javy, springa i to jeszcze konkretnej wersji... koniec bajki drugiej.

0

Odpowiedzi w sumie tyle ile osób :P

Ja zgadzam się z tą teza zacytowana z książki w temacie. Jakiekolwiek współdzielenie powoduje wzrost zależności, sprzężenia, spada spójność.

Ale wiemy, że w życiu nigdy nie jest tak jak w idealnym świecie.

Według @jarekr000000 , jeśli dobrze Cię zrozumiałem, w mikroserwisach, pomiędzy nimi, możemy współdzielić drobe utilsy, czy jakiś kod wygenerowany na podstawie wsdla klienta itp. Coś co nie ma stanu i generalnie nie robi nic istotnego, popraw mnie proszę jak się mylę:)

Co do jakiś serwisów walidujacych PESEL itp. To raczej nie powinniśmy tego współdzielić, co nie znaczy że wiele osób nie robi tego nagminnie

0
jarekr000000 napisał(a):

W microserwisach jest problem raczej mentalny - ktoś kiedyś stwierdza, że to fajnie by wydzielić jakiś powtarzany kod - np. security, bo więcej serwisów z tego korzysta. OK.
Potem są jakieś zmiany w security, ale że jest jeden moduł, z którego wszyscy korzystają to nie ma problemu, są tam zmiany wrzucane i jest git.
Pewnego pięknego dnia chcesz coś zrobić w innej technologii i nagle się okazuje, że nikt już w zasadzie nie wie jak to zrobić, bo kluczowe elementy związane z security mają totalnie nieaktualną dokumentację. Przecież wszystko jest w jarze. Jar zmusza cię do korzystania z javy, springa i to jeszcze konkretnej wersji... koniec bajki drugiej.

Bajka pierwsza brzmi trochę jak niemiecki sen :-)

Co do kodu typu security, logowanie, connection poole, czy strzelanie po różnych technicznych interfejsach, to chyba nikt takiego kodu w dzisiejszych czasach nie klepie od 0, tylko korzysta z gotowców (biblioteki / skonteneryzowane zestawy klocków). Co do funkcjonalności wspólnej, to można wydzielić do osobnego mikroserwisu.

Może tę pozostałą funkcjonalność nie każdy chce wydzielać do osobnego mikroserwisu? Ale jak ma 100 mikroserwisów, to czemu miałby nie chcieć?

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0