Комментарии

Недавно я запустил MVP маркетплейса. В отличие от многих, я выбрал WordPress с WooCommerce и добавил плагины для поддержки мультивендорности. Это оказалось бюджетным решением, но потребовало много времени на интеграцию. Позже выяснилось, что WooCommerce — это не самый удачный выбор. В личном кабинете поставщика нет важных функций: нет информации о комиссиях, уведомлений, фильтров в каталоге. Система доставки тоже статичная, а не через API. Я не уделил достаточно внимания изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

Главный вывод: даже для MVP лучше сразу заложить достаточную сумму и тщательно выбрать систему. Сейчас я работаю с ДСТ Платформ. Это дороже, но первые продажи начались уже через месяц после запуска. Такой подход действительно работает, и в движке есть всё, что нужно.

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

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

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

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

— хранение данных должно происходить распределённо, то есть внутри сети, которая состоит из нескольких ЭВМ, несмотря на то, что сами файлы могут быть достаточно большими;

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

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

Как правило, реляционные базы выбирают для работы со сложными запросами и обработки рутинных задач. И здесь следует учесть вот что: SQL-базы масштабируются по вертикали, то есть с помощью увеличения нагрузки на отдельный конкретный сервер. В свою очередь, NoSQL-базы хорошо масштабируются по горизонтали за счёт увеличения количества серверов, что является весьма удобным при работе с большими объёмами данных, так называемыми Big Data.

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

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

Среди некоторых из популярных нереляционных баз можно перечислить: MongoDB, Apache Cassandra, Couchbase.

давайте оставим авиакомпании, там все понятно, но по 3му пункту уточню: я нигде не пытался «опровергнуть CAP» — наоборот, в рамках имеющихся ограничений физического мира инженеры придумали как их можно «почти обойти» — и для подавляющего большинства бизнес кейсов можно сказать что «Spanner поборол CAP теорему» — и это будет почти правда с практической точки зрения и оговоркой что относительно небольшая часть данных может быть недоступна относительно короткие промежутки времени.

Хм. Очень интересный комментарий. Попробую по пунктам.
1. Здесь на самом деле парадоксальная ситуация. Теоретически они должны выбирать CP, чтобы гарантировать точность данных и избежать продажи одного и того же места нескольким пассажирам. Практически они выбирают AP, чтобы обеспечить высокую доступность и работоспособность в условиях сложных взаимодействий между глобальными и локальными системами. Это как бы не противоречит CAP. Скорее показывает практическое применение.

2. Да, все верно. Многие компании продают билеты сверх лимита на досадку, основываясь на статистике. Здесь двоякая ситуация. С одной стороны бизнес-решение, а с другой можно рассматривать, то фактически является способом адаптации к невозможности обеспечить строгую согласованность в распределённой системе. И демонстрирует, как бизнес-процессы могут дополнять технические решения, чтобы минимизировать последствия ограничений, описанных в теореме CAP.

3. Агась! Но это скорее не опровержение теоремы, а отличная демонстрация, как технологии развиваются. Spanner — отличный пример минимизации ограничений, описанных в CAP. При этом CAP не утверждает, что невозможно достичь всех трех свойств вообще. Теорема говорит, что невозможно гарантировать их одновременно в любых условиях. Spanner достигает всех трех свойств в подавляющем большинстве случаев, но допускает временные потери Availability в экстремальных условиях.

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

Во вторых, некоторые авиакомпании(особенно в штатах) осознанно делают overbooking(продажи нескольких билетов на одно место), потому что статистически какой то % народа не является на посадку и тогда все хорошо. Если на посадку приходят все, то предлагают деньги желающим за то чтобы «полететь завтра», а если все хотят «полететь сегодня» — рандомно выбирают неудачников и советуют почитать что написано мелким шрифтом в соглашении по покупке билета.

Ну и третьих, оно же главное: принцип CAP был сформулирован 25 лет назад и с той поры лучшие инженеры потратили много сотен тысяч часов для того чтобы этот принцип обойти — и это получилось. Это Cloud Spanner от гугла. Если коротко, то там придумали как выкрутиться и нашли компромис который (почти)гарантирует все 3 свойства CAP в подавляющем числе случаев использования, ослабляю гарантии по Availability с существенными оговорками.

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

Теорема 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 без дополнительных затрат?