Писят два миллиона строк... Страшно представить... Это же как два ядра Линукс в сумме. Точно писят два? Не просто "два"?
Ну а по теме скажу так, мы тоже пробовали такой подход и нам не зашло. Из проблем было: проблемы переиспользования сервисов, глубокая вложенность сервисов (когда один вызывает второй, затем третий и в итоге - лапша), большой шанс дублирования и нелепых попыток его избегания, когда связанность проекта растет как на дрожжах.
В общем-то идея хорошая, но только для ситуаций когда такие сервисы сводятся к функциям без состояния (в том числе без работы с БД), вот тогда подход раскрывается просто за счёт того, что тестами такие функции покрыть легко, они не имеют эффектов и фактически это уже ФП.
Мы в итоге остановились на более гибком подходе - Feature slice. Эт когда для каждой фичи есть блок "сервисов", который более гибок чем стандартный шаблон одного класса(с точки зрения организации кода), но при этом сервисы не могут переиспользоваться между фичами. Таким образом high cohesion достигается из той жёлтой книжки из превью к статье. А вот переиспользуемый код уже как раз в функциональном стиле и он пишется в отдельных блоках.
Честно говоря - это не просто. Обилие логики всегда порождает связи, которые потом влияют на развитие, мешают вносить изменения и "ломают то, что мы даже не меняли*. Кажется, это проблема больших систем в целом, а не подхода в частности. Одно из решений - повальное дублирование и жёсткие контракты (формата HTTP API). Но микросервисами такой подход попахивает, а ими мы тоже уже наелись.
Что дальше? Может быть модульный монолит где каждый модуль - отдельная фича? Может быть...
Возникло несколько вопросов, ответ в статье не нашел:
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. Строитель у вас это врождённое нечто из мира ООП, которое в питоне, конечно ни к чему. Ну и логики обычно там поболе, параметрами по-умолчанию не отделаешься.
Как мне кажется в статье рассмотрены самые неверно понимаемые паттерны. Экстраполировать на все остальное я бы не стал.
В общем-то паттерны существуют для того, чтобы упрощать сложную логику. Если сложной логики в приложении нет - то и накручивать смысла нет.
Однако, стратегия, например, очень даже повсеместно используемый паттерн, без которого расширяемую реализацию писать ой как тяжело.
Я честно пытался натянуть на глобус эти "прогнозы", но все таки осталось стойкое ощущение, что как и все остальные гороскопы - этот только для тех, кто верит в такого рода "предсказания".
Со всем уважением к проделанной работе! Молодцы ребята, монетзируйте свой труд, идея в целом дорогого стоит.
Писят два миллиона строк... Страшно представить... Это же как два ядра Линукс в сумме. Точно писят два? Не просто "два"?
Ну а по теме скажу так, мы тоже пробовали такой подход и нам не зашло. Из проблем было: проблемы переиспользования сервисов, глубокая вложенность сервисов (когда один вызывает второй, затем третий и в итоге - лапша), большой шанс дублирования и нелепых попыток его избегания, когда связанность проекта растет как на дрожжах.
В общем-то идея хорошая, но только для ситуаций когда такие сервисы сводятся к функциям без состояния (в том числе без работы с БД), вот тогда подход раскрывается просто за счёт того, что тестами такие функции покрыть легко, они не имеют эффектов и фактически это уже ФП.
Мы в итоге остановились на более гибком подходе - Feature slice. Эт когда для каждой фичи есть блок "сервисов", который более гибок чем стандартный шаблон одного класса(с точки зрения организации кода), но при этом сервисы не могут переиспользоваться между фичами. Таким образом high cohesion достигается из той жёлтой книжки из превью к статье. А вот переиспользуемый код уже как раз в функциональном стиле и он пишется в отдельных блоках.
Честно говоря - это не просто. Обилие логики всегда порождает связи, которые потом влияют на развитие, мешают вносить изменения и "ломают то, что мы даже не меняли*. Кажется, это проблема больших систем в целом, а не подхода в частности. Одно из решений - повальное дублирование и жёсткие контракты (формата HTTP API). Но микросервисами такой подход попахивает, а ими мы тоже уже наелись.
Что дальше? Может быть модульный монолит где каждый модуль - отдельная фича? Может быть...
Возникло несколько вопросов, ответ в статье не нашел:
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. имени программиста Шамсудина в статье нет. Неуважительно как-то что ли..