Открыть список
Как стать автором
Обновить

Комментарии 16

Отличный материал! Как глоток свежего воздуха — уже и не ожидаешь увидеть что-то за пределами Microservices and APIs are web-scale. Вопрос: какие уже существующие продуктовые решения вы могли бы отнести к той или иной категории? Например, где на вашей карте находится платформа SAP HANA. Спасибо!
НЛО прилетело и опубликовало эту надпись здесь
HANA это очень хороший пример архитектуры, комплексный, состоящий из сервера приложений, СУБД, веб-сервера. Но я не специалист в SAP и глубоко не расскажу, а что точно понятно, что все компоненты там работают отдельно, как разные службы, без встраивания, о котором я пишу в статье, и такое решение застряло в середине нулевых годов, хотя, на то время было очень передовым. Разные процессы требуют постоянного межпроцессового взаимодействия, а это не только существенная потеря ресурсов, но и ограничения, например, сервер приложений должен дублировать в модель предметной области в памяти, а вообще она в БД хранится, так зачем же дублировать и синхронизировать. Все идет к интеграции.

Как по мне, то database-centric решения очень нишевые, будущее вижу в event-based распределенных сетях, почти одноранговых, где часть нод берут на себя роль глобальных координаторов и "числодробилок". К событиям, похоже, можно свести и все остальные варианты в рамках, как говорится, "современной элементной базы", разница лишь в том, какие части распределенного приложения будут эмитировать события, а какие слушать и обрабатывать, насколько высоко в иерархии архитектурных сущностей отдельных процессов будут подниматься в виде каких-то абстрактных событий такие реальные события как приход пакета по сети или совершения пользователем действия типа нажатия клавишы.

Про QNX непонятно, поясните, к чему она тут?
Микро-сервисная архитектура ОС и обмен сообщениями, как основной механизм взаимодействия между ними. А вообще: идеальная система — это та, которой физически не существует, а функции её выполняются!

На самом деле при повседневной текучке задач не сильно успеваешь задуматься куда мы идем.
Интересно разнести то что мы видим и используем в жизни в такую систему.


№0 Data files

Любимые всеми таблички Excel


№1 File-server

Ранее были очень популярные MS Access, FoxPro — базы данных интегрированные в приложение. Можно сказать что это движок базы данных с интерфейсом вшытым в нее.


№2 Local DB

В этом сегменте прошло мое отрочество — BDE и иже с ним.


№3 Client-Server

Большинство старых бизнес приложений, всё работающее в связке с MS SQL. Собственно большинство приложений работающих с локальной базой при росте количества пользователей мигрировали в этот режим работы.


№4 Three-tier

Большинство современных бизнес приложений (это в том числе и 1С и всевозможные клиенты к разнообразным промышеленным системам). Это просто колосальный по обьемам пулл приложений, обслуживающих заводы, общепит, производства, трубопроводы...


№5 Web-client

тут живет большая часть вэба — всевозможные php с wordpress (с колосальной долей сайтов в интернете)


№6 Web 2.0

мир открытый для меня первыми версиями gmail, с jquery и вереницами ajax запросов. Все сайты из №5 которые научились взаимодействовать с пользователями. Те же форумы, трекеры.


№7 SPA/WebApp

тут мы живем сейчас, Angular 2, React. Весьма уютное место на самом деле.


№8 PWA & Mobile

Сюда мы стремися попасть, добавляя PouchDB, FireBase etc.


Database-centric P2P Network — нечто похожее предсавляет из себя Эфириум с его смарт-контрактами

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Подскажите, пожалуйста? (Я серьёзно).
Много думал.
Попытался «натянуть» варианты #A, #B, #C and #D на ERP системы (ими занимаюсь) — не получилось.
Все варианты не полностью соответствуют задачам.

Больше всего сомнений в месте, где надо располагать логику. Если её писать и на клиенте и на сервере — очень быстро начинаются большие проблемы. В варианте #D вся логика на сервере, но зачем в ERP Peer-to-Peer — не понятно. В остальных вариантах логика и там и там и это может создать сложности.
Хотя если сделать вариант с «синхронизацией» части логики между сервером и клиентом — это может быть интересно. Описываешь всю логику на сервере, но часть из нее (например, первичная проверка данных) автоматом переносится в клиентское приложение и выполняется там…

