Проектирование архитектуры приложений на основе контейнеров и микрослужб
Совет
Это содержимое представляет собой отрывок из электронной книги, архитектуры микрослужб .NET для контейнерных приложений .NET, доступных в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
Микрослужбы дают большие преимущества, но в то же время создают новые проблемы. Шаблоны архитектуры микрослужб являются основополагающим элементом при создании приложения на основе микрослужб.
Ранее в этом руководстве вы ознакомились с основными понятиями, связанными с контейнерами и Docker. Это минимальная информация, требуемая для начала работы с контейнерами. Даже несмотря на то, что контейнеры необходимы для использования микрослужб и отлично подходят для них, они не являются обязательными для архитектуры микрослужб. Многие архитектурные концепции, описанные в этом разделе, можно применять без контейнеров. Однако в данном руководстве основное внимание уделяется совместному использованию обоих вариантов из-за уже упоминавшейся важности контейнеров.
Корпоративные приложения могут быть сложными и часто состоят из нескольких служб, а не одной. В таких случаях необходимо хорошо представлять себе другие подходы к проектированию архитектуры, такие как использование микрослужб, а также определенные шаблоны проектирования на основе доменов и принципы оркестрации контейнеров. Имейте в виду, что в этой главе описываются не только микрослужбы в контейнерах, но и любые контейнерные приложения.
Принципы проектирования контейнеров
В модели на основе контейнеров экземпляр образа контейнера представляет отдельный процесс. Определив образ контейнера как границу процесса, вы можете создавать примитивы, с помощью которых можно масштабировать процесс или помещать его в пакет.
Когда вы проектируете образ контейнера, в Dockerfile отображается определение ENTRYPOINT. С его помощью определяется процесс, время существования которого контролирует время существования контейнера. По завершении процесса время существования контейнера истекает. Контейнеры могут представлять как длительные процессы, например веб-серверы, так и кратковременные, например пакетные задания, которые ранее могли реализовываться как веб-задания Azure.
В случае сбоя процесса работа контейнера завершается и оркестратор принимает управление. Если в оркестраторе настроена поддержка пяти выполняющихся экземпляров, то в случае сбоя одного из них оркестратор создаст ему на замену еще один экземпляр контейнера. В пакетном задании процесс запускается с параметрами. По завершении выполнения процесса работа считается выполненной. В этом руководстве оркестраторы будут рассматриваться более подробно позже.
Возможны ситуации, когда в одном контейнере желательно выполнять несколько процессов. Так как каждый контейнер может иметь только одну точку входа, в таком случае в контейнере можно использовать скрипт, который будет запускать нужное количество программ. Например, можно использовать Supervisor или аналогичное средство, отвечающее за запуск нескольких процессов в одном контейнере. Но хотя архитектуры, предусматривающие выполнение несколько процессов в контейнере, используются, это не очень популярное решение.