Привет! 👋
В современной разработке мы привыкли решать проблемы производительности стандартным набором инструментов. "База не тянет? Поставь Redis!" — это стало почти рефлексом. Но всегда ли оправдано тащить в инфраструктуру лишний сервис, настраивать сетевые хопы и следить за инвалидацией, если ваша задача — это всего лишь быстрый доступ к небольшому справочнику?
В нашем Open Source проекте BMSTU-ITSTECH/SSOЧитать полностью »
Для начала хотелось бы сказать, что же такое массивы и слайсы.
Массив в Go - это структура данных, которая представляет собой упорядоченную последовательность элементов одного типа фиксированной длины.
Давайте рассмотрим на примере:
package main
func main() {
/*
Массив создаётся в таком формате:
Имя := [количество элементов массива] тип данных {элементы массива, через запятую}
*/
arr := [3]int{0, 1, 2}
fmt.Println(arr[1])
}
На примере выше был создан массив с 3-мя элементами и типом данных int.
После создания массива мы не можем изменять его вместительность, однако можем менять сами элементы.
В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе.
Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут.
Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть.
Почему стандартные решения не подошли?
Сталкивались ли вы с болью при управлении порядком запуска и остановки зависимостей в вашем Go-сервисе?
Разработка больших сервисов неизбежно приводит к необходимости управлять множеством зависимостей. В этом контексте мы говорим о долгоживущих компонентах, чья работа обеспечивается отдельными горутинами: как правило, это блокирующий метод (например, Start), внутри которого крутится цикл обработки.
Примерный сценарий жизненного цикла сервиса выглядит так:
При запускеЧитать полностью »
Привет! Это моя первая статья тут, я надеюсь получилось читабельно и интересно :-)
Привет! В данной статье хотел бы раскрыть тему - почему на 'младших' стендах api работает стабильно, но в проде начинаются проблемы: рост памяти, кол-во горутин множится, и через несколько часов - просадка производительности, gc не справляется, out of memory killer и т. д.
Давайте разберемся, что разработчику может помочь, чтобы он мог спать спокойно после деплоя своего решения. Попробуем детально разобраться в природе утечек ресурсов, научимся находить их с помощью профилировщиков и построим систему защиты от самых распространённых паттернов утечек.
Разобьем на несколько частей, в 1-ой части:
Всем привет! Меня зовут Яна Курышева, и я тимлид одной из команд разработки бэкенда в Спортсе’’.
Мы – спортивное медиа. Наш продукт – это сайт и приложения со спортивной статистикой, новостями, редакционным и пользовательским контентом, пушами, рекомендациями и комментариями.
За 25+ лет развития архитектура Спортса’’ стала достаточно разнообразной под капотом: десятки микросервисов на Go соседствуют с монолитными Perl- и PHP-приложениями, которые мы планомерно переводим на новый стек.
Чтобы вся система оставалась управляемой, мы активно используем трейсинг с помощью Elastic APMЧитать полностью »
Оригинал: Understand Go pointers in less than 800 words or your money back
Автор: Дэйв Чейни
Дата: 26 апреля 2017 г.
Проще говоря, указатель — это значение, которое указывает на адрес другого значения. Это определение из учебников, но если вы пришли из языка, который не позволяет работать с адресами переменных, эта фраза может показаться магической.
Давайте разберемся.