С локальными DB тоже много вопросов. Выгрузить на клиента тот же справочник номенклатуры, если там сотни тысяч позиций — сомнительный вариант. Выгрузить частично — но тогда что именно выгружать и усложняется логика работы со справочниками.
Можно локально хранить данные об открытом / редактируемом документе, но это обычно небольшой кусок данных, и не очень понятно, насколько хранение таких данных поможет…

Вычисления на клиенте — возможно. Но точно не в самом клиентском приложении, а что то вроде распределенной вычислительной среды вполне можно использовать. Но в ERP потребность в таких вычислениях не очень часто встречается, и при этом обычно надо обрабатывать большие объемы данных — забьется канал.
В варианте #D есть логика и на клиенте и на сервере, он от варианта #B отличается только одноранговым взаимодействием клиентов и дополнительной функцией сервера — быть брокером в одноранговом взаимодействии.

Вообще, конечно, для ERP лучше разделить логику, что и предложено в «Hybrid Application». С разной пропорцией можно выделить:
— Логику модели (она запускается и на клиенте и на сервере, там, где работает модель)
— Логику бизнес-процессов (которую для ERP удобнее реализовывать на сервере)
— Логику интерфейса (которая запускается только на клиенте и абстрагирована от прочей логики)
И эти три вещи не можно так построить, что они не будут пересекаться и «знать» друг о друге.
Уже много раз сталкивался с граблями при разделении логики на разные виды.
Например, описали логику проверки корректности вводимых данных в интерфейсной форме (ведь при ошибке надо выдать пользователю предупреждение — значит логика интерфейса). Потом, например, реализуем загрузку тех же данных в пакетном режиме и тоже пишем ту же логику проверок. И после нескольких модификаций наборы правил проверки не полностью совпадают, и у нас труднодиагностируемый глюк в данных…
Если Вам не удавалось разделить логику, более того, если бы даже это не удавалось ни кому, то это не значило бы, что этого сделать нельзя. Но, поверьте, удавалось. Например, логика корректности разделяется на две части, собственно правила корректности и алгоритм применения правил к данным. Правила пишутся в формате метаданных (не обязательно только декларативные, метаданные могут содержать и функции) и помещается в метамодель (схему) предметной области. Алгоритм же пишется 2 раза (и она действительно разный), один раз для применения правил к UI, второй — для применения правил к данным на сервере приложений для пакетной обработки. Может быть и третья реализация, для применения правил к данным в СУБД. Не вижу тут сложностей, честное слово.
Сама по себе принципиальная возможность разделения логики сомнения не вызывает. Но хорошей реализации такого разделения я пока не видел.
Причина в том, что логика может быть достаточно сложной. Например, было простое предупреждение, что заказ нельзя отгрузить, так как у клиента недостаточно кредитного лимита. Бралась текущая задолженность, к ней прибавлялась сумма заказа и результат сравнивался с кредитным лимитом. Если меньше или равен — то можно отгружать, если больше кредитного лимита — нельзя. Потом появилась идея для некоторых товаров (которые надо распродать) не учитывать их стоимость при расчете кредитного лимита. И правило должно было выглядеть так: если у клиента кредитный лимит больше нуля и нет просроченной задолженности, то сравниваем с кредитным лимитом только не распродажные товары, а распродажные товары из текущего заказа и предыдущих заказов в сравнении не участвуют. Это тоже можно описать функцией, но это намного более сложная функция получалась… И вообще такую проверку наверно надо не на уровне интерфейса делать, а на сервере. Но в первом варианте все было просто и легко реализовывалось на уровне интерфейса.

Если вы можете привести примеры систем, где удалось удачно реализовать описываемое вами разделение логики — укажите ссылку. Было бы интересно почитать.

И возможно стоит чуть подробнее описать «Hybrid Application». В таком виде, как сейчас, не совсем понятно, что скрывается за некоторыми терминами. Например, чем три вида логики друг от друга отличаются.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.