1) на текущий момент нет, но если добавить в app.toml название системы, в которую входит в сервис, то это легко можно реализовать: показывать системы, потом проваливаться в них, смотреть детали.
2) У нас 1 система - "Сбермаркет", но в ней есть крупные направления, к примеру "Поддержка пользователей", если app.toml указать какому направлению относится сервис, то можно будет видеть в каком крупном модуле "Сбермаркет" учавствует сервис.
Схемы перерисовываются 1 раз в день, поэтому все изменения будут актуализированы и отражены на схемах в течение 24 часов.
Идей для развития огромное множество, можно различные срезы формировать:
Вокруг систем (как вы предлагали)
Вокруг топиков
Хоть вокруг серверов можно сделать срез, лиж бы потребность в этом была
1) У нас целевое состояние - все в K8S. Поэтому все что не там - то легаси и не получает таких инструментов, о которых я писал в статье и других. Это мотивирует команды переезжать в k8s.
2) Но тем не менее, если вы поместите Values.yaml и App.toml в проект, который не в k8s - то его можно спарсить и отрисовать. Но нюанс в том - что 100% актуальности схемы может уже не быть, так как проекты на BM не используют Values.yaml и App.toml для развертывания. Есть вероятность, что файл может быть не актуален. Но ВМ повторюсь - сильно не целевая история для нас. Поэтому таких проектов очень мало.
На самом деле это очень актуальный вопрос и ко мне как к архитектору часто приходят команды и PO с вопросами где взять те или иные данные, после запуска данного решения у меня выходит очень быстро находить ответ и направлять их к верным владельцам сервиса,.
К примеру, вам нужны для вашей системы данные о пользователе (имя, фамилия) и его платежи.
Способ 1
1) У нас вся компания разбита по Subdomain, поэтому если вам нужно что-то про юзера, то легко понять куда копать. И отыскать нужный сервис. Так же у нас есть реестр сервисов, вы можете поискать сервис, в котором скорее всего есть данные. Вы можете воспользоваться поиском и найти нужные сервисы по описанию или названию.
2) Вы открываете ER диаграмму и смотрите есть ли в БД сервиса нужные вам данные, если да идем дальше.
3) Вы открываете Contaimer diagram и смотрите стримит ли сервис подходящие вам события в какие-то топики. Топики мы стараемся именовать хорошо. Поэтому если вы увидите "user.changed" или "payment.finished", то скорее всего это будут нужные вам топикик
4)Вся схема кликабельная, нажав на топик в новой вкладке открывается его контракт в protobuf, вы можете убедиться что нужные данные отправляются.
Способ 2
Также отдельно есть реестр всех топиков, можно поиск начать не с сервисов, а попытаться по имени топика определить подходящий, исследовать его контракт и уже понять какой сервис стримит данные
Да, мы не отказались от архитектурных решений, в них архитектор и команда показывают Change, но они могут начать делать схему отталкивась от текущего состояния. Это сильно повышает вероятность того, что при арх решении они исходили из реальности, а не из фантазии.
В арх решениях мы тоже исползуем подход Architecture as Code, поэтому команда может просто взять исходный код схемы, доработать и начать с нее.
Арх решения храняться в GitLab, и это состояние To-be. Принятие и ревьюе просиходит аналогично как и в подходах работы с кодом. Треды, MR и тп. Удобно.
Да, мы не отказались от архитектурных решений, в них архитектор и команда показывают Change, но они могут начать делать схему отталкивась от текущего состояния. Это сильно повышает вероятность того, что при арх решении они исходили из реальности, а не из фантазии.
В арх решениях мы тоже исползуем подход Architecture as Code, поэтому команда может просто взять исходный код схемы, доработать и начать с нее.
Изначально я решал проблему понимания системы разработчиками и аналитиками. А так же хотел контролировать избыточные сихронные связи, поэтому текущее решение заточено под решение этих проблем.
Но администраторы уже приходили и задавали аналогичный вопрос, а можно ли построить сетевую схему, ответ прост - если они скажут откуда считать мета информацию о сети и прочих инфраструктурных системах, то строить такие схемы нет проблем. Такие схемы даже есть в нотации. С4 model - https://c4model.com/#DeploymentDiagram.
2)Как один, это https://sbermarket.ru/. Мы не рисуем 1 схему, мы рисуем схемы для каждого микросервиса. Если отрисовать разом для всех, то схема будет не очень информативна, но технически такая возможность есть: можно отрисовать схему для всех сервисов разом или к примеру для определенных 3ех.
3) Да покрывает, вопервых с инфраструктурными системами типа S3, БД и тп, а так же с внешними системаи, так как информация о них так же должна быть указана в Values.yaml, иначе сервис к ним доступа не получит.
4)Если эту информацию можно считать откуда-то, то да, можно было бы так сделать. Сейчас из того, о чем не было рассказано в статье и находиться в работе: подписть интеграций (комментарий), ссылка на контракт (kafka, grpc). После этого схемы будут еще более информативными и интерактивными. Поскольку формат SVG, то все элементы кликабильные.
Да, это сумма всех миграций.
1) на текущий момент нет, но если добавить в app.toml название системы, в которую входит в сервис, то это легко можно реализовать: показывать системы, потом проваливаться в них, смотреть детали.
2) У нас 1 система - "Сбермаркет", но в ней есть крупные направления, к примеру "Поддержка пользователей", если app.toml указать какому направлению относится сервис, то можно будет видеть в каком крупном модуле "Сбермаркет" учавствует сервис.
Схемы перерисовываются 1 раз в день, поэтому все изменения будут актуализированы и отражены на схемах в течение 24 часов.
Идей для развития огромное множество, можно различные срезы формировать:
Вокруг систем (как вы предлагали)
Вокруг топиков
Хоть вокруг серверов можно сделать срез, лиж бы потребность в этом была
1) У нас целевое состояние - все в K8S. Поэтому все что не там - то легаси и не получает таких инструментов, о которых я писал в статье и других. Это мотивирует команды переезжать в k8s.
2) Но тем не менее, если вы поместите Values.yaml и App.toml в проект, который не в k8s - то его можно спарсить и отрисовать. Но нюанс в том - что 100% актуальности схемы может уже не быть, так как проекты на BM не используют Values.yaml и App.toml для развертывания. Есть вероятность, что файл может быть не актуален. Но ВМ повторюсь - сильно не целевая история для нас. Поэтому таких проектов очень мало.
Да.
На самом деле это очень актуальный вопрос и ко мне как к архитектору часто приходят команды и PO с вопросами где взять те или иные данные, после запуска данного решения у меня выходит очень быстро находить ответ и направлять их к верным владельцам сервиса,.
К примеру, вам нужны для вашей системы данные о пользователе (имя, фамилия) и его платежи.
Способ 1
1) У нас вся компания разбита по Subdomain, поэтому если вам нужно что-то про юзера, то легко понять куда копать. И отыскать нужный сервис. Так же у нас есть реестр сервисов, вы можете поискать сервис, в котором скорее всего есть данные. Вы можете воспользоваться поиском и найти нужные сервисы по описанию или названию.
2) Вы открываете ER диаграмму и смотрите есть ли в БД сервиса нужные вам данные, если да идем дальше.
3) Вы открываете Contaimer diagram и смотрите стримит ли сервис подходящие вам события в какие-то топики. Топики мы стараемся именовать хорошо. Поэтому если вы увидите "user.changed" или "payment.finished", то скорее всего это будут нужные вам топикик
4)Вся схема кликабельная, нажав на топик в новой вкладке открывается его контракт в protobuf, вы можете убедиться что нужные данные отправляются.
Способ 2
Также отдельно есть реестр всех топиков, можно поиск начать не с сервисов, а попытаться по имени топика определить подходящий, исследовать его контракт и уже понять какой сервис стримит данные
Да, мы не отказались от архитектурных решений, в них архитектор и команда показывают Change, но они могут начать делать схему отталкивась от текущего состояния. Это сильно повышает вероятность того, что при арх решении они исходили из реальности, а не из фантазии.
В арх решениях мы тоже исползуем подход Architecture as Code, поэтому команда может просто взять исходный код схемы, доработать и начать с нее.
Арх решения храняться в GitLab, и это состояние To-be. Принятие и ревьюе просиходит аналогично как и в подходах работы с кодом. Треды, MR и тп. Удобно.
Да, мы не отказались от архитектурных решений, в них архитектор и команда показывают Change, но они могут начать делать схему отталкивась от текущего состояния. Это сильно повышает вероятность того, что при арх решении они исходили из реальности, а не из фантазии.
В арх решениях мы тоже исползуем подход Architecture as Code, поэтому команда может просто взять исходный код схемы, доработать и начать с нее.
Супер! Да, наше решение работает схожим образом. Схема рисуется в SVG и:
1) Если кликнуть на сервис, то проваливаешся в его схему
2) Если кликнуть на топик - то проваливаешся в его Protobuf контракт
Изначально я решал проблему понимания системы разработчиками и аналитиками. А так же хотел контролировать избыточные сихронные связи, поэтому текущее решение заточено под решение этих проблем.
Но администраторы уже приходили и задавали аналогичный вопрос, а можно ли построить сетевую схему, ответ прост - если они скажут откуда считать мета информацию о сети и прочих инфраструктурных системах, то строить такие схемы нет проблем. Такие схемы даже есть в нотации. С4 model - https://c4model.com/#DeploymentDiagram.
Поэтому это следующий шаг.
Добрый день.
1)Пока опенсорс варианта нет, но идея такая есть.
2)Как один, это https://sbermarket.ru/. Мы не рисуем 1 схему, мы рисуем схемы для каждого микросервиса. Если отрисовать разом для всех, то схема будет не очень информативна, но технически такая возможность есть: можно отрисовать схему для всех сервисов разом или к примеру для определенных 3ех.
3) Да покрывает, вопервых с инфраструктурными системами типа S3, БД и тп, а так же с внешними системаи, так как информация о них так же должна быть указана в Values.yaml, иначе сервис к ним доступа не получит.
4)Если эту информацию можно считать откуда-то, то да, можно было бы так сделать. Сейчас из того, о чем не было рассказано в статье и находиться в работе: подписть интеграций (комментарий), ссылка на контракт (kafka, grpc). После этого схемы будут еще более информативными и интерактивными. Поскольку формат SVG, то все элементы кликабильные.