Показать HN: Служба Go, которая предоставляет очередь сообщений FIFO в оперативной памяти ( github.com/raiyanyahya )
Поздравляем с публикацией вашего проекта!
Поскольку вы не написали много в своем посте, я не совсем уверен, каковы ваши конкретные намерения. Ожидаете ли вы, что люди будут использовать ваше приложение, ищете ли вы отзывы или советы?
Я думаю, мой первый совет: если вы хотите, чтобы его использовали другие, убедитесь, что качество немного выше, прежде чем публиковать проект. Если это скорее обучающий проект, это нормально, но тогда было бы неплохо указать это! И, возможно, попросить о конкретной помощи.
Я немного посмотрел на код и увидел некоторые странности и интересные вещи, из-за которых я не решаюсь использовать это приложение в продакшене. Я думаю, что требуется немного больше полировки, прежде чем оно будет готово к продакшену. Я не собираюсь делать полный обзор кода, но вот несколько случайных указателей на вещи, которые я заметил.
* В файле Readme говорится, что конечными точками являются POST и GET. Но так ли это? Что происходит, когда вы ставите GET в очередь или выводите HEAD из очереди? * Методы очереди обновляют глобальные переменные, действительно ли это лучший выбор дизайна? Почему бы не рассмотреть возможность помещения их в качестве полей в очередь? Если нет, то почему поля очереди не являются просто глобальными переменными? * В Go есть отличный пакет `slog` для структурированного ведения журнала JSON, и было бы довольно идиоматичным использовать его * В некоторых средах, таких как Kubernetes, реализованная процедура постепенного завершения работы завершит работу приложения, в то время как служба может по-прежнему направлять ему запросы (насколько мне известно, она отправляет SIGINT одновременно с просьбой к службе удалить pod из службы [упрощенно]) * Является ли “слишком много запросов” наиболее подходящим кодом состояния, когда метод enqueue возвращает ошибку? * Тайм-ауты сервера можно считать довольно большими, когда все, что он делает, это считывает и записывает максимум 128 КБ полезной нагрузки; желательно, чтобы такие опции были настраиваемыми в любом случае
Честно говоря, в целом это похоже на студенческий проект. Особенно из-за акцента на изложении концепций компьютерной науки и специфики Go в Readme (например, «Обнуляет каждую запись среза, чтобы трехцветный GC Go мог быстро освободить память; сбрасывает счетчики», «Мьютекс обеспечивает линеаризуемость (каждая операция кажется мгновенной). Поскольку мы удерживаем блокировку только достаточно долго, чтобы изменить срез, пропускная способность линейно масштабируется, пока не преобладает конкуренция при постановке в очередь/выводе из очереди»). В этом нет ничего плохого, но было бы неплохо обозначить это как таковое.
Также я настоятельно рекомендую книгу «100 ошибок Go и как их избежать», в которой рассматриваются некоторые моменты, которые я вижу в этом коде.
В любом случае продолжайте в том же духе и удачного вам кодирования!
Разве в Go нет встроенной параллельной очереди?
Source: news.ycombinator.com