Сегодня я хотел бы поделиться особенностью разработки сервисов на Golang вместе с протоколом gRPC. В этой статья я не буду рассказывать, что такое gRPC, protobuf и для чего они нужны, вместо этого я сосредоточусь на технической части.

Мы напишем простое приложение на Golang, который в качестве транспортного протокола будет использовать gRPC, а так же с помощью gRPC Gateway мы подключим поддержку RESTful API.

Введение

Как сейчас проходят собеседования на golang разработчика? Что спрашивают?

Свежая подборка новостей и материалов

Интересное в этом выпуске

Выпущены Go 1.17.7 и 1.16.14, Go 1.18 Release Candidate 1: Заметки, Самомодифицирующийся исполняемый файл на Go, Go Workspaces в Go 1.18, Gambit - шахматы в терминале, Подкаст - обсуждаем дженерики от Go Get Podcast, FQ - Инструмент для работы с бинарными данными

Приятного чтения!

Традиционно для сценариев поточной обработки с использованием Map-Reduce рассматриваются такие решения как Hadoop/Spark, либо используются конвейерные системы (например Kafka), для которых есть возможность реализовать концепцию потоков (streams) с помощью дополнительных инструментов (в случае с Kafka это Kafka Connect (для подключения к источникам и получателям потока) и Kafka Streams для реализации Map-Reduce на потоке сообщений.

Начиная с версии 3.9 RabbitMQ анонсировал поддержку нового типа очереди, оптимизированного для поточной обработки. В этой статье мы посмотрим на основные отличия очередей RabbitMQ от классического режима очереди сообщений, а также возможные сценарии использования (с примерами кода на Go).

Как переопределить интерфейсный метод от встроенной структуры.

Когда вы начинаете разрабатывать веб-приложение с применением Go, один из первых вопросов, которым вы, вероятно, зададитесь, — “Какой роутер мне следует использовать?”.

И это не такой простой вопрос, как может показаться сначала. Доступно более 100 различных роутеров с разными API, функциями и поведением. Для этой статьи я оценил 30 самых популярных из них и создал краткий список лучших вариантов вместе с блок-схемой, которую вы можете использовать, чтобы сделать свой выбор.

Привет! Меня зовут Антон, я ведущий инженер по тестированию в Ozon: занимаюсь созданием и поддержкой end-to-end Go-тестов бэкенда для QA.

Мы довольно долго писали тесты в основном на Python. Go – молодой язык, и популярных устоявшихся инструментов у него пока немного. В Python есть pytest, в Java – JUnit и TestNG, в Go – пока что весьма свободно. 

Однажды, в очередной раз переписав группу старых Python-тестов, я решил, что надо что-то менять. Эта мысль в итоге привела меня к созданию нашей собственной опенсорс-библиотеки – с поддержкой Allure без перегрузки интерфейса, инфраструктурой для хранения тестов как в одних репозиториях с сервисами, так и в отдельных, репортами в Slack и разными другими штуками.

Почему мы всё-таки решили создать своё решение, с какими сложностями пришлось разбираться в процессе и как это может пригодиться вам для тестов на Go, я расскажу в этой и следующих статьях. Сегодня – об интеграции с Allure. 

В один день одна из крупных досок объявлений начала возвращать фейковые характеристики объявлений, когда понимала, что мы - бот.

Видимо сайт добавил наш прокси в blacklist, но в нашем пуле около 100к проксей, все прокси попали в blacklist?

Попробовав запустить парсер на другом сервере, HTTP запросы возвращали корректные данные. Спустя неделю, ситуация повторилась.

Мы также попробовали отправить запрос на локальной машине с "забанненым" прокси, на удивление, данные пришли корректные, но отправив запрос с этим же прокси на сервере, получили фейковые. Отсюда вытекает вопрос: как сайт определяет, что запросы посылаются с одной машины, если используются прокси?

Прошарив весь гугл, мы узнали об интересной технологии под названием TLS Fingerprint и теперь хотим поделиться что это такое и как обойти.

Скоро выходит версия Go 1.18, и в массовом сознании она, скорее всего, будет ассоциироваться с Generic-ами. Но помимо них туда попадает еще несколько вкусных фичей. Например, Go Workspaces.

В современной микросервисной разработке очень популярна чистая архитектура (она же луковая). Этот подход ясно отвечает на много архитектурных вопросов, а также хорошо подходит для сервисов с небольшой кодовой базой. Другая приятная особенность чистой архитектуры состоит в том, что она отлично сочетается с Domain Driven Development — они отлично дополняют друг друга.

Одной из прикладных реализаций чистой архитектуры является гексагональная архитектура — подход, явно выделяющей слои, адаптеры и прочее. Данный подход заслуженно сыскал любовь среди разработчиков на Go — он не требует сложных абстракций или зубодробительных паттернов, а также почти ни в чем не противоречит сложной идиоматике языка — так называемому Go way.

Но есть проблема, которую я часто вижу во многих командах, адаптирующих гексагоны, и с которой я сам столкнулся и успешно решил — реализация транзакций базы данных в рамках DDD и пресловутого гексагона. Что у меня вышло я и расскажу в этой заметке.

Всем привет! В статье расскажу:

— Как и почему у нас возникла необычная проблема, вызвавшая поток 400-ых ошибок. 

— Как реализовали полноценную поддержку отмены операций в микросервисе.

— Как реализовали свой пул подключений к базе для переиспользования подключений к базе в рамках запроса к сервису.

— Как применили контексты в микросервисе и что от этого получили.

В работе над одним проектом нам в компании NUT.Tech понадобилась система событий, работа которой не влияла бы на основной поток выполнения программы. Как ни странно, но мы не смогли найти полностью отвечающую нашим требованиям готовую библиотеку. И тогда, конечно же, мы решили написать ее сами.

Скоро выйдет релиз 1.18 в котором появятся долгожданные дженерики. Они позволят сделать универсальные методы. Я написал пару примеров для себя. Может быть они будут интересны кому-нибудь ещё.

Сегодня мы будем анализировать бинарники на пару с CPU профилями, чтобы создать на их основе расширенные профили исполнения. Эти дополненные профили мы сможем использовать для оценки времени, которое программа тратит на проверки выхода за границу массивов и слайсов.

В настоящее время существует огромное количество консенсус алгоритмов для блокчейн систем, каждый из которых имеет свои преимущества и недостатки присущие только ему, либо целому классу сходных алгоритмов. Так или иначе, в данное время лидирует две концепции консенсуса - основанные на майнинге (PoW) [1] и форжинге (PoS) [2], которые в свою очередь представляют конкурентную и последовательную модели генерации блоков непосредственно. Такое разделение либо предполагает крайне большое расходование материальных ресурсов, либо представляет собой необходимость комбинации с другими методами консенсуса [3], что приводит к сложности реализации, а следовательно и к проблеме доказуемой безопасности конечного решения [4, с.319]. Альтернативной моделью конкуренции и последовательности может являться алгоритм объединения узлов (PoU), решающий общую задачу сообща и главным преимуществом которого является простота реализации, сродни PoW и быстрота генерации блоков, эквивалентная PoS.

В этой статье мы рассмотрим, каким образом можно использовать GitHub Actions для создания конвейера непрерывной интеграции, который автоматически тестирует, проверяет и анализирует ваш код Go.