Architektura logiczna a architektura fizyczna

Wskazówka

Ta treść jest fragmentem eBooka "Architektura mikrousług .NET dla konteneryzowanych aplikacji .NET", dostępnego na .NET Docs lub jako bezpłatny plik PDF do pobrania i czytania w trybie offline.

Pobierz plik PDF

W tym momencie warto zatrzymać i omówić rozróżnienie między architekturą logiczną i architekturą fizyczną oraz sposób, w jaki ma to zastosowanie do projektowania aplikacji opartych na mikrousługach.

Aby rozpocząć, tworzenie mikrousług nie wymaga użycia żadnej konkretnej technologii. Na przykład kontenery platformy Docker nie są obowiązkowe do tworzenia architektury opartej na mikrousługach. Te mikrousługi mogą być również uruchamiane jako zwykłe procesy. Mikrousługi to architektura logiczna.

Ponadto, nawet jeśli mikrousługę można fizycznie zaimplementować jako pojedynczą usługę, proces lub kontener (dla uproszczenia jest to podejście podjęte w początkowej wersji eShopOnContainers), ta parzystość między mikrousługą biznesową i usługą fizyczną lub kontenerem nie musi być wymagana we wszystkich przypadkach podczas tworzenia dużej i złożonej aplikacji składającej się z wielu kilkudziesięciu, a nawet setek usług.

W tym miejscu istnieje różnica między architekturą logiczną aplikacji a architekturą fizyczną. Logiczna architektura i granice logiczne systemu nie muszą odpowiadać jeden do jednego architekturze fizycznej lub wdrożeniowej. Może się to zdarzyć, ale często nie.

Chociaż być może zidentyfikowano pewne mikrousługi biznesowe lub ograniczone konteksty, nie oznacza to, że najlepszym sposobem ich zaimplementowania jest zawsze utworzenie jednej usługi (takiej jak interfejs API sieci Web ASP.NET) lub pojedynczego kontenera platformy Docker dla każdej mikrousługi biznesowej. Posiadanie reguły informującej, że każda mikrousługa biznesowa musi być zaimplementowana przy użyciu jednej usługi lub kontenera, jest zbyt sztywna.

W związku z tym mikrousługa biznesowa lub Kontekst ograniczony to architektura logiczna, która może się zbiegać (lub nie) z architekturą fizyczną. Ważnym punktem jest to, że mikrousługa biznesowa lub Ograniczony Kontekst musi być autonomiczna, umożliwiając niezależne wersjonowanie, wdrażanie i skalowanie kodu i stanu.

Na rysunku 4-8 pokazano, że mikrousługa biznesowa katalogu może składać się z kilku usług lub procesów. Może to być wiele usług ASP.NET Web API lub dowolnego innego rodzaju usług korzystających z protokołu HTTP lub innego protokołu. Co ważniejsze, usługi mogą udostępniać te same dane, o ile te usługi są zgodne z tą samą domeną biznesową.

Rysunek 4–8. Mikrousługi biznesowe z kilkoma usługami fizycznymi

Usługi w przykładzie współdzielą ten sam model danych, ponieważ usługa internetowego interfejsu API jest przeznaczona dla tych samych danych co usługa Search. Dlatego w fizycznej implementacji mikrousługi biznesowej dzielisz te funkcje, aby można było skalować każdą z tych usług wewnętrznych w górę lub w dół zgodnie z potrzebami. Być może usługa API sieciowego zwykle potrzebuje więcej wystąpień niż usługa wyszukiwania, lub na odwrót.

Krótko mówiąc, architektura logiczna mikrousług nie zawsze musi być zgodna z architekturą wdrożenia fizycznego. W tym przewodniku zawsze, gdy wspominamy o mikrousłudze, oznaczamy mikrousługę biznesową lub logiczną, która może być mapowana na co najmniej jedną usługę (fizyczną). W większości przypadków będzie to jedna usługa, ale może to być więcej.

PoprzedniNastępny