Логическая и физическая архитектура
Совет
Это содержимое является фрагментом из электронной книги, архитектуры микрослужб .NET для контейнерных приложений .NET, доступных в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно читать в автономном режиме.
Теперь будет полезно отвлечься и обсудить разницу между логической и физической архитектурами, а также поговорить о том, какое значение она имеет для проектирования приложений на основе микрослужб.
Начнем с того, что для разработки микрослужб не требуется использовать какую-либо определенную технологию. Например, для создания архитектуры на основе микрослужб контейнеры Docker не являются обязательными. Микрослужбы могут также выполняться как обычные процессы. Микрослужбы образуют логическую архитектуру.
Кроме того, даже несмотря на то, что микрослужба может быть физически реализована как отдельная служба, процесс или контейнер (для простоты именно такой подход был выбран в первоначальной версии приложения eShopOnContainers), подобное соответствие бизнес-микрослужбы и физической службы или контейнера не всегда является обязательным, особенно при разработке больших и сложных приложений, состоящих из десятков и даже сотен служб.
Именно в этом проявляется различие между логической и физической архитектурами приложения. Логическая архитектура и логические границы системы необязательно должны в точности совпадать с физической архитектурой или архитектурой развертывания. Они могут совпадать, но часто это не так.
Возможно, вы уже выделили определенные микрослужбы или ограниченные контексты, но это не значит, что оптимальный способ их реализации всегда состоит в создании отдельной службы (например, веб-API ASP.NET) или отдельного контейнера Docker для каждой микрослужбы. Правило, гласящее, что каждая микрослужба должна реализовываться как отдельная служба или контейнер, является слишком строгим.
Таким образом, бизнес-микрослужба или ограниченный контекст — это компонент логической архитектуры, которая может совпадать с физической архитектурой, а может, и нет. Важным требованием является автономность микрослужбы или ограниченного контекста, которая обеспечивает независимое управление версиями, развертывание и масштабирование кода и состояния.
Как показано на рис. 4-8, микрослужба каталога может состоять из нескольких служб или процессов. Это может быть несколько служб на основе веб-интерфейсов API ASP.NET или любых других служб, использующих протокол HTTP либо иной протокол. Более того, эти службы могут использовать одни и те же данные при условии, что они связаны с одной предметной областью.
Рис. 4-8. Бизнес-микрослужба с несколькими физическими службами
Службы в примере имеют общую модель данных, так как служба на основе веб-интерфейса API обращается к тем же данным, что и служба поиска. Поэтому в физической реализации микрослужбы вы разделяете эту функциональность, чтобы каждую из внутренних служб можно было масштабировать по мере необходимости. Например, для службы на основе веб-интерфейса API обычно может требоваться больше экземпляров, чем для службы поиска, или наоборот.
Короче говоря, логическая архитектура микрослужб не всегда должна совпадать с архитектурой физического развертывания. Каждый раз, когда в этом руководстве упоминается микрослужба, имеется в виду бизнес-микрослужба или логическая микрослужба, которой могут соответствовать одна или несколько (физических) служб. В большинстве случаев это будет одна служба, но их может быть и больше.
