Tworzenie architektury aplikacji opartych na kontenerach i mikrousługach
Porada
Ta zawartość jest fragmentem książki eBook, architektury mikrousług platformy .NET dla konteneryzowanych aplikacji .NET, dostępnym na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
Mikrousługi oferują ogromne korzyści, ale także budzą ogromne nowe wyzwania. Wzorce architektury mikrousług są podstawowymi filarami podczas tworzenia aplikacji opartej na mikrousługach.
Wcześniej w tym przewodniku przedstawiono podstawowe pojęcia dotyczące kontenerów i platformy Docker. Te informacje były minimalnymi informacjami potrzebnymi do rozpoczęcia pracy z kontenerami. Mimo że kontenery są włączone i doskonale nadają się do mikrousług, nie są one obowiązkowe dla architektury mikrousług. Wiele pojęć dotyczących architektury w tej sekcji architektury można zastosować bez kontenerów. Jednak ten przewodnik koncentruje się na przecięciu obu ze względu na już wprowadzone znaczenie kontenerów.
Enterprise aplikacje mogą być złożone i często składają się z wielu usług zamiast jednej aplikacji opartej na usłudze. W takich przypadkach należy poznać inne podejścia dotyczące architektury, takie jak mikrousługi i niektóre wzorce projektowania Domain-Driven (DDD) oraz koncepcje orkiestracji kontenerów. Należy pamiętać, że w tym rozdziale opisano nie tylko mikrousługi w kontenerach, ale także każdą konteneryzowaną aplikację.
Zasady projektowania kontenerów
W modelu kontenera wystąpienie obrazu kontenera reprezentuje pojedynczy proces. Definiując obraz kontenera jako granicę procesu, można utworzyć elementy pierwotne, których można użyć do skalowania lub dzielenia na partie procesu.
Podczas projektowania obrazu kontenera zobaczysz definicję ENTRYPOINT w pliku Dockerfile. Ta definicja definiuje proces, którego okres istnienia kontroluje okres istnienia kontenera. Po zakończeniu procesu cykl życia kontenera kończy się. Kontenery mogą reprezentować długotrwałe procesy, takie jak serwery internetowe, ale mogą również reprezentować krótkotrwałe procesy, takie jak zadania wsadowe, które wcześniej mogły zostać zaimplementowane jako zadania WebJob platformy Azure.
Jeśli proces zakończy się niepowodzeniem, kontener zakończy się, a koordynator przejmie. Jeśli orkiestrator został skonfigurowany do działania pięciu wystąpień i jeden ulegnie awarii, orkiestrator utworzy kolejne wystąpienie kontenera, aby zastąpić proces, który zakończył się niepowodzeniem. W zadaniu wsadowym proces jest uruchamiany z parametrami. Po zakończeniu procesu praca zostanie ukończona. Te wskazówki przejdą do szczegółów orkiestratorów, później.
Może się okazać, że potrzebujesz wielu procesów uruchomionych w jednym kontenerze. W tym scenariuszu, ponieważ może istnieć tylko jeden punkt wejścia dla każdego kontenera, można uruchomić skrypt w kontenerze, który uruchamia dowolną liczbę programów zgodnie z potrzebami. Na przykład można użyć nadzorcy lub podobnego narzędzia, aby dbać o uruchamianie wielu procesów wewnątrz jednego kontenera. Jednak mimo że można znaleźć architektury, które przechowują wiele procesów na kontener, takie podejście nie jest bardzo powszechne.