Комментарии

Распределенные системы лежат в основе большинства современных приложений — от облачных сервисов до финансовых платформ и социальных сетей. Проектирование сопряжено с рядом сложных компромиссов, особенно когда речь идет о согласованности данных, доступности системы и устойчивости к сетевым сбоям.

Теорема CAP (дословно: Consistency (согласованность), Availability (доступность), Partition Tolerance (устойчивость к разделению)), предложенная Эриком Брюером в 2000 году, объясняет, почему невозможно одновременно обеспечить все три этих свойства.

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

Да, многие могут сказать, что это больше стезя архитектора. Но грань между аналитиком и архитектором в текущих реалиях очень смазана. Хороший системный аналитик фактически является lite версией архитектора. Поэтому щас выскажусь!)))

Почему нельзя иметь всё сразу?

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

Физические ограничения сети

Распределенные системы состоят из множества узлов, которые взаимодействуют через сеть. Сеть это ненадежная среда, подверженная потере пакетов и полному разрыву соединений. Эти проблемы делают невозможным одновременное обеспечение согласованности и доступности.

Противоречие между согласованностью и доступностью

Согласованность требует, чтобы все узлы имели одинаковое представление о данных. Это достигается за счет координации между узлами, которая становится невозможной при разрыве связи.

Доступность предполагает, что система всегда отвечает на запросы, даже если данные временно несогласованны. Это означает, что система может продолжать работать, но рискует предоставить устаревшие или конфликтующие данные.

Устойчивость к разделению как обязательное требование

Теорема CAP утверждает, что в реальных системах невозможно игнорировать устойчивость к разделению. Любая распределенная система должна быть готова к сетевым сбоям, так как они неизбежны в современных условиях.

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

Практический пример

Рассмотрим базу данных, используемую в системе онлайн-банкинга:

— Если выбрать согласованность (Consistency), то при сетевом сбое система заблокирует транзакции до тех пор, пока связь не будет восстановлена. Это гарантирует, что данные о балансах всегда точны, но может привести к недоступности системы для пользователей.

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

Как аналитик выбирает, чем пожертвовать?

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

1. Анализуем бизнес-требования

— Критичность данных: Насколько важно, чтобы данные всегда были согласованными? Например, в финансовых системах ошибки в данных могут привести к серьезным последствиям.

— Допустимость простоев: Готов ли бизнес терпеть временную недоступность системы ради сохранения согласованности?

— Вероятность сетевых сбоев: Насколько часто происходят сетевые сбои в текущей инфраструктуре?

2. Изучаем пользовательские ожидания

— Опыт пользователей: Как пользователи реагируют на задержки или временные несоответствия в данных? Например, пользователи интернет‑магазина могут мириться с небольшими несоответствиями, но клиенты банков ожидают максимальной точности.

— Частота взаимодействий: Насколько часто пользователи взаимодействуют с системой? Чем чаще взаимодействия, тем важнее доступность.

3. Оцениваем технические возможности

— Технологии и инструменты: Какие базы данных и технологии поддерживают выбранный компромисс? Например, реляционные базы данных лучше подходят для обеспечения согласованности.

— Сложность реализации: Насколько сложно реализовать выбранный подход? Например, использование eventual consistency требует дополнительных механизмов для синхронизации данных.

4. Принимаем решение

— Создание матрицы приоритетов: Аналитик составляет таблицу, где каждому свойству (Consistency, Availability, Partition Tolerance) присваивается вес в зависимости от его важности для бизнеса и пользователей.

— Обсуждение с заинтересованными сторонами: Решение принимается совместно с бизнесом и разработчиками, чтобы учесть все точки зрения.

Пример выбора

Рассмотрим две гипотетические системы:

— Система управления авиаперелетами:

— — Приоритет: Consistency (согласованность).

— — Обоснование: Продажа одного и того же места нескольким пассажирам недопустима. Система должна гарантировать точность данных, даже если это приведет к временной недоступности.

— Система электронной торговли:

— — Приоритет: Availability (доступность).

— — Обоснование: Пользователи ожидают, что сайт всегда работает, даже если данные о наличии товаров временно несогласованны. Ошибки можно исправить позже (например, через возврат средств).

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

Что в итоге?

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

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

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

