Понял принял, благодарю за совет. Если есть ссылка на источник про разграничение доступов на уровне дашбордов в рамках одной графаны - буду благодарен.
Про разграничение доступов к конкретным дашбордам в рамках одного сервиса графаны - честно признаюсь, ни разу не слышал или слышал, но подобные трюки требовали дополнительных прослоек - по сути самодельных реализаций. Если есть ссылка на источник - буду благодарен.
Графана не спорю, сама по себе прекрасна. Но это только дашборды, задача была упаковать/встроить метрики и соответствующие им диаграммы в единую админку над всей платформой, включающую тех.поддержку, анализ клиентуры, управление миграциями...
По сему, вместо возни с графаной проще было реализовать все самому, ну и если уже такое дело - зачем хранить метрики вне основного приложения -> отсюда отказ уже от прометеуса.
В итоге единая модель сбора + отображения метрик для админов, так ещё и с определением инцидентов и статусом всей платформы для клиентов.
Прома + графана были оставлены больше как запасной вариант, если что-то пойдет уж совсем не так.
В целом, понимаю вашу позицию по поводу использования стандартизированных инструментов, но по какой-то неведомой мне причине, всегда было желание объединить мониторинг и другие административные функции в рамках одной системы на основе разграничения доступов даже для метрик.
На больших масштабах, да, чаще всего и правда кроме основной платформы рядом будет стоять ещё пару сервисов, контролирующих нагрузку на ядро. Вопрос только в том, что это будут за сервисы.
В статье упоминаю, что в идеале воркеры и хранилище метрик должны быть изолированы от основной платформы. Такой подход с агрегацией метрик своими силами очевидно имеет большой минус в виде отсутствия стандартизации, но с другой стороны дает возможность крутить собранными данным как душе угодно. Хотите страницу статуса - получайте. Хотите репорты при превышении нагрузки - пожалуйста.....список можно продолжать бесконечно
В общем и целом - ничего. Пару часов за настройкой дашбордов и загораживанием sso порта графаны. Проблема не столько в недостаточности графаны и прометеуса, сколько в разграничении доступов между админами и суммаризации всех собранных метрик под видом статуса всей платформы.
Клиенты/пользователи - преимущественно не технические пользователи, нужны им не столько дашборды, сколько понимание текущего статуса и произошедших за последние 24 часа инцидентов. В комментарии сверху хабровчанин предлагает реализовать то же самое поверх http, добавив по сути агрегирующий слой отдельным сервисом и тягать метрики с прометеуса - как вариант.
В конкретно моём случае проще показалось в целом отказаться от внешнего "склада" метрик и хранить и собирать на стороне основного приложения. Как результат - все те же метрики и диаграммы, что и с графаной и промой + страница статуса платформы для всех клиентов.
По преимуществу прометея для большинства проектов - согласен, чаще всего добавить один сервис в конфиг и реализовать минимальный /metrics проще.
В статье не ставил честно говоря задачу доказать, что можно проще, скорее, что в конкретных случаях целесообразнее воссоздать сбор метрик вручную - результат уже на оценку читателю.
По поводу определения статуса платформы запросами поверх http, честно хз, напрягать ради этого сеть сомнительно, но как вариант - да, своеобразная прослойка между промой и приложением возможна.
Все верно, аналог, построенный вокруг <операционных показателей>, а не бухгалтерии, адаптированный под мсб. В статье акцентирую внимание на том, что не стремлюсь повторить функционал 1с или стать его копией. Думаю очевидно, что это просто невозможно, да и бессмысленно.
Вполне возможно, что и так, на 100% мало кто что-то понимает. Возьмусь утверждать лишь только то, что все модули строились исходя из принципов, которые я наблюдал всё это время в сервисе и парочке смежных организаций такого же масштаба.
Да, сделать абсолютно для всех не получится, но определённый функционал (те же финансы, но интегрированные напрямую в управление сделками) отлично ложится на большинство известных мне предприятий.
Повторюсь: особенностью и в целом главным преимуществом Kroncl не является какой-то конкретный модуль или функции обмена с 1С. При разработке просто-напросто не ставилось задачи быть с ним совместимым. Такое отношение может показаться поверхностным (ведь каждая вторая организация ведёт бухгалтерию в 1С -> нужно обеспечивать совместимость) — но здесь дело больше в общей сути и целевой платформы.
Основная идея и задача (не озвучена в статье, но сквозит в каждом слове про изоляцию данных организаций) — это возможность быстро развёртывать своего рода инстансы малого бизнеса прямо в облачке, минуя интеграторов, демо-стенды и прочий сюр. Каждый такой инстанс имеет свои настройки тарификации, свои настройки прав, свой состав модулей и так далее. И у предпринимателей/финансистов/аутсорс-агентств появляется возможность вести хоть 10, хоть 100, хоть 1000 таких организаций-заказчиков параллельно, переключаясь между пространствами за секунды.
По поводу самой предметной области ERP повторю тезис из статьи: Kroncl не рассчитан на бухгалтерию. Любому специалисту 1С всё это покажется абсурдом, но дело в том, что 1С сделан для специалистов по 1С, а Kroncl — для обычных предпринимателей. В масштабах организаций до условных 10-15 человек (а таких десятки тысяч, часть из которых и не пытается вести бухгалтерию) необходимый функционал покрывается 5-6 модулями: финансы, сделки, клиенты, склад, сотрудники. Совместив автоматизацию процесса создания инстансов с относительной простотой и функциональностью модулей, без сомнений можно добиться определённых результатов.
То, что есть на рынке сейчас для этого сегмента предпринимателей - либо срмки (под капотом которых единая свалка данных), либо только фин.учёт, либо только склад (МойСклад), либо наш любимый 1с или попытки его повторить. Никто не собирался делать удобно, дёшево и функционально для предприятий такого микро-масштаба (смысла в этом с точки зрения выгоды мало), я собрался - я делаю (собственно про это и статья).
Соглашусь, в большинстве проектов такого рода партнёрская сеть является не опцией, а основным требованием для хоть какого-либо развития. По поводу работы - в большинстве компаний, решающих аналогичные задачи, весь проект сводится к "коробочной" ERP, пусть даже и на современном стеке.
По правде сказать, интересно мне было сделать не столько саму ERP (хотя и не без этого), сколько грамотную изоляцию, и в целом воссоздать концепцию "покупки ресурсов" инстанса для управления бизнесом. Основная идея здесь - не столько повторить 1с или что-то в этом духе, сколько дать возможность вести параллельно хоть 10 организаций, каждая из которых бы имела свои настройки тарификации, свои лимиты хранилища, свой состав модулей.
Автоматизировать процесс создания таких организаций и организовать работоспособность всех инстансов в облаке - вот это наверное самая интересная часть.
Утверждаю ли я, что 1с нужно чем-то заменять? - нет, не утверждаю (как и в любой системе есть минусы и плюсы, просто в случае конкретно 1с плюсы перевешивают минусы [с точки зрения рынка])
Обязаны ли все системы управления предприятиями выглядеть как 1с? - нет, не обязаны (разные масштабы -> разные цели -> разные способы реализации)
По моему скромному мнению мультитенантность на пхп (да и не только) напротив сильно недооценена. И на то есть несколько основных причин:
Отладка этого добра.
Вы предлагаете делегировать установку глобального контекста на мидлварь для роутов, связанных с клиентской логикой. И казалось бы всё отлично, хэндлеры пишем как-будто бы для одного клиента.
А что будет, если по каким-то неведомым или случайным причинам последовательность установки контекста будет нарушена или упоси господи произойдёт установка неправильного?
Произойдет пиздец, выявление почему и где это случилось займет немало времени, а устранение последствий ещё больше.
Красота ручного конфигурирования pdo соединения для конкретного тенанта через связку роутера + фабрики репозиториев как раз в том, что все строго изолировано. Нет никакого магического глобального состояния, шанс накосячить мал или вообще сводится к нулю. Мы просто принимаем uuid тенанта из мидлваря (например из jwt), и говорим, мне нужны репозитории под тенанта вот с таким ключом. И да, делаем так каждый раз, когда нам требуется взаимодействие с базой данных. В обмен на две строки в каждом хэндлере получаем изоляцию каждого роута и как следствие безопасность.
Понимание кода.
Возможно для команды из 1 человека проще скинуть все на контекст, оставив себе лишь написание самой логики, но на деле поддержка такого кода опять же по моему скромному мнению усложняется. Магия, ребята.
Тестирование.
Здесь говорить даже ничего не надо. Думаю всем понятно, что глобальные состояния без обоснованных на то причин (это не обоснованная) если и не запрещены, то являются признаком дурного тона....именно по причине сложности тестирования.
Очереди+консольные команды.
Это вообще пиздец, я думаю и так понятно, что все эти глобальные скоупы отметаются.
Запросы к общим схемам.
Условно в схеме shared у вас хранятся iso коды валют. И что очевидно при написании логики отдельного тенанта они могут потребоваться. Манипуляции по переключению с глобального контекста займут время.
Что касается ResultType. Идея просто в том, чтобы сделать ошибки частью возвращаемого каждым звеном приложения ответа. Это шаг в сторону той самой строгости и контрактности, которые опять же по моему скромному мнению необходимы в крупных multitenancy проектах.
Согласен, мог больше внимания уделить объяснению удобства составления цепочек с помощью такого контракта, не отказываясь полностью от исключений, просто выбрасывая их при фатальных ошибках.
Мог сказать про централизованный обработчик ошибок где-то в бутстрапе, убирающий необходимость try...catch-ить там где не надо.
И свести всё к тому, что с какой стороны не посмотреть, явная обработка ошибок (построенная не на if..else, а на методах по типу .then, .map, .catch и т.д.) лучше для восприятия логической цепочки людьми.
Суть в том, чтобы сделать ошибки частью возвращаемого типа, по аналогии с растом, хаскеллом или десятком других языков. Но в php всё держится на исключениях, там где-то внизу выбросим, потом наверху всё равно всё поймается, а в контроллере мы будем расчитывать на идеальный случай, когда все операции вернули то, что надо...
Да нет, напротив, далеко не гениальное решение, не заменяющее (и не пытающееся это делать там где не надо) способ обработки ошибок, предусмотренный самим языком.
По задумке использование такого объекта уместно при составлении логической цепочки по типу: здесь данные взял + проверил, здесь их сохранил + проверил результат сохранения... Если ваш контроллер, юз кейс, да как его не назовите выполняет все эти операции, и вы чётко понимаете, когда какая из них заканчивается провалом - да, конечно, создание нового объекта ответа избыточно.
Но если всё резделено на отдельные репозитории, всё переиспользуется по сотне раз в разных местах приложения, хочеца-не хочеца нужно будет вводить что-то подобное "единому стандарту ответов" для передачи данных между слоями.
Это не просто переход с try на if, это переход на явное выполнение цепочки запросов (как это изначально и было сказано в статье).
В слоях где сосредоточена главная часть приложения и важна последовательность выполнения операций - это более чем удобно.
Да, сэр, вы правы, алертинг это в целом отдельная тема, хоть и тесно связанная с метриками.
Понял принял, благодарю за совет. Если есть ссылка на источник про разграничение доступов на уровне дашбордов в рамках одной графаны - буду благодарен.
Про разграничение доступов к конкретным дашбордам в рамках одного сервиса графаны - честно признаюсь, ни разу не слышал или слышал, но подобные трюки требовали дополнительных прослоек - по сути самодельных реализаций. Если есть ссылка на источник - буду благодарен.
Графана не спорю, сама по себе прекрасна. Но это только дашборды, задача была упаковать/встроить метрики и соответствующие им диаграммы в единую админку над всей платформой, включающую тех.поддержку, анализ клиентуры, управление миграциями...
По сему, вместо возни с графаной проще было реализовать все самому, ну и если уже такое дело - зачем хранить метрики вне основного приложения -> отсюда отказ уже от прометеуса.
В итоге единая модель сбора + отображения метрик для админов, так ещё и с определением инцидентов и статусом всей платформы для клиентов.
Прома + графана были оставлены больше как запасной вариант, если что-то пойдет уж совсем не так.
В целом, понимаю вашу позицию по поводу использования стандартизированных инструментов, но по какой-то неведомой мне причине, всегда было желание объединить мониторинг и другие административные функции в рамках одной системы на основе разграничения доступов даже для метрик.
На больших масштабах, да, чаще всего и правда кроме основной платформы рядом будет стоять ещё пару сервисов, контролирующих нагрузку на ядро. Вопрос только в том, что это будут за сервисы.
В статье упоминаю, что в идеале воркеры и хранилище метрик должны быть изолированы от основной платформы. Такой подход с агрегацией метрик своими силами очевидно имеет большой минус в виде отсутствия стандартизации, но с другой стороны дает возможность крутить собранными данным как душе угодно. Хотите страницу статуса - получайте. Хотите репорты при превышении нагрузки - пожалуйста.....список можно продолжать бесконечно
В общем и целом - ничего. Пару часов за настройкой дашбордов и загораживанием sso порта графаны. Проблема не столько в недостаточности графаны и прометеуса, сколько в разграничении доступов между админами и суммаризации всех собранных метрик под видом статуса всей платформы.
Клиенты/пользователи - преимущественно не технические пользователи, нужны им не столько дашборды, сколько понимание текущего статуса и произошедших за последние 24 часа инцидентов. В комментарии сверху хабровчанин предлагает реализовать то же самое поверх http, добавив по сути агрегирующий слой отдельным сервисом и тягать метрики с прометеуса - как вариант.
В конкретно моём случае проще показалось в целом отказаться от внешнего "склада" метрик и хранить и собирать на стороне основного приложения. Как результат - все те же метрики и диаграммы, что и с графаной и промой + страница статуса платформы для всех клиентов.
Какой вариант выбирать - на усмотрение читателя.
По преимуществу прометея для большинства проектов - согласен, чаще всего добавить один сервис в конфиг и реализовать минимальный /metrics проще.
В статье не ставил честно говоря задачу доказать, что можно проще, скорее, что в конкретных случаях целесообразнее воссоздать сбор метрик вручную - результат уже на оценку читателю.
По поводу определения статуса платформы запросами поверх http, честно хз, напрягать ради этого сеть сомнительно, но как вариант - да, своеобразная прослойка между промой и приложением возможна.
Все верно, аналог, построенный вокруг <операционных показателей>, а не бухгалтерии, адаптированный под мсб. В статье акцентирую внимание на том, что не стремлюсь повторить функционал 1с или стать его копией. Думаю очевидно, что это просто невозможно, да и бессмысленно.
Вполне возможно, что и так, на 100% мало кто что-то понимает. Возьмусь утверждать лишь только то, что все модули строились исходя из принципов, которые я наблюдал всё это время в сервисе и парочке смежных организаций такого же масштаба.
Да, сделать абсолютно для всех не получится, но определённый функционал (те же финансы, но интегрированные напрямую в управление сделками) отлично ложится на большинство известных мне предприятий.
Благодарю за комментарий и замечание по партнёрам. Наверное, из-за таких оценок до сих пор и пишу.
Повторюсь: особенностью и в целом главным преимуществом Kroncl не является какой-то конкретный модуль или функции обмена с 1С. При разработке просто-напросто не ставилось задачи быть с ним совместимым. Такое отношение может показаться поверхностным (ведь каждая вторая организация ведёт бухгалтерию в 1С -> нужно обеспечивать совместимость) — но здесь дело больше в общей сути и целевой платформы.
Основная идея и задача (не озвучена в статье, но сквозит в каждом слове про изоляцию данных организаций) — это возможность быстро развёртывать своего рода инстансы малого бизнеса прямо в облачке, минуя интеграторов, демо-стенды и прочий сюр. Каждый такой инстанс имеет свои настройки тарификации, свои настройки прав, свой состав модулей и так далее. И у предпринимателей/финансистов/аутсорс-агентств появляется возможность вести хоть 10, хоть 100, хоть 1000 таких организаций-заказчиков параллельно, переключаясь между пространствами за секунды.
По поводу самой предметной области ERP повторю тезис из статьи: Kroncl не рассчитан на бухгалтерию. Любому специалисту 1С всё это покажется абсурдом, но дело в том, что 1С сделан для специалистов по 1С, а Kroncl — для обычных предпринимателей. В масштабах организаций до условных 10-15 человек (а таких десятки тысяч, часть из которых и не пытается вести бухгалтерию) необходимый функционал покрывается 5-6 модулями: финансы, сделки, клиенты, склад, сотрудники. Совместив автоматизацию процесса создания инстансов с относительной простотой и функциональностью модулей, без сомнений можно добиться определённых результатов.
То, что есть на рынке сейчас для этого сегмента предпринимателей - либо срмки (под капотом которых единая свалка данных), либо только фин.учёт, либо только склад (МойСклад), либо наш любимый 1с или попытки его повторить. Никто не собирался делать удобно, дёшево и функционально для предприятий такого микро-масштаба (смысла в этом с точки зрения выгоды мало), я собрался - я делаю (собственно про это и статья).
Соглашусь, в большинстве проектов такого рода партнёрская сеть является не опцией, а основным требованием для хоть какого-либо развития. По поводу работы - в большинстве компаний, решающих аналогичные задачи, весь проект сводится к "коробочной" ERP, пусть даже и на современном стеке.
По правде сказать, интересно мне было сделать не столько саму ERP (хотя и не без этого), сколько грамотную изоляцию, и в целом воссоздать концепцию "покупки ресурсов" инстанса для управления бизнесом. Основная идея здесь - не столько повторить 1с или что-то в этом духе, сколько дать возможность вести параллельно хоть 10 организаций, каждая из которых бы имела свои настройки тарификации, свои лимиты хранилища, свой состав модулей.
Автоматизировать процесс создания таких организаций и организовать работоспособность всех инстансов в облаке - вот это наверное самая интересная часть.
Утверждаю ли я, что 1с нужно чем-то заменять? - нет, не утверждаю (как и в любой системе есть минусы и плюсы, просто в случае конкретно 1с плюсы перевешивают минусы [с точки зрения рынка])
Обязаны ли все системы управления предприятиями выглядеть как 1с? - нет, не обязаны (разные масштабы -> разные цели -> разные способы реализации)
И не поспоришь ведь даже...в контексте "детерминированного контекста"
По моему скромному мнению мультитенантность на пхп (да и не только) напротив сильно недооценена. И на то есть несколько основных причин:
Отладка этого добра.
Вы предлагаете делегировать установку глобального контекста на мидлварь для роутов, связанных с клиентской логикой. И казалось бы всё отлично, хэндлеры пишем как-будто бы для одного клиента.
А что будет, если по каким-то неведомым или случайным причинам последовательность установки контекста будет нарушена или упоси господи произойдёт установка неправильного?
Произойдет пиздец, выявление почему и где это случилось займет немало времени, а устранение последствий ещё больше.
Красота ручного конфигурирования pdo соединения для конкретного тенанта через связку роутера + фабрики репозиториев как раз в том, что все строго изолировано. Нет никакого магического глобального состояния, шанс накосячить мал или вообще сводится к нулю. Мы просто принимаем uuid тенанта из мидлваря (например из jwt), и говорим, мне нужны репозитории под тенанта вот с таким ключом. И да, делаем так каждый раз, когда нам требуется взаимодействие с базой данных. В обмен на две строки в каждом хэндлере получаем изоляцию каждого роута и как следствие безопасность.
Понимание кода.
Возможно для команды из 1 человека проще скинуть все на контекст, оставив себе лишь написание самой логики, но на деле поддержка такого кода опять же по моему скромному мнению усложняется. Магия, ребята.
Тестирование.
Здесь говорить даже ничего не надо. Думаю всем понятно, что глобальные состояния без обоснованных на то причин (это не обоснованная) если и не запрещены, то являются признаком дурного тона....именно по причине сложности тестирования.
Очереди+консольные команды.
Это вообще пиздец, я думаю и так понятно, что все эти глобальные скоупы отметаются.
Запросы к общим схемам.
Условно в схеме shared у вас хранятся iso коды валют. И что очевидно при написании логики отдельного тенанта они могут потребоваться. Манипуляции по переключению с глобального контекста займут время.
Что касается
ResultType. Идея просто в том, чтобы сделать ошибки частью возвращаемого каждым звеном приложения ответа. Это шаг в сторону той самой строгости и контрактности, которые опять же по моему скромному мнению необходимы в крупных multitenancy проектах.Согласен, мог больше внимания уделить объяснению удобства составления цепочек с помощью такого контракта, не отказываясь полностью от исключений, просто выбрасывая их при фатальных ошибках.
Мог сказать про централизованный обработчик ошибок где-то в бутстрапе, убирающий необходимость try...catch-ить там где не надо.
И свести всё к тому, что с какой стороны не посмотреть, явная обработка ошибок (построенная не на if..else, а на методах по типу .then, .map, .catch и т.д.) лучше для восприятия логической цепочки людьми.
Суть в том, чтобы сделать ошибки частью возвращаемого типа, по аналогии с растом, хаскеллом или десятком других языков. Но в php всё держится на исключениях, там где-то внизу выбросим, потом наверху всё равно всё поймается, а в контроллере мы будем расчитывать на идеальный случай, когда все операции вернули то, что надо...
Вариант конечно живой, но есть и альтернатива.
Да нет, напротив, далеко не гениальное решение, не заменяющее (и не пытающееся это делать там где не надо) способ обработки ошибок, предусмотренный самим языком.
По задумке использование такого объекта уместно при составлении логической цепочки по типу: здесь данные взял + проверил, здесь их сохранил + проверил результат сохранения... Если ваш контроллер, юз кейс, да как его не назовите выполняет все эти операции, и вы чётко понимаете, когда какая из них заканчивается провалом - да, конечно, создание нового объекта ответа избыточно.
Но если всё резделено на отдельные репозитории, всё переиспользуется по сотне раз в разных местах приложения, хочеца-не хочеца нужно будет вводить что-то подобное "единому стандарту ответов" для передачи данных между слоями.
Это не просто переход с try на if, это переход на явное выполнение цепочки запросов (как это изначально и было сказано в статье).
В слоях где сосредоточена главная часть приложения и важна последовательность выполнения операций - это более чем удобно.