Комментарии

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

В 2022 году мы решили изменить подход и перейти на решение «Сотбит» от «Битрикса». Мы продолжали работать над проектом, но столкнулись с отсутствием технической поддержки после продажи. Мы поняли, что проблема не только в сложности системы, но и в том, что наш маркетплейс не выдерживает нагрузок. Даже с небольшим количеством товаров и трафика система работала нестабильно.

Оптимизация базы данных и серверов не принесла результатов. Мы обратились к специалистам, которые подтвердили, что проблема в самой платформе «Битрикс».

В 2023 году мы перешли на CS Cart. Сначала всё шло хорошо, мы даже приобрели версию «Энтерпрайз». Однако через полгода работы с техподдержкой и разработчиками мы столкнулись с серьёзными проблемами. Разработчики сообщили, что в движке много проблемного кода, который нужно переписать для работы с 100 000 товаров. Ошибки и сбои в системе стали ежедневным явлением, а импорты, экспорты и доставки не работали должным образом.

Измотанными мы решили обратиться к другому решению. Сейчас мы работаем на ДСТ Маркетплейс. Здесь нас радует бесплатная техническая поддержка, в отличие от CS Cart, где поддержка платная и не всегда доступна. Мы заплатили за CS Cart 1,2 миллиона рублей, но получили движок с множеством ошибок. За ДСТ Маркетплейс мы заплатили 650 тысяч рублей, и он работает без проблем.

Запуская MVP, важно тщательно выбирать не только платформу для работы, но и техническую поддержку. Даже если у вас есть свои разработчики, поддержка всё равно необходима.

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

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

Я не уделил достаточно времени изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

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

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

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

Я не уделил достаточно времени изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

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

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

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

Я не уделил достаточно времени изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

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

Основная проблема не в этом а в том что все это прибито намертво гвоздями в ядре.

В тем проблема вынести это в отдельный service provider и дать выбор пользователю самому решить где и что в каком виде хранить?

В итоге приходиться делать патч на ядро а это боль и при обновлении все это слетит.

И ещё у Laravel странное поведение кеша. А ещё постоянные с архитектурой. Например, то мы модели в одном месте храним, то в другом, то снова в первом.

вот поддержал бы, последний год проект вели на Yii2, всё отлично было
в этом решили сделать его форк на Laravel, сделав упор на оптимизацию, переписав логику, упростив процессы и после Yii2 Лара просто вызывает удивление. Yii2 из коробки убирает возню с маршрутами, с генерацией CRUD, простое введение ролей в проект за счёт RBAС, валидация простая и понятная, шаблоны в плане синтаксиса как-то поаккуратнее шаблонов блейда выглядят. В Ларе мы успели и с путями покуролесить, и с валидацией поморочились, и CRUD-генератор, который варит контроллеры/модели/формы, тоже искали. В Ларе строка текста, которая имеет переводы, выглядит как __('admin.Enter name'), к нам подходил джун, спрашивал, что это за «магические методы у нас в формах, я не знаю, как такое гуглить»))
Да, мы потом со всем разобрались и настроили, но Yii2 из коробки в плане документации и удобства выглядит как зрелый, цельный фреймворк, а Лара как хайп-фреймворк, который дёргал с миру по нитке + такое ощущение, что эти люди страшно скучали по разработке на javasript)
п.с: хотя у этих фреймворков, скорее, разные назначения и возможности, но вот как раз в плане удобства Yii2 как раз, имхо, максимально удобен, а на основные вещи есть даже актуальная документация на русском

А мне после Yii2 Laravel кажется жутко неудобным. Особенно после AR и Yii2-debug. Но это всё дело вкуса.
>Laravel хорош для новичка
О да, то, что новички вытворяют на Laravel, такого ужаса на Yii мне не встречалось. Кстати, документация у Yii2, как по мне, более удобная и информативная.

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

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

Laravel хорош для новичка — все из коробки, просто развернуть, просто работать — но как только появляется необходимость что-то поменять в ядре — жизнь боль, Job's если поменять параметры конструктора — тоже валяться на раз два. При работе с миграциями — необходимо быть предельно осторожным.

Symfony — монстр с решениями на все случаи жизни, но на его изучение также придется потратить пару жизней.

Zend — раньше жил только за счет его форса ZendFoundation и был жутко неудобной страшной штукой. Сейчас (Laminas) даже не смотрел.

Yii — Собран на коленке для создания проектов на коленке, после laravel покажется жутко не удобным.

Phalcon — был актуален на php5.6 так как работал намного быстрее всего что было тогда — за счет того что ядро скомпилировано как плагин php. При php >= 7.0 уже почти не имеет смысла так как из самого php выжали почти все возможное и теперь дожимают остальное.

Все остальное — уже жуткий legacy — проще с нуля собрать свой фреймворк с помощью php-di

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

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

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

Недавно я запустил 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, заставляет внимательно взвешивать компромиссы, исходя из требований бизнеса и ожиданий пользователей.

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