Вот список бед на кроссплатформе, которые на поздней стадии сожрут больше денег, чем на старте:

— Уменьшить потребление памяти и пакета приложения
— Избавиться он лагов анимации
— Снизить влияние на батарею
— Прокачать производительность
— Отполировать тач-интерфейс
— Техдолг. Кроссплатформенный код обрастает им значительно быстрее
— Прикрутить функциональность с интенсивными вычислениями на процессоре или видеоядре
— Ликвидация пойманных багов внутри кроссплатформенных библиотек. (Airbnb устав ждать багфиксы Facebook сама контрибьютила в исходный код RN и создавала сопутствующую инфраструктуру. А вам это надо?)
— Кадры.
— и это далеко не всё.

Хорошая статья. От себя добавим. Выпускать приложения для лишь одной мобильной платформы – не актуально и нужно заботиться о разработке сразу двух версий, для iOS и Android. И здесь можно выбрать два пути: работать на «нативных» языках программирования для каждой операционной системы или использовать кроссплатформенные фреймворки.

При разработке одного из проектов в компании DD Planet я сделал ставку на последний вариант. И в этой статье расскажу об опыте разработки кроссплатформенного приложения, проблемах, с которыми мы столкнулись, и найденных решениях.

Три подхода в разработке кроссплатформенных мобильных приложений

Для начала рассмотрим, какие подходы используются, когда нужно получить сразу два приложения: под iOS и Android.

Первый – cамый затратный, как по времени, так и по ресурсам: разработка отдельного приложения для каждой из платформ. Сложность этого подхода заключается в том, что каждая из операционных систем требует своего подхода: это выражается как в языке, на котором ведется разработка (для Android – Java или Kotlin, для iOS – Objective-C или Swift), так и способах описания UI части приложения (axml и xib или storyboard файлы соответственно).

Уже этот факт подводит нас к тому, что для такого подхода необходимо формирование двух команд разработчиков. Помимо этого придется дублировать логику для каждой из платформ: взаимодействие с api и бизнес-логику.

А что, если количество используемых API будет расти?
Из этого возникает вопрос: как уменьшить необходимое количество человеческих ресурсов? Избавиться от необходимости дублировать код для каждой платформы. Существует достаточное количество фреймворков и технологий решающих эту задачу.

Использование кроссплатформенного фреймворка (Xamarin.Forms, например) дает возможность писать код на одном языке программирования и описать логику данных и логику UI один раз, в одном месте. Поэтому необходимость использовать две команды разработчиков отпадает. А по итогу компиляции проекта на выходе получаем два нативных приложения. И это – второй подход.

Многие, думаю, знают, что такое Xamarin, или хотя бы слышали о нем, но как это работает? Xamarin основан на open-source реализации платформы .NET — Mono. Mono включает в себя собственный компилятор C#, среду выполнения, а также ряд библиотек, включая реализацию WinForms и ASP.Net.

Цель проекта — позволить запускать программы, написанные на C#, на операционных системах, отличных от Windows — Unix-системах, Mac OS и других. Сам же фреймворк Xamarin, по сути своей – библиотека классов, предоставляющей разработчику доступ к SDK платформы и компиляторы для этих них. Xamarin.Forms, в свою очередь, позволяет не только писать под обе платформы на одном языке, но проектировать дизайн экранов с использованием XAML разметки, привычной тем, кто уже имел опыт работы с WPF приложениями. В итоге сборки проекта получаем практически идентичный вид на всех платформах, так как на этапе компиляции все XF контролы преобразовываются в нативные для каждой платформы.

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

Один язык программирования, мало кода и так далее. Все это звучит красиво но, Xamarin.Forms – не серебряная пуля, и вся его красота разбивается о камни реальности. Как только возникает ситуация, когда встроенные в XF-контролы уже не отвечают предъявленным к ним требованием, структура экранов и контролов становится всё сложнее и сложнее. Для обеспечения комфортной работы с экранами из общего проекта приходится писать все больше и больше кастомных рендеров.

На этом перейду к третьему подходу, который мы и используем при разработке приложений.

Мы уже выяснили, что использование Xamarin Forms может осложнить работу, а не упростить ее. Поэтому для реализации архитектурно сложных экранов, дизайнерских элементов и контролов, кардинально отличающихся от нативных, нашелся компромисс и возможность объединения первого и второго подхода.

