Файл: Критерии выбора средств разработки WEB-приложений (CMS 5).pdf

Это приложения, которые используют принципы инверсии зависимости и проблемно-ориентированного проектирования и обладающие схожей архитектурой. Долгое время она меняла своё название, по началу называвшись шестигранной архитектурой, далее архитектурой портов и адаптеров, сейчас же она называется чистой или многослойной архитектурой, но более подходящее ей название всё же является «чистая архитектура». Например, эталонное (абстрактное) приложение под названием eShopOnWeb использует свой подход на основе чистой архитектуры для того, чтобы организовать код в соответствующий проект. В приделах этой чистой архитектуры ядром приложения значится его модель и бизнес-логика. В данном случае бизнес-логика не имеет зависимость от доступа к данным либо другим инфраструктурам. Проще говоря стандартная зависимость имеет инвестирование, соответственно, чему инфраструктура и детали реализации имеют зависимость от ядра этого приложения. Оно достигается с помощью определения абстракций или интерфейсов в ядре, они же реализуются формами, которые указаны в слое инфраструктуры. Она графически обозначается путём серий окружностей, имеющие общий центр, лично мне он внешне напомнил срез луковицы. Стоит обратить внимание, что на этой схеме зависимости направленны из внутренней окружности. Именно поэтому ядро приложения им и является, что находится в центре схемы. Также ядро приложения не имеет зависимостей от других слоёв этого приложения. А интерфейсы и так сказать сущности (тип объекта) приложения находятся в центре. После них (в пределах ядра) находятся доменные службы, которые в основном реализуют интерфейсы, они же определены во внутренней окружности. А вот за пределами ядра находятся слои пользовательского интерфейса и инфраструктуры, они же зависят напрямую от ядра приложения, и не могут иметь зависимость друг от друга. В понятиях чистой архитектуры слой пользовательского интерфейса работает напрямую с внутренними интерфейсами, они же находятся в ядре приложения во время компиляции, и по-хорошему слой не должен иметь доступ к типам реализации, находящихся в слои инфраструктуры, но всё же при выполнении, когда эти виды реализации просто необходимы для исполнения приложения, потому они должны работать и иметь привязку к интерфейсам ядра через внедрение зависимостей. Так, как ядро никак не зависит от инфраструктуры, для такого слоя очень просто написать автоматические модульные тесты. Поскольку слои пользовательского интерфейса не имеет прямых зависимостей видов, которые определены в проекте инфраструктуры, будет соответственно просто изменять реализации в случаях изменения требований к приложению, либо просто его тестированию. Кроссплатформенный фреймворк ASP.NET Core имеет возможность встроенной поддержки внедрения зависимостей, поэтому подобная архитектура представляет собой более оптимальный подход к структурированию технически сложных монолитных приложений. Инфраструктуры пользовательского интерфейса выполняются как единое целое приложения, для таких элементов, как: монолитных приложений, проекты ядра приложений, а также пользовательского интерфейса и инфраструктуры.

7.6 Чистая архитектура (упорядочивание кода)

В решении, которого через значение чистой архитектуры для каждого проекта определены свои обязанности. По факту каждому из которых проекту будут принадлежать определённые типы, в самих же проектах представлены соответствующие типам папки. Само ядро приложения содержит, так называемую бизнес-модель, в ней же находятся службы, интерфейсы, сущности. Подобные интерфейсы содержат в себе абстракции для операций, которые должны выполнятся при помощи архитектуры, задействовав операции доступа к файловой системе или данным и другого. Иногда бывает службы или интерфейсы, находящиеся в этом слое, работают с типами, которые не являются типами сущностей, они не зависят от инфраструктуры либо пользовательского интерфейса, но могут определятся простыми объектами передачи данных.

7.7 Слои пользовательского интерфейса (типы)

