Ankieta - mikroserwisy a współdzielenie kodu

Ankieta - mikroserwisy a współdzielenie kodu
Czy w twoim projekcie macie tzw "shared libraries" między mikroserwisami?
Nie, nie mamy żadnych
9%
9% [2]
Mamy tylko jedną dzieloną libke jako bazę dla wszystkich serwisów
18%
18% [4]
Mamy wiele małych paczek odpowiadających za konkretną rzecz (np. logging, komunikacja z Kafką, Pulsar, MongoDB itd.)
27%
27% [6]
Mamy wiele paczek zawierających kod infra (np logging, komunikacja) oraz kod biznesowy
23%
23% [5]
Nasz projekt to typowy distributed monolith - niby mikroserwisy, ale jedna baza, wszędzie współdzielony kod i koszmar przy deploymentach
23%
23% [5]
azalut
  • Rejestracja:około 12 lat
  • Ostatnio:ponad rok
  • Postów:1129
4

cześć
Temat stary jak świat i wiadomo że współdzielenie kodu miedzy mikroserwisami raczej przysparza problemów.

(mówiąc dalej "paczka" mam na myśli np. .jar w JVM, paczke w node, nuget w c# itd.)
Realia jednak są takie, że czasami to się zdarza. Nie tyle współdzielony kod biznesowy, co np. osobna paczka do logowania w okreslonym standardzie projektowym, osobna paczka dla konsumerów i producerów Kafki, osobna dla konfiguracji połączenia z bazą (nawet majac baza per serwis), osobna konfigurująca GraphQL itd.
Albo - jedna paczka która służy jako baza dla każdego mikroserwisu, zawierająca wszystko z czego korzysta większość z nich. Np większosc używa Kafki, Postgresa, jakiegoś loggera itd.

Pewne rzeczy to upraszcza, ale też powoduje oczywiste komplikacje.

Może jestem w błędzie, ale mam wrażenie, że taki dylemat rzadziej występuje jak w projekcie używany jest powiedzmy Spring, który praktycznie do wszystkiego ma paczkę, która wystarczy wrzucic na classpath i mamy coś skonfigurowane. Natomiast używając mniejsze biblioteki np. jakieś (strzelam) Akka HTTP, Ktor, Quarkus, Micronaut i tak dalej - często trzeba niektóre rzeczy trzeba po prostu sobie napisać ;)

Stoję teraz trochę przed takim dylematem. Przekopałem już cały internet, ale mam niedosyt.
Zachęcam do odpowiedzi w ankiecie. Będę wdzieczny za jakieś odpowiedzi jak to u was jest i jak to się z tym żyje :) (chyba warto wspomnieć z jaką ilościa mikrosvc pracujecie)

Dzięki!

edytowany 1x, ostatnio: azalut
AK
  • Rejestracja:ponad 6 lat
  • Ostatnio:około rok
  • Postów:3561
1
azalut napisał(a):

Temat stary jak świat i wiadomo że współdzielenie kodu miedzy mikroserwisami raczej przysparza problemów.

Podobnie jak odwrotność, rozpi..l i totalna wolnoamerykanka, założenie, ze nic wspólnego
https://4programmers.net/Mikroblogi/View/85567


Bo C to najlepszy język, każdy uczeń ci to powie
edytowany 1x, ostatnio: AnyKtokolwiek
azalut
to prawda; skrajności rzadko wychodza na dobre :P
Aventus
  • Rejestracja:prawie 9 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:UK
  • Postów:2235
3

Brakuje mi odpowiedzi w stylu "mamy wiele paczek odpowiadających za dzielenie wspólnego kodu takiego jak DTO, dostęp do infrastruktury itp.". Tutaj najbliżej jest opcja trzecia ale aż tak drobnego podziału nie mamy.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
azalut
o to dokładnie chodziło mi w punkcie 3
Bronzebeard
  • Rejestracja:ponad 4 lata
  • Ostatnio:4 miesiące
  • Postów:15
1

W projekcie, w którym obecnie pracuję mamy monorepo, ale każdy z serwisów jest wdrażany ciągle i niezależnie. Każdy serwis, to osobny projekt gradlowy. Podobnie z kodem specyficznym pod względem logowania ze względu na wymogi dotyczące SoC i audytu, czy z kodem odpowiedzialnym za:

  • dostęp do infrastruktury,
  • instrumentowanie zależności, których Elastic APM z pudełka nie instrumentuje.

