Mikrousługi i model kanoniczny

9

Kiedy czytałem o mikrousługach na tej stronie , natknąłem się na poniższe oświadczenie. Co należy rozumieć przez schemat kanoniczny? Czy to nie to samo co model domeny?

Wzorzec architektury Microservices Architecture odrzuca również inne części SOA, takie jak koncepcja schematu kanonicznego.

web-services soa microservices nginx Punter Vicky
źródło
Czy znasz źródło tego stwierdzenia? (dla celów linkowania)
Jack
Jasne, Jack, jest tutaj - nginx.com/blog/introduction-to-microservices/…
Punter Vicky
Przypuszczam, że tego artykułu w Wikipedii jest tym, czego szukasz. Jednak nie uważam tego artykułu za łatwy do zrozumienia.
Arseni Mourzenko
Dzięki @ArseniMourzenko. Wierzę, że nawet w architekturze mikrousług, żądanie i odpowiedź muszą być zgodne z pewnym modelem danych. Nie jestem jeszcze w stanie zrozumieć, dlaczego jest nazywany odrzucany przez architekturę mikrousług.
Punter Vicky,
2
Niektóre modele danych tak, ale wydaje mi się, że artykuł odnosi się do „wspólnych” lub „wspólnych” modeli danych między 2 lub więcej usługami. Schemat kanoniczny jest wzorcem przeznaczonym do oszczędzania usług podczas transformacji danych wykonawczych. Wspólny „język” między usługami. Wygląda więc na to, że artykuł podkreśla całkowitą niezależność państw członkowskich od „ekosystemu”, w którym żyje. Weźmy na przykład wzmiankę o ESB. ESB zwykle wymaga modelu danych przedsiębiorstwa (komunikatów), który będzie wspólny dla wszystkich w autobusie. MS odrzuca dołączenie do jakiegokolwiek zewnętrznego ograniczenia systemu.
Laiv

Odpowiedzi:

5

Z góry przepraszam za poleganie na komentarzu @ArseniMourzenko, ale kiedy zacząłem czytać Wikipedię, od razu zrozumiałem, co oznacza schemat kanoniczny .

Oto komentarz OP, który koncentruje się na prawdziwych wątpliwościach

Wierzę, że nawet w architekturze mikrousług, żądanie i odpowiedź muszą być zgodne z pewnym modelem danych.

Niektóre modele danych tak, ale wydaje się, że artykuł odnosi się do „wspólnych” lub „wspólnych” modeli danych między 2 lub więcej usługami.

Canonical Schema to oznaczało, aby zapisać wzór z usług w przekształceniach danych uruchomieniowych. Oszczędza to również przed kopiowaniem kodu. Ale następnie łączysz swoją usługę z zewnętrznym modelem danych. (Zobacz diagramy na stronie Wikipedii, do której link znajduje się powyżej)

Jest to rodzaj wspólnego „języka” między usługami.

Wygląda więc na to, że artykuł podkreśla całkowitą niezależność państw członkowskich od „ekosystemu”, w którym żyje.

Weźmy na przykład wzmiankę o ESB.

Bardzo również unikają używania ESB i zamiast tego implementują funkcjonalność podobną do ESB w samych mikrousługach.

ESB zwykle wymaga modelu danych przedsiębiorstwa (komunikatów), który będzie wspólny dla wszystkich podłączonych do magistrali.

Wracając do artykułu, wydaje się, że autor wskazuje na to, że stwardnienie rozsiane odrzuca przywiązanie do dowolnego systemu zewnętrznego (i ich ograniczenia) .

Laiv
źródło
Dzięki @Laiv. Przyznam nagrodę za 9 godzin - więc mnie to ogranicza :)
Punter Vicky
1

W mikrousługach chodzi o ścisłą spójność i luźne połączenie. W obrębie mikrousług masz ścisłą spójność, ale między mikrousługami masz luźne połączenie, dlatego chcesz uniknąć wspólnych schematów lub kontraktów danych. Jeśli zauważysz, że masz mikrousługi wykonujące ze sobą połączenia synchroniczne w sposób, który wymaga wspólnego wspólnego schematu, może to wskazywać, że nieprawidłowo zdefiniowałeś granice usług.

Mikrousługi powinny być ściśle dostosowane do ograniczonych kontekstów, w języku projektowania opartym na domenie.

pnschofield
źródło
If you find that you have microservices making synchronous calls. Niekoniecznie wywołania asynchroniczne. Może się to zdarzyć również w przypadku komunikatów asynchronicznych ESB. Myślę, że koncentruje się na fakcie, że ma być powiązany ze wspólnymi schematami lub umowami dotyczącymi danych. Zakładam, że w architekturze MS należy unikać wszelkiej komunikacji p2p między serwisami. Komunikacja powinna odbywać się za pośrednictwem aplikacji zamiast dowolnej warstwy wewnętrznej (wewnętrzna warstwa usługi) lub zewnętrznej (ESB, kolejka itp.)
Laiv