Пока еще не понятно, как именно работает фильтр на kafka-consumer. Вот у меня consumer из активного поколения (g4), из топика пришло сообщение с g3. По идее, должно быть два сценария: 1) если есть где-то еще консьюмер из legacy-поколения g3, то нужно игнорировать это сообщение. 2) если нет консьюмеров из legacy-поколений, то нужно его попробовать обработать.
Но для этого каждый консьюмер должен знать про всех других консьюмеров (и синхронно). Как это реализуется? Или это тема следующей статьи?
А почему не рассматривались какие-то другие инструменты для хранения, кроме ElasticSearch? Тот же CH или хотя бы Influx или иные инструменты? Кажется, что использование полнотекстового движка для мониторинга по метрикам - не самое лучшее решение.
В статье постоянно путают HTTP API и REST, что вызывает серьезные сомнения в компетентности как автора, так и переводчиков. При этом никаких реально важных вещей (документация, версионирование, совместимость с сетевой инфраструктурой) не рассматривают.
Да ладно, сплошь и рядом в крупных телекомах делали и делают полную фигню, несмотря на все комитеты. Собственно, в телекомах бардак еще больший, чем в банках и куда больший, чем в средних продуктовых компаниях (где, кстати, тоже крайне редко считают ROI для проектов, там вообще чуть-чуть другой подход к развитию).
В микросервисных продуктах сложность продукта уходит из самих сервисов в их взаимодействие. Но так как за то, что "между сервисами" никто обычно не отвечает, то и продукт очень быстро начинает портится. Чем больше сервисов - тем, обычно, быстрее.
Ну, 250k платежей в день на весь мир - это очень, очень мало. Это меньше, чем заказов в день в Яндекс.Еде или покупок на Озоне в особенно неудачный день. А вот для покупок инструмента рискованных инвестиций - да, нормальное число операций с рискованным и не очень ликвидным активом.
Не совсем понятно, а какой выигрыш у GraphQL в сравнении с каким-нибудь json-rpc-like протоколом. Указанные плюсы или совсем несущественные (уменьшение числа получаемых полей) или неверны (уменьшение зависимости от бэка). А вот проблемы - очень существенные, по сути делающими невозможным работу с сколь-нибудь существенной нагрузкой и объемом данных. У GraphQL есть интересные сценарии использования - но совсем не такие, как указаны в статье.
Хм, классический ServiceLocator - это просто singleton, который реализует кучу методов типа getOrderValidator() - и в такой реализации большей части описанных проблемы не будет возникать. У такого решения, конечно, тоже дофига проблем (например то, что это синглтон), но в некоторых простых случаях это решение удобнее, чем какой-нибудь DI-контейнер. Тут же рассматривается очень специфическая реализация, которая, действительно, не очень удачная. Впрочем, часть описанных проблем будут вообще у любых IoC решений - что не повод отказываться от IoC (да и замены особой не предложено).
И почему у вас тесты начинают писать после реализации задачи, а не после планирования? По идее уже все необходимые API должны быть к этому времени согласованы, зачем тогда ждать? Глядишь, в этом случае и времени на автотесты хватило бы.
А сравнивали стоимость разработки своего фреймворка с выигрышем от использования go? С учетом стоимости переобучения, сложностей найма новых тестировщиков (тестирование на go - не самый популярный подход), стоимостью поддержки своего инструментария?
Вообще не очень понятна польза от перехода в написании тестов на go.
Статья - какой-то не очень грамотный пересказ microseriveces.io, с кучей ошибок и неточностей. После подобных статей есть отчетливое ощущение, что в Serverspace вообще не понимают того, что делают, нет никаких специалистов выше джуниора. Забавно, когда маркетинговая активность только ухудшает отношение к компании.
Статья в Fortune - явно про внутриштатовские разборки, типа "как круто Байдон разобрался с Китаем" и рассчитана на свою публику. Действия штатов, опять-таки, рассчитаны на выборы и на демонстрацию "да, демократы и с Китаем борются, не только с Россией". Реальный эффект при этом никого не волнует. Там же выборы через несколько недель...
Весь мир за очень редким исключением. Можешь посмотреть в wiki, но число стран, признающих Тайвань совсем небольшое - и это не самые значимые страны, мягко говоря.
Ну, прием заказов - это как раз про "небольшой объем данных", там не нужен ES.
Спасибо за статью!
Пока еще не понятно, как именно работает фильтр на kafka-consumer.
Вот у меня consumer из активного поколения (g4), из топика пришло сообщение с g3. По идее, должно быть два сценария:
1) если есть где-то еще консьюмер из legacy-поколения g3, то нужно игнорировать это сообщение.
2) если нет консьюмеров из legacy-поколений, то нужно его попробовать обработать.
Но для этого каждый консьюмер должен знать про всех других консьюмеров (и синхронно). Как это реализуется?
Или это тема следующей статьи?
А почему не рассматривались какие-то другие инструменты для хранения, кроме ElasticSearch? Тот же CH или хотя бы Influx или иные инструменты?
Кажется, что использование полнотекстового движка для мониторинга по метрикам - не самое лучшее решение.
Да, все это есть в Javа, в том или ином виде.
В статье постоянно путают HTTP API и REST, что вызывает серьезные сомнения в компетентности как автора, так и переводчиков.
При этом никаких реально важных вещей (документация, версионирование, совместимость с сетевой инфраструктурой) не рассматривают.
Люди не идиоты, но обычно принимают решение вне зоны своей компетентности.
Да ладно, сплошь и рядом в крупных телекомах делали и делают полную фигню, несмотря на все комитеты. Собственно, в телекомах бардак еще больший, чем в банках и куда больший, чем в средних продуктовых компаниях (где, кстати, тоже крайне редко считают ROI для проектов, там вообще чуть-чуть другой подход к развитию).
В микросервисных продуктах сложность продукта уходит из самих сервисов в их взаимодействие. Но так как за то, что "между сервисами" никто обычно не отвечает, то и продукт очень быстро начинает портится. Чем больше сервисов - тем, обычно, быстрее.
Ну, 250k платежей в день на весь мир - это очень, очень мало. Это меньше, чем заказов в день в Яндекс.Еде или покупок на Озоне в особенно неудачный день.
А вот для покупок инструмента рискованных инвестиций - да, нормальное число операций с рискованным и не очень ликвидным активом.
Не совсем понятно, а какой выигрыш у GraphQL в сравнении с каким-нибудь json-rpc-like протоколом. Указанные плюсы или совсем несущественные (уменьшение числа получаемых полей) или неверны (уменьшение зависимости от бэка). А вот проблемы - очень существенные, по сути делающими невозможным работу с сколь-нибудь существенной нагрузкой и объемом данных.
У GraphQL есть интересные сценарии использования - но совсем не такие, как указаны в статье.
То есть переход на Go был "просто так", без какого-то обоснования. И, с учетом затрат, скорее всего для компании вредным?
Хм, классический ServiceLocator - это просто singleton, который реализует кучу методов типа getOrderValidator() - и в такой реализации большей части описанных проблемы не будет возникать. У такого решения, конечно, тоже дофига проблем (например то, что это синглтон), но в некоторых простых случаях это решение удобнее, чем какой-нибудь DI-контейнер.
Тут же рассматривается очень специфическая реализация, которая, действительно, не очень удачная. Впрочем, часть описанных проблем будут вообще у любых IoC решений - что не повод отказываться от IoC (да и замены особой не предложено).
И почему у вас тесты начинают писать после реализации задачи, а не после планирования? По идее уже все необходимые API должны быть к этому времени согласованы, зачем тогда ждать? Глядишь, в этом случае и времени на автотесты хватило бы.
А сравнивали стоимость разработки своего фреймворка с выигрышем от использования go?
С учетом стоимости переобучения, сложностей найма новых тестировщиков (тестирование на go - не самый популярный подход), стоимостью поддержки своего инструментария?
Вообще не очень понятна польза от перехода в написании тестов на go.
Статья - какой-то не очень грамотный пересказ microseriveces.io, с кучей ошибок и неточностей.
После подобных статей есть отчетливое ощущение, что в Serverspace вообще не понимают того, что делают, нет никаких специалистов выше джуниора. Забавно, когда маркетинговая активность только ухудшает отношение к компании.
Статья в Fortune - явно про внутриштатовские разборки, типа "как круто Байдон разобрался с Китаем" и рассчитана на свою публику. Действия штатов, опять-таки, рассчитаны на выборы и на демонстрацию "да, демократы и с Китаем борются, не только с Россией". Реальный эффект при этом никого не волнует. Там же выборы через несколько недель...
Ну, мог сам посмотреть в wiki, зачем задавать вопрос про общедоступную информацию?
Это не является, вообще говоря, официальной политикой США.
Весь мир за очень редким исключением. Можешь посмотреть в wiki, но число стран, признающих Тайвань совсем небольшое - и это не самые значимые страны, мягко говоря.
То есть это не про собственный опыт эксплуатации, а пересказ чужой рекламы?
Кажется, это очень плохая реклама для компании.