Возникло несколько вопросов, ответ в статье не нашел:
1) Есть ли у заданий какой-то payload? Например, собрать данные по конкретному сотруднику с идентификатором, скажем "42"? Если есть - то как он сохраняется? В бд или в виде JSON в отдельном хранилище?
2) Судя по схеме - в одну PG базу данных ходят сразу 3 микросервиса (планировщик ,менеджер и диспетчер). Обычно это антипаттерн при проектировании распределенных систем. Такое решение осознанно выбрано? Почему?
3) Если под каждый тип задания создаётся свой пул микросервиса - что требуется изменить в коде системы (вроде как точно нужно менять воркеров как минимум)? В случае изменений в коде для нового типа задания - как мутирует код? Дописывается в том же репозитории или форк может быть?
Почему искать отели удобнее через агрегаторов - думаю ответ очевиден. А почему бронировать лучше напрямую - так просто потому, что отели агрегатору неплохо так комиссии отстегивают за каждое бронирование. И в некоторых случаях отелю выгодно сделать вам скидку по прямому бронированию вместо оплаты комиссии условному "booking.com"
Могу сказать - браво! Вы проделали действительно сложную работу. Ну и CTO вашему тоже браво, что тему данную протащил и поддержал (думаю не без поддержки от него все произошло).
Я бы предположил, что каждый запрос - это запрос по одному отелю. Если поисковая выдача содержит 30+ отелей, например, на одну страницу выдачи, то это уже 30+ запросов в движок от одного пользователя, а потом пользователь листает до следующей страницы (подгружает данные) или меняет даты проживания...
Сюда же добавим всяких ботов-парсеров, внешних партнёров с кривой интеграцией которые на каждый чих шлют кучу запросов и картинка, в общем-то, может сложиться.
Однако, 30к RPS звучит очень солидно, конечно, с текущими вводными.
Работаю в той же сфере, что и автор, только компания другая)
Так вот, товарищи с Канар очень быстро увидят такую ситуацию в своей Property Management System (PMS), быстренько свяжутся с вами и попросят отменить бронирование в островке(комиссия же)
Это я к тому, что отели тоже все понимают и овербукинг по такого рода ситуациям не всегда решается в минус для поставщика услуги онлайн бронирования.
А вот когда ситуация становится стабильно неприятной (много оверов в период ажиотажа, например, черные пятницы) - вот тогда у отелей возникает вопросик уже, в том числе и финансовый.
Ну и последний момент, есть такая штука у отелей как "In-house квота" - это определенное количество номеров, которые не продается онлайн, а придерживается как раз под описанные вами ситуации (таким обычно довольно зрелые отели занимаются, где развито управление доходами через оптимизацию продаж, оно же Revenue)
В статье малость прослеживается пассивность "выгорающего".
Иногда имеет смысл не "ждать что позовут на архитектурное обсуждение", а инициировать его самостоятельно. На моей памяти почти все растущие ребята - проактивны. Подсвечивают проблемы и иногда не только своему непосредственному руководителю, но и смежным командам, чтобы "обстучать" свое мнение. Многие просто общаются в "курилке" (чатах), участвуют в обсуждениях проблемы, даже если не были инициаторами обсуждения.
"на архитектурных митапах вы присутствуете как слушатель, а не участник дискуссии" - вот чистой воды пассивность. Если хочешь быть участником - надо участвовать. До ситуации, когда твоего мнения спрашивают и тихо ждут ответа, все таки, надо дорасти.
В общем и целом, конечно, есть разные ситуации и автор в своем контексте может быть прав по всем пунктам. Но на мой взгляд, как говорится, каждый сам кузнец своего счастья. Смена компании может помочь, но есть ли гарантия успеха тут - вопрос открытый...
На дотнете 10 лет и VS - единственная IDE где использую светлую тему. Вот буквально везде использую темную (даже на телефоне и в обсидиан), а в студии белую. Привычка, похоже, но на темную никак не могу пересесть, очень уж нравится сочетание цветов в комбинации с кодом на шарпе)
Согласен с тезисом "нужно делать проще", это факт и оверинжиниринг ни у чему хорошему не приводит на дистанции. Но:
Синглтон - антипаттерн ужо много лет, строитель, в вашем примере, не то, о чем писали GoF.
Суть паттерна строитель не в классе с методами SetSomething, а в комбинации builder+director. Строитель у вас это врождённое нечто из мира ООП, которое в питоне, конечно ни к чему. Ну и логики обычно там поболе, параметрами по-умолчанию не отделаешься.
Как мне кажется в статье рассмотрены самые неверно понимаемые паттерны. Экстраполировать на все остальное я бы не стал.
В общем-то паттерны существуют для того, чтобы упрощать сложную логику. Если сложной логики в приложении нет - то и накручивать смысла нет.
Однако, стратегия, например, очень даже повсеместно используемый паттерн, без которого расширяемую реализацию писать ой как тяжело.
Я честно пытался натянуть на глобус эти "прогнозы", но все таки осталось стойкое ощущение, что как и все остальные гороскопы - этот только для тех, кто верит в такого рода "предсказания".
Со всем уважением к проделанной работе! Молодцы ребята, монетзируйте свой труд, идея в целом дорогого стоит.
Возникло несколько вопросов, ответ в статье не нашел:
1) Есть ли у заданий какой-то payload? Например, собрать данные по конкретному сотруднику с идентификатором, скажем "42"? Если есть - то как он сохраняется? В бд или в виде JSON в отдельном хранилище?
2) Судя по схеме - в одну PG базу данных ходят сразу 3 микросервиса (планировщик ,менеджер и диспетчер). Обычно это антипаттерн при проектировании распределенных систем. Такое решение осознанно выбрано? Почему?
3) Если под каждый тип задания создаётся свой пул микросервиса - что требуется изменить в коде системы (вроде как точно нужно менять воркеров как минимум)? В случае изменений в коде для нового типа задания - как мутирует код? Дописывается в том же репозитории или форк может быть?
Почему искать отели удобнее через агрегаторов - думаю ответ очевиден. А почему бронировать лучше напрямую - так просто потому, что отели агрегатору неплохо так комиссии отстегивают за каждое бронирование. И в некоторых случаях отелю выгодно сделать вам скидку по прямому бронированию вместо оплаты комиссии условному "booking.com"
Могу сказать - браво! Вы проделали действительно сложную работу. Ну и CTO вашему тоже браво, что тему данную протащил и поддержал (думаю не без поддержки от него все произошло).
Я бы предположил, что каждый запрос - это запрос по одному отелю. Если поисковая выдача содержит 30+ отелей, например, на одну страницу выдачи, то это уже 30+ запросов в движок от одного пользователя, а потом пользователь листает до следующей страницы (подгружает данные) или меняет даты проживания...
Сюда же добавим всяких ботов-парсеров, внешних партнёров с кривой интеграцией которые на каждый чих шлют кучу запросов и картинка, в общем-то, может сложиться.
Однако, 30к RPS звучит очень солидно, конечно, с текущими вводными.
Работаю в той же сфере, что и автор, только компания другая)
Так вот, товарищи с Канар очень быстро увидят такую ситуацию в своей Property Management System (PMS), быстренько свяжутся с вами и попросят отменить бронирование в островке(комиссия же)
Это я к тому, что отели тоже все понимают и овербукинг по такого рода ситуациям не всегда решается в минус для поставщика услуги онлайн бронирования.
А вот когда ситуация становится стабильно неприятной (много оверов в период ажиотажа, например, черные пятницы) - вот тогда у отелей возникает вопросик уже, в том числе и финансовый.
Ну и последний момент, есть такая штука у отелей как "In-house квота" - это определенное количество номеров, которые не продается онлайн, а придерживается как раз под описанные вами ситуации (таким обычно довольно зрелые отели занимаются, где развито управление доходами через оптимизацию продаж, оно же Revenue)
Механизм для генерации вопросов на собеседовании) Вроде и понимать все должны, но с другой стороны понимание пригождается раз в пятилетку.
"В сегодня лет" узнал, что dotnet-script это не детище Microsoft.
Сначала не понял чего они такого нового сделали по сравнению с *.CSX , а оказывает вон оно как.
https://www.reddit.com/r/csharp/s/zAhlOPvPlw
На гитхабе уже
Repository unavailable due to DMCA takedown
В общем-то статья же полезна. В особенности для тех кто не знаком с multistage сборкой. Кликбейт это да, конечно. Но в целом не умаляет трудов автора.
В статье малость прослеживается пассивность "выгорающего".
Иногда имеет смысл не "ждать что позовут на архитектурное обсуждение", а инициировать его самостоятельно. На моей памяти почти все растущие ребята - проактивны. Подсвечивают проблемы и иногда не только своему непосредственному руководителю, но и смежным командам, чтобы "обстучать" свое мнение. Многие просто общаются в "курилке" (чатах), участвуют в обсуждениях проблемы, даже если не были инициаторами обсуждения.
"на архитектурных митапах вы присутствуете как слушатель, а не участник дискуссии" - вот чистой воды пассивность. Если хочешь быть участником - надо участвовать. До ситуации, когда твоего мнения спрашивают и тихо ждут ответа, все таки, надо дорасти.
В общем и целом, конечно, есть разные ситуации и автор в своем контексте может быть прав по всем пунктам. Но на мой взгляд, как говорится, каждый сам кузнец своего счастья. Смена компании может помочь, но есть ли гарантия успеха тут - вопрос открытый...
На дотнете 10 лет и VS - единственная IDE где использую светлую тему. Вот буквально везде использую темную (даже на телефоне и в обсидиан), а в студии белую. Привычка, похоже, но на темную никак не могу пересесть, очень уж нравится сочетание цветов в комбинации с кодом на шарпе)
Ну да, точно)
А потом после таких "проектировщиков" в ELK приложение 100% отвечает 200 ОК, при том что там 500-х половина. Successfully Failed антипаттерн какой-то.
Ещё и модель OSI прилетаете. Http, на секундочку, уровень "прикладной", то есть как бы как раз того самого приложения.
Работайте кодами ответов HTTP и не слушайте вредных советов и команда SRE скажет вам спасибо за это.
Дайте пожалуйста знать когда будет электронная версия. Полка для книг с картинками животных уже ломится, электронный вариант был бы удобен. Подпишусь)
Люди, значит, вайбокодят километрами листингов кода, а вы предлагаете от IDE в пользу нотпада оказаться)
Мне когда-то так же советовали писать на ассемблере. Круто, конечно, вот только зачем...
Согласен с тезисом "нужно делать проще", это факт и оверинжиниринг ни у чему хорошему не приводит на дистанции. Но:
Синглтон - антипаттерн ужо много лет, строитель, в вашем примере, не то, о чем писали GoF.
Суть паттерна строитель не в классе с методами SetSomething, а в комбинации builder+director. Строитель у вас это врождённое нечто из мира ООП, которое в питоне, конечно ни к чему. Ну и логики обычно там поболе, параметрами по-умолчанию не отделаешься.
Как мне кажется в статье рассмотрены самые неверно понимаемые паттерны. Экстраполировать на все остальное я бы не стал.
В общем-то паттерны существуют для того, чтобы упрощать сложную логику. Если сложной логики в приложении нет - то и накручивать смысла нет.
Однако, стратегия, например, очень даже повсеместно используемый паттерн, без которого расширяемую реализацию писать ой как тяжело.
Выглядит здорово! Будем ждать релиз)
Довольно таки толстенько
Я честно пытался натянуть на глобус эти "прогнозы", но все таки осталось стойкое ощущение, что как и все остальные гороскопы - этот только для тех, кто верит в такого рода "предсказания".
Со всем уважением к проделанной работе! Молодцы ребята, монетзируйте свой труд, идея в целом дорогого стоит.
Покажите программисту Шамсудину Typescript, он будет в восторге!)
А вообще типизация конечно да...
P.s. имени программиста Шамсудина в статье нет. Неуважительно как-то что ли..
Нуу.. изменилось примерно все :)
Имеет смысл ещё раз присмотреться.