Имеем все те же три проекта: общий PCL проект, но уже без Xamarin Forms, и два проекта Xamarin Android и Xamarin iOS. По-прежнему имеется возможность писать всё на одном языке, общая логику между двумя проектами, но нет ограничений единой XAML разметки. UI-составляющая контролируется каждой из платформ и использует нативные средства, на Android – нативный AXML, на iOS – XIB-файлы. Каждая платформа имеет возможность соблюдать свои гайдлайны, так как связь между Core и платформенными проектами организовывается только на уровне данных.

Для организации такой связи можно использовать паттерн проектирования MVVM и достаточно популярную его реализацию для Xamarin – MVVMCross. Его использование позволяет держать общую ViewModel для каждого экрана, где описана вся “бизнес-логика” работы, а его отрисовку доверить платформе. Так же это позволяет двум разработчикам работать с одним и тем же экраном (один с логикой — другой с UI) и не мешать друг другу. Кроме реализации паттерна, получаем достаточное количество инструментов для работы: реализация DI и IoC. Для подъема взаимодействия с платформой на уровень общего кода разработчику достаточно объявить интерфейс и реализовать его на платформе. Для типовых вещей MvvmCross уже предоставляет набор собственных плагинов. В команде мы используем плагин мессенджера для обмена сообщениями между платформой и общим кодом и плагин для работы с файлами (выбор изображений из галереи и др.).

Кроссплатформенная разработка позволяет сэкономить время и деньги;

Создавать приложение со сложным дизайном удобнее, описывая его на платформе, а не в общем коде;

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

Абсолютное позиционирование и ленивая инициализация позволяют реализовывать сложные и ресурсоемкие экраны;

SignalR – удобное решение для двустороннего клиент-серверного взаимодействия в реальном времени;

При обновлении данных в реальном времени нельзя мешать пользователю взаимодействовать с приложением;

Взгляд на проблему под разными углами позволяет найти удачное, а иногда и необычное, решение;

Используйте десятки контроллеров на одном экране, устанавливайте несколько SignalR-соединений, переворачивайте экраны, пишите код, оптимизируйте, экспериментируйте.

Если говорить о масштабирование DST Store в DST маркетплейс то любая версия DST Store может обновиться до DST Marketplace без остановки работы сайта.

База данных и структура у них одна и та же, поэтому не нужно менять товары или дизайн.

Оплата и переход на новую лицензию. Для перехода на DST Marketplace нужно написать куратору и доплатить разницу. Разница составляет примерно 400 000 рублей.

Никаких сверх оплат не будет.

Также переход на маркетплейс можно сделать в любой момент, независимо от срока давности.

Кстати возможно потребуется расширение сервера, что можно сделать бесплатно в DST.

Если говорить о масштабирование DST Store в DST маркетплейс то любая версия DST Store может обновиться до DST Marketplace без остановки работы сайта.

База данных и структура у них одна и та же, поэтому не нужно менять товары или дизайн.

Оплата и переход на новую лицензию. Для перехода на DST Marketplace нужно написать куратору и доплатить разницу. Разница составляет примерно 400 000 рублей.

Никаких сверх оплат не будет.

Также переход на маркетплейс можно сделать в любой момент, независимо от срока давности.

Кстати возможно потребуется расширение сервера, что можно сделать бесплатно в DST.

Если говорить о масштабирование DST Store в DST маркетплейс то любая версия DST Store может обновиться до DST Marketplace без остановки работы сайта.

База данных и структура у них одна и та же, поэтому не нужно менять товары или дизайн.

Оплата и переход на новую лицензию. Для перехода на DST Marketplace нужно написать куратору и доплатить разницу. Разница составляет примерно 400 000 рублей.

Никаких сверх оплат не будет.

Также переход на маркетплейс можно сделать в любой момент, независимо от срока давности.

Кстати возможно потребуется расширение сервера, что можно сделать бесплатно в DST.

Если говорить о масштабирование DST Store в DST маркетплейс то любая версия DST Store может обновиться до DST Marketplace без остановки работы сайта.

База данных и структура у них одна и та же, поэтому не нужно менять товары или дизайн.

