Несколько лет назад я прочитал статью о параллелизации в GO и ничего не понял – я тогда только начинал программировать на этом языке. Но размышления автора мне очень понравились – они подкреплялись бэнчмарками, что было довольно убедительно. Автор игрался c параметром GOMAXPROCS и показал, что увеличение этого параметра не всегда приводит к увеличению производительности. Под конец статьи он подобрал такое значение, которое будет максимально эффективным для его функции, на мое удивление, это значение оказалось равно единице! Т.е. его код работал максимально эффективно, если работал всего на одном ядре процессора! Однако, в одном из комментариев под той статьей я прочел, что все эти изыскания нелепы, поскольку та же самая функция из статьи запущенная всего в один поток оказывается эффективнее любой ее параллельной реализации.

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

Я люблю время от времени взять и переделать что-нибудь уже готовое. Цель не в том, чтобы сделать что-то лучше или доказать свою гениальность – я просто ищу опыт. Как получить опыт в разработке сложного инструмента, если ты берешь уже готовые фреймворки и пакеты и просто собираешь из них свое решение? Да, это быстро и часто довольно эффективно, но получаешь ли ты ценный опыт, узнаешь ли о вероятных подводных камнях и начнешь ли ты лучше понимать язык на котором программируешь? Конечно нет.

Сразу скажу: велосипедостроение в коммерческой разработке — зло. Создавать что-то, что уже существует и было отлажено многократно – это бессмысленно. И учитывая время, необходимое для выхода на рынок (Time To Market), это еще и опасно. Кроме того, новый код — это новые ошибки. Именно поэтому часто проще взять готовое и дополнить его до нужного уровня при работе в реальных продуктовых проектах.

Тем не менее, я противоречу сам себе, опровергая то, что сказал ранее. Я разработал на языке GO свой собственный easyjson в рамках именно продуктовой разработки, за что мне бесконечно стыдно. Если кто-то скажет, что я потратил деньги бизнес-заказчика в угоду своим амбициям, я не буду с ним спорить, но у меня были определенные причины, а главное теперь у меня есть интересный опыт. Об этом опыте я и расскажу.

Эта статья впервые появилась в журнале Computer и подготовлена InfoQ & IEEE Computer Society.

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

За десятилетие, прошедшее с появления теоремы, разработчики и исследователи использовали теорему CAP (а иногда и злоупотребляли ею) как повод для изучения широкого спектра новых распределенных систем. Движение NoSQL также использовало её в качестве аргумента против традиционных баз данных.

В теореме CAP говорится, что любая сетевая система с общими данными может иметь не более двух из трех желаемых свойств:

• согласованность (С), эквивалентная наличию единственной актуальной копии данных;
• высокая доступность (A) этих данных (для обновлений); и
• устойчивость к сетевым разделениям (P).

Такое толкование CAP помогало разработчикам быть открытыми для более широкого диапазона систем и компромиссов; действительно, за последнее десятилетие возникло множество новых систем и много споров об относительных достоинствах согласованности и доступности. Формулировка «2 из 3» всегда вводила в заблуждение, поскольку имела тенденцию чрезмерно упрощать противоречия между свойствами. Но сейчас такие тонкости имеют значение. CAP запрещает лишь крошечную часть проектного пространства: идеальная доступность и согласованность при наличии разделений, которые встречаются редко.

Давайте я сразу зайду с козырей. Сколько ошибок в коде этой функции вы можете найти за 60 секунд?

func NewConnectionString(host, path, database, user, password string, debug bool) string {
	return fmt.Sprintf(
		"proto://%s/%s?userName=%s&password=%s&database=%s&debug=%t",
		host, path, database, user, password, debug,
	)
}

Все ошибки в этом довольно небольшом коде найти и обезвредить довольно сложно. Я попробую их сейчас сформулировать и скомпоновать в две основные:

• очевидная — перепутаны параметры;
• не очевидная — параметры не экранируются.

Ладно, признавайтесь — наверняка каждый за 60 секунд смог заметить первую ошибку, но не все из вас смогут заметить вторую. Если ваш список ошибок оказался короче, чем мой — тогда прошу под кат.

