Comments 24
Спасибо за пост.
Ваш сервис Architect имеет опен сурс версию на гитхабе, например?
У вас 300 мс как один проект? Или же это набор проектов? Если набор проектов, архитектура всех проектов может быть представлена на одной схеме, или это работает только как 1 проект - 1 Арх схема?
Сетевые связанности с другими внешними интеграциями ваш сервис Architect тоже покрывает и показывает?
Что если воркер ноды k8s выделены под конкретный проект ввиду КИИ, например, на схеме это тоже может быть указано, или это не проверяется?
Добрый день.
1)Пока опенсорс варианта нет, но идея такая есть.
2)Как один, это https://sbermarket.ru/. Мы не рисуем 1 схему, мы рисуем схемы для каждого микросервиса. Если отрисовать разом для всех, то схема будет не очень информативна, но технически такая возможность есть: можно отрисовать схему для всех сервисов разом или к примеру для определенных 3ех.
3) Да покрывает, вопервых с инфраструктурными системами типа S3, БД и тп, а так же с внешними системаи, так как информация о них так же должна быть указана в Values.yaml, иначе сервис к ним доступа не получит.
4)Если эту информацию можно считать откуда-то, то да, можно было бы так сделать. Сейчас из того, о чем не было рассказано в статье и находиться в работе: подписть интеграций (комментарий), ссылка на контракт (kafka, grpc). После этого схемы будут еще более информативными и интерактивными. Поскольку формат SVG, то все элементы кликабильные.
Генерировать архитектурные схемы из метаданных систем — быстро, дешево, но есть техническе нюансы.
Спасибо. Интересная и актуальная стать. К сожалению не для работы, а для себя я столкнулся с этой ж проблемой.
Мне кажется есть только один вариант - это генерации схем. Для себя я только решил, что хочу сделать генерацию на основе json.ld. Впечатлениями к сожалению не могу поделиться, потому что это только в самом начале, но ваша статья это хороший вариант того, что в итоге как минимум должно получиться.
Видел доклад на Ютубе, большое спасибо, что выложили в тексте, очень интересный подход и полезная информация
Кирилл, привет! Статья супер, вопрос следующий: как на архитектуре отображать интеграционные цепочки между сервисами\системами? Аля сервис - кафка - найфай - сетевой ресурс - адаптер - БД системы? Или у вас этим подходом покрывается только архитектура самих сервисов, а архитектура решений, в которых имеются интеграционные цепочки - черный ящик?
Изначально я решал проблему понимания системы разработчиками и аналитиками. А так же хотел контролировать избыточные сихронные связи, поэтому текущее решение заточено под решение этих проблем.
Но администраторы уже приходили и задавали аналогичный вопрос, а можно ли построить сетевую схему, ответ прост - если они скажут откуда считать мета информацию о сети и прочих инфраструктурных системах, то строить такие схемы нет проблем. Такие схемы даже есть в нотации. С4 model - https://c4model.com/#DeploymentDiagram.
Поэтому это следующий шаг.
Я как-то делал штуку, которая по метаданным про то же - делает UI, который все это рисует через graphvis. С фильтрами по сервисам и прочему. И можно было, скажем, сделать диаграмму одного сервиса с интеграциями, дальше тыкнуть в какой-нибудь соседний, и сказать «покажи еще его интеграции». Или посмотреть кто юзает определенный топик.
Спасибо за статью!
Получается, при проектировании новой фичи архитектор смотрит на схемы, описывающие текущую реализацию, и отображает новую целевую архитектуру где-то в сторонке. Потом, после разработки, деплоя и генерации модели изменённой архитектуры, можно сравнить то, что получилось, с тем, как это изначально видел архитектор. Верно?
Да, мы не отказались от архитектурных решений, в них архитектор и команда показывают Change, но они могут начать делать схему отталкивась от текущего состояния. Это сильно повышает вероятность того, что при арх решении они исходили из реальности, а не из фантазии.
В арх решениях мы тоже исползуем подход Architecture as Code, поэтому команда может просто взять исходный код схемы, доработать и начать с нее.
Пользуюсь для аналогичных задач https://diagrams.mingrammer.com/
При таком подходе архитектурные схемы описывают состояние as-is. А как описывается архитектура to be?
Целевая архитектура, новые фичи, интеграции до из реализации и деплоя в прод.
Да, мы не отказались от архитектурных решений, в них архитектор и команда показывают Change, но они могут начать делать схему отталкивась от текущего состояния. Это сильно повышает вероятность того, что при арх решении они исходили из реальности, а не из фантазии.
В арх решениях мы тоже исползуем подход Architecture as Code, поэтому команда может просто взять исходный код схемы, доработать и начать с нее.
Арх решения храняться в GitLab, и это состояние To-be. Принятие и ревьюе просиходит аналогично как и в подходах работы с кодом. Треды, MR и тп. Удобно.
Спасибо за статью.
Мы используем https://mermaid.js.org/intro/. Он уже поддерживается и в gitlab и в github, по этому не нужно ни каких дополнительных приседаний.
Мне очень понравился подход Arch as Code, надеюсь он будет только развиваться.
Большое спасибо, Кирилл.
В роли РО периодически сталкивался со следующим - где взять нужные данные для моей системы. Ваш подход поможет только в ситуации, когда другие системы уже пишут данные в топики. Но просто так писать в топики дорого и бесполезно.
Поэтому начиналась беготня по другим РО - а у кого есть нужные мне данные (ну или ко мне прибегали с аналогичным вопросом).
Пробовали решить данную проблему или не сталкивались с подобным? Может как-то иначе процесс организован в целом?
Да.
На самом деле это очень актуальный вопрос и ко мне как к архитектору часто приходят команды и PO с вопросами где взять те или иные данные, после запуска данного решения у меня выходит очень быстро находить ответ и направлять их к верным владельцам сервиса,.
К примеру, вам нужны для вашей системы данные о пользователе (имя, фамилия) и его платежи.
Способ 1
1) У нас вся компания разбита по Subdomain, поэтому если вам нужно что-то про юзера, то легко понять куда копать. И отыскать нужный сервис. Так же у нас есть реестр сервисов, вы можете поискать сервис, в котором скорее всего есть данные. Вы можете воспользоваться поиском и найти нужные сервисы по описанию или названию.
2) Вы открываете ER диаграмму и смотрите есть ли в БД сервиса нужные вам данные, если да идем дальше.
3) Вы открываете Contaimer diagram и смотрите стримит ли сервис подходящие вам события в какие-то топики. Топики мы стараемся именовать хорошо. Поэтому если вы увидите "user.changed" или "payment.finished", то скорее всего это будут нужные вам топикик
4)Вся схема кликабельная, нажав на топик в новой вкладке открывается его контракт в protobuf, вы можете убедиться что нужные данные отправляются.
Способ 2
Также отдельно есть реестр всех топиков, можно поиск начать не с сервисов, а попытаться по имени топика определить подходящий, исследовать его контракт и уже понять какой сервис стримит данные
Проблему поиска данных решают продукты класса Data Catalog - Datahub, Alation и т.п.
Кирилл, благодарю за статью - очень интересно! Есть два вопроса:
1. Подскажите как именно обеспечиваете вот этот момент?
в Values.yaml, не указана какая-то зависимость, то в проде этой зависимости у сервиса не будет. И наоборот: если сервис в Values.yaml укажет какую-то зависимость, то в проде он ее получит.
Правильно понимаю, что таким образом собираете информацию только с тех сервисов, которые развернуты с помощью Helm в k8s? Как поступаете с сервисами, развернутыми на ВМ?
1) У нас целевое состояние - все в K8S. Поэтому все что не там - то легаси и не получает таких инструментов, о которых я писал в статье и других. Это мотивирует команды переезжать в k8s.
2) Но тем не менее, если вы поместите Values.yaml и App.toml в проект, который не в k8s - то его можно спарсить и отрисовать. Но нюанс в том - что 100% актуальности схемы может уже не быть, так как проекты на BM не используют Values.yaml и App.toml для развертывания. Есть вероятность, что файл может быть не актуален. Но ВМ повторюсь - сильно не целевая история для нас. Поэтому таких проектов очень мало.
Интересная статья, спасибо! У меня возникло 2 связанных вопроса:
Позволяет ли решение отрисовывать вложенность компонентов на диаграмме? Пример: вызываемый сервис входит в подсистему, которая, в свою очередь, является частью некой большой АС.
Если в ходе пересмотра архитектуры некий сервис будет решено "приписать" к другой АС (у которой может быть свой владелец и свой архитектор), этот факт как-то будет виден?
1) на текущий момент нет, но если добавить в app.toml название системы, в которую входит в сервис, то это легко можно реализовать: показывать системы, потом проваливаться в них, смотреть детали.
2) У нас 1 система - "Сбермаркет", но в ней есть крупные направления, к примеру "Поддержка пользователей", если app.toml указать какому направлению относится сервис, то можно будет видеть в каком крупном модуле "Сбермаркет" учавствует сервис.
Схемы перерисовываются 1 раз в день, поэтому все изменения будут актуализированы и отражены на схемах в течение 24 часов.
Идей для развития огромное множество, можно различные срезы формировать:
Вокруг систем (как вы предлагали)
Вокруг топиков
Хоть вокруг серверов можно сделать срез, лиж бы потребность в этом была
Кирилл, спасибо!
Подскажите, а файл Structure.sql это просто сумма всех миграций, или что-то дополнительное?
Да, это сумма всех миграций.
Как автоматизировать построение архитектурных схем в большой микросервисной системе