Проектирование приложений на основе контейнеров и микрослужб

Микрослужбы предлагают большие преимущества, но также вызывают огромные новые проблемы. Шаблоны архитектуры микрослужб являются основными основами при создании приложения на основе микрослужб.

Ранее в этом руководстве вы узнали основные понятия о контейнерах и Docker. Эта информация была минимальной, необходимой для начала работы с контейнерами. Несмотря на то, что контейнеры являются включателями и отлично подходят для микрослужб, они не являются обязательными для архитектуры микрослужб. Многие понятия архитектуры в этом разделе архитектуры могут применяться без контейнеров. Однако в этом руководстве основное внимание уделяется пересечению этих элементов ввиду ранее озвученной важности контейнеров.

Корпоративные приложения могут быть сложными и часто состоят из нескольких служб вместо одного приложения на основе служб. В таких случаях необходимо понять другие архитектурные подходы, такие как микросервисы, определенные шаблоны проектирования Domain-Driven (DDD), а также концепции оркестрации контейнеров. Обратите внимание, что в этой главе описываются не только микрослужбы контейнеров, но и любое контейнерное приложение.

Принципы проектирования контейнеров

В модели контейнера экземпляр образа контейнера представляет один процесс. Определив образ контейнера как границу процесса, можно создать примитивы, которые можно использовать для масштабирования или пакетирования процесса.

При проектировании образа контейнера вы увидите определение ENTRYPOINT в Dockerfile. Это определение определяет процесс, время существования которого управляет временем существования контейнера. По завершении процесса жизненный цикл контейнера заканчивается. Контейнеры могут представлять длительные процессы, такие как веб-серверы, но также могут представлять короткие процессы, такие как пакетные задания, которые ранее были реализованы как веб-задания Azure.

Если процесс завершается ошибкой, контейнер завершается, и оркестратор берет на себя. Если оркестратор настроен на поддержание работы пяти экземпляров и один из них завершится сбоем, оркестратор создаст новый экземпляр контейнера для замены неудачного процесса. В пакетном задании процесс запускается с параметрами. По завершении процесса работа завершена. В этом руководстве подробно рассматриваются оркестраторы позже.

Вы можете найти сценарий, в котором требуется несколько процессов, выполняемых в одном контейнере. В этом сценарии, так как на контейнер может быть только одна точка входа, можно запустить скрипт в контейнере, который запускает столько программ, сколько требуется. Например, можно использовать диспетчер или аналогичное средство для запуска нескольких процессов в одном контейнере. Однако, несмотря на то, что вы можете найти архитектуры, которые содержат несколько процессов для каждого контейнера, этот подход не очень распространен.