Главная » Хабрахабр » Кратко о типах архитектур программного обеспечения, и какую из них выбрали мы для IaaS-провайдера

Кратко о типах архитектур программного обеспечения, и какую из них выбрали мы для IaaS-провайдера

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


/ libreshot / PD

Типы архитектур ПО

Многоуровневая архитектура

Это одна из самых распространенных архитектур. На её основе построено множество крупных фреймворков — Java EE, Drupal, Express. Пожалуй, самый известный пример этой архитектуры — это сетевая модель OSI.

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

Чаще всего используют трехзвенные системы: с уровнем представления (клиентом), уровнем логики и уровнем данных. Архитектура не подразумевает какое-то обязательное количество уровней — их может быть три, четыре, пять и больше.

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

Плюсы:

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

Например, LASG для Visual Studio предлагает несколько методов генерации кода, которые автоматизируют рутинные задачи и помогают выстраивать уровни приложения. В целом многоуровневые приложения настолько распространены, что для их разработки создаются специальные генераторы шаблонов.

Недостатки:

Однако такой подход в конечном счете может привести к плохой организации кода и запутать разработчиков. В программировании есть присказка, что любую проблему можно решить добавлением еще одного уровня абстракции.

Очень много информации начинает бесполезно проходить от слоя к слою, не используя бизнес-логику. Отсюда вытекает еще одна проблема — низкая скорость работы. Иногда эту проблему называют sinkhole anti-pattern — шаблон проектирования, когда количество бесполезных операций начинает преобладать над полезными.

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

Хорошо подходит:

  • Для создания новых приложений, которые нужно развернуть по-быстрому. Это своеобразный «шаблон общего назначения».

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

    Среди разработчиков есть мнение, что не нужно с первых же дней проекта готовить его к колоссальным нагрузкам (писать future proof программное обеспечение). Реальные требования к приложению или сервису могут отличаться от ожидаемых, а бизнес-цели могут измениться. Потому код, написанный с прицелом на далекое будущее, рискует превратиться в технический долг.

  • Как пишет O’Reilly, многоуровневая архитектура — естественный выбор для многих корпоративных приложений. Так как в компаниях (особенно крупных) часто происходит разделение компетенций: есть команда, ответственная за фронтенд, есть люди, которые отвечают за бэкенд, и так далее. Отсюда вытекает естественное деление приложений на уровни: одни разработчики трудятся над клиентом, другие — над логикой.

    Он гласит: «Разрабатывая какую-либо систему, организации вынуждены придерживаться схемы, которая бы повторяла структуру коммуникаций внутри компании». Подобная взаимосвязь, между структурой организации и подходами к разработке приложений также продиктована законом Конвея, сформулированном еще в 1967 году.

Событийно-ориентированная архитектура

В этом случае разработчик прописывает для программы поведение (реакции) при возникновении каких-либо событий. Событием в системе считается существенное изменение её состояния.

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

Типов событий обычно тоже два: инициализирующее событие и событие, на которое реагируют потребители. Система, управляемая событиями, обычно содержит два компонента: источники событий (агенты) и их потребители (стоки).

Если классу нужно оповещение о каком-либо событии, разработчик реализует так называемого слушателя — ActionListener (он «ловит» соответствующий эвент), и дописывает его к объекту, который это событие может сгенерировать. Примером реализации такой архитектуры может служить библиотека Java Swing.

На Wiki приводится следующий код реализации этого механизма:

public class FooPanel extends JPanel implements ActionListener @Override public void actionPerformed(ActionEvent ae) { System.out.println("Button has been clicked!"); }
}


Достоинства архитектуры:

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

Недостатки:

Одно событие может запускать сразу несколько цепочек действий. Асинхронная натура таких приложений усложняет отладку. Для решения проблемы приходится прорабатывать сложные условия обработки ошибок. Если таких цепочек будет много, то понять, что именно вызвало сбой, может быть затруднительно. Отсюда же вытекает проблема с журналированием — логи трудно структурировать.

