Comments 7
а вот расскажите ваш опыт с Istio:
* как бороться с 500мб сайдкар
* багами, которые встретили
* особенности, которые нужно учитывать
* личный опыт — что нужно учитывать при внедрении.
* как бороться с 500мб сайдкар
* багами, которые встретили
* особенности, которые нужно учитывать
* личный опыт — что нужно учитывать при внедрении.
Пока поделиться особо нечем. Прода с istio в данный момент нет.
Мы планируем катнуть возможность использования Istio в 70+ кластеров до конца месяца и где-то в апреле/мае у нас будет первый реальный продакшен опыт на реальных кейсах.
Мы обязательно поделимся полученным опытом, так как будет большое количество различных кейсов на различных нагрузках и конфигурациях.
Вы ЭТО называете простым? По-моему микросервисный фреймворк, включающий все что тут упомянуто, встроеный внутрь микросервиса (как в начале статьи) по-проще будет. Там хоть язык тот-же что и у самого сервиса. И этих жутких yaml нет.
Здравствуйте, подскажите а позволяет ли Istio организовать сеть так чтобы можно было подключить один замещающий сервис из выделенного окружения? Поясню что имею ввиду, одно из преимуществ микросервисов что их можно разрабатывать отдельным командам, т.е. группа которая не имеет доступа ко всем проектам и т.д. может писать свой компонент. Но вот как дебажить в таком случае? Себе все не поднять (доступа нет допустим просто у внешней команды к другим проектам). А как то подебажить в процессе разработки в общем окружение было бы полезно. Допустим есть DEV окружение где все сервисы запущены и вот мы хотим подключиться к этой сетке заменив только один сервис и только для определенного клиента. Т.е. чтобы для других команд DEV окружение не изменилось (особенно учитывая что над одним сервисом теоретически могут работать несколько разработчиков одновременно). Т.е. надо как-то создать наследуемую сетку с заменой части конфигурации в зависимости от входной точки. Например есть какой-то сервис который вызывается в середине стека RPC вызовов и вот, надо чтобы в стеке RPC вызовов при запуске через выделенный фронт (team-51.some-service.ru), например который предоставлен root командной, вызывалась копия определенного сервиса (service-x) который запущен на каком-нибудь внешнем узле (service-x.team-51.ru).
Может я не с того края пытаюсь проблему решить, просто как изолированно разрабатывать один микросервис с интеграцией в общее RPC окружение, без поднятия в облаке или локально полной сетки сервисов для каждого разработчика?
Может я не с того края пытаюсь проблему решить, просто как изолированно разрабатывать один микросервис с интеграцией в общее RPC окружение, без поднятия в облаке или локально полной сетки сервисов для каждого разработчика?
опираясь на код статуса в ответе, оно понимает, произошёл ли сбой в запросе, и выполняет его повторно.
А если у нас сервисы на GraphQL? В рамках одного запроса GraphQL могут посылаться несколько квери/мутаций и возвращать они могут разные статусы. Поэтому в GraphQL по сути статусов HTTP в привычном понимании нет. Как тут быть?
Sign up to leave a comment.
Назад к микросервисам вместе с Istio. Часть 1