Основы энтерпрайз архитектуры (введение)
Все хотя бы раз в своей жизни слышали термин "кровавого энтерпрайза", но у каждого свое представление о его значении. В рамках данного стрима под энтерпрайз решениями понимаются решения обладающие следующими требованиями: - многопользовательский режим (подразумевает одновременную работу пользователей, потенциально их может быть очень много); - большой объем данных; - долгосрочное хранение данных; - устойчивость к сбоям и возможность восстановления; - унификация интерфейса; - интеграция с другими приложениями/системами.
Энтерпрайз - это всегда гетерогенная система, даже если в самом начале это не так, то со временем становится именно так.
Калькуляция нагрузки
Duration: 10
Основные требования: - масштабируемость - время отклика (скорость с которой система понимает, что от нее требует пользователь) - скорость реакции (время которая система тратит на выполнения полезных действий) - время задержки (время на распространение данных по сети)
Формирование ограничений: - максимальное количество единовременно работающих пользователей - предельные значения отклика - режим работы: - приближенный к реальному - интервальный принцип (относительно интервала времени)
Способы оценки - аналитическая оценка - эмпирическая оценка
Аналитическая оценка:
- графический способ оценки
- оценка по пиковому, среднему и минимальному значению
- оценка в относительных единицах
- IOPS - количество операций ввода-вывода в секунду
- MIPS - миллионы инструкций в секунду
- коэффициенты
- алгоритмическая сложность (BIG O нотация)
Эмпирическая оценка: - замеры аналогичных решений - прототипирование
Нагрузка по ресурсам (для аналитических методов): - дисковая нагрузка - для оценки рассматриваются варианты реализации с учетом специфики решения: - линейное чтение - рандомное чтение - системы хранения данных (RAID, NAS и т.д.) - физические носители (HDD, SSD, RAM) - вычислительная нагрузка - потребляемые инструкции (под нагрузкой, без нагрузки) - многопоточность/однопоточность - коэффициент повышения производительности (закон Амдала) - сетевая нагрузка
Типовые оценки по времени
Duration: 5
Часто для калькуляции производительности можно оттолкнуться от типовых оценок времени, которые можно выработать самостоятельно, или найти в сети, например в статье "Google Pro Tip: Use back-of-envelope-calculations To Choose The Best Design" приводились такие оценки:
- L1 cache = 0,5 ns
- L2 cache = 7 ns
- Mutex lock/unlock = 100ns
- Memory reference = 100ns
- Read 1Mb from memory = 250 000 ns
- Disk seek - 10 000 000 ns
- Read 1Mb from network (последовательно) - 10 000 000 ns
- Read 1Mb from disk (последовательно) - 30 000 000 ns
Выбор типа архитектуры
Duration: 5
Энтерпрайз архитектуры строятся на принципах параллельного выполнения, при этом целевые свойства системы достигаются путем применения принципа "разделяй и властвуй", когда система бьется на подсистемы, при этом для проектирования как правило используются следующие архитектуры:
- Сервис-ориентированная архитектура
- Микросервисная архитектура
- Монолитная архитектура
В некотором смысле все заканчивается монолитом: микросервис - монолит, но при этом в системе может быть всего лишь один блок развертывания, который тоже будет являться монолитным.
Модель слоев
Duration: 10
Конечная единица проектирования, как правила реализуется в виде слоистого монолита, который удобнее всего выразить в трехслойной архитектуре.
- представление
- предметная область
- данные
Основная проблема - конкуренция за использование ресурсов.
Решается через: - параллельные задания - транзакции
Параллельные задания
Duration: 5
В основном параллельность достигается за счет многосеансовой работы, второй вариант - конкурирующие системные процессы (этот вариант пока рассматривать не будем).
Для совместной работы нескольких пользователей в сеансовом подходе используется механизм параллельных заданий, который реализуется через механизм блокировок. Обычно формируется из небольших моно-задач, которые не имеют большого количества промежуточных состояний.
Блокировки бывают: - оптимистичные - никого не блокируем, согласовываем конечный вариант по мере закрытия транзакций - пессимистичный - блокировки до завершения транзакции, при этом допускаются ситуации совмещения блокировок по типам: - чтение (предотвращение несогласованного чтения) - запись (предотвращение несогласованной записи) - полная
Транзакции
Duration: 10
Для управления сложными действиями, которые могут состоять из нескольких этапов используются - транзакции. Транзакция может быть целиком размещена в слое предметной области (однофазные), а может распространяться по всей системе (многофазные)
По способу обработки: - синхронные (ACID) - в основном используются для однофазных транзакций - асинхронные (BASE) - в основном используются для много фазных транзакций
По назначению: - служебные - прикладные (бизнес)
По сути выбор сводится к способу обработки транзакций: ACID и BASE
ACID: - Атомарность (Atomicity) - Согласованность (Consistency) - Изолированность (Isolation) - Прочность (Durability)
BASE: - базовая доступность (Basically Available) - неустойчивое состояние (Soft-state) - согласованность в конечном счёте (Eventually consistent)
CAP: - Согласованность (Consistency) - Доступность (Availability) - Устойчивость к разделению (Partition tolerance)
AP - целостность в конечном итоге
Шлюзы
Основной способ управляемого разделения компонентов сложной системы заключается в использовании "шлюзов". Шлюзы являются типовыми элементами, с которыми может взаимодействовать произвольный компонент системы. Таким образом все знают о шлюзе, но ничего не знают друг о друге. Это позволяет реализовать концепцию низкого зацепления.
Использование шлюзов помогает отделить способ получения от информации, от непосредственно получения. Таким образом конечные компоненты не содержат специфической логики связанной с реализацией сторонних компонент.
Шлюз может работать в одном из двух режимов: - широковещательный - все сообщения передаются всем компонентам подключенным к шлюзу - персональный - реализация "умного шлюза" который может точно установить кому адресовать данные
Способы взаимодействия: - API (монолиты) - Протокол (реактивная архитектура)
Предметная область (по Фаулеру)
Duration: 10
Наиболее распространенный подход - ООП. Часто прибегают к паттернам Фаулера:
- сценарий транзакций (может быть выполнен в процедурном стиле)
- модель предметной области
- модуль таблица
Опасность: анемичная модель
Хранение данных
Duration: 10
- реляционная (SQL) СУБД
- NoSQL СУБД
На сегодняшний день стандартом является комбинирование NoSQL и SQL решений
Преимущества SQL: - оптимальная структура хранения данных (позволяет оптимизировать объем) - транзакции (выполняется ACID) - мощный язык запросов
Недостатки: - Слабая горизонтальная масштабируемость
Преимущества NoSQL: - гибкость в отношении структур данных - механизмы подписка/отписка
Недостатки: - Транзакции
Задачи для SQL: - все что касается финансовых операций - сложные композитные отчеты
Задачи для NoSQL: - сбор слабоструктурированной статистики, для последующей обработки (данные мониторинга) - промежуточный кэш (NoSQL ключ-значение) - хранение документооборота - хранение состояния сеанса
Представление
Duration: 10
- SPA
- толстый клиент