Есть многие типы программных архитектур со своими плюсами и минусами.
Далее мы поговорим об особенностях наиболее популярных из них и расскажем о нашем переходе на микросервисы.
/ либрешот /ПД
Типы архитектур программного обеспечения
Многоуровневая архитектура
Это одна из самых распространенных архитектур.На его основе построено множество крупных фреймворков — Java EE, Drupal, Express. Возможно, самым известным примером этой архитектуры является сетевая модель.
ИОС .
Система разделена на уровни, каждый из которых взаимодействует только с двумя соседними.
Поэтому запросы к базе данных, которая обычно находится в самом конце цепочки взаимодействия, проходят последовательно через каждый «уровень».
Архитектура не подразумевает определенное обязательное количество уровней – их может быть три, четыре, пять и более.
Чаще всего используются трехуровневые системы: с уровнем представления (клиент), логическим уровнем и уровнем данных.
О многоуровневой архитектуре написано бесчисленное количество книг и статей.
И мнения о его преимуществах и недостатках были разные.
Плюсы: Каждый уровень этой архитектуры выполняет строго ограниченный набор функций (которые не повторяются от слоя к слою) и не знает, как устроены остальные уровни.
Следовательно, «контент» слоев можно менять без риска глобальных конфликтов между слоями.
В общем, многоуровневые приложения настолько распространены, что для их разработки создаются специальные генераторы шаблонов.
Например, LASG для Visual Studio предлагает несколько методов генерации кода, которые автоматизируют рутинные задачи и помогают создавать уровни приложения.
Недостатки: В программировании есть поговорка, что любую проблему можно решить, добавив еще один уровень абстракции.
Однако такой подход может в конечном итоге привести к плохой организации кода и путанице для разработчиков.
Это приводит к еще одной проблеме – низкой скорости.
Множество информации начинает бесполезно передаваться из слоя в слой без использования бизнес-логики.
Иногда эта проблема называется Антипаттерн воронка — паттерн проектирования, когда количество бесполезных операций начинает преобладать над полезными.
Также поиск ошибок в многоуровневых системах может быть сложно .
Прежде чем попасть в базу данных, информация проходит все уровни (поскольку база данных является конечным компонентом).
Если по каким-то причинам эта информация повреждена (или утеряна в пути), то каждый уровень необходимо анализировать отдельно, чтобы найти ошибку.
Хорошо подходит:
- Для создания новых приложений, которые необходимо быстро развернуть.
Это своего рода «шаблон общего назначения».
Когда мы в 1облако начали работать над внутренними системами нашего провайдера виртуальной инфраструктуры, мы использовали именно такую архитектуру.
Среди разработчиков у меня есть мнение что нет необходимости готовить его к колоссальным нагрузкам с самых первых дней проекта (написание перспективного ПО).На старте перед нами не стояла задача создать IaaS-сервис, способный обрабатывать трафик десятков и сотен тысяч пользователей.
Мы решили быстро выпустить продукт на рынок и начать развивать клиентскую базу, а также решать проблемы масштабирования по мере их возникновения (а сейчас мы переводим все системы на микросервисную архитектуру, о чем речь пойдет позже).
Фактические требования к приложению или услуге могут отличаться от ожидаемых, и цели бизнеса могут измениться .
Поэтому код, написанный с прицелом на отдаленное будущее, рискует превратиться в технический долг.
- Как пишет О'Рейли, многоуровневая архитектура является естественным выбором для многих корпоративных приложений.
Так как в компаниях (особенно крупных) часто существует разделение компетенций: есть команда, отвечающая за фронтенд, есть люди, отвечающие за бэкенд и так далее.
Это приводит к естественному разделению приложений на уровни: одни разработчики работают над клиентом, другие — над логикой.
Аналогичная связь между организационной структурой и подходами к разработке приложений также диктуется законом Конвея , сформулированный еще в 1967 году.
В нем говорится: «При разработке любой системы организации вынуждены придерживаться схемы, которая бы воспроизводила структуру коммуникаций внутри компании».
Событийно-ориентированная архитектура
В этом случае разработчик прописывает поведение (реакции) программы при возникновении каких-либо событий.Событием в системе считается существенное изменение ее состояния.
Можно провести аналогию с покупкой автомобиля в автосалоне.
Когда автомобиль находит нового владельца, его статус меняется с «Продается» на «Продан».
С этого мероприятия начинается процесс предпродажной подготовки – установка дополнительного оборудования, проверка технического состояния, мойка и т.д. Система, управляемая событиями, обычно содержит два компонента: источники событий (агенты) и потребители событий (приемники).
Обычно также выделяют два типа событий: инициирующее событие и событие, на которое реагируют потребители.
Примером реализации такой архитектуры является библиотека Java Swing. Если классу необходимо уведомление о событии, разработчик реализует так называемый слушатель — ActionListener (он «перехватывает» соответствующее событие) и добавляет его к объекту, который может сгенерировать это событие.
Wiki предоставляет следующий код для реализации этого механизма:
Преимущества архитектуры: Поскольку приложения состоят из большого количества асинхронных модулей (которые не знают о реализациях друг друга), их легко масштабировать.public class FooPanel extends JPanel implements ActionListener { public FooPanel() { super(); JButton btn = new JButton("Click Me!"); btn.addActionListener(this); this.add(btn); } @Override public void actionPerformed(ActionEvent ae) { System.out.println("Button has been clicked!"); } }
Такие системы собираются в виде конструктора — нет необходимости указывать зависимости, достаточно реализовать новый модуль.
Кроме того, асинхронная модель обеспечивает высокую производительность приложений.
Недостатки: Асинхронная природа таких приложений затрудняет отладку.
Одно событие может запустить сразу несколько цепочек действий.
Если таких цепочек много, то поймите, что именно стало причиной сбоя, может быть сложно .
Решить проблему придется работать в сложных условиях обработки ошибок.
Это также приводит к проблеме с логированием - логи трудный состав.
Подходит для:
- Создание асинхронных систем.
Это очевидно, поскольку сама архитектура состоит из большого количества асинхронных модулей.
- Может быть применено для создания пользовательского интерфейса.
Веб-страница выступает в роли контейнера, в котором каждый ее компонент изолирован и реагирует на определенные действия пользователя.
- Организовать обмен сообщениями между различными информационными системами.
Микроядерная архитектура
Этот тип архитектуры состоит из двух компонентов: ядра системы и плагинов.Плагины отвечают за бизнес-логику, а ядро управляет их загрузкой и выгрузкой.
Как пример микроядерной архитектуры в книге О'Рейли.
дано Затмение IDE. Это простой редактор, который открывает файлы, позволяет редактировать их и запускает фоновые процессы.
Но с добавлением плагинов (например, компилятора Java) его функциональность расширяется.
Микроядерная архитектура в свое время использовал Операционная система Symbian для мобильных устройств (разработка остановлена в 2012 году).
Его микроядро содержало планировщик задач, системы управления памятью и драйверы, а в качестве плагинов выступали файловая система и компоненты, отвечающие за телефонную связь.
Преимущества архитектуры: Легко порт приложение из одной среды в другую, поскольку модифицировать нужно только микроядро.
Отделение политик высокого уровня от механизмов низкого уровня упрощает обслуживание и расширяемость системы.
Недостатки: Производительность приложения снижается, если подключить слишком много модулей.
Однако такое случается трудно найти баланс между количеством плагинов и количеством задач микроядра (обычно содержит только часто используемый код).
Также сложно заранее (до разработки приложения) определить оптимальную степень фрагментации кода микроядра.
А изменить подход потом практически невозможно.
Хорош для:
- Создание расширяемых приложений, которыми пользуется большое количество людей.
Например, ОС для iPhone имеет «микроядерные» корни — ее разработчики черпали вдохновение из Мах (это один из самых первых примеров микроядра).
- Создавайте приложения с четким разделением основных методов и правил высокого уровня.
- Разработка систем с динамически изменяющимся набором правил, которые приходится часто обновлять.
Микросервисы
Аналогично архитектуре, управляемой событиями, и микроядру.Но они используются, когда отдельные задачи приложения можно легко разделить на небольшие функции — независимые услуги .
Эти сервисы могут быть написаны на разных языках программирования, поскольку они взаимодействуют друг с другом с помощью REST API (например, с помощью JSON или Бережливость ).
Разработчик решает, в каких пропорциях делить код, а Сэм Ньюман, автор книги « Создание микросервисов », рекомендует выделить микросервису столько строк кода, сколько команда сможет воспроизвести за две недели.
По его словам, это позволит избежать ненужного «раздутия» архитектуры.
Чаще всего микросервисы запускаются в так называемых контейнерах.
Эти контейнеры доступны по сети другим микросервисам и приложениям, и все они управляются системой оркестрации: примеры включают Kubernetes, Docker Swarm и т. д. Преимущества: Микросервисная архитектура упрощает масштабирование приложений.
Для реализации новой функции достаточно написать новый сервис.
Если функция больше не нужна, микросервис можно отключить.
Каждый микросервис — это отдельный проект, поэтому работу над ним можно легко распределить между командами разработчиков.
Подробнее о механизмах масштабирования микросервисных систем можно прочитать в книге Мартина Л.
Эбботта « Искусство масштабирования «(Искусство масштабируемости).
Недостатки: Трудно найти ошибки.
В отличие от монолитных систем (где все функции находятся в одном ядре), определить причину сбоя запроса может быть сложно.
За подробностями придется обратиться к логам «виновного» процесса (если их несколько, то проблема усугубляется).
Это приводит к дополнительным затратам на передачу сообщений между микросервисами.
По нашим оценкам, рост сетевых затрат может составить 25%.
Еще один недостаток - необходимость мириться с концепцией эвентуальной согласованности ( предельная согласованность ).
Микросервисы имеют собственные хранилища данных, к которым имеют доступ другие микросервисы.
Информация об изменении этих данных не распространяется по системе мгновенно.
Поэтому возникают ситуации, когда некоторые микросервисы (даже на крайне короткий период времени) имеют устаревшие данные.
Где использовать:
- В крупных проектах с высокой нагрузкой.
Например, микросервисы используются потоковыми платформами.
Системы доставки контента и другие вспомогательные сервисы можно масштабировать независимо друг от друга, адаптируясь к изменениям нагрузки.
- В системах, использующих «разнообразные» ресурсы.
Если одной части приложения требуется больше процессорного времени, а другой части — больше памяти, то имеет смысл разделить их на микросервисы.
После чего их можно разместить на разных машинах — с мощным процессором или большим объемом памяти соответственно.
- Когда нужна безопасность .
Поскольку микросервисы изолированы и взаимодействуют через API, вы можете гарантировать, что будет передана только та информация, которая необходима конкретному сервису.
Это важно при работе с паролями или данными платежных карт.
Почему мы переходим на микросервисы в 1cloud?
Как мы уже говорили, в основе предоставляемых нами услуг( частное облако , виртуальные серверы , облачное хранилище объектов и т. д.) представляет собой многоуровневую архитектуру.Он показал себя хорошо, но теперь его возможности масштабирования начали иссякать.
У нас появляется все больше и больше партнеров, которые предоставляют свои решения на основе нашей франчайзинговой платформы.
Появляются удаленные площадки и сервисы, которыми становится сложно управлять из одной точки (в частности, наше оборудование расположено в нескольких дата-центрах).
в России, Казахстане и Белоруссии ).
Чтобы было проще масштабировать существующие функции и внедрять новые возможности, мы 1облако Мы переводим всю нашу инфраструктуру на микросервисы.
Мы хотим разделить их на отдельные модули и вместо одной сложной базы данных получить N простых.
Таким образом, в новой архитектуре каждая функция будет иметь отдельную базу данных.
Это гораздо удобнее и эффективнее в поддержке и развитии.
Мы сможем разделить работу над сервисами между несколькими разработчиками (выделить специализации в компании) и эффективно масштабироваться по горизонтали — при необходимости мы просто будем подключать новые микросервисы.
Наши клиенты также получат ряд преимуществ.
Поскольку микросервисы не связаны друг с другом, в случае сбоя конкретного сервиса будет недоступен только он; все остальные продолжат работать в обычном режиме.
Более того, даже если произойдет глобальное падение нашего сервиса, панель управления продолжит работать.
Клиенты из Казахстана и Беларуси (и других стран, где мы откроем офисы) заметят значительное увеличение скорости и отзывчивости интерфейсов, поскольку панели управления будут размещаться локально.
Что уже сделано
Пока мы реализовали только первый пилот: «Службу мониторинга».Остальные перевозки переведем на новые рельсы в конце 2018 – начале 2019 года.
При этом новая архитектура закладывает технологическую основу для следующего этапа — миграции на контейнеры.
Сейчас мы используем инфраструктуру Windows, и для перехода на контейнеры нам нужно весь накопленный код переписать на .
NetCore и передать под управление Linux. Новый переход мы планируем начать в начале 2019 года и завершить в конце следующего года.
Простыми словами, что стоит помнить об архитектуре
- Многоуровневая архитектура — приложение разделено на уровни, каждый из которых выполняет строго определённый набор функций.
Каждый уровень можно изменить индивидуально.
Недостатками являются низкая скорость кода и сложность поиска ошибок.
Подходит для разработки приложений, которые необходимо быстро вывести на рынок.
Часто используется для создания корпоративных сервисов.
- Событийно-ориентированная архитектура — здесь разработчик прописывает реакцию системы на любые события.
Например, если пришли данные, запишите их в файл.
Приложения, основанные на архитектуре, управляемой событиями, легко масштабируются, поскольку все обработчики событий ничего не знают о реализациях друг друга.
Однако отладка таких систем затруднена — одно действие может вызвать сразу несколько цепочек действий (сложно понять, какое из них вызвало сбой).
Используется для создания асинхронных систем, организации графических интерфейсов и систем обмена сообщениями.
- Микроядерная архитектура — состоит из двух ключевых компонентов: плагинов и ядра.
Плагины отвечают за бизнес-логику, а ядро отвечает за их загрузку и выгрузку.
Такое разделение обязанностей упрощает поддержку системы.
Однако это может повлиять на производительность — она напрямую зависит от количества подключенных и активных модулей.
Подходит для разработки расширяемых приложений, которыми пользуется большое количество людей, и систем с набором правил, которые приходится часто обновлять (плагины гарантируют простоту обновления).
- Микросервисная архитектура — приложения делятся на функции — микросервисы.
Каждый микросервис — это независимый компонент со своей бизнес-логикой.
Эти компоненты взаимодействуют друг с другом с помощью API. Такие приложения легко разрабатывать (можно распределить работу между командами разработчиков), но сложно отлаживать.
Используется в крупных проектах с высокими нагрузками, требующих повышенной безопасности.
О чем еще мы пишем в блоге 1cloud:
- «Эволюция облачной архитектуры 1cloud: трудности модуляции»
- Как IaaS помогает франчайзи 1С: опыт 1cloud
- Зачем нужен мониторинг?
-
Часть Экипажа, Часть Корабля
19 Oct, 24 -
Cms Будущего
19 Oct, 24 -
Wi-Fi 6 И Huawei P40: Где Связь?
19 Oct, 24 -
Ключевые Тенденции Мошенничества В 2021 Году
19 Oct, 24 -
Агрегация Строк В Мире Sql Server
19 Oct, 24
