А с конфигами так. Есть сервис, который смотрит в репозиторий и наблюдает за появлением новых комитов. При появлении новых комитов, проходит валидация, препроцессинг, дальше данные загружаются в динамические таблицы YT, про который мы тоже как-то писали.
Аппхосты уже смотрят в YT и качают оттуда обновления.
Вообще звучит хорошо, да. В очень похожем сеттинге живет другой большой поисковик. Как там устроен поиск я доподлинно не знаю, но все сервисы создаются через grpc описание, в моннорепозитории можно пойти и всем закомитить нововеденние. Так что, да схема может работать.
Про шестую проблему, все таки не совсем тебя понял. Чтобы внедрить фичу, мне нужно потрогать все сервисы на пути пользователь -> мой микросервис. То есть пойти кода написать в микросервисы соседних команд, что не очень удобно. Под аппхостом, я добавил вершинку в граф, написал бекенд этой вершинки и готово.
Вот тут хороший вопрос и на него нет однозначного ответа. То есть, можно грамотно задизайнить то что есть сейчас на классической микросервисной архитектуре и это будет хорошо работать.
Почему конкретно у нас Apphost, я для себя отвечаю так.
— Понятное разделение зоны ответственности. Команда реализует бизнес логику, мы реализуем передачу данных. Когда мы что-то чиним, мы чиним у всех сразу.
— Кто-нибудь обязательно забудет сделать одно из N обязательных действий с использованием правильной стандартизованной технологии и все сломает.
— И шестую проблему из статьи не понятно как решать. Чтобы внедрить фичу, тебе придется комитить в код другой команды, или ставить на них задачу.
Если баг в софте, то да, можно все сломать. Но тут как, если баг в ядре, балансировщике нагрузки, софте свитча, в супервизоре облака, все сломается точно так же… Так что добавление Apphost не делает конструкцию более хрупкой.
Остается только качественно тестироваться и аккуратно катать релизы.
А вот это прямо в точку! Когда думали как объяснять новым людям, что такое Аппхост, сошлись, что API Gateway самый близкий аналог. Только API Gateway это обычно кастомный код, а Аппхост это некоторый способ сконфигурировать свой API Gateway.
А про сервис меш не думал никогда, но да, что-то есть.
Не совсем похоже. Брокер скорее про очереди сообщений, задач, данных на доставку, а Аппхост про выполнение запроса в твой сервис.
Наиболее яркая разница в роли клиента. Клиент у брокера, читает или поставляет данные в него и делает это по некоторой собственной логике. Как минимум клиент сам решает, куда подписаться и когда и что ему написать.
В случае Аппхоста вся логика выполнение запроса описана в графе, а клиенты под Аппхостом только обрабатывают запросы.
Брокер в Яндексе тоже есть, но не самописный, конечно :) Мы про него писали некоторое время назад.
Язык — плюсы.
А с конфигами так. Есть сервис, который смотрит в репозиторий и наблюдает за появлением новых комитов. При появлении новых комитов, проходит валидация, препроцессинг, дальше данные загружаются в динамические таблицы YT, про который мы тоже как-то писали.
Аппхосты уже смотрят в YT и качают оттуда обновления.
Про шестую проблему, все таки не совсем тебя понял. Чтобы внедрить фичу, мне нужно потрогать все сервисы на пути пользователь -> мой микросервис. То есть пойти кода написать в микросервисы соседних команд, что не очень удобно. Под аппхостом, я добавил вершинку в граф, написал бекенд этой вершинки и готово.
Почему конкретно у нас Apphost, я для себя отвечаю так.
— Понятное разделение зоны ответственности. Команда реализует бизнес логику, мы реализуем передачу данных. Когда мы что-то чиним, мы чиним у всех сразу.
— Кто-нибудь обязательно забудет сделать одно из N обязательных действий с использованием правильной стандартизованной технологии и все сломает.
— И шестую проблему из статьи не понятно как решать. Чтобы внедрить фичу, тебе придется комитить в код другой команды, или ставить на них задачу.
Остается только качественно тестироваться и аккуратно катать релизы.
А про сервис меш не думал никогда, но да, что-то есть.
Наиболее яркая разница в роли клиента. Клиент у брокера, читает или поставляет данные в него и делает это по некоторой собственной логике. Как минимум клиент сам решает, куда подписаться и когда и что ему написать.
В случае Аппхоста вся логика выполнение запроса описана в графе, а клиенты под Аппхостом только обрабатывают запросы.
Брокер в Яндексе тоже есть, но не самописный, конечно :) Мы про него писали некоторое время назад.