exam17 2 - stankin/design-part-2 GitHub Wiki

Архитектурные паттерны высоконагруженных систем.

Реферат к лекции 17 "Высоконагруженные системы и системы реального времени." ✋

Выполнил: Саркисьянц Григорий, группа: ИДБ-18-06

Проверил: Беркаль Виктор, группа: ИДБ-18-06

Масштабирование

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

Архитектурные паттерны — это обобщенное часто используемое решение распространенной задачи в архитектуре ПО в заданном контексте.

Есть два основных способа масштабирования приложения. Вертикальное масштабирование (увеличение масштаба) означает увеличение емкости ресурса, например, за счет увеличения размера виртуальной машины. Горизонтальное масштабирование (развертывание) — это добавление новых экземпляров ресурса, например виртуальных машин или реплик базы данных.

Горизонтальное масштабирование имеет значительные преимущества по сравнению с вертикальным:

Истинный масштаб облака. Приложения можно разрабатывать так, чтобы они выполнялись на сотнях или даже тысячах узлов, достигая масштабов, которые невозможно реализовать на одном узле.
Горизонтальное масштабирование является эластичным. При повышении нагрузки можно добавлять экземпляры, а при ее понижении — удалять их.
Масштабирование может активироваться автоматически, по расписанию или в соответствии с изменением нагрузки.
Затраты на горизонтальное масштабирование могут быть меньше, чем на вертикальное. Несколько небольших виртуальных машин могут обойтись дешевле, чем одна большая.
Кроме того, горизонтальное масштабирование повышает устойчивость за счет избыточности. Если экземпляр выходит из строя, приложение продолжает работать.

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

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

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

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

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

ses

Что такое микросервисы?

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

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

Управление и оркестрация Этот компонент отвечает за размещение сервисов на узлах, определение сбоев, перераспределение сервисов между узлами и другие операции. Как правило, этот компонент является коммерческим продуктом (например, Kubernetes), а не разрабатываемым по заказу.

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

Преимущества использования шлюза API:

Он разделяет клиенты и сервисы. Можно управлять версиями сервисов и выполнять их рефакторинг без обновления всех клиентов.
Микросервисы могут использовать протоколы обмена сообщениями, которые не работают в Интернете, например AMQP.
Шлюз API может выполнять другие сквозные функции, например аутентификацию, ведение журнала, завершение запросов SSL и балансировку нагрузки.
Готовые политики, такие как регулирование, кэширование, преобразование или проверка.

Преимущества микросервисов:

Гибкость. Так как микросервисы развертываются независимо друг от друга, можно легко управлять исправлениями ошибок и выпусками компонентов. Можно обновить службу без повторного развертывания всего приложения, а также откатить обновление, если что-то работает неправильно. Во многих традиционных приложениях ошибка, выявляемая в одной части приложения, может заблокировать процесс выпуска. В результате новые компоненты могут ожидать интеграции, тестирования и публикации исправлений.
Небольшие специализированные команды. Микросервис должен быть достаточно компактным, чтобы одна команда, которая его разрабатывает, могла его создать, проверить и развернуть. Небольшое количество разработчиков в команде способствует повышению уровня гибкости. Большие команды, как правило, менее продуктивны из-за замедленного обмена информацией, больших расходов на управление и снижения гибкости.
Небольшая кодовая база. В монолитных приложениях со временем зависимости в коде усложняются. Чтобы добавить новый компонент, нужно изменить код в множестве мест. Благодаря использованию отдельных кодовых баз и хранилищ данных в архитектуре микросервисов становится меньше зависимостей, что упрощает добавление новых компонентов.
Сочетание технологий. При необходимости команды могут применять те технологии, которые лучше всего соответствуют особенностям используемых сервисов.
Изоляция ошибок. Если один микросервис станет недоступен, это не нарушит работу всего приложения, так как все вышестоящие микросервисы спроектированы правильно реагировать на ошибки (например, путем автоматического отключения).
Масштабируемость. Микросервисы можно масштабировать независимо. Благодаря этому можно горизонтально увеличивать масштаб подсистем, для которых требуются дополнительные ресурсы, не увеличивая масштаб всего приложения горизонтально. С помощью оркестраторов (например, Kubernetes или Service Fabric) вы можете создавать на одном узле пакеты сервисов с более высокой плотностью, оптимизируя использование ресурсов.
Изоляция данных. Гораздо проще обновлять схему, так как это отражается на работе только одного микросервиса. В монолитном приложении обновление схемы может быть очень сложной задачей, так как разные части приложения могут использовать одни и те же данные. Из-за этого внесение любых изменений в схему может оказаться рискованным.

