ВВЕДЕНИЕ 4
1. Архитектура 6
2. Выбор платформы и технологий 9
2.1 Анализ существующих платформ разработки 9
3. Задействованные технологии/инструменты 14
3.1 SignalR Core 3 preview 14
3.2 Entity Framework Core 3 preview 15
3.3 Blazor preview 17
3.3.1 Client-Side 18
3.3.2 Server-side 20
3.4 Docker 22
3.4.1 Принцип работы 22
4. Базовые сущности платформы 24
4.1 Спецификации вычислительной машины 24
4.2 Загруженность вычислительной машины 25
4.3 Сущность модуля 25
4.4 Сущность задачи 26
5. Головной модуль - Хаб 28
5.1 Регистрация модулей в системе 29
5.2 Спецификации и загруженность вычислительных машин 31
5.3 Обеспечение неявного общения модулей 33
5.4 Распределение нагрузки 35
5.5 Интеллектуальное распределение нагрузки 38
6. Библиотека соединений 41
6.1 Интерфейс соединения - IConnect 41
6.2 Сервис соединения - IConnection Service 43
6.3 Сервис сбора технических спецификаций - IMachine Info Collector
Service 44
6.3.1 Сбор технической спецификации 45
6.3.2 Сбор данных о загруженности 48
6.4 Сервис обработки задач - IBase Task Handler Service 49
6.5 Сервис оценки сущностей - IType Evaluate Service 51
7. Прочие модули платформы 54
7.1 Демонстрационные модули 55
7.2 Демонстрационный модуль пользовательского интерфейса 55
7.3 Демонстрационный модуль базы данных 58
8. Алгоритм приблизительной оценки задач 59
8.1 Первые идеи и попытки реализации 59
8.1.1 Концептуальное понимание оценки задач 60
8.1.2 Технические ограничения 62
8.2 Отказ от обобщенного контекста 64
8.2.1 Задача поиска 64
8.2.2 Задача вычислений 67
8.3 Работа алгоритма в экосистеме платформы 67
ЗАКЛЮЧЕНИЕ 70
СПИСОК ЛИТЕРАТУРЫ 74
ПРИЛОЖЕНИЕ 76
Интернет-ресурсы - это подавляющая часть интернет сети, которую мы знаем на сегодняшний день. Миллионы людей пользуются различными интернет ресурсами каждый день: поисковые системы, новостные блоги, социальные сети, корпоративные порталы и различные другие ресурсы, которые наполняют интернет и делают его таким, каким его можно наблюдать сейчас. Благодаря им человечество способно мгновенно обмениваться не только информацией, но и совершать большинство действий, например заказ такси и оплата банковских счетов, в любом месте, где есть возможность выхода в глобальную сеть.
Интернет-ресурсы внедрились в повседневную жизнь достаточно серьезно и в связи с популярностью, многие вещи стали доступны в сети, в том числе и бизнес. Различные организации/предприниматели находятся в интернет сети позволяя работать со своими клиентами более оперативно и большинство организаций озадачены созданием собственного интернет-ресурса.
Ранее создание интернет-ресурса, была не простой задачей, так как не было такого количества различных инструментов. Сегодня создание достаточного простого интернет-ресурса, например новостной блог, не самая тяжелая задача. Однако помимо простых интернет-ресурсов, не требующих существенной производительности от сервера, существуют и достаточно большие интернет-ресурсы, требующие не только максимум производительности от одного, но и зачастую максимум от нескольких десятков серверов. Такие интернет-ресурсы, как правило имеют огромное количество ежедневных пользователей и им необходима не только производительность, но и надежность.
Обычные системы, ориентированные на не самый большой поток пользователей, не способны предоставить такой уровень производительности и надежности. А потому для таких целей, все чаще используют комбинированные решения в виде платформ/систем, на которых возможно создание таких интернет-ресурсов.
В данной работе, будет предпринята попытка создание платформы, способной обеспечить не только высокую производительность, а также надежность и относительно удобство использования и поддержки.
Целью данной работы - является создание отказоустойчивой платформы, которая позволит создавать масштабируемые и отказоустойчивые системы. Функциональность данной платформы, будет определятся программами - модулями, которые могут быть созданы по необходимости. Для достижения цели работы, необходимо выполнить следующие задачи:
- хранение информацией о модулях в системе.
- Хранение информацией о загруженности системы, на которой запущен модуль.
- Отправка/перенаправление запросов между модулями.
- Балансировка нагрузки между модулями, имеющими одинаковую функциональность.
1. Архитектура
Данный тип приложений всегда требовал куда большего внимания к разработке, чем приложения, рассчитанные на меньшую нагрузку. Модульные платформы, должны обладать отказоустойчивостью не ниже серверной машины/кластера, на которой будет располагаться сама платформа, а позже и собранная на её основе система.
Когда речь заходит о модульности и распределенности системы, то наиболее частые варианты это:
1. полностью автономные и независимые приложения/системы, с поддержкой масштабирования (В качестве примера ниже, будет рассмотрена система - DNetCMS).
2. Неавтономные и зависимые модули/сервисы, зависящие от модуля управления.
Первый вид систем, показал себя хорошо, как уже полностью готовые и самостоятельные системы, обладающие достаточной производительностью, чтобы с небольшим запасом удовлетворить потребности средних по размеру, и количеству посетителей, интернет-ресурсов. При необходимости же большего, имелась поддержка масштабирования системы на уровне систем автоматизации развертывания ПО (к примеру Docker, который также будет поддерживаться и в этой платформе), которая позволяла относительно быстро поднять производительность интернет-ресурса. Однако у такого подхода есть несколько минусов:
1. нет синхронизации между отдельно запущенными системами, что могло приводить, в лучшем случае, к неактуальности данных.
2. Требовался отдельно располагающийся балансировщик нагрузок, который бы балансировал и распределял нагрузку отдельно стоящих систем.
3. Не оптимальное потребление ресурсов, в контексте распределенной системы. Так как приложение монолитное, части системы, которые не всегда нужны, потребляют системные ресурсы на ровне с необходимыми компонентами системы.
Это основные минусы, однако из самой концепции данных систем следует, что они рассчитаны преимущественно на самостоятельное и независимое использование. Обладающие полным спектром необходимых компонентов, для решения одной/нескольких заранее определенных задач. Возможность масштабирования на таких системах - всегда плюс, однако это не то, на что были рассчитаны эти системы при разработке.
Второй же вид систем, подразумевает обратное - модули/сервисы не автономны и как правило не способны работать без других компонентов платформы. Однако данный вид систем показывает себя, как минимум на несколько пунктов, а за частую и в несколько раз, лучше в контексте распределенных систем, чем первый вид систем.
Такой прирост возможен благодаря иному архитектурному подходу, так как платформа изначально проектируется, опираясь на то, что конечная система будет распределенной, то это позволяет распределить функционал конечной системы, на несколько модулей/сервисов. А связывающим звеном, выступит отдельный и специальный головной модуль, созданный специально для этого, который лучше знает все особенности платформы и как следствие всей будущей системы. Данный подход позволяет нивелировать минусы предыдущего подхода, а дополнительными плюсами будут:
1. повышение общей производительности системы благодаря тому, что связующий модуль изначально поддерживает масштабирование.
2. Более эффективная балансировка нагрузки.
3. Возможность масштабирования необходимой части системы, к примеру увеличение производительности только бизнес логики, не затрагивая другие части системы.
Ввиду плюсов и минусов рассмотренных подходов, а также требований к целевой платформе, то для реализации данной работы, был выбран второй подход. Исходя из этого, Бконечная архитектура приложения состоит из 2-х частей:
1. головной(связующий) модуль - Хаб.
2. Другие модули платформы, формирующие функциональность той или иной системы.
В конечном итоге, архитектура приложения будет иметь следующий вид (рисунок 1):
В данной работе была разработана модульная платформы для распределенных приложений с интеллектуальным распределением нагрузки. В данной работе было применено и освоено немалое количество технологий, предприняты попытки реализовать непростые задачи, например, такие как алгоритм приблизительной оценки для всех задач.
Прежде всего, стояла задача - выполнить все критерии, что были поставлены в начале разработки. Как результат итоговая платформа, соответствует всем, установленным ранее критериям, а именно:
- хранение информацией о модулях в системе.
- Хранение информацией о загруженности системы, на которых запущены модули.
- Отправка/перенаправление запросов между модулями.
- Балансировка нагрузки между модулями, имеющими одинаковую функциональность.
Из этого следует, что все задачи данной работы, успешно выполнены. Все вышеперечисленные критерии, за исключением хранении информации о модулях в системе, являлись обязательными к реализации, так как без них, платформа попросту бы не функционировала.
Хоть выполнение обязательных критериев и вполне достаточно, чтобы данная работа была выполнена, то в таком случае данная платформа была бы обычным балансировщиком нагрузок без каких-либо отличительных качеств. По этой причине был введен ряд улучшений для того, чтобы данная платформа, могла называться платформой, а не просто более продвинутым балансировщиком нагрузок.
В конечном итоге, разработанная платформа обладает следующим функционалом:
- регистрация, хранение и обработка информации с модулей.
- Неявное общение между модулями, посредством головного модуля.
- Отправка сущности задач вместо перенаправления запросов.
- Балансировка нагрузок.
- Интеллектуальная балансировка нагрузок.
- Алгоритм приблизительной оценки задач поиска.
- Поддержка Docker и Kubernetes.
Довольно непросто можно найти применение разработанной платформе, на первый взгляд. Ведь разработка модулей платформы создания целостной системы, уже требует немалых ресурсов. Такое вложение ресурсов должно быть чем-то оправдано, иначе данная платформа, будет попросту не интересна на таких условиях. Оправданием таковым затратам служит экосистема, которая выстраивается внутри платформы.
Именно экосистема данной платформы является одним из главных аргументов в её пользу. Используя данную платформу, можно собственноручно выстроить нужную экосистему, комбинируя не только модули, но и системы внутри платформы. Это позволяет гибко использовать платформу, подстраивая под необходимую систему(-мы).
Как уже могло показаться ранее, слово «система» была упомянута во множественном числе, и неспроста. Платформа позволяет выстроить систему, масштабировать её как это необходимо, наращивая мощности «слабых» мест в системе. Однако, не было и слова сказано о том, что система может быть только одна.
На основе данной платформы, можно несколько одновременно работающих систем, каждая из которых будет содержать уникальный набор модулей с необходимым количеством. Позволяя настраивать не только количество систем, но и их взаимодействие.
Поддержка Docker облегчает развертывание и мониторинг головного модуля и платформы в целом. Ввиду того, что платформа поддерживает Docker - следует то, что платформа автоматический поддерживает Kubernetes. Это позволяет не сильно задумываться о сложности развертывания платформы, достаточно установить Docker на целевую машину, скачать образ и запустить контейнер.
Разработанная платформа получилась вполне жизнеспособным программным обеспечением, которое справляется с поставленными перед ней задачами. А именно - является платформой для распределенных приложений, способной распределять нагрузку, как обычными способами, так и интеллектуальными.
Разработанная платформа, на текущий момент, лишь малая часть от того, что в потенциале она будет из себя представлять. Ввиду актуальности таковых платформ, при должном развитии данной платформы, она не будет уступать своим аналогам, а в чём-то даже и превосходить.
Улучшения всей системы балансировки нагрузок, позволит более грамотно распределять задачи, возможно даже предвосхищать загруженность тех или иных модулей после отправки определенного типа задач. Улучшение системы регистрации и обработки хранения информации о модулях, в сторону обработок динамических изменений самого модуля, позволит отлавливать потенциальное уменьшение/увеличение производительности. Улучшение в конвейере обработки задач, как минимум в сторону учёта разрыва соединений, позволит достаточно сильно разгрузить ту или иную систему в будущем.
В данной платформе открыт широкий простор для развития. Подбирая и реализовывая различные виды улучшений, можно добиться высокой производительности любых систем без привлечения стороннего программного обеспечения.
Резюмируя всю работу, можно сказать, что попытка разработать модульную платформу для распределенных приложений с интеллектуальным распределением нагрузки, оказалось скорее удачной, чем нет. Все поставленные задачи были выполнены, а где-то и перевыполнены. Данный опыт, несомненно, был полезен, так как были изучены и разобраны самые современные, на сегодняшний день, технологии.
Используя различные архитектурные решения, принимались разные попытки по реализации тех или иных задач. Некоторые попытки были удачные, некоторые не совсем, в любом из этих случаев был получен крайне полезный опыт и лучшие решения будут применены в будущих проектах. Ведь попытка создать программное обеспечение такого масштаба, достаточно поучительный опыт, мотивирующий не останавливаться на достигнутом, что подтверждают перспективы по развитию данной платформы.
Помощь студентам и аспирантам в выполнении работ от наших партнеров
