Основы энтерпрайз архитектуры (введение)

preview

Все хотя бы раз в своей жизни слышали термин "кровавого энтерпрайза", но у каждого свое представление о его значении. В рамках данного стрима под энтерпрайз решениями понимаются решения обладающие следующими требованиями: - многопользовательский режим (подразумевает одновременную работу пользователей, потенциально их может быть очень много); - большой объем данных; - долгосрочное хранение данных; - устойчивость к сбоям и возможность восстановления; - унификация интерфейса; - интеграция с другими приложениями/системами.

Энтерпрайз - это всегда гетерогенная система, даже если в самом начале это не так, то со временем становится именно так.

Калькуляция нагрузки

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
  • толстый клиент