Существует класс Startup, который в ответе за настройку приложений, а также типы реализации в интерфейс, соответственно обеспечивая плавную работу внедрения зависимостей при выполнении процесса. Для того, чтобы сделать привязку внедрения зависимостей ConfigureServices в файл Startup.cs пользовательского интерфейса может потребоваться ссылка на проект инфраструктуры.

И вот основные их типы:

Контроллер
Представление
Модель представлений
Фильтр
Запуск

7.8 Ядро приложения (типы)

И его проект инфраструктуры, в большинстве случаев, включает функцию реализации доступа к данным. Типовое web-приложение, в котором ASP.NET Core включает элемент Entity Framework (EF) DbContext, другие объекты Migration EF Core и классы реализации доступа к данным. В основном используется такой подход абстрагированию кода реализации данных, как конструктивный шаблон репозитории. А также проект инфраструктуры должен обладать реализации служб, они же должны взаимодействовать с инфраструктурными задачами. Данные службы реализуют определённые интерфейсы в ядре приложения, тем самым инфраструктура должна содержать в себе ссылку на проект ядра приложения.

И вот основные их виды:

Служба
Интерфейс
Сущность
Объект передачи данных

7.9 Монолитные приложения и контейнеры

С помощью которых возможно создать одно монолитное web-приложение, либо службу и сделать их как контейнер. Монолитность может не соблюдаться в приделах приложения, но будет реализована организация на основе определённого числа библиотек, слоёв или компонентов. Внешне оно будет представляться, как единый контейнер: единое web-приложение, единый процесс, либо единую службу. Развёртывается один контейнер для управления этой моделью, который представляет собой приложение. Для того, чтобы управлять этой моделью, необходимо просто добавить дополнительные копии, обладающие подсистемой балансировки нагрузки. Управление одним развёртыванием в одном контейнере или виртуальной машине намного легче. Обратная отрицательная сторона этого подхода является очевидным, когда это приложение разрастается и его нужно масштабировать, но если это делать целиком, то всё будет удачно. Проблема заключается в том, что в большинстве случаев нужно масштабировать лишь определённые его части, когда другие компоненты исправно работают. Как пример можно взять приложение для электронной торговли, для которого, наверное, понадобится масштабирование компонента со сведениями о его товарах. Также ещё реже оставляют положительные отзывы о компании (про отрицательные всё понятно) и смотрят историю покупок. Клиенты гораздо чаще просто смотрят товары, иногда складывая в корзину, но не покупают их. Скорее всего у вас работают всего несколько сотрудников в одном регионе (городе, селе, посёлке, районе), управляющие содержимым и маркетинговыми компаниями. Когда вы масштабируете монолитное решение, исходных код полностью развёртывается многократно. Мало того, что нужно масштабировать все его компоненты, так ещё при изменении в одном компоненте необходимо проводить полный тест работы всего приложения на выявления ошибок, и полного развёртывания всех экземпляров. Монолитный подход приобрёл широкое распространение при разработке архитектуры и используется многими компаниями. В большинстве случаев позволяя достичь желаемых результатов, но бывает компания сталкивается с определёнными ограничениями. Ранее в большинстве случаев приложения строились по этой модели, ибо в прошлом с помощью уже существующих инструментов инфраструктуры было очень сложно создавать архитектуры, направленные на службы SOA, проблем тогда не возникало до поры, когда приложение начинало разрастаться. Если вы столкнулись с этой проблемой ограничений монолитного подхода, то её решением будет разбиение приложения для эффективного использования микрослужб и контейнеров. В программе Microsoft Azure монолитные приложения возможно развёртывать с помощью нескольких выделенных виртуальных машин для каждого экземпляра. При помощи масштабируемых наборов виртуальных машин Azure имеется возможность с лёгкостью масштабировать виртуальные машины, также могут выполнять монолитный приложения службами приложений Azure и также легко масштабировать экземпляры, чтобы не пришлось управлять вириальными машинами. Службы приложений Azure могут ещё выполнять отдельные экземпляры контейнеров под названием Docker, тем самым упрощая развёртывание. При помощи Docker можно одну виртуальную машину на его узле и соответственно выполнять на ней несколько экземпляров. А для того, чтобы управлять масштабированием, можно использовать систему балансировки под названием Azure. Для того, чтобы управлять развёртыванием на тех или иных узлах, управление идёт с помощью традиционных методов развёртывания. Узлы Docker с помощью которых можно управлять через вводимых команд вручную вида docker run либо автоматически. Как пример ввод автоматических команд при помощи конвейеров непрерывной поставки со значением CD.

7.10 Развёртывание монолитных приложений в контейнере

Контейнеры, использующиеся для управления развертываниями монолитных приложений, обладают определёнными преимуществами, например, масштабировать экземпляры контейнера намного быстрее и легче, чем развертывать дополнительные виртуальные машины. При использовании масштабируемых наборов виртуальных машин применяется основанный на экземплярах подход, а при развертывании в виде экземпляров приложения управление конфигурацией приложения осуществляется в составе виртуальной машины. Развертывание обновлений в виде образов Docker выполняется в разы быстрее и эффективнее в плане использования сети. Образы Docker как правило запускаются за считанные секунды, что позволяет ускорить выпуск, а вот остановить образ Docker можно с помощью команды docker stop, в большинстве случаев это происходит моментально. Так, как контейнеры являются неизменяемыми элементами, вам не нужно будет беспокоиться о возможности повреждения виртуальной машины. Бывает, когда скрипты обновления не учитывают те или иные оставшиеся на диске файлы или конфигурации.

Контейнеры Docker имеют возможность использования для монолитного развертывания простых web-приложений, что оптимизирует процессы непрерывной интеграции и непрерывного развертывания, а ещё помогает добиться успешного развертывания в рабочей среде. Поэтому больше не придется «плясать с бубном» и думать, почему решение, выполняющееся на компьютере, не может выполнится в рабочей среде. Архитектура на базе микрослужб обладает большим количеством преимуществ, но с другой стороны «медали» придётся столкнуться с повышением сложности. Бывает, когда затраты перевешивают преимущества, и лучше выбрать монолитное развертывание приложения в одном контейнере или нескольких.

Монолитное приложение бывает непросто разделить на отдельные микрослужбы, потому что микрослужбы работают независимо друг от друга для повышения отказоустойчивости приложения. Например, если приложение не представляется возможным разложить на независимые функциональные составляющие, то попытка его разделения только увеличит сложность работы. Приложение пока что не может исправно работать без независимого масштабирования компонентов. Многие приложения, когда им необходимо взять в использование более одного экземпляра, они достаточно легко клонируют весь экземпляр. Ещё одна работа по разделению приложений на отдельные службы предоставляет малое число преимуществ, а вот масштабирование полноценных экземпляров приложения является простым и экономичным решением. На ранних стадиях развертывания приложения может отсутствовать ясное понятие, где находятся границы меж функциональными областями. Во время разработки проекта, который обладает самым небольшим необходимым набором возможностей, его естественное разделение на две и более части может быть неправильным, часть из этих условий может быть временным. Можно сначала создать монолитное приложение, а потом отделить некоторые компоненты для разработки и развертывания в качестве микрослужб. Другие условия могут быть необходимыми особенностями приложения для его работы, это означает, что приложение в общем то невозможно разделить на несколько микрослужб, разделение приложения на множество отдельных процессов также приводит к соответствующим проблемам. Если разделить компонент на несколько процессов также будет повышаться сложность, ещё усложняться протоколы обмена данными. Вместо того, чтобы просто сделать вызовы методов, необходимо использовать асинхронное взаимодействие между службами. Когда вы переходите на архитектуру микрослужб необходимо добавить множество стандартных блоков, реализованных в версии приложения eShopOnContainers на основе микрослужб, а точнее: отказоустойчивость и повторную отправку сообщений, обработку шины событий, итоговую согласованность и так далее. Намного проще привести пример приложения eShopOnWeb, которое поддерживает использование одного монолитного контейнера, тогда включается одно web-приложение с традиционными представлениями MVC, web-API и Razor Pages. Оно (приложение) может запускаться из корня решения с помощью команд docker-compose build и docker-compose up. Эта команда делает насройку контейнера для web-экземпляра при помощи Dockerfile из корневого каталога web-проекта, а ещё выполняет контейнер в указанном порте. Можно скачать исходный код этого приложения, например, с популярного ресурса под названием GitHub и запустить его в локальной системе. Подобное монолитное приложение имеет преимущество от развертывания в контейнерной среде. Начнём с того, что контейнерное развертывание значит: каждый экземпляр приложения выполняется в одной и той же среде, оно относится и к среде разработки, в которой, кстати, проводятся начальные этапы разработки и дальнейшего тестирования. Разработчик имеет возможность запускать приложение в контейнерной среде, которая аналогична рабочей. Помимо того, контейнерные приложения обеспечивают более экономное горизонтальное масштабирование. Контейнерная среда помогает эффективнее организовывать общее использование ресурсов, нежели традиционные среды виртуальных машин. В-третьих, когда вы помещаете приложение в контейнеры, вы тем самым разделяете бизнес-логику и сервер хранилища. В процессе масштабирования приложения все контейнеры будут использовать один физический носитель данных. В большинстве случаев в качестве хранилища, используется сервер высокой доступности с базой данных под названием SQL Server.

7.11 Docker (поддержка)

Так называемый проект eShopOnWeb работает в .NET Core, благодаря чему можно его запустить как в контейнерах на базе Linux, так соответственно и на Windows. И да, для развёртывания Docker нужно использовать тот же вид узла для SQL Server. Опять же вернёмся к сравнению Linux и Windows, а точнее говоря для контейнеров на базе Linux требуется меньше ресурсов, и они лучше по другим пораметрам. Можно использовать Visual Studio 2017, для добавления поддержки Docker в существующие приложение, нажав проект в обозревателе решений правой кнопкой мыши и выбрав Добавить → Поддержка Docker, этим самым добавив необходимые файлы и внести изменения в проект для их использования. На данном примере eShopOnWeb эти файлы присутствуют: например, файл docker-compose.yml ссылается на Dockerfile в проекте web. При помощи Dockerfile можно указать, какой базовый контейнер будет использоваться и как приложение будет настроено на нем. А вот файл docker-compose.yml содержит такие сведения: какие образы нужно создать и какие контейнеры запустить. Этот файл позволяет использовать команду docker-compose для того, чтобы запустить несколько приложений одновременно. В таком случае он запускает сам web-проект. Также имеется возможность с его помощью настроить зависимости, как пример отдельный контейнер базы данных.

7.12 Docker (неполадки в работе)

После запуска контейнерное приложение продолжает работать, пока его самостоятельно не остановят. Команда docker ps необходима, чтобы посмотреть, какие контейнеры выполняются. Можно остановить выполняющийся контейнер командой docker stop и ID самого контейнера. Запущенные контейнеры Docker могут иметь привязку к портам, которые в противном случае вы могли бы использовать в среде разработки. Если попытаться сделать запуск или выполнить отладку приложения через порт, связанный с контейнером Docker, вылетит ошибка с сообщением о том, что сервер не может выполнить привязку к этому порту, решение этой проблемы очень простое, необходимо всего лишь остановить контейнер. Если вам нужно добавить поддержку Docker в приложение при помощи Visual Studio, удостоверьтесь, что Docker Desktop работает. Если вдруг при запуске мастера средство Docker Desktop не выполняется, мастер будет работать неисправно, к тому же, мастер проверяет выбранные контейнеры, чтобы правильно реализовать поддержку Docker. Для того чтобы добавить поддержку контейнеров OS Windows, при запуске мастера должно быть запущено средство Docker Desktop с настроенными контейнерами Windows. Дабы добавить поддержку контейнеров Linux, при запуске мастера должно выполняться средство Docker с настроенными контейнерами OS Linux.