To wszystko są oddzielne projekty w monorepo. Niektóre z nich publikujemy do użytku wewnątrz organizacji.

Jeśli już współdzielimy kod pomiędzy serwisami, to właśnie tylko ten wyżej wspomniany. Jeśli mamy komunikację pomiędzy serwisami, to model i klientów powielamy tu i tu albo generujemy je na podstawie YAMLa (OpenAPI).

Właściwie to trzymamy się tego, że jeśli nasz serwis ma wystawione API po HTTP, to publikujemy odpowiednią definicję w OpenAPI. Na podstawie tej definicji generujemy kod serwera, z którego sami korzystamy odcinając się na adapterze, żeby upewnić się, że jest YAML aktualny i czy nie ma z nim problemów.


"Delve Deeper Dwarves" by Lunar Giant is licensed under CC BY-SA 3.0.
edytowany 5x, ostatnio: Bronzebeard
Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
1
  1. Każdy serwis ma moduł client budowany jako osobny artefakt i inne serwisy go sobie wciągają, żeby nie musieć myśleć o takich rzeczach jak nazwy endpointów czy mapowanie odpowiedzi na DTO
  2. Oprócz tego jest kilka artefaktów commons-* z jakimiś wspólnymi boilerplatami.

"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
danek
moduł client ma w sobie klienta http + odpowiednie modele?
Shalom
Ma klasę która ma w sobie http clienta i zna wszystkie endpointy i umie w nie stukać + ma wszystkie DTO zeby móc pisać/czytać z tych endpointów. W efekcie w swoim kodzie robisz np. client = new XakepClient(host,port) a potem jakieś result = client.sendMonies(cośtam) i nie zastanawiasz się jak sformować jsona z argumentami albo jak zmapować odpowiedź, albo pod jaki to endpoint ma iść.
FE
  • Rejestracja:ponad 11 lat
  • Ostatnio:prawie 3 lata
0

@Shalom: A co robicie gdy endpointy się zmieniają? Wersjonujecie klienta a stare utrzymujecie do końca świata?


Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
1

@Fedaykin a co robisz w dowolnym innym przypadku kiedy endpointy sie zmieniają? :) Artefakty są w repo i są wersjonowane, a czy trzymamy stare API czy nie, to zależy od sytuacji. Jeśli wiem dokładnie kto korzysta to mówie im zeby podbili wersje klienta i oram stare endpointy. W innym wypadku możesz wersjonować sobie API.
Niemniej tak czy siak, twoje pytanie nijak sie ma do samego faktu robienia artefaktu z klientem, a raczej do problemu wersjonowania API jako takiego.


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
edytowany 1x, ostatnio: Shalom
FE
  • Rejestracja:ponad 11 lat
  • Ostatnio:prawie 3 lata
0

@Shalom: Rozumiem. Trochę tak, trochę nie - mając np. monorepo z bezpośrednimi zależnościami zmiana API / obiektów powinna spowodować brak kompilacji / błędy w testach jednostkowych/akceptacyjnych innych serwisów. W takim przypadku łatwiej jest sprawdzić wszystkie użycia i ewentualnie je updatować jeżeli nie chcemy wersjonować.

Dodatkowo breaking zmiany w commonach też powodują j/w, to powoduje przeniesienie części odpowiedzialności na osoby robiące tam zmiany bo nie mogą sobie po prostu podbić wersji i zapomnieć o backwards compatibility. Co może być i dobre i złe zależnie od struktury organizacji.


Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
0

@Fedaykin bardzo śmiałe założenie że z twojego API korzystają tylko "wewnętrzne" zależości i zmiana w monorepo wszystko "automatycznie naprawi" ;) No i znów bardzo śmiałe założenie że jesteś w stanie "naprawić" inne serwisy które właśnie popsułeś swoją zmianą. Bo wyobraź sobie że nie zmieniłeś nazwy endpointu, tylko np. dane które są zwracane mają inną postać. Naprawienie innego serwisu który z tego korzysta może być mocno nietrywialne...

Dodatkowo breaking zmiany w commonach też powodują j/w, to powoduje przeniesienie części odpowiedzialności na osoby robiące tam zmiany bo nie mogą sobie po prostu podbić wersji i zapomnieć o backwards compatibility. Co może być i dobre i złe zależnie od struktury organizacji.

