Architektura logiczna a architektura fizyczna
Napiwek
Ta zawartość jest fragmentem książki eBook, architektury mikrousług platformy .NET dla konteneryzowanych aplikacji platformy .NET dostępnych na platformie .NET Docs lub jako bezpłatnego pliku PDF, który można odczytać w trybie offline.
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ą. Architektura logiczna i granice logiczne systemu nie muszą mapować jeden na jeden do architektury fizycznej lub wdrożenia. 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ługę biznesową lub ograniczony kontekst musi być autonomiczny, umożliwiając niezależne wersjonowanie, wdrażanie i skalowanie kodu i stanu.
Jak pokazano na rysunku 4–8, mikrousługa biznesowa wykazu może składać się z kilku usług lub procesów. Może to być wiele ASP.NET usług internetowego interfejsu API lub dowolnego innego rodzaju usług przy użyciu protokołu HTTP lub dowolnego 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 wyszukiwania. 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 internetowego interfejsu API zwykle potrzebuje więcej wystąpień niż usługa wyszukiwania lub odwrotnie.
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.
