здесь просто всем честно следует признаться, что таковы правила игры. Яндекс ни от кого не скрывает свои задачи, их эйчар уже даже присылает чуть ли не образцы тех задач, которые спрашивают на собеседованиях и никто никому не мешает подстроиться под эти правила, выучить сортировки, деревья и прочие штуки. С другой стороны, было множество статей, про то, как действительно крутые разработчики физически не могут писать на досках, листках, не могут писать программы по таймеру или под страхом смерти — кому в действительности нужны эти скиллы?
Для полноты картины, нужно было также написать, сколько % рабочего времени вы вообще не используете те алгоритмы, которые спрашиваете, а то статья выглядит как неубедительное оправдание перед теми, кто не прошел собес)
1. Получается, что все сервисы шарят общий базовый код? Ведь в литературе о микросервисах мы повсеместно находим что-то вроде этого:
Microservices should adhere to a “shared nothing” approach where microservices do not possess shared code. Microservices should instead accept code redundancy and resist the urge to reuse code in order to avoid a close organizational link.
“Don’t repeat yourself” isn’t a golden rule Microservices allow you to violate the DRY (don’t repeat yourself) principle safely. Traditional software design recommends that you generalize repetitive code so that you don’t end up maintaining many copies of slightly different code. Microservice design is exactly the opposite: each microservice is allowed to go its own way
2. Если я ничего не упустил, у вас получается голый кубер, рассматривали ли какие-нибудь сервис меши для него? Чем закончились результаты рассмотрения, если были?
3. Вопрос авторизации и аутентификации в микросервисной архитектуре: долго ли мучались, на чем остановились?
4. Для чего вы используете в названиях пакетов несколько слов и underscores ?)
Теперь на стороне сервисов (все gRPC-методы в Go реализации принимают первым параметром context), вы просто достаёте это значение из контекста:
Нередко считается плохим тоном, так лучше не использовать контекст. Если пробрасывать такого рода значения в контексте, код становится трудно поддерживать. Назначение context.Value — информирование, а не контроль логики
Для полноты картины, нужно было также написать, сколько % рабочего времени вы вообще не используете те алгоритмы, которые спрашиваете, а то статья выглядит как неубедительное оправдание перед теми, кто не прошел собес)
1. Получается, что все сервисы шарят общий базовый код? Ведь в литературе о микросервисах мы повсеместно находим что-то вроде этого:
2. Если я ничего не упустил, у вас получается голый кубер, рассматривали ли какие-нибудь сервис меши для него? Чем закончились результаты рассмотрения, если были?
3. Вопрос авторизации и аутентификации в микросервисной архитектуре: долго ли мучались, на чем остановились?
4. Для чего вы используете в названиях пакетов несколько слов и underscores ?)
Нередко считается плохим тоном, так лучше не использовать контекст. Если пробрасывать такого рода значения в контексте, код становится трудно поддерживать. Назначение context.Value — информирование, а не контроль логики