Подходит для:

  • Создания асинхронных систем. Это очевидно, поскольку сама архитектура состоит из большого количества асинхронных модулей.
  • Можно применить для создания UI. Веб-страница выступает в роли контейнера, в котором каждый её компонент изолирован и реагирует на определённые действия пользователя.
  • Для организации обмена сообщениями между различными информационными системами.

Микроядерная архитектура

Этот тип архитектуры состоит из двух компонентов: ядра системы и плагинов. Плагины отвечают за бизнес-логику, а ядро руководит их загрузкой и выгрузкой.

Как пример микроядерной архитектуры в книге O’Reilly приводится Eclipse IDE. Это простой редактор, который открывает файлы, дает их править и запускает фоновые процессы. Но с добавлением плагинов (например, компилятора Java) его функциональность расширяется.

В её микроядре находился планировщик задач, системы управления памятью и драйверы, а файловая система и компоненты, отвечающие за телефонную связь, выступали в роли плагинов. Микроядерную архитектуру в свое время использовала операционная система Symbian для мобильных устройств (разработку прекратили в 2012 году).

Достоинства архитектуры:

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

Недостатки:

Однако бывает проблематично найти баланс между количеством плагинов и числом задач микроядра (обычно оно содержит лишь часто используемой код). Производительность приложения снижается, если подключать слишком много модулей.

А поменять подход позднее практически невозможно. Также сложно определить заранее (до начала разработки приложения) оптимальную степень дробления кода микроядра.

Хорошо подходит для:

  • Создания расширяемых приложений, которыми пользуется большое количество людей. Например, ОС для iPhone имеет «микроядерные» корни — её разработчики черпали вдохновение в Mach (это один из самых первых примеров микроядра).
  • Создания приложений с четким разделением базовых методов и высокоуровневых правил.
  • Разработки систем с динамически меняющимся набором правил, которые приходится часто обновлять.

Микросервисы

Похожи на архитектуру, управляемую событиями, и микроядро. Но используются тогда, когда отдельные задачи приложения можно легко разделить на небольшие функции — независимые сервисы. Эти сервисы могут быть написаны на разных языках программирования, поскольку общаются друг с другом при помощи REST API (например, с использованием JSON или Thrift).

По его словам, это позволит избежать излишнего «раздувания» архитектуры. В каких пропорциях делить код, решает разработчик, но Сэм Ньюмен (Sam Newman), автор книги «Создание микросервисов», рекомендует выделять на микросервис столько строк кода, сколько команда сможет воспроизвести за две недели.

Эти контейнеры доступны по сети другим микросервисами и приложениям, а управляет ими всеми система оркестровки: примерами могут быть Kubernetes, Docker Swarm и др. Чаще всего микросервисы запускаются в так называемых контейнерах.

Достоинства:

Чтобы внедрить новую функцию достаточно написать новый сервис. Микросервисная архитектура упрощает масштабирование приложений. Каждый микросервис — это отдельный проект, потому работу над ними легко распределить между командами разработчиков. Если функция стала не нужна, микросервис можно отключить.