Nie bardzo rozumiem w jaki niby sposób. Przecież nikt w twoim projekcie ci nie podbija wersji commonów o_O Tobie wszystko nadal działa tak jak działało, bo lecisz na starej wersji. Dopiero jak sam będziesz podbijać wersje to zobczysz ze coś jest niekompatybilne i musisz to u siebie naprawić. To właśnie pomysł z monorepo i barkiem wersjonowania może powodować takie fuckupy, że coś nagle przestało ci działać, bo kto w innym miejscu coś sobie zmienił, a ty nie miałeś 100% pokrycia testami...


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
FE
  • Rejestracja:ponad 11 lat
  • Ostatnio:prawie 3 lata
0

@Shalom: W przypadku wewnętrznych systemów bazowanych na mikroserwisach to rozsądne założenie, zazwyczaj zewnętrzne systemy w takim przypadku nawet nie są w tej samej sieci. End-pointy wychodzące na świat zewnętrzny mają ten problem nadal, ale jest ich zazwyczaj zdecydowanie mniej. Oczywiście że to nic "automatycznie nie naprawia", to jedynie pokazuje problemy po stronie wprowadzającej zmiany. Może być mocno nietrywialne i to jest ok, wtedy wiemy kto jest za ten serwis odpowiedzialny i angażujemy go do zmian.

Nie bardzo rozumiem w jaki niby sposób. Przecież nikt w twoim projekcie ci nie podbija wersji commonów o_O Tobie wszystko nadal działa tak jak działało, bo lecisz na starej wersji. Dopiero jak sam będziesz podbijać wersje to zobczysz ze coś jest niekompatybilne i musisz to u siebie naprawić. To właśnie pomysł z monorepo i barkiem wersjonowania może powodować takie fuckupy, że coś nagle przestało ci działać, bo kto w innym miejscu coś sobie zmienił, a ty nie miałeś 100% pokrycia testami...

Dokładnie monorepo miałem na myśli! I to jest fuckup z jednej strony, z drugiej wymusza na wprowadzających zmiany nieco ostrożniejsze/bardziej kolaboracyjne podejście. Brak dobrych testów w tym przypadku będzie prowadzić do problemów tak czy inaczej, bo w modelu nie-monorepo i tak będzie strach w momencie podbijania zależności, więc pewnie będą podbijane tylko gdy jest to absolutnie koniecznie. A tak wszyscy muszą być up-to-date czy tego chcą czy nie.

To absolutnie nie jest złoty graal, inne rozłożenie odpowiedzialności i problemów. Nawet nie jestem przekonany czy jestem fanem takiego podejścia.


superdurszlak
wewnętrznych systemów bazowanych na mikroserwisach ale że co? Ktoś przepisuje DBMS na mikroserwisy?
FE
bazowanych, nie "bazodanowych'
Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
1

i tak będzie strach w momencie podbijania zależności

Zawsze jest, ale czym innym jest sytuacja kiedy wiesz ze podbijasz i patrzysz szczegółowo czy coś się nie sypnęło, a czym innym kiedy nawet nie wiesz ze ktoś coś zmienia w monorepo ;)

więc pewnie będą podbijane tylko gdy jest to absolutnie koniecznie

Wręcz przeciwnie, podbijasz tak szybko kiedy to możliwe, bo poprawki po jednej małej zmianie są proste, a jak podbijesz się o 100 wersji w góre nagle to może się okazać że bardzo cięzko ogarnąć wszystkie potrzebne zmiany.


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
FE
Chciałbym żeby wszyscy tak robili :)
Kliknij, aby dodać treść...

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj <u>underline</u>.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, <b>, <i>, <kbd>, <del>, <strong>, <dfn>, <pre>, <blockquote>, <hr/>, <sub>, <sup> oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H<sub>2</sub>O i m<sup>2</sup> otrzymasz: H2O i m2.

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript
document.write('Hello World');
```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy  by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

  • Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
  • Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
  • Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
  • Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

  • Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

  • Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

  • Alt+L - zaznaczenie całej linii
  • Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
  • Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
  • Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

  • Ctrl+Enter - dodaj post
  • ⌘+Enter - dodaj post (MacOS)