Highload прошел, но интересные доклады еще остались)

"AppHost: как Яндекс организует взаимодействие сотен микросервисов"

Честно - не ожидал такого хода от Яндекса.
В чем суть?

У Яндекса микросервисная архитектура, большое количество микросервисов и жесткие требования по времени ответа пользователю. При этом очень сложно контролировать всю цепочку вызовов микросервисов по конкретной фиче, чтобы оптимизировать время ответа. Убрать лишние вызовы или найти самый долгий для его оптимизации. Один из вариантов решения проблемы есть в предыдущем моем посте (реверс-инжиниринг по трейсам), но ребят данный вариант не устроил из-за его не 100% точности.

Они тоже сделали граф вызовов для каждого бизнес-процесса. Но граф этот задается владельцем процесса явно в текстовом виде. Ремарка - как найти владельца для бизнес-процесса из десятка микросервисов - отдельный вопрос. Возвращаясь к сути, из того что я увидел: в конфигурации задаются сервисы - поставщики данных, их зависимости, таймауты, протоколы и схемы обмена данными. И это не просто часть аналитики, более того - как я понимаю в Яндексе нет требований по наличию аналитики. Это исполняемая спецификация: каждый запрос вначале попадает на новый микросервис - собственно AppHost из названия доклада - который загружает граф и выполняет его. Вызывая нужные микросервисы, предварительно проверяя необходимость и возможность его вызова. В итоге получаем топологию микросервисов в виде звезды, где AppHost в центре.

Сразу же возникает вопрос по надежности решения.
Ответы:
а) AppHost - stateless сервис, горизонтально масштабируемый, более того его инсталляции разделены по разным бизнес-доментам. Плюс есть всякие лайфхаки - например, при сбое по умолчанию пользовательский запрос отправляется на повторное выполнение, но при наличии специфических ошибок (ошибок, ломающих логику AppHost) повтор отключается
б) всегда есть критически важные сервисы, от которых зависят все или почти все остальные. Аутентификация, авторизация, прокси - как минимум. И ничего - они тоже дорабатываются, новые версии выкатываются. Здесь главное не сделать такой оркестратор слишком сложным.

Да, возвращаясь к принципу: все новое - это хорошо забытое старое. Во-первых это мне напоминает паттерн Сага в виде оркестратора. Во-вторых - старый недобрый ESB - Enterprise Service Bus - на новом витке развития. Напомню, его ключевое отличие от Kafka - брокер ESB содержит бизнес-логику и занимается маппингом данных, а брокер Kafka - в основном обеспечивает отказоустойчивость.

Ну и отдельно - вот принцип Architecture As Code в действии. Этап вливания конфигурации с графом сервисов - хорошая точка для контроля архитектуры. В целом идея мне нравится, ключевой момент тут - сознательное ограничение сложности оркестратора. Тогда получим увеличение надежности системы в целом. Но повторюсь - не ожидал, что эта идея возникнет у Яндекса.

#arch #aac #saga #esb

Всем привет!

Нужно ли хранить информация об архитектуре АС?
Я считаю, что да, нужно.
Почему?
1) контроль интеграций
2) контроль использования компонентов и технологий
3) обмен информацией между командами

Т.к. в канале была серия про AI - вспомним его и сейчас. А что если AI агент будет ходить по репозиториям и собирать информацию об архитектуре в одном месте? В теории да, но есть ряд важных нюансов:
1) доступы ко всем репозиториям. В целом решаемо.
2) достаточность данных в коде для точного определения архитектуры. Трудно решить, часто нужных данных просто нет в коде, т.к. они стендозависимы. Отсюда потенциальные пробелы и галлюцинации.
3) мы получаем слепок AS IS, но TO BE все равно придется рисовать ручками

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

Поэтому пока рассмотрим другие варианты.

Ок, заводим отдельную АС для хранения архитектуры. Есть UI, можно легко описывать компоненты, интеграции и технологии.

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

Что же делать? А пусть команды сами выбирают, кто отвечает за описание. Весьма вероятно, что этим кем-то станет аналитик. Аналитик конечно же знает архитектуру, но сверху, до определенного уровня. Например, на уровне единиц деплоя, технологий точно будут проблемы. Ок, архитектура описана. К чему приведет данных подход? К тому, что в нашей архитектурной АС будет некое представление актуальной архитектуры, неполное, устаревшее сразу после создания. И поддерживать такую архитектуру в актуальном состоянии никто не будет. Если только из под палки. И самое главное - системой никто не пользуется. Но заполнять надо(

Итого - так можно, но не нужно делать.
Какие главные проблемы:
1) нежелание разработчиков работать за пределами IDE. А именно разработчик понимает архитектуру в целом, как минимум с уровня Senior
2) UI представление данных, к которому так просто не применишь diff и которое легко сломать
3) разрыв AS IS и TO BE - релиза и архитектуры

И, соответственно, как их фиксить:
1) у нас есть IDEA и рабочий проект в git, архитектура должна лежать в проекте вместе кодом. Также нужен плагин IDEA для удобства работы с файлами архитектуры
2) по аналогии с Infrastructure as Code, Documentation as code - Architecture as Code. Вообще говоря Everything as Code, но сегодня про архитектуру). Т.е. все в текстовом виде. OpenAPI, PlantUML в эту парадигму отлично вписываются
3) актуальная архитектура хранится в ветке релиза и согласовывается командой на уровне Pull Request (Merge Request). Целевая - в централизованном репозитории, тоже в git. Актуальная архитектура синхронизируется с целевой тоже через Pull Request, но уже с другими согласующими.

Если до сих пор казалось, что я слишком абстрактен - открою тайну, я веду к конкретной системе, о которой недавно узнал - DocHub.
Снова спасибо @AViIgnatov

Исходники https://github.com/DocHubTeam/DocHub
Живой проект с описанием архитектуре на примере самого себя: https://dochub.info
Цикл статей на Хабре: https://habr.com/ru/articles/659595/ и далее по автору.
К слову, разработка российская, из rabota.ru

Итого: я не уверен, что DocHub - это серебряная пуля. Не могу гарантировать, что он решит проблему контроля и вообще наличия актуальной архитектуры в компании. Все-таки, повторюсь - очень мало людей хотят описывать архитектуру, во многих командах нет соответствующей роли. Я про факт, а не формальности. Но у данного подхода IMHO шансов побольше, чем у всего, что я видел.

#aac #arch