Недостатки

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

Сложность. Приложение на микросервисах содержит больше движущихся частей, чем аналогичное монолитное приложение. Каждая служба является простой структурой, но вся система в целом гораздо сложнее.
Разработка и тестирование. Написание небольшого сервиса на основе других зависимых сервисов требует иного подхода, чем написание традиционного монолитного или многоуровневого приложения. Существующие средства не всегда предназначены для работы с зависимостями сервисов. Рефакторинг между службами может быть сложной задачей. Также непросто тестировать зависимости сервисов, особенно если приложение быстро изменяется.
Недостаток управления. Децентрализованный подход к созданию микросервисов имеет свои преимущества, но он также может привести к проблемам. В приложении может появиться так много разных языков и платформ, что его будет трудно обслуживать. Можно попробовать установить некоторые стандарты для всего проекта, не ограничивая чрезмерно гибкость разработчиков. В частности, это касается сквозных функций, таких как ведение журнала.
Перегрузки и задержки сети. Использование большого количества мелких сервисов может привести к интенсивному взаимодействию между ними. Кроме того, если цепочка зависимостей службы становится слишком длинной (служба A вызывает службу B, которая вызывает службу C и так далее), дополнительная задержка может стать проблемой. Необходимо тщательно разрабатывать API-интерфейсы. Не стоит создавать API-интерфейсы, которые отправляют слишком много сообщений, и по возможности стоит найти места, в которых можно использовать асинхронные модели связи, например выравнивание нагрузки на основе очередей.
Целостность данных. Каждая микрослужба отвечает за сохранение своих данных. Поэтому может быть сложно поддерживать согласованность данных.
Управление. Для успешной работы с микросервисами требуется современная культура DevOps. Согласованное ведение журнала для разных сервисов может оказаться сложной задачей. Как правило, ведение журнала необходимо согласовывать с несколькими вызовами службы для одной операции пользователя.
Управление версиями. Обновления службы не должны нарушать работу сервисов, зависящих от нее. Несколько сервисов могут обновляться в любой момент времени, поэтому без тщательного планирования могут возникнуть проблемы с обратной или прямой совместимостью.
Навыки. Микросервисы являются распределенными системами. Для работы с этими службами следует тщательно оценить знания и опыт своей команды.

Паттерны проектирования облачных приложений

Для повышения производительности, устранения бутылочных горлышек и обеспечения масштабируемости могут использоваться следующие конструктивные шаблоны проектирования:

Модель	Описание
Cache-Aside	Загрузка данных по запросу из хранилища данных в кэш.
Choreography	Каждый компонент системы принимает участие в процессе принятия решений о рабочем процессе бизнес-транзакции, не полагаясь на центральную точку управления.
CQRS	Разделение интерфейса на операции считывания и записи данных.
Event Sourcing	Использование инкрементируемого хранилища для сохранения всей последовательности событий, то есть всех действий с данными.
Deployment Stamps	Развертывание нескольких независимых копий компонентов приложения, включая хранилища данных.
Geode	Развертывание серверных сервисов в нескольких географических узлах, каждый из которых может обслуживать любой клиентский запрос в любом регионе.
Index Table	Создание в хранилище данных индексов по полям, которые часто используются в запросах.
Materialized View	Создание предварительно заполненных представлений на основе данных из одного или нескольких хранилищ данных, когда данные не отформатированы для требуемых операций запросов.
Priority Queue	Запросы, к сервису получают разные приоритеты. Запросы с высоким приоритетом принимаются и обрабатываются быстрее, чем запросы с низким приоритетом.
Queue-Based Load Leveling	Очередь выполняет роль буфера между задачей и сервисом, который ее выполняет, позволяя сгладить кратковременные всплески нагрузки.
Sharding	Разделение хранилища данных на несколько горизонтальных секций, которые называются шардами.
Static Content Hosting	Разверните статический контент в облаке для доставки непосредственно клиенту.
Throttling	Контроль потребления ресурсов, используемых экземпляром приложения, отдельным клиентом или всем сервисом.