С 1.14 defer поправили https://tip.golang.org/doc/go1.14#runtime "This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. "
Для микросервисов кубер с вольтом решение без минусов. Поддержка вольта в инфре с кубером задача админов и это проще, чем самописный код, который к тому же начинает знать о существовании хранилища
Возможно, я не понял задумки, но почему в примере с ограничением времени процесса. Но задача сформулирована как "не может производить какое-то действие больше 10 секунд."
А выход из функции (прерывание обработки) происходит по таймеру case <-time.After(time.Second * time.Duration(s.AllowedSecondsToProcess)): независимо от премиум аккаунт или нет. Ведь select это не бесконечных цикл обработки, а разовый выбор одного из вариантов
@apostteriori,спасибо,за мероприятие. Так быстро я еще ни в одной компании оффер не получал. Все ребята доброжелательные, приветливые и вежливые. Единственный, на мой взгляд, недочет это жесткий временной регламент для интервьюеров, с одного собеседования они фактически убегали на другое. Если они не укладывались в регламентированное время, то начинали заметно нервничали, что, на мой взгляд, сказывалось на качестве собеседования.
Чем он огромнее, тем больше команд работают над ним, все больше надо межкомандного взаимодействия и надо либо все держать в одном монорепозитории, имея растущие проблемы связанные с этим, либо разбиваться на разные репозитории и иметь свои проблемы связанные с этим.
Думаю, это основная причина по которой следует рассмотреть переход на микросервисы. Микросервисы это скорее не про архитектуру приложения, а про управление процессом разработки разработки в больших командах разработчиков.
Но к сожалению, зачастую в компаниях выбор в сторону микросервисов, принимается, на хайпе, менеджерами высшего звена. При этом команда проекта состоит из десятка разработчиков.
В контексте программного обеспечения паттерн предполагает разделение ресурсов сервиса на несколько независимых блоков, например, создание двух пулов подключений к базе данных: один для критических задач, второй для остальных.
Не совсем понятен контекст данного примера. Два пула на одну БД или это две разные БД? Почему не разделить задачи на два разных сервиса?
Хорошей практикой при реализации бизнес логики является создание собственных классов исключений. При создании такого класса исключения, разработчик путем выбора родительского класса (RuntimeExecption или Exception) как раз и определяет требуется ли откатывать транзакцию при этом исключении или нет. При таком подходе не будет возникать всех вышеописанных проблем по откату транзакций в котлине или java.
Думаю, цель статьи донести простые критерии по переходу на микросервисы, для тех кто плохо разбирается в теме. Для подробного анализа всех нюансов использования микросервисов и организации процесса существует множество книг.
Из статьи не совсем понятно про какую версию jdk идет речь, ведь с выходом каждой новой версии появляются дополнительные оптимизации, в том числе и в классе string
Из собственного многолетнего опыта работы с RI, оптимально резервировать convertible типы виртуалок. Часть резервировать на 3 года, а часть на 1 год. Т.к. aws ежегодно выпускают обновленные линейки ec2, которые как правило дешевле и быстрее, переход на которые, например, позволяет уменьшить число узлов в кластере или снизить latency. В случае convertible RI вы можете в любой момент перевести работающую инфраструктуру на новые типы в рамках текущего периода резервирования
PECS — Producer-Extends-Consumer-Super, метод отдаёт ковариантный тип, принимает контравариантный (прим. автора — последнее интуитивно не очень понятно)
Интуитивно можно понять контрвариантность как это обращение иерархии наследования по отношению к действию над иерархией, например, все операции, которые можно выполнить над object можно выполнить и над string
С 1.14 defer поправили https://tip.golang.org/doc/go1.14#runtime
"This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. "
Для микросервисов кубер с вольтом решение без минусов. Поддержка вольта в инфре с кубером задача админов и это проще, чем самописный код, который к тому же начинает знать о существовании хранилища
Возможно, я не понял задумки, но почему в примере с ограничением времени процесса. Но задача сформулирована как "не может производить какое-то действие больше 10 секунд."
А выход из функции (прерывание обработки) происходит по таймеру case <-time.After(time.Second * time.Duration(s.AllowedSecondsToProcess)): независимо от премиум аккаунт или нет. Ведь select это не бесконечных цикл обработки, а разовый выбор одного из вариантов
for i := 0; i < 10; i++ {resultChan := wp.AddJob(context.Background(),..В реальных приложениях такое делать не стоит, потому что пользовательский запрос зависнет без возможности отмены пока все работы не выполнятся
@apostteriori,спасибо, за мероприятие. Так быстро я еще ни в одной компании оффер не получал. Все ребята доброжелательные, приветливые и вежливые. Единственный, на мой взгляд, недочет это жесткий временной регламент для интервьюеров, с одного собеседования они фактически убегали на другое. Если они не укладывались в регламентированное время, то начинали заметно нервничали, что, на мой взгляд, сказывалось на качестве собеседования.
Думаю, это основная причина по которой следует рассмотреть переход на микросервисы. Микросервисы это скорее не про архитектуру приложения, а про управление процессом разработки разработки в больших командах разработчиков.
Но к сожалению, зачастую в компаниях выбор в сторону микросервисов, принимается, на хайпе, менеджерами высшего звена. При этом команда проекта состоит из десятка разработчиков.
Не совсем понятен контекст данного примера. Два пула на одну БД или это две разные БД? Почему не разделить задачи на два разных сервиса?
Хорошей практикой при реализации бизнес логики является создание собственных классов исключений. При создании такого класса исключения, разработчик путем выбора родительского класса (RuntimeExecption или Exception) как раз и определяет требуется ли откатывать транзакцию при этом исключении или нет. При таком подходе не будет возникать всех вышеописанных проблем по откату транзакций в котлине или java.
Думаю, цель статьи донести простые критерии по переходу на микросервисы, для тех кто плохо разбирается в теме. Для подробного анализа всех нюансов использования микросервисов и организации процесса существует множество книг.
Интуитивно можно понять контрвариантность как это обращение иерархии наследования по отношению к действию над иерархией, например, все операции, которые можно выполнить над object можно выполнить и над string