Разработка модели среды распределенных вычислений Evergrid для сравнения алгоритмов управления потоками задач и данных (1187422), страница 4
Текст из файла (страница 4)
Выполнение запросов изолировано другот друга. В данных ограничениях удобно писать код, но страдает масштабируемость и не стоит использовать продолжительные по времени подключения(websocket’ы, например). Синхронным такой подход называется т. к. в случае1234567http://rubyonrails.org/https://nodejs.org/en/Например: http://expressjs.com/https://www.djangoproject.com/http://php.net/https://www.playframework.com/http://www.phoenixframework.org/20одного обработчика мы блокируем выполнение следующего запроса до завершения предыдущего.С "асинхронной"архитектурой – в этом подходе для каждого входящего запроса на лету создается свой поток обработки.
Т. е. мы, в отличие от предыдущегоподхода, не вынуждены ждать завершения обработки предыдущего запроса дляначала обработки нового. Для такой архитектуры сложнее писать код, но обычно решения на ней обладают лучшей производительностью и более широкимспектром возможностей.Это описание, достаточное для общего понимания. Еще один важный параметр- это используемый язык программирования. От него зависит как скорость продукта,так и, отчасти, легкость его сопровождения.Сначала рассмотрим технологии, использование которых может оказаться неэффективным:Java/ASP.NET Плохо годятся для небольших команд.
ASP.NET плох своим акцентам на Windows-сервера. Java, на фоне прочих языков, слишком "многословна ибыстро реализовать на ней прототип довольно тяжело.Node.js Несмотря на асинхронность архитектуры, javasript работает в одном потоке.Но главный его недостаток - это дизайн языка. У JS крайне слабая систематипов, запутанная спецификация и много неоправданно неочевидных моментов.PHP Очень популярен в вебе, до сих пор развивается, множество фреймворков. Нодизайн языка хоть и лучше, чем у JS, все равно уступает ruby и python.
Другойего недостаток - слабость как языка общего назначения - выражается в том,что на нем неудобно писать что-то кроме непосредственно генерации ответовна запросы к веб-серверу. А подобное может понадобиться - например, дляорганизации выполнения внешних очередей задач или удобного использованияwebsocket’ов. Кратко говоря, PHP неоправданно накладывает слишком многоограничений.Теперь рассмотрим список технологий, хорошо подходящих этому проекту:21Python Python активно используется как для веб-разработки, так и для научныхцелей. Веб-фреймворки на нем довольно качественные, и есть большое количество решений для типовых задач (например, регистрация пользователей ипр.).
Поскольку Python скриптовый язык с GIL, большинство решений на немреализуют синхронную архитектуру. Это не настолько большой недостаток,как может показаться, но, если высокая производительность или использование websocket’ов является критичным, - python может оказаться не лучшимвыбором.Ruby on Rails В основном ситуация, схожая с python за исключением следующихразличий: редко используется в научной среде; язык более гибкий, но и болеесложный, чем python; большее количество библиотек с готовыми решениямидля веб-разработки.
Отдельным преимуществом является и то, что Rails однозначный лидер среди Ruby-фреймворков, а это означает, что почти любаяразвитая библиотека умеет корректно с ним работать. В случае с python все более разобщено. То есть, если есть возможность эффективно использовать Rails- то это является удачным решением в рамках синхронной архитектуры.Phoenix Framework (Elixir) Если важно использование асинхронной архитектуры, то стоит вспомнить об Erlang. Продукты, написанные на Erlang, в виду особенностей BEAM (Bogdan/Björn’s Erlang Abstract Machine) и принципов OTP(Open Telecom Platform) отличаются высокой стабильностью и производительностью. Elixir - это молодой язык для BEAM, который более удобен в использовании, имеет больше возможностей, чем Erlang, и может без ограниченийиспользовать его библиотеки.
На этом языке реализован Phoenix Framework.Что язык, что сам фреймворк - еще молодые, используются в production, нопока еще не получили широкого распространения. Сам фреймворк удобен виспользовании. Данный вариант хорош, если хочется получить преимуществаErlang/OTP-экосистемы: высокая стабильность, высокая производительностьна IO задачах, дешевый и удобный параллелизм благодаря green threads и акторной модели, преимущества подходов из функциональной парадигмы программирования.Play Framework (Scala) Еще одно возможное решение, если нужна асинхронностьи производительность. Scala - преимущественно функциональный язык про22граммирования поверх JVM, имеющий возможности интероперабельности сJava. Тоже использует акторную модель (Akka). Более зрелое решение, чемphoenix, и более широко распространено на данный момент.
Из недостатковможно отметить то, что в Erlang более развитые средства для мониторинга и более стабильная реализация акторной модели и супервизоров. Также Scala является более сложным в изучении и использовании языком, нежели Elixir/Erlang.Из преимуществ можно отметить, что мы получаем доступ к внушительномупарку Scala и Java библиотек.3.3.2. Core и Control UnitЭти два компонента формируют внутреннюю инфраструктуру сервиса.
В данном случае корректным будет следующий список требований:∙ высокая производительность (система должна адекватно вести себя под высокими нагрузками)∙ выбранное решение должно использоваться для схожих известных продуктов∙ иметь развитые библиотеки для сетевого взаимодействия∙ чем проще будет инициализировать новые сервера - тем лучше∙ язык должен быть популярен и иметь активное сообщество∙ простота языка будет плюсомТребование высокой производительности ставит под сомнение использованиеинтерпретируемых языков. Из "быстрых"языков в первую очередь приходят на умC/C++ и go. ASP.NET плохо дружит с Linux, а Java/Scala довольно прожорливыв плане памяти и не являются простыми в использовании языками.
С++ - тожедовольно сложный в использовании язык. Если же внимательнее посмотреть на go,то становится видно, что он является хорошим решением:∙ на нем написаны продукты hashicorp (nomad, consul), на нем написан docker∙ скорость выполнения сравнима с C/C++∙ прост в изучении: опытный программист может освоить все основные возможности языка за пару вечеров23∙ популярен для написания микросервисов∙ встроенная в язык модель параллелизма CSP∙ активное сообщество и большое количество готовых библиотек∙ скомпилированное приложение для своей работы не требует установки самогоgo или каких-либо специфических пакетовПоэтому для Core и Control Unit go является подходящим выбором.
Причемданный выбор имеет жесткий характер, так как симулятор тоже написан на go, ичасть его преимуществ основывается на том, что для реализации инфраструктурытоже будет использоваться этот язык.3.3.3. DBНа самом деле на данном этапе сложно предсказать все те требования, которыемогут возникнуть для основного хранилища. Возможно, даже одного продукта нехватит, и будет использоваться некая комбинация (например: часто можно встретитьсвязки Postgres + Redis).Но, в качестве решения по умолчанию, стоит рассматривать именно Postgres. Наданный момент это наиболее универсальное и активно используемое решение средиopen source баз данных.3.4. Ограничения, связанные с CAP-теоремойПоскольку мы имеем дело с распределенной системой, то стоит явно указатьприоритеты в терминах CAP-теоремы.
Причем эти приоритеты отдельные для каждого слоя (именно из-за этого вообще появилось разделение на слои).Также первый и второй слой используют consul - он предоставляет service discoveryи leader election интерфейсы, к тому же он создан для решения этих задач как разтаки в распределенных системах.Слой Execution Для этого слоя подходит конфигурация [C]AP. Если машина потеряла связь с системой – перераспределяем нагрузку. Здесь важно в любоймомент времени максимально использовать доступные ресурсы.24Слой Control При критичной сегментации сети в слое, Control Unit’ы перестаютпринимать запросы, но продолжают выполнение локальных очередей. Примерно так выглядит жертва availability во имя consistency и partition tolerance.Стоит сказать, что это довольно грубый подход.
Но начать разработку прощеименно с него. Как второй шаг может подойти weak consistency подход ("согласованность в итоге").Слой Interface На этом слое крайне важна согласованность данных, а без доступности он не имеет смысла. Поэтому жертвуем partition tolerance.3.5. Требования к симуляторуИмея описание архитектуры, можно сформулировать список требований к симулятору.Первое из них связано с симуляцией сети. Для симуляции данной архитектурынам не важен пинг между ее компонентами. Нам важна только скорость передачиданных между ними и сам факт наличия связи. Отдельный случай - это черезмернобольшой пинг - это может повлиять на порядок запросов и подобное. Но по фактунам нужно симулировать не пинг, а факт поздней доставки сообщений.
В итоге имеемследующие требования:∙ симуляция видимости между машинами∙ симуляция скорости передачи данных∙ симуляция разрыва соединения∙ симуляция поздно пришедших сообщенийВторое ограничение связанно с тем, что мы должны симулировать время. Т. к.нам важно понимать когда выполнялась задача и сколько времени она выполнялась.Наиболее гибким простым решением является "дискретная"природа симулируемоговремени. То есть мы используем дискретный таймер, и каждый агент системы делаетту работу, которую теоретически может успеть за эту дискретную единицу времени.И третье ограничение - симулятор должен быть достаточно гибким, чтобы приизменении принципов работы компонент можно было легко внести изменения в модель.25Всякий симулятор преследует цель проверки гипотез.
В данном случае симулятор должен помогать в исследовании:∙ эффективности алгоритмов планировщиков∙ принципов взаимодействия компонентов системы26Глава 4Сравнение с существующими решениямиВ рамках работы была рассмотрена возможность использования или модификации существующего решения вместо написания своей реализации. Для корректногосравнения стоит сразу перечислить преимущества написания своей реализации наgo.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
