Логическая архитектура и физическая архитектура

Подсказка

Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

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

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

Кроме того, даже если микрослужба может быть физически реализована как отдельная служба, процесс или контейнер (для простоты, это подход, принятый в первоначальной версии eShopOnContainers), этот паритет между бизнес-микрослужбой и физической службой или контейнером не обязательно требуется во всех случаях при создании большого и сложного приложения, состоящего из нескольких десятков или даже сотен служб.

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

Хотя вы могли определить определенные микрослужбы бизнеса или ограниченные контексты, это не означает, что лучший способ их реализации всегда заключается в создании одной службы (например, веб-API ASP.NET) или одного контейнера Docker для каждой бизнес-микрослужбы. Имея правило, указывающее, что каждый бизнес-микросервис должен быть реализован с помощью одной службы или контейнера, слишком строго.

Таким образом, бизнес-микрослужба или ограниченный контекст — это логическая архитектура, которая может совпадать (или нет) с физической архитектурой. Важно отметить, что бизнес-микрослужба или ограниченный контекст должны быть автономными, позволяя коду и состоянию становиться независимо версиионированными, развёртываться и масштабироваться.

Как показано на рисунке 4-8, микрослужба бизнес-службы каталога может состоять из нескольких служб или процессов. Это может быть несколько ASP.NET веб-API или любой другой вид служб с помощью HTTP или любого другого протокола. Более важно, что службы могут совместно использовать те же данные, если эти службы связаны с тем же бизнес-доменом.

Рис. 4-8. Микрослужба бизнеса с несколькими физическими службами

Службы в примере используют ту же модель данных, так как веб-СЛУЖБА API ориентирована на те же данные, что и служба поиска. Таким образом, в физической реализации бизнес-микрослужбы вы разделяете эту функцию, чтобы можно было масштабировать каждую из этих внутренних служб вверх или вниз по мере необходимости. Может быть, служба веб-API обычно требует больше экземпляров, чем служба поиска, или наоборот.

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

НазадДалее