Оплата и переход на новую лицензию. Для перехода на DST Marketplace нужно написать куратору и доплатить разницу. Разница составляет примерно 400 000 рублей.

Никаких сверх оплат не будет.

Также переход на маркетплейс можно сделать в любой момент, независимо от срока давности.

Кстати возможно потребуется расширение сервера, что можно сделать бесплатно в DST.

Да, перейти с DST Store на DST Marketplace можно без дополнительных затрат. Для этого необходимо выполнить следующие шаги:

Для этого нужно написать своему куратору, который работает с вами, о желании перейти с одной лицензии на другую.

Доплатить разницу в стоимости между лицензиями.

Важно отметить, что никаких сверх оплат с вас никто не возьмёт.

Да, перейти с DST Store на DST Marketplace можно без дополнительных затрат. Для этого необходимо выполнить следующие шаги:

Для этого нужно написать своему куратору, который работает с вами, о желании перейти с одной лицензии на другую.

Доплатить разницу в стоимости между лицензиями.

Важно отметить, что никаких сверх оплат с вас никто не возьмёт.

Да, перейти с DST Store на DST Marketplace можно без дополнительных затрат. Для этого необходимо выполнить следующие шаги:

Для этого нужно написать своему куратору, который работает с вами, о желании перейти с одной лицензии на другую.

Доплатить разницу в стоимости между лицензиями.

Важно отметить, что никаких сверх оплат с вас никто не возьмёт.

Да, перейти с DST Store на DST Marketplace можно без дополнительных затрат. Для этого необходимо выполнить следующие шаги:

Для этого нужно написать своему куратору, который работает с вами, о желании перейти с одной лицензии на другую.

Доплатить разницу в стоимости между лицензиями.

Важно отметить, что никаких сверх оплат с вас никто не возьмёт.

Мы сейчас работаем напряму с клиентами сами, но в дальнейшем планируем привлечь поставщиков и вырасти до маркетплейса. Можно ли перейти с DST Store на DST Marketplace без дополнительных затрат?

Мы сейчас работаем напряму с клиентами сами, но в дальнейшем планируем привлечь поставщиков и вырасти до маркетплейса. Можно ли перейти с DST Store на DST Marketplace без дополнительных затрат?

Мы сейчас работаем напряму с клиентами сами, но в дальнейшем планируем привлечь поставщиков и вырасти до маркетплейса. Можно ли перейти с DST Store на DST Marketplace без дополнительных затрат?

Мы сейчас работаем напряму с клиентами сами, но в дальнейшем планируем привлечь поставщиков и вырасти до маркетплейса. Можно ли перейти с DST Store на DST Marketplace без дополнительных затрат?

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

— Тематические доски объявлений: Ориентированные на конкретные ниши (недвижимость, авто, работа, цифровые товары и т.д.).
— Региональные доски объявлений: Сосредоточенные на конкретных географических регионах.
— Рынки, связанные с инновациями: Технологии, электронная коммерция, зелёная энергетика, здоровье и фитнес.

Ну а для быстрого запуска и эффективного управления доской объявлений рекомендуется использовать платформы, такие как DST Доска объявлений, которые предоставляют широкий функционал, интуитивно понятный интерфейс и возможности для масштабирования бизнеса.

Современные ИТ-системы, характеризующиеся сложными, взаимосвязанными и облачными архитектурами, подвержены различным типам инцидентов, начиная от сбоев оборудования и заканчивая проблемами с облачными сервисами. Эти инциденты могут серьезно повлиять на доступность сервисов и доходы. Эффективное управление ИТ-инцидентами, включающее централизованную регистрацию и отслеживание, необходимо для быстрого восстановления нормальной работы.

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

Развитие современных ИТ-систем неизбежно ведет к усложнению их архитектуры и увеличению количества потенциальных точек отказа. В этих условиях традиционные подходы к управлению инцидентами уже не способны обеспечить необходимый уровень надежности и доступности сервисов.

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

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

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

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

Современные ИТ-инфраструктуры представляют собой сложные экосистемы, где каждый компонент тесно взаимосвязан с остальными, и сбой в одном месте может привести к каскадному эффекту, затрагивающему всю систему в целом.

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

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

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