ИМ
про уменьшение сложности системы в микросервисной архитектуре - интересное утверждение
Size: a a a
2021 March 12
ИМ
я всегда думал микросервисы для всякого масштабирования нужны в основном
IV
В общем, если я правильно услышал мнение общественности, то схема “один Кубернетес в котором есть общий staging + для каждой команды по namespace для их песочницы” — это нормальный и достаточно дефолтный способ решения задачи.
не знаю насчет «дефолтный», но это точно имеет право на существование
DT
Ну не, когда у тебя монолит в который коммитят 250 человек и у которого 400+ методов API, то попилив это на куски сложность всё же снижается 🙂
E
Возникает вопрос, как сделать так, чтобы заданное приложение из общего staging ходило в моё приложение не из staging, а из песочницы (если я хочу проверить, что своим деплоем не поломаю клиентов), тут надо подумать.
Если я правильно понял, то нужен service map, где описаны пути к staging сервисам, а если ты хочешь заставить кого-то ходить в свой локальный сервис, но обновить этот конфиг
DT
Если я правильно понял, то нужен service map, где описаны пути к staging сервисам, а если ты хочешь заставить кого-то ходить в свой локальный сервис, но обновить этот конфиг
Типа того, да. Надо по этому buzzword действительно поискать👌наверняка для Кубика что-то такое есть
DT
Мы в Я.Картах это имплементировали на уровне http-server-а и передачей такого service-map-а с запросом, но хотелось чего-то более простого и “снаружи”, а не “внутри” приложения
DT
Ну не, когда у тебя монолит в который коммитят 250 человек и у которого 400+ методов API, то попилив это на куски сложность всё же снижается 🙂
(если сделать это нормально, а не в виде “распределённый монолит где всё от всего зависит и деплоить можно только всё и сразу”)
IV
Возникает вопрос, как сделать так, чтобы заданное приложение из общего staging ходило в моё приложение не из staging, а из песочницы (если я хочу проверить, что своим деплоем не поломаю клиентов), тут надо подумать.
upstream не может ходить в downstream.
Но может быть ситуация, когда upstream сервису нужно дернуть какую-нибудь ручку, например, вебхук или загрузить детали по ID. Лично я в этом случае явно передаю что нужно дергать в запросе к апстрипу чтобы избежать конфигов. Например, вместо
Но может быть ситуация, когда upstream сервису нужно дернуть какую-нибудь ручку, например, вебхук или загрузить детали по ID. Лично я в этом случае явно передаю что нужно дергать в запросе к апстрипу чтобы избежать конфигов. Например, вместо
POST /external/ task_id=42 запрос выглядит POST /external/ task_details_url=https://myservice/instance/42DT
upstream не может ходить в downstream.
Но может быть ситуация, когда upstream сервису нужно дернуть какую-нибудь ручку, например, вебхук или загрузить детали по ID. Лично я в этом случае явно передаю что нужно дергать в запросе к апстрипу чтобы избежать конфигов. Например, вместо
Но может быть ситуация, когда upstream сервису нужно дернуть какую-нибудь ручку, например, вебхук или загрузить детали по ID. Лично я в этом случае явно передаю что нужно дергать в запросе к апстрипу чтобы избежать конфигов. Например, вместо
POST /external/ task_id=42 запрос выглядит POST /external/ task_details_url=https://myservice/instance/42👌
DT
Спасибо, будет о чём подумать на выходных 🙂
IV
спасибо микросервисной архитектуре. благодаря ей только на одних консультациях как с этим всем теперь жить можно заработать миллионы
DT
тут стоит сказать, что она всегда была так-то и норм, до тех пор пока не стали сервисы размером с функцию писать
DT
и ещё пытаться всю коммуникацию из синхронного API в очереди запихать
DT
чтобы точно ничего было не понятно
A
>2) пишешь сколько бабок
Расскажите, кстати, а всегда такое, что известно сколько бабок?
У нас, например, бывает так что вилка ОЧЕНЬ разнится. Вплоть до 100-150%
Расскажите, кстати, а всегда такое, что известно сколько бабок?
У нас, например, бывает так что вилка ОЧЕНЬ разнится. Вплоть до 100-150%
сейчас меня все запинают, но я в вакансиях всегда пишу "заплтим столько, сколько захотите"
работает так же, как с неограниченным отпуском - в результате обходится дешевле.
можете начинать меня ненанвидеть
считайте это советом для владельцев бизнеса (АКА людям которым жалко денег)
работает так же, как с неограниченным отпуском - в результате обходится дешевле.
можете начинать меня ненанвидеть
считайте это советом для владельцев бизнеса (АКА людям которым жалко денег)
A
с ув, ваш manipulative bitch
ИМ
сейчас меня все запинают, но я в вакансиях всегда пишу "заплтим столько, сколько захотите"
работает так же, как с неограниченным отпуском - в результате обходится дешевле.
можете начинать меня ненанвидеть
считайте это советом для владельцев бизнеса (АКА людям которым жалко денег)
работает так же, как с неограниченным отпуском - в результате обходится дешевле.
можете начинать меня ненанвидеть
считайте это советом для владельцев бизнеса (АКА людям которым жалко денег)
я всегда думал что это так и работает =)
AS
сейчас меня все запинают, но я в вакансиях всегда пишу "заплтим столько, сколько захотите"
работает так же, как с неограниченным отпуском - в результате обходится дешевле.
можете начинать меня ненанвидеть
считайте это советом для владельцев бизнеса (АКА людям которым жалко денег)
работает так же, как с неограниченным отпуском - в результате обходится дешевле.
можете начинать меня ненанвидеть
считайте это советом для владельцев бизнеса (АКА людям которым жалко денег)
всегда ли дешевле? я же помню, что вас несколько человек супербойцов в команде. это точно работает для массового найма или найма в десятки человек? ;)
A
всегда ли дешевле? я же помню, что вас несколько человек супербойцов в команде. это точно работает для массового найма или найма в десятки человек? ;)
ну в 80% случаев, попзже напишу развернуто, щас не могу