Abbott) «Искусство масштабирования» (The Art of Scalability). Подробнее о механизмах масштабирования микросервисных систем можно почитать в книге Мартина Эббота (Martin L.

Недостатки:

В отличие от монолитных систем (когда все функции находятся в одном ядре), бывает сложно определить, почему «упал» запрос. Сложно искать ошибки. За деталями приходится идти в логи «виновного» процесса (если их несколько, то проблема усугубляется).

По нашим оценкам, рост сетевых издержек может достигать 25%. При этом появляются дополнительные накладные расходы на передачу сообщений между микросервисами.

У микросервисов есть собственные хранилища данных, к которым обращаются другие микросервисы. Еще один недостаток — необходимость мириться с концепцией eventual consistency (согласованность в конечном счёте). Потому возникают ситуации, когда у некоторых микросервисов (пусть и на крайне короткий промежуток времени) оказываются устаревшие данные. Информация об изменении этих данных распространяется по системе не мгновенно.

Где использовать:

  • В крупных проектах с высокой нагрузкой. Например, микросервисы используются стриминговыми платформами. Системы доставки контента и иные вспомогательные сервисы можно масштабировать независимо друг от друга, подстраиваясь под изменения нагрузки.
  • В системах, использующих «разномастные» ресурсы. Если одной части приложения нужно больше процессорного времени, а второй — памяти, то имеет смысл разделить их на микросервисы. После чего их можно захостить на разных машинах — с мощным CPU или большим объемом памяти соответственно.
  • Когда нужна безопасность. Так как микросервисы изолированы и общаются по API, можно гарантировать, что передаваться будет только та информация, которая нужна тому или иному сервису. Это важно при работе с паролями или данными платёжных карт.

Почему мы в 1cloud переходим на микросервисы

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

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

Чтобы было проще масштабировать существующие функции и внедрять новые фичи, мы в 1cloud переводим всю нашу инфраструктуру на микросервисы.

Таким образом, в новой архитектуре каждой фиче будет соответствовать отдельная БД. Мы хотим выделить их в отдельные модули и вместо одной сложной базы данных получить N простых. Это гораздо удобнее и эффективнее в поддержке и разработке.

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

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

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

Что уже сделано

Пока мы реализовали только первый пилот: «Услугу Мониторинг». Остальные сервисы переведем на новые рельсы в конце 2018 — начале 2019 года.

Сейчас мы используем Windows-инфраструктуру, и для перехода в контейнеры нужно переписать весь накопившийся код на . При этом новая архитектура закладывает технологическую основу для следующего этапа — миграции на контейнеры. NetCore и перевести его под управление Linux.

Начать новый переход планируем в начале 2019 года и закончить его в конце следующего года.

Простыми словами о том, что стоит запомнить про архитектуры

  • Многоуровневая архитектура — приложение делится на уровни, каждый из которых выполняет строго определенный набор функций. Каждый уровень можно модифицировать по отдельности. Из недостатков — низкая скорость работы кода и сложность поиска багов.

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

  • Событийно-ориентированная архитектура — здесь разработчик прописывает реакции системы на какие-либо события. Например, если поступили данные, записать их в файл. Приложения на базе событийно-ориентированной архитектуры просто масштабировать, так как все обработчики событий ничего не знают о реализации друг друга. Однако отладка таких систем затруднена — одно действие может вызывать сразу несколько цепочек действий (сложно понять, какая из них вызвала сбой).

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

  • Микроядерная архитектура — состоит из двух ключевых компонентов: плагинов и ядра. Плагины отвечают за бизнес-логику, а ядро — за их загрузку и выгрузку. Такое разделение обязанностей упрощает поддержку системы. Однако может сказаться на производительности — она напрямую зависит от количества подключенных и активных модулей.

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

  • Микросервисная архитектура — приложения делятся на функции — микросервисы. Каждый микросервис — это независимый компонент со своей бизнес-логикой. Эти компоненты общаются друг с другом при помощи API. Такие приложения просто разрабатывать (есть возможность распределить работу между командами разработчиков), но сложно отлаживать.

    Используют в крупных проектах с высокой нагрузкой, которым требуется повышенная безопасность.

О чем еще мы пишем в блоге 1cloud:


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Два успеха частной космонавтики

На прошлой неделе произошло два достаточно важных события для частной космонавтики. Прежде всего, два пилота Virgin Galactic могут сверлить дырки в своих костюмах под значки астронавтов — поднявшийся 13 декабря до 82,7 км SpaceShipTwo оказался выше линии 50 миль, которая ...

Дайджест свежих материалов из мира фронтенда за последнюю неделю №343 (10 — 16 декабря 2018)

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.     Медиа    |    Веб-разработка    |    CSS    |    Javascript    |    Браузеры Медиа • Подкаст «Frontend Weekend» #83 – Илья Климов о том, как и зачем был создан образовательный проект JavaScript.Ninja• Девшахта #61: TypeScript и его ...