С чего начинается Azure? Часть 1.

07.08.2018

Друзья, как уже ранее писал, мы запустили цикл статей, посвящённых Индустрии 4.0. и в частности облачным технологиям Microsoft Azure.

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

На сегодняшний день, облачные технологии кардинально меняют способы и методы разработки приложений. Вместо единой структуры, приложения разбиваются на мелкие рассредоточенные службы и сервисы, которые в свою очередь взаимодействуют между собой с помощью API или асинхронного обмена данными. Но возникают вопросы: «Как это всё собрать во едино, да что бы ещё и работало?» «Как грамотно просчитать расходы на разработку?»; «А сколько будет стоить содержание?».
Конечно же, на первых парах вы не сможете взять и рассчитать расходы, вы ведь не знаете, что в эти расходы будет включено! В этой связи, первый шаг в освоении простор облачной технологии, предлагаю начать именно с азов облачной архитектуры.

Стили архитектуры.

На сегодняшний день, корпорация Microsoft рекомендует к использованию (но не ограничивает ими) 6 стилей построения архитектуры приложений. Давайте поговорим об одном из них.

1. n-уровневая архитектура

Классическая схема построения архитектуры приложения. За частую разворачивается в три «Уровня»:

· Уровень первый. Клиентский.

На данном уровне отрабатываются все сценарии взаимодействия пользователя приложения с его интерфейсом.

· Уровень второй. Логический

Второй уровень отвечает за логику выполнения команд и запросов.

После того как вы нажали кнопку «получить информацию», второй уровень начинает формировать запросы на уровень три и отправлять их.

· Уровень три. Хранилище данных

После того как логический уровень направил запрос, включается третий уровень архитектуры: «Уровень данных». Этот уровень используется как хранилище данных, из которого происходит выборка информации, согласно запросу, из уровня два.

После завершения операций на этапе три, информация поступает в «логический раздел», где все данные собираются, обрабатываются и в готовом виде направляются на первый уровень как результат выполненного запроса.

Объясняя на пальцах это выглядит следующим образом:
Вы открыли мобильное приложение банка и таким образом начали взаимодействовать с первым уровнем архитектуры, как правило это графический интерфейс. Когда вы запросили остаток денежных средств на карте, в «логическом уровне» сформировался запрос на поиск информации с определенными критериями и отправлен в уровень три. На третьем уровне, запрос попадает в базу данных банка и подбирает релевантные данные по заданным ранее критериям (Ф.И.О. клиента, номер счёта и т.д.), после чего, с полученной информацией, запрос возвращается в логический уровень и формирует отчёт о проделанной работе, после отправляя его на клиентский уровень. В финале, вы получаете цифры с конкретной суммой остатка на балансе.

Большинство классических приложений работают именно в такой архитектуре, ну а остальные модели мы рассмотрим в следующих статьях.

Друзья, в данной статье, мы рассмотрели классический пример архитектуры приложений. Подписывайтесь, чтобы не пропустить свежие статьи и развиваться в ногу со временем.