В первой части этой дилогии мы написали рантайм контроллер для приложения на golang. Все что он умеет делать — запускать методы интерфейса Resources и функцию MainFunc, контролировать результат их выполнения, и корректно обрабатывать сигнал операционной системы о завершении работы. Это не так уж и много, но довольно полезно.

Теперь я постараюсь показать, как этот пакет можно использовать на примере простейшего бэкенда для апплета “Труд всем”. Немного поясню идею этого апплета. Допустим у нас есть любой сайт — от хомяка до новостной ленты, а в любом свободном углу при обновлении страницы показана случайная вакансия. Код апплета будет отправлять запрос на сервер и получать в качестве результата HTML код (уже готовый рендер) для вставки на страницу сайта.

Правда интригующе? Где же получать информацию о вакансиях? Где хранить эту информацию? Какие критерии отбора вакансий использовать? Для того, чтобы узнать ответы на эти вопросы, прошу заглянуть под кат!

Напишем вместе HTTP-сервис на golang с нуля? Я уверен, что это довольно несложно. Для тех, кто каждую неделю этим занимается, моя статья не будет особенно интересна, но я все равно рекомендую взглянуть и оценить, возможно, ваши комментарии спасут кому-то жизнь. А может кое-какие из моих рассуждений спасут вашу.

Эта статья будет полезна тем, кто некоторое время назад начал осваивать язык программирования golang и уже достиг того момента, когда может попробовать окунуться в полный цикл разработки микросервисов на этом языке. Также она подойдет тем, кто решил сменить профильный язык, и по каким-то причинам его выбор пал на golang. Я не буду останавливаться на очевидных вещах вроде конструкций языка, парадигм конкурентности и прочего, но уделю время архитектуре приложения и постараюсь заострить внимание на моментах, в которых разработчик может допустить ошибку.

Это первая часть. Первые шаги в нашем нелегком пути. И в этой статье мы попробуем достичь следующих целей:

• Выработаем понимание структуры и жизненного цикла приложения.
• Формализуем наше представление жизненного цикла на языке go.

Порой читаю в Дзене или на Хабре статьи, полные разочарования, о том, как собеседовали - собеседовали да и не взяли на работу. О том, как HRы на начальном этапе задают такие вопросы, что не сразу понимаешь, кого ищут и зачем. О том, как работодатели хотят получить senior-разработчиков по цене middle. Да что же это с миром-то произошло? Или хороших разработчиков стало пруд-пруди и работодатели начали "копаться", или наоборот, все это джуниоры обижаются и пытаются таким образом вылить свой праведный гнев на просторы интернета в виде диванной журналистики, к которой так легко лепятся комментарии в виде "Сложно все", "Идите в мировой рынок, а Россию в игнор-лист", "Они там вообще резюме не читают уже"...

Что же не так с этим миром? Почему хороший специалист не может получить хорошую работу с первого, со второго и даже с третьего собеседования? Кто в этом виноват или, может быть, мы чего-то недопонимаем?

А... Ну так давайте разбираться!

Эта статья будет полезна, если вы начинаете проект, который может перерасти в HL (HighLoad) или у вас уже есть проект, который имеет высокую нагрузку. Каждый пункт этого чек-листа поможет избежать определенных проблем, возникающих в процессе эксплуатации таких систем. И хотя некоторые пункты могут показаться довольно очевидными, а иные даже лишними, я рекомендую ознакомиться со всем списком, т.к. судя по статьям на хабре, периодически с некоторыми из этих проблем встречаются компании, которые уже обрели некоторую популярность. Дополняя систему каким то компонентом довольно просто забыть о таких вещах, как KeepAlive между двумя сервисами, а процессы изменения и дополнения в IT происходят постоянно.

Я не буду тут говорить про вертикальное и горизонтальное масштабирование, о микросервисах, балансировке нагрузки, важности тестирования и прочем таком. Будем считать, что читатели все это уже знают, ну а если кто-то не знает, пусть гуглит сейчас. Кроме того, тут вы не найдете инструкции, как проектировать и строить такие системы, цель этой статьи проста - собрать воедино какой-никакой удобоваримый чек-лист для HighLoad системы. Пункты взяты не с потолка - это результат исследовательской деятельности перемежающейся с личным опытом.