40УДК 004
Кальянов Никита Александрович Kalyanov Nikita Alexandrovich
Студент Student
Тольяттинский государственный университет
Togliatti State University
АНАЛИЗ ПРИМЕНЕНИЯ CRDT ДЛЯ РАЗРАБОТКИ КЛИЕНТ-СЕРВЕРНЫХ ПРИЛОЖЕНИЙ
AN ANALYSIS OF CRDT USAGE IN THE DEVELOPMENT OF CLIENT-SERVER APPLICATIONS
Аннотация. В статье выделено 5 осей клиент-серверных приложений, релевантных для внедрения CRDT. На выделенных осях выбрано 6 основных архитектур приложений. Для каждой выделенной архитектуры проанализировано оптимальное логическое расположение CRDT в приложении и построена графическая диаграмма развертывания CRDT.
Для повышения практической применимости исследования учитывались новейшие технологии и тенденции развертывания клиент-серверных приложений, выработаны рекомендации для применения CRDT в разных архитектурах приложений и для популярных платформ разработки Enterprise-приложений. Кроме того, определены наиболее подходящие реализации CRDT для 5 широких классов приложений.
Abstract. The article highlights 5 axes of client-server applications that are relevant for the implementation of CRDT. On the selected axes, 6 main application architectures are selected. For each dedicated architecture, the optimal logical location of the CRDT in the application is analyzed and a graphical diagram of the CRDT deployment is constructed.
To increase the practical applicability of the study, the latest technologies and trends in the deployment of client-server applications were taken into account, and recommendations were developed for the use of CRDT in different application architectures and for popular Enterprise application development platforms. In addition, the most suitable CRDT implementations for 5 broad classes of applications are identified.
Ключевые слова. CRDT, распределенные системы, типы данных, репликация, EVENTUAL CONSISTENCY, клиент-серверные приложения
Key words: CRDT, distrubutes systems, data types, replication, eventual consistency, clientserver applications
IXМеждународная научно-практическая конференция
Введение
CRDT обладают привлекательными свойствами для использования в практических приложениях (отсутствие конфликтов и т. д.). Однако, наблюдается отсутствие широкого внедрения CRDT в массовые клиент-серверные приложения. В связи с этим были намечены задачи, призванные облегчить внедрение CRDT. В частности, в рамках данного исследования прорабатывается определение места CRDT в архитектуре современных клиент-серверных приложений, а также классификация приложений по применимости CRDT для их задач с упором на практическую значимость результатов.
Определение места CRDT в архитектуре клиент-серверного приложения Анализ архитектур современных клиент-серверных приложений
Рассмотрим основные типы архитектур клиент-серверных приложений и место CRDT в них. Для большей наглядности сконцентрируемся на логической архитектуре [1] (т.е. отражению основных компонентов системы), абстрагируясь от деталей физической реализации (количество серверов, сетевая топология и так далее). Существуют различные подходы к анализу архитектуры приложений в зависимости от интересующих измерений, уровня детализации, целей анализа и так далее. В данном исследовании было выделены следующие релевантные оси клиент-серверных приложений (рис. 1).
Рис. 1. Схематическое отображение многомерного пространства клиент-серверных приложений
Далее приведено описание каждой из выделенных осей (табл. 1).
IXМеждународная научно-практическая конференция Таблица 1. Оси клиент-серверных приложений
Идентиф икатор Название оси Описание оси Левый полюс Правый полюс Причина релевантности
а Тип развертывания Отражает путь от традиционного развертывания с самостоятельным обслуживанием до современного облачного развертывания Self-hosted развертыван ие Облачное развертыван ие Специфичные облачные архитектуры могут повлиять на способ внедрения СЯБТ
б Модульность приложения Отражает путь от единого монолитного приложения до слабо связанных микросервисов Монолитное приложение Микросерви сная архитектура Особенности использования микросервисов могут повлиять на способ внедрения СЯБТ
в Сложность решаемых задач Отражает сложность и масштабность задач, решаемых приложением Single-Page Application (SPA) для малого бизнеса Enterpise-приложение Особенности разработки приложений Е^егрпве- уровня могут повлиять на способ внедрения СЯБТ
г Тип рендеринга Отражает где логически рендерятся страницы приложения (на клиенте или на сервере) Server-Side Rendering (SSR) Client-Side Rendering (CSR) Способ рендеринга влияет на способ получения данных и поэтому может повлиять на способ внедрения СЯБТ
д Хранение состояния Отражает то, хранит ли клиент-серверное приложение состояние [между запросами] Stateless Stateful Хранение состояния усложняет разработку и развёртывание приложения и поэтому может повлиять на способ внедрения СЯБТ
«Инновационные аспекты развития науки и техники» По результатам анализа был сформирован список архитектур для рассмотрения (рис. 2).
Рис. 2. Схематическое изображение выделенных архитектур
приложений на осях
Далее приведено подробное описание каждой из рассматриваемых архитектур (табл. 2).
IXМеждународная научно-практическая конференция Таблица 2. Описание выделенных архитектур клиент-серверных
приложений.
Номер Название архитектуры Измерения архитектуры Причина рассмотрения
6 Простое клиент-серверное приложение а) self-hosted развертывание б) монолитное приложение в) SPA-приложение г) CSR-приложение д) stateful Простейшее возможное приложение, Самая простая архитектура для внедрения CRDT, база для дальнейшего анализа
1 Клиент-серверное приложение с использованием СУБД а) self-hosted развертывание б) монолитное приложение в) SPA-приложение г) CSR-приложение д) stateful Для хранения состояния в stateful приложениях чаще всего используется СУБД
4 Клиент-серверное приложение с использованием микросервисной архитектуры а) self-hosted развертывание б) микросервисная архитектура в) SPA-приложение г) CSR-приложение д) stateful Позволяет выделить особенности микросервисной архитектуры и её влияние на внедрение CRDT
2 FaaS клиент-серверное приложение а)облачное б) микросервисная архитектура в) SPA-приложение г) CSR-приложение д) stateful FaaS является одной из самых облегченных облачных моделей развертывания
3 Клиент-серверное приложение на платформе приложений уровня предприятия а) self-hosted б) монолитное приложение в) Enterprise-приложение г) CSR-приложение д) stateful Использование различных платформ приложений уровня Enterprise является популярным способом разработки и развёртывания таких приложений
5 Server-side rendering (SSR) а) self-hosted б) монолитное приложение в) SPA-приложение г) SSR-приложение д) stateful Использование подхода SSR для динамических приложений позволяет совместить преимущества SSR и CSR
Именно такая классификация архитектур позволит нам рассмотреть все релевантные измерения клиент-серверных приложений. Кроме того, почти все из выделенных архитектур встречаются на практике.
В следующих разделах представлен последовательный анализ каждой из выбранных архитектур в порядке возрастания сложности. Для каждой из архитектур определено предпочтительное логическое размещение CRDT и представлена графическая иллюстрация предложенного размещения. Размещения сравниваются друг с другом по релевантным параметрам.
Простое клиент-серверное приложение
Application server
Рис. 3. Простое клиент-серверное приложение
Клиентское приложение — часть приложения, которая выполняется на устройстве пользователя (например JavaScript в браузере, мобильное приложение, консольное приложение). Обычно клиентское приложение для предоставления полезных функций обращается к серверной части приложения [2]. Другие используемые термины перечислены в разделе «Глоссарий». В простейшем случае имеем один сервер приложения, который принимает и обрабатывает запросы клиентов (рис. 3). В данном случае приложение не пользуется внешними системами. Логично предположить, что приложение является динамическим (т.е. хранит состояние (stateful), а не отдаёт клиентам статические веб-страницы), так как в противном случае не возникает задачи
IXМеждународная научно-практическая конференция синхронизации и соответственно не возникает необходимости использования
CRDT. В таком случае, наиболее подходящим применением CRDT выглядит
использование на клиенте. Клиентский код приложения (например JavaScript в
браузере) регулярно запрашивает состояние сервера и использует алгоритмы
слияния CRDT чтобы обновить своё состояние и отправить его на сервер.
Однако такой подход потенциально ограничивает производительность. При появлении многопользовательских функций или внедрении альтернативного клиентского приложения становится возможной ситуация, в которой несколько экземпляров клиентских приложений синхронизируют одно и то же состояние с сервером. Благодаря свойствам CRDT изменения могут корректно (без конфликтов и потери данных) применится в любом порядке, но само конкурентное изменение состояния со стороны нескольких клиентских приложений может вызвать повышенную нагрузку на клиентские приложения (так как каждому клиенту придётся синхронизировать состояние большее число раз). Чтобы этого избежать возможно использовать модуль CRDT и в серверной части приложения. В таком случае сервер сможет буферизовать изменения клиентов (это возможно благодаря свойствам CRDT) и выполнять другие оптимизации для ускорения работы. В таком случае схема станет выглядеть так (рис. 4).
Client CRDT module
Server CRDT
Module
► Application server
Рис. 4. Использование серверного модуля CRDT
«Инновационные аспекты развития науки и техники» Клиент-серверное приложение с использованием СУБД Стоит отметить что данная схема достаточно сильно упрощена, реальные приложения чаще используют выделенную СУБД (Систему Управления Базами Данных) для работы с постоянным хранением данных, а не реализуют хранение данных самостоятельно. В таком случае обновлённая схема приложения будет выглядеть так (рис.5).
Рис. 5. Приложение с использованием Базы Данных
Появляется выбор: теперь серверный модуль CRDT можно разместить не только внутри приложения, но и внутри СУБД. В таком случае единожды разработанное решение, реализующее CRDT на уровне БД может использоваться в широком множестве приложений, что позволит достичь общего ускорения разработки. При этом сама СУБД в данном случае представляет собой логический сервис, на физическом уровне возможно использование распределенной СУБД с репликацией. Кроме того, перед физической Базой Данных может присутствовать дополнительный кэширующий т-шешогу слой для ускорения запросов. Указанные детали развёртывания не изменяют место CRDT в архитектуре.
Приведённая архитектура может горизонтально масштабироваться путём увеличения числа серверов приложений и использования балансировщика нагрузки.
IXМеждународная научно-практическая конференция Клиент-серверное приложение с использованием микросервисной
архитектуры
Одна из современных тенденций развёртывания клиент-сервисных приложений - использование микросервисной архитектуры [3]. Рассмотрим место CRDT в подобной архитектуре (рис. 6).
Рис. 6. Использование CRDT в микросервисной архитектуре
В данном случае эффективнее всего выделить функционал, связанный с CRDT в отдельный микросервис. Это позволит повысить переиспользование кода в разных частях приложения, разделить ответственность между командами и повысить стабильность работы модуля CRDT за счёт фиксации контракта (так как модуль CRDT является для остальных модулей внешним API). Несомненно, такое решение несколько снизит общую производительность серверной части приложения так как сетевой запрос обладает на порядки большей задержкой чем локальный вызов функции [4]. Эту задержку можно попытаться снизить путём использования эффективных бинарных протоколов для общения между микросервисами, вместо текстового HTTP/1.1 (например, протокол gRPC[5]).
Для развёртывания микросервисной архитектуры часто используются контейнеры и системы оркестрации контейнеров (например, Kubernetes), при
этом инфрастуктурный слой может быть физически расположен у облачного провайдера (так называемая модель Platform-as-a-Seгvice, Paas, рис. 7) [6]. Выводы по использованию CRDT в данном случае не изменятся.
Рис. 7. Различные модели облачных услуг. Иллюстрация из книги
Cloud Native Spring in Action[7]
FaaS клиент-серверное приложение Рассмотрим также специфичную для облачных развёртываний архитектуру. Это так называемая Function-as-a-Service, FaaS. Данная модель развёртывания предполагает максимальное использование облачной инфраструктуры, приложение представляет собой исключительно реализацию бизнес-логики (function, конкретный блок кода на каком-либо из поддерживаемых языков программирования), а все инфраструктурные компоненты предоставляются облачным провайдером [8]. Такая модель максимально упрощает развёртывание и поддержку приложения. В то же время, из-за максимальной изолированности компонентов приложения отсутствует возможность выделить модуль CRDT в отдельный сервис. Если выбранный
IXМеждународная научно-практическая конференция облачный провайдер не предоставляет готовый функционал CRDT, то возникает
необходимость явно использовать модуль CRDT в каждой из функций,
составляющих приложение (рис. 8). Такое решение представляется менее
гибким, чем выделение CRDT в отдельный микросервис так как возникают
проблемы централизованного обновления модуля CRDT сразу во всех
использующих его функциях.
Calling functions from CRDT module
Рис. 8. Использование CRDT в модели развертывания FaaS
Клиент-серверное приложение на платформе приложений уровня предприятия
Рассмотрим также наиболее популярные платформы для разработки приложений уровня предприятия (Enterprise). Данные платформы предоставляют полноценную среду для разработки корпоративных приложений, в том числе клиент-серверных и часто используются при разработке и развёртывании клиент-серверных приложений уровня Enterprise. Стандартизованный набор взаимосвязанных спецификаций различных
«Инновационные аспекты развития науки и техники» компонентов позволяет выбирать конкретную реализацию среди несколько
свободных и проприетарных реализаций, а также комбинировать реализации
разных компонентов от разных поставщиков. Анализ конкретных популярных
платформ позволит повысить практическую применимость исследования.
Наиболее популярные платформы[9]: Java Enterprise Edition (Java EE,
развивается компанией Oracle и другими участниками сообщества)[10] и .NET
Framework (развивается компанией Microsoft, новейшие версии называются
просто .NET, например .NET 5)[11].
Платформа Java EE
Рассмотрим архитектуру Java EE. Платформа Java EE обладает многослойной архитектурой, одно из наиболее популярных разделений на слои — трехслойное разделение Presentation Layer — Business Layer — Database Layer (Слой представления — Слой бизнес-логики — Слой данных)[12]. Также перед слоем представления может добавляться клиентской слой.
Серверная часть Java EE приложения, реализующая слой бизнес логики и частично слой представления часто состоит из веб-контейнера (Web Container) в котором запущены сервлеты (servlet) и/или EJB контейнера в котором запущены EJB (Entreprise Java Beans)[13]. В таком случае компонент, предоставляющий функционал CRDT можно разместить как отдельный Servlet или как отдельный EJB[14].
Кроме того, возможно реализовать функциональность CRDT как middleware (промежуточный слой), например в качестве фильтра перед соответствующими сервлетами.
Выбор конкретной реализации из трёх предложенных будет зависеть от используемых реализаций компонентов Java EE, так как практическая сложность внедрения того или иного способа зависит от особенностей выбранной реализации, её производительности и расширяемости.
Исходя из общих соображений, реализация CRDT компонента как Enterprise Java Bean выглядит наиболее привлекательной, так как в таком случае становится возможным использовать компонент, не только через веб-сервис, но
IXМеждународная научно-практическая конференция и вызывать методы компонента через Remote Method Invocation (RMI) и Java Naming and Directory Interface (JNDI). Таким образом, один и тот же компонент может использоваться и в веб-приложении, и как внутреннее API для других компонентов. Также использование EJB позволяет дополнительно отделить логику представления (формирование ответа пользователю, которым чаще занимается сервлет) от собственно бизнес-логики CRDT.
Клиентская реализация CRDT может быть реализована как отдельный applet в браузере или как часть Java EE Application Client, запущенного на компьютерах пользователей. Выбор конкретного способа реализации зависит от поддерживаемых клиентских приложений.
Платформа .NET
Рассмотрим архитектуру платформы .NET 5 (новейшая версия .NET Framework) [15]. В .NET 5 входит фреймворк для разработки веб-приложений ASP.NET Core. При разработке с использованием ASP.NET Core по умолчанию используется модель MVC, однако согласно рекомендациям Microsoft для упрощения развития и поддержки приложения лучше использовать слоёную архитектуру. Выделяются 3 основных слоя: User Interface, Business Logic, Data Access [16].
Более того, для новых приложений на платформе ASP.NET рекомендуется использовать технологию Razor Pages[17]. Данная технология представляет собой альтернативу классическому шаблону MVC. Каждая страница Razor Pages состоит из файла с шаблоном разметки, и соответствующего класса-обработчика.
Тaким образом в серверной части ASP.NET приложения реализовать функции CRDT для нового приложения лучше всего путём создания отдельного модуля в слое Business Logic, а затем использовать этот модуль из обработчиков каждой Razor Page.
В клиентской части ASP.NET приложения реализовать функции CRDT можно как отдельный модуль, так же как и в предыдущих рассмотренных архитектурах.
«Инновационные аспекты развития науки и техники» Однако клиентскую часть ASP.NET приложения можно также реализовать
как wasm-модуль с использованием технологии Blazor WebAssembly (для
браузеров, поддерживающих стандарт WebAssembly). В этом случае становится
возможным переиспользовать логику CRDT в клиентской и серверной части так
как обе части могут быть написаны на одном и том же языке
программирования[ 18].
Server-side rendering (SSR) До сих пор мы рассматривали приложения с клиентской частью, хотя и Java EE и .NET 5 позволяют возвращать в качестве ответа сервера готовый HTML-документ, т.е. Осуществлять полный Server-Side Rendering. Тем не менее, большинство современных веб-сайтов используют возможности исполнения кода на стороне клиента (JavaScript)[19]. Наличие клиентской части веб-приложения позволяет обеспечить более качественный пользовательский опыт (UX), а именно возможность динамического обновления содержимого страницы без полной перезагрузки[20].
Однако такой подход повышает время загрузки приложения, так как браузер клиента должен осуществить ещё несколько запросов, прежде чем он сможет отобразить полное содержимое страницы. Это может стать проблемой если на клиентских устройствах недостаточно аппаратных ресурсов. Кроме того, время до того, как страница станет полностью активной может считаться одним из важнейших показателей для данного конкретного приложения (например, это время может влиять на позицию приложения в результатах выдачи поисковой системы).[21]
Для ускорения загрузки страницы используется подход Server-side Rendering (SSR) применительно к динамическим страницам. В рамках этого подхода перед отдачей страницы клиенту осуществляется пре-рендер страницы на сервере. То есть клиентский JavaScript-код выполняется на сервере, загружает необходимые динамический контент используя мощные аппаратные ресурсы сервера и лишь затем возвращает заполненную страницу клиентскому браузеру. SSR позволяет одновременно использовать преимущества серверной генерации
IXМеждународная научно-практическая конференция страниц (меньшая нагрузка на клиентскую часть, более короткое время до того
как страница станет активной[22]) и при этом сохранить все преимущества
динамических страниц. Предзаполненная страница может продолжать
динамически обновляться уже в браузере клиента (рис. 9).
Рис.9. Использование CRDT в рамках подхода SSR
Итоговые результаты анализа выделенных архитектур представлены в таблице (табл. 3).
Таблица 3. Результаты анализа архитектур клиент-серверных приложений
Номер Название архитектуры Рекомендуемое вид внедрения CRDT
6 Простое клиент-серверное приложение Клиентский модуль CRDT + серверный модуль CRDT
1 Клиент-серверное приложение с использованием СУБД Клиентский модуль CRDT + серверный модуль CRDT и/или модуль CRDT, встроенный в СУБД
4 Клиент-серверное приложение с использованием микросервисной архитектуры Клиентский модуль CRDT + Микросервис CRDT
«Инновационные аспекты развития науки и техники»
Продолжение Таблицы 3
2 FaaS клиент-серверное приложение Клиентский модуль CRDT + Использование модуля CRDT в каждой функции
3 Клиент-серверное приложение на платформе приложений уровня предприятия Java EE: CRDT-EJB + applet CRDT/Java EE Application Client .NET: использование модуля CRDT в каждой Razor Page + Blazor WebAssembly для клиентской части
5 Server-side rendering (SSR) Клиентский модуль CRDT + серверный модуль CRDT
Источник: анализ автора
Применение СЯСТ для решения общей задачи синхронизации пользовательских данных в клиент-серверной архитектуре
Для успешного внедрения СЯСТ требуется не только определить логическое место СЯСТ в архитектуре приложения, но и выбрать конкретную реализацию СЯСТ, подходящую под задачи приложения. Это является отдельной нетривиальной задачей так как выбор конкретной реализации СЯСТ сильно зависит от особенностей конкретной задачи, семантики данных. Не существует единой универсальной реализации СЯСТ. Поэтому выбор реализации СЯСТ для использования в клиент-серверных приложениях представляет собой отдельную задачу. Чтобы решить данную задачу не прибегая к рассмотрению каждого конкретного приложения, разделим все множество клиент-серверных приложений на некоторые классы. Основной критерий выделения отдельного класса — присутствие у каждого приложения класса схожих данных (структур) и способов их преобразования, таких что работу с этими структурами можно реализовать средствами одних и тех же реализаций СЯСТ. То есть другими словами цель состоит в выделении таких классов клиент-серверных приложений, что каждому приложению одного класса можно поставить в соответствие одно и то же множество реализаций СЯСТ, в той или иной степени подходящее для задач всех приложений этого класса. Стоит
IXМеждународная научно-практическая конференция отметить что такое разделение не производит непересекающиеся классы — то есть возможно присутствие многофункциональных приложений, принадлежащих сразу нескольким классам. Кроме того, данное разделение скорее всего не является исчерпывающим, то есть допускается наличие клиент-серверных приложений, не принадлежащих ни одному классу. Классификация всего множества клиент-серверных приложений представляет собой отдельную задачу. В данном случае цель классификации состоит в сопоставлении множества известных реализаций CRDT и множества часто возникающих задач клиент-серверных приложений. При этом для более универсальных решений стоит стремится к укрупнению классов. Ниже перечисленны полученные классы клиент-серверных приложений и соответствующие им реализации CRDT.
Приложения с отложенным множеством сущностей. Например, корзина товаров, список избранного, список отложенных фильмов, список задач, список заказов и так далее.
Отличительной особенностью данного класса приложений является именно семантика множества: элементы неупорядочены и не дублируются. Кроме того, с точки зрения бизнес-логики приложений при конфликтах одновременного удаления и добавления лучше использовать семантику addition wins (добавление выигрывает), так как в подобных списках важнее не потерять нужный элемент, чем показать пусть даже «лишний» (уже удаленный) элемент.
Однако, использование CRDT позволяет обойтись без ручного разрешения конфликтов. Для этого класса приложений подходит Observed-Removed Set (OR Set)[23]. Эта реализация CRDT соответствует семантике множества, относительно проста и при этом избегает некоторых странностей более ранних реализаций (например, в некоторых реализациях удаленный элемент невозможно повторно добавить в множество) [24]. OR Set также отдает приоритет операции добавления при параллельном добавлении и удалении. Внутренняя реализация использует присвоение каждому элементу множества уникального идентификатора, а подключенные клиенты передают друг другу и элементы, и свои идентификаторы при синхронизации.
«Инновационные аспекты развития науки и техники»
Приложения с коллаборативным редактированием. В данный класс
приложений входят приложения для общения с черновиками сообщений (например социальные сети, мессенджеры с поддержкой редактирования черновиков на нескольких устройствах), а также совместные заметки, совместно заполняемые формы, общие документы в различных приложениях.
Исторически это одна из самых старых и проработанных областей применения CRDT, список конкретных реализаций достаточно широк. Выбор реализации зависит желаемого соотношения качества работы и сложности — более универсальные и надежные реализации часто оказываются сложнее в разработке. Кроме того, реализации различаются поведением при различных пограничных случаях (одновременные вставки и удаления). В качестве относительно простой реализации имеет смысл выделить Replicated Growable Array[25]. Данная реализация представляет текст как связный список (Linked List), а для элементов списка вводится порядок через присваивание каждому элементу его временной метки (timestamp). Элементы списка представляют собой вносимые в текст изменения (отдельные символы, подстроки или даже встроенную графику).
Из более сложных реализаций можно рассмотреть возможность использовать Logoot[26] или Treedoc[27] — реализации на основе деревьев и непрерывных уникальных идентификаторов. При этом деревья представлены как CRDT-множества вершин и связей.
Приложения, хранящие количество быстро изменяющихся сущностей. Например, количество просмотров в социальной сети, количество добавлений в избранное у популярных статей, общая сумма очков в популярной игре.
Отличительной особенностью данного подкласса приложений является тот факт, что количество может изменятся только в одну сторону (только расти), при этом сами изменения могут быть очень частыми и со стороны большого числа клиентов. Для подобной семантики и высоких нагрузок идеально подходит CRDT Increment-Only Counter (G-Counter) — возрастающий счетчик [28][29]. Счетчик поддерживает только одну операцию — инкрементирование
IXМеждународная научно-практическая конференция (увеличение на единицу), а внутренняя реализация может использовать массив
по числу реплик или множество.
Приложения, хранящие новейшее значение. Например, время последнего изменения ресурса, а также любые значения, которые возможно обновлять параллельно нескольким клиентам в распределенном приложении (например, текущий назначенный исполнитель задачи, оценка задачи в часах и так далее).
Особенность данного класса приложений — более новые изменения значения должны перезаписывать более старые значения. Кроме того, возможно получить текущее актуальное значение. Эта задача решается в CRDT Last-Writer-Wins Register (LWW-Register) путем присваивания временных меток каждому обновлению значения [30]. При этом само обновляемое значение может быть любого типа.
Перечисленные простые реализации можно комбинировать в рамках полей специфичной для конкретного приложения структуры данных [31], получая в итоге различную логику слияния для полей разного типа и значения в соответствии с задачами приложения. Кроме того, одно и то же приложение может принадлежать нескольким классам и использовать все перечисленные реализации (например, корпоративная платформа с множеством функций).
Итоговые рекомендации реализаций CRDT для выделенных классов приложений представлены в таблице (табл. 4).
Таблица 4. Результаты классификации приложений
Класс приложений Примеры приложений Рекомендуемые реализации CRDT
Приложения с отложенным множеством сущностей Корзина товаров, список избранного, список отложенных фильмов, список задач, список заказов Observed-Removed Set (OR Set)
Приложения с коллаборативным редактированием Социальные сети, мессенджеры с поддержкой редактирования черновиков на нескольких устройствах, а также совместные заметки, совместно заполняемые формы, общие документы в различных приложениях Replicated Growable Array или Logoot/Treedoc (в зависимости от требований)
«Инновационные аспекты развития науки и техники»
Продолжение Таблицы 4
Приложения, хранящие количество быстро изменяющихся сущностей Количество просмотров в социальной сети, количество добавлений в избранное у популярных статей, общая сумма очков в популярной игре Increment-Only Counter (G-Counter)
Приложения, хранящие новейшее значение Время последнего изменения ресурса, а также любые значения, которые возможно обновлять параллельно нескольким клиентам в распределенном приложении (например текущий назначенный исполнитель задачи, оценка задачи в часах и так далее). Last-Writer-Wins Register (LWW-Register)
Заключение
В рамках статьи были разработаны релевантные классификации клиент-серверных приложений с точки зрения особенностей внедрения CRDT и выбора конкретной реализации CRDT. Полученные результаты приблизят широкое применение CRDT для задач типичных клиент-серверных приложений, с учётом используемых на практике технологий и новейших тенденций разработки и развёртывания клиент-серверных приложений. Открываются возможности дальнейшего подробного анализа других приложений, а также дальнейшего прототипирования.
Библиографический список:
1. Kong X., Liu L. A web application architecture framework //Australian World Wide Web Conference. - Norsearch Reprographics, 2004.
2. Haroon Shakirat Oluwatosin, Client-Server Model, IOSR Journal of Computer Engineering, Volume 16, Issue 1 (2014), стр. 67-71
3. Mike Loukides, Steve Swoyer, Microservices Adoption in 2020, [Электронный ресурс]: O'reilly Radar. Режим доступа: https://www. oreilly.com/radar/microservices-adoption-in-2020/ (дата обращения: 16.05.2021)
IX Международная научно-практическая конференция
4. Jeff Dean, Designs, Lessons and Advice from Building Large Distributed Systems, The 3rd ACM SIGOPS International Workshop on Large Scale Distributed Systems and Middleware (2009), Keynote #3, [Электронный ресурс]: ladis2009 keynotes. Режим доступа: http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf (дата обращения: 16.05.2021)
5. Официальная документация gRPC, [Электронный ресурс]: официальная документация gRPC. Режим доступа: https://grpc.io/docs/ (дата обращения: 16.05.2021)
6. J. Gibson, R. Rondeau, D. Eveleigh и Q. Tan, "Benefits and challenges of three cloud computing service models," 2012 Fourth International Conference on Computational Aspects of Social Networks (CASoN), 2012, стр. 198-205
7. Thomas Vitale, Cloud Native Spring in Action With Spring Boot and Kubernetes (MEAP), 2020, chapter 1.
8. P. Castro, V. Ishakian, V. Muthusamy и A. Slominski, "Serverless Programming (Function as a Service)," 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS), 2017, стр. 2658-2659
9. Enlyft, Companies using J2EE, [Электронный ресурс]: статистика компании Enlyft. Режим доступа: https://enlyft.com/tech/products/j2ee (дата обращения: 16.05.2021)
10. Java Platform, Enterprise Edition at a Glance, [Электронный ресурс]: официальный сайт Oracle. Режим доступа: https://www.oracle.com/ru/ java/technologies/java-ee-glance.html (дата обращения: 16.05.2021)
11. Введение в .NET, [Электронный ресурс]: официальная документация .NET. Режим доступа: https://docs.microsoft.com/ru-m/dotnet/core/introduction (дата обращения: 16.05.2021)
12. Java Enterprise System Architecture, Sun Java Enterprise System 2004Q2 Technical Overview, [Электронный ресурс]: 2004Q2 Technical Overview. Режим доступа: https://docs.oracle.com/cd/E19263-01/817-5764/architecture.html (дата обращения: 16.05.2021)
«Инновационные аспекты развития науки и техники»
13. Java EE Containers, [Электронный ресурс]: официальная документация Java EE 5. Режим доступа: https://docs.oracle.com/javaee/5/tutorial/doc/bnabo.html (дата обращения: 16.05.2021)
14. Web Applications, [Электронный ресурс]: официальная документация Java EE 7. Режим доступа: https://docs.oracle.com/javaee/7/tutorial/webapp 001.htm#GEYSJ (дата обращения: 16.05.2021)
15. Архитектурные компоненты .NET, [Электронный ресурс]: официальная документация .NET. Режим доступа: https://docs.microsoft.com/ru-ru/dotnet/standard/components (дата обращения: 16.05.2021)
16. Общие архитектуры веб-приложений, [Электронный ресурс]: официальная документация .NET. Режим доступа: https://docs.microsoft.com/ru-ru/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures (дата обращения: 16.05.2021)
17. Разработка приложений MVC ASP.NET Core, [Электронный ресурс]: официальная документация .NET. Режим доступа: https://docs.microsoft.com/ru-ru/dotnet/architecture/modern-web-apps-azure/develop-asp-net-core-mvc-apps (дата обращения: 16.05.2021)
18. Введение в ASP.NET Core Blazor, [Электронный ресурс]: официальная документация .NET. Режим доступа: https://docs.microsoft.com/ru-ru/aspnet/core/blazor/?view=aspnetcore-5.0 (дата обращения: 16.05.2021)
19. W3Techs, Usage statistics of JavaScript as client-side programming language on websites, [Электронный ресурс]: статистика компании w3Techs. Режим доступа : https://w3techs.com/technologies/details/cp-javascript (дата обращения: 16.05.2021)
20. P. Kishore, Mahendra B.M. Evolution of Client-Side Rendering over ServerSide Rendering, recent Trends in Information Technology and its Application, vol.3, no.2 (2020).
21. Addy Osmani, Ilya Grigorik, Speed is now a landing page factor for Google Search and Ads, Web Updates 2018 (July), [Электронный ресурс]: технические
IX Международная научно-практическая конференция новости компании Google. Режим доступа: https://developers. google.com/web/updates/2018/07/search-ads-speed (дата обращения: 16.05.2021)
22. Taufan Fadhilah Iskandar и другие, Comparison between client-side and server-side rendering in the web development, IOP Conference Series: Materials Science and Engineering, vol. 801 (2019)
23. Bieniusa A. и другие, An optimized conflict-free replicated set [Research Report] RR-8083, Inria - Centre Paris-Rocquencourt; INRIA. 2012, стр. 3.
24. Gene T. J. Wuu и Arthur J. Bernstein. Efficient solutions to the replicated log and dictionaryproblems. InSymp. on Principles of Dist. Comp. (PODC), стр. 233242, Vancouver, BC, Canada, 1984.
25. Roh H. G. И другие. Replicated abstract data types: Building blocks for collaborative applications //Journal of Parallel and Distributed Computing. - 2011. -Т. 71. - №. 3. - С. 354-368.
26. Weiss S., Urso P., Molli P. Logoot: A scalable optimistic replication algorithm for collaborative editing on p2p networks //2009 29th IEEE International Conference on Distributed Computing Systems. - IEEE, 2009. - С. 404-412.
27. Pregui?a N. et al. A commutative replicated data type for cooperative editing //2009 29th IEEE International Conference on Distributed Computing Systems. -IEEE, 2009. - С. 395-403.
28. Cabrita G. M. Non-uniform replication for replicated objects : дис. - 2017.
29. Shapiro M. И другие. Conflict-free replicated data types //Symposium on Self-Stabilizing Systems. - Springer, Berlin, Heidelberg, 2011. - С. 386-400.
30. P. R. Johnson and R. H. Thomas. The maintenance of duplicate databases. Internet Request for Comments RFC 677, Information Sciences Institute, Jan. 1976.
31. Evan Wallace, How Figma's multiplayer technology works, [Электронный ресурс]: блог компании Figma. Режим доступа: https://www.figma.com/blog/how-figmas-multiplayer-technology-works/ (дата обращения: 16.05.2021)
