Определимся с требованиями к нашему бэкэнду:
Из этих требований становится ясно, что нам нужен кеш. Мы не можем выполнять поиск вакансии “налету”, поскольку не уверены, что получим ответ за такое короткое время. Сам я, когда пробовал выполнять запросы к публичному АПИ поиска вакансий, получал среднее время ответа около 200 мс, что не соответствует нашим требованиям. Кроме того, сервис поиска вакансий не дает возможности рандомизировать ответ. Ну и последний довод, самый весомый: всегда кешируйте ответ сторонних сервисов, потому что это экономит ресурсы вашего сервера, сервера стороннего АПИ и драгоценное время пользователя, который ждет ваш ответ, а в случае когда сервис платный, вы сэкономите деньги.
Из кеширующих инструментов я не могу вам сегодня предложить такие замечательные вещи, как супербыстрые key-value базы данных наподобие Redis или memcached, просто потому, что это уведет нас от темы. И прошу меня простить за реализацию кеша в ОЗУ нашего приложения, все-таки у нас не такие сложные требования для того, чтобы собрать какую-то приличную систему, которая бы имела базу данных, очереди сообщений, деплоилась в кубернетес и автоматически масштабировалась. Однако, не огорчайтесь, те, кто подпишется на мой канал, наверняка дождутся и таких статей.
А сейчас GO пилить то, что есть…
Для начала разберемся, откуда будем получать информацию о вакансиях. Конечно, мы не будем генерировать ее рандомайзерами, это будут реальные данные с официального бесплатного портала. Работа России — федеральная государственная информационная система, проект Федеральной службы по труду и занятости. Этот портал помогает гражданам найти работу, а работодателям — сотрудников. Все услуги портала предоставляются бесплатно, и поэтому мы просто берем их апи и прикручиваем к своему бэкэнду в качестве ресурса.
Как вы помните из предыдущей статьи, ресурсы нашего бэкэнда мы держим в виде интерфейсов Service, т.е. структур, которые имплементируют следующие методы:
Service interface {
Init(ctx context.Context) error
Ping(ctx context.Context) error
Close() error
}
Определим какие поля требуются нашей структуре: мьютекс, потому у нас будет конкурентный доступ к списку вакансий, сам список вакансий, как слайс, может быть, http.Client, если мы хотим обернуть все тестами. Ну и давайте еще сохранять последнее время обновления списка вакансий, чтобы как-то выполнять инвалидацию кеша.
type trudVsem struct {
mux sync.RWMutex
requestTime time.Time
client *http.Client
vacancies []Vacancy
}
Обратите внимание на мьютекс, который я использую. Учитывая то, что кол-во запросов на чтение случайной вакансии будет во много раз превышать кол-во операций обновления этих вакансий, я сделал выбор в сторону RWMutex, который позволяет брать блокировку на чтение отдельно от блокировок на запись, предоставляя возможность одновременного чтения данных из разных горутин. Будем использовать метод RLock для блокировок при чтении, это позволит нескольким горутинам выполнять чтение одновременно, пока нет никаких операций записи. А простой Lock для блокировок при записи, позволит блокировать небезопасный конкурентный доступ к защищаемой памяти, как в обычном мьютексе (под капотом там именно обычный мьютекс).
Итак. Проштудировав документацию открытого АПИ сервиса “Работа России” я собрал структуры, необходимые для маппинга Json данных. Возможно будет немного избыточно, и некоторые поля мы вообще не задействуем в дальнейшем, но я подумал, что лучше будет удалить потом, чем постоянно сверяться с документацией и добавлять какие-то поля в процессе разработки. Кроме того, как ни крути, количество данных в сети мы изменить не сможем — чужой АПИ нам все равно будет присылать все что знает независимо от того, есть ли у нас под эти данные соответствующие поля в наших структурах или нет.
Раскройте, чтобы увидеть код этих структур
Для тех, кто знает как работает маршалинг структур в GO, тут нет ничего нового, для остальных немного пояснения: теги (текст в одинарных кавычках), прилагаемые к полям структур, не влияют непосредственно на маппинг данных или сериализацию, тут опять нет никакой магии. Теги используются для получении информации о полях структур в рантайме. Для получения доступа к ним используется пакет reflect, который еще называют рефлексией в go. Я об этом говорю, потому что если вы хотите строить легковесные и производительные алгоритмы, то не стоит использовать рефлексию и ничего, что прямо или косвенно ее использует, вместо этого есть кодогенераторы, которые, пользуясь рефлексией, создают в своем рантайме уже готовый код на языке go, который содержит все необходимые для маршалинга/демаршалинга функции, которые, в свою очередь, уже в нашем рантайме не используют рефлексию. К таким относятся, например пакет easyjson. Подход с кодогенерацией не на много сложнее, чем подход с использованием json.Decoder, но мы его использовать пока не будем в силу того, что это опять мимо темы.
Давайте же займемся реализацией интерфейса. Первым у нас будет метод Init, который должен подготовить все ресурсы сервиса к работе. Сделаем следующее: проинициализируем рандомизатор, выберем http-клиент по умолчанию и сразу выделим необходимое место в памяти под список вакансий.
func (t *trudVsem) Init(context.Context) error {
rand.Seed(time.Now().UnixNano())
t.client = http.DefaultClient
t.vacancies = make([]Vacancy, 0, prefetchCount)
return nil
}
Для новичков сделаю еще одну ремарку: использование пакета rand может быть обосновано только в алгоритмах, которые не чувствительны к качеству генератора случайных чисел, в других случаях (например, в криптографических алгоритмах), требуется использование генератора из пакета crypto/rand.
Следующим в очереди будет метод Ping, как мы помним, он должен использоваться для самодиагностики и возвращать error, если произошла критическая ошибка, которая не позволяет работать дальше. Такой случай для этого сервиса я себе представить пока не могу, поэтому будем возвращать всегда nil. Функция Ping будет вызываться контроллером рантайма, а если быть точнее, ServiceKeeper должен циклично пинговать наши сервисы с определенными промежутками времени до тех пор, пока не получит команду на завершение работы. Давайте глянем, как ее реализовать.
func (t *trudVsem) Ping(context.Context) error {
if time.Since(t.requestTime).Minutes() > 1 {
t.requestTime = time.Now()
go t.refresh()
}
return nil
}
Проверяем время обновления кеша, если прошло больше минуты, инициируем обновление кеша в фоновой горутине, чтобы не ломать процесс анализа работоспособности сервиса. Возвращаем nil. И вот вам вопрос на засыпку: какая ошибка в имплементации этой функции? Подсказка следующая: синтаксических ошибок нет, все прекрасно компилируется и замечательно работает. Давайте подискутируем об этом в комментариях?
Последняя функция имплементирующая интерфейс Service, необходимая для того, чтобы нашу структуру можно было считать сервисом и передать в ServiceKeeper под контроль. И в ней нечего обсуждать — она идеальна.
func (t *trudVsem) Close() error {
return nil
}
Поскольку функция рефреша списка вакансий должна обновлять данные списка вакансий, то именно в ней мы должны использовать блокировку записи (чтения/записи). После выполнения t.mux.Lock() чтение списка вакансий будет недоступно, пока не выполнится t.mux.Unlock(), но мы должны будем гарантировать это выполнением t.mux.RLock() в читающей функции. Прошу обратить внимание на следующую деталь: с самого начала функции никакие блокировки не ставятся, а выполняется функция вызывающая загрузку обновленных вакансий loadLastVacancies само выполнение этой функции не приводит к обновлению списка, поэтому блокировок тут не нужно. Это кажется очевидным, но тем не менее, ситуация, когда разработчик оборачивает в Lock/Unlock лишние операции, довольно распространена. Всегда ограничивайте блокировкой наименьший участок кода, все, что можно выполнить без блокировок, нужно выполнять без блокировок. Блокировки — это всегда вынужденное зло.
func (t *trudVsem) refresh() {
vacancies, err := t.loadLastVacancies(context.Background(), "программист", 0, prefetchCount)
if err != nil {
log.Println(err)
return
}
t.mux.Lock()
t.vacancies = t.vacancies[:0]
for _, v := range vacancies {
t.vacancies = append(t.vacancies, v.Vacancy)
}
t.mux.Unlock()
}
Вероятно, все знают, почему я использовал t.vacancies = t.vacancies[:0] а не make([]Vacancy, 0, prefetchCount). Это сделано для уменьшения кол-ва аллокаций памяти. На самом деле этот участок кода не критичный и выделение памяти в этом месте не приведет к деградации даже при самых высоких нагрузках, но я позволил себе сумничать. Выражение slice[:0] просто установит длину слайса (len) в 0, оставив его вместительности (cap) прежнее значение, а это значит, что выполнение append будет наполнять слайс заново, просто перетирая старые значения новыми.
Теперь посмотрим, как выполняется загрузка вакансий, комментарии по коду четко отделяют три этапа этой функции: создание запроса, передача его по сети, парсинг ответа. Если какой-то из этапов вернет ошибку, мы просто пробросим ее в качестве ответа для вызывающей функции.
func (t *trudVsem) loadLastVacancies(ctx context.Context, text string, offset, limit int) ([]VacancyRec, error) {
// создадим HTTP-запрос для получения данных
req, err := newVacanciesRequest(ctx, text, offset, limit)
if err != nil {
return nil, err
}
// выполняется запрос данных
resp, err := t.client.Do(req)
if err != nil {
return nil, err
}
// выполняем парсинг данных
parsed, err := parseResponseData(resp)
// не забываем закрывать Body
resp.Body.Close()
return parsed.Results.Vacancies, err
}
Давайте посмотрим, как выполняется создание HTTP-запроса:
func newVacanciesRequest(ctx context.Context, text string, offset, limit int) (*http.Request, error) {
URL, err := url.ParseRequestURI(serviceURL)
if err != nil {
return nil, err
}
query := url.Values{
"text": []string{text},
"offset": []string{strconv.Itoa(offset)},
"limit": []string{strconv.Itoa(limit)},
"modifiedFrom": []string{time.Now().Add(-time.Hour * 168).UTC().Format(time.RFC3339)},
}
URL.RawQuery = query.Encode()
return http.NewRequestWithContext(ctx, http.MethodGet, URL.String(), http.NoBody)
}
И тут есть о чем подискутировать, ведь в самой первой строке я выполняю парсинг константы! Каждый раз вызов этой функции будет выполнять парсинг константы serviceURL и даже возвращать ошибку, если она возникнет. Как-то не очень умно, да? Можно же было использовать литерал url.URL структуры. А еще весьма прилично и даже наглядно будет смотреться вызов функции форматирования fmt.Sprintf, как в примере под спойлером.
Пример
Но я сейчас сам отвечу на свой же вопрос. Я хочу быть уверенным в том, что сделал минимум ошибок: в нелепом тексте ?text=%s&offset=%d&limit=%d&modifiedFrom=%s так легко допустить синтаксическую ошибку и так трудно ее искать потом. Кроме того, ошибку можно допустить, устанавливая значение константы serviceURL. Я не говорю уже о том, что не все параметры в примере с fmt.Sprintf были обернуты в url.QueryEscape и я не знаю, кто будет решать, какой параметр нужно оборачивать, а какой нет. И самое главное, я не могу дать гарантии, что доработка такого кода не сломает логики; кто-то может сломать форматирующую строку или добавить параметр, который не будет проходить через QueryEscape, и у нас выйдет какой-нибудь нелепый query injection.
Преимущества моего варианта в том, что ParseRequestURI может обнаружить некоторые синтаксические ошибки в константе serviceURL, далее литерал url.Values и вызов его метода Encode позволит правильно вписать пары ключ/значение в наш HTTP-запрос, он экранирует все недопустимые символы по всем канонам URL, и никаких ошибок тут не будет. Ну и как итог URL.String() вернет нам какую-то гарантию корректного URL. Единственное, что можно было бы сделать — вынести парсинг константы отдельно, но этот участок кода настолько нетребователен к производительности, что разделять эту логику и выносить куда-то ее часть, я считаю нецелесообразным.
Немного по поводу длинного и неприятного выражения time.Now().Add(-time.Hour * 168).UTC().Format(time.RFC3339). Его логика, думаю, всем понятна — мы получаем текущее время, уменьшаем его на 168 часов (это ровно неделя), переводим в UTC и форматируем по стандарту RFC3339 — это то, чего от нас ждет сервис вакансий. Но я хотел сказать другое. Когда мы видим в коде среди простых выражений сложное, у нас должно возникать желание упростить код. Давайте же спрячем это страшное выражение внутрь функции и вместо него будем вызывать функцию:
const hoursInWeek = 168
func modifiedFrom() string {
return time.Now().Add(-time.Hour * hoursInWeek).UTC().Format(time.RFC3339)
}
Парсинг ответа от сервиса вакансий будет состоять из демаршалинга тела http.Response в нашу структуру с помощью базового json.Decoder и минимальной проверки на валидность этих данных. Ничего такого о чем бы я хотел сказать отдельно.
func parseResponseData(resp *http.Response) (result Response, err error) {
decoder := json.NewDecoder(resp.Body)
if err = decoder.Decode(&result); err != nil {
return
}
// мы ожидаем статус 200
if result.Status != "200" {
err = errors.New("wrong response status")
return
}
// если вакансий в слайсе нет, тут явно что-то не то
if len(result.Results.Vacancies) == 0 {
err = io.EOF
}
return
}
Итак, вот наш первый checkpoint — готов единственный ресурс нашего бэкэнда. Готов сервис бесплатных вакансий. На уровне кода он плоский с единственной внешней связью в виде вызова стороннего АПИ через HTTP и никаких кешей и прочих премудростей. На верхнем уровне мы считаем, что у него все-таки есть кеш, потому что для выполнения своих функций, ему не требуется выполнять вызов стороннего апи.
В предыдущей статье я описал код runtime-контроллера, а в главе выше описал код сервиса вакансий, который будет являться единственным ресурсом нашего бэкэнда. Теперь пора аккумулировать полученный опыт и построить работающее приложение. Вероятно, из предыдущей статьи не становится понятным, как использовать runtime-контроллер так, чтобы изнутри кода с бизнес-логикой были доступны ресурсы приложения. Но давайте сейчас посмотрим на код main:
type server struct {
// все ресурсы нашего бэкэнда перечислены здесь
trudVsem trudVsem
}
func main() {
var srv server
var svc = appctl.ServiceKeeper{
Services: []appctl.Service{
&srv.trudVsem, // регистрируем ссылку на ресурс trudVsem
},
PingPeriod: time.Millisecond * 500, // периодичность вызова Ping
}
var app = appctl.Application{
MainFunc: srv.appStart, // эта функция будет запущена с Run
Resources: &svc, // регистрируем ServiceKeeper
TerminationTimeout: time.Second * 10, // для порядка
}
// стартуем
if err := app.Run(); err != nil {
logError(err)
os.Exit(1)
}
}
Немного освежим память. Структура server понятна — она состоит всего из одного поля — структуры сервиса вакансий trudVsem. Это не интерфейс и оно не скрывает реализации, кроме того, я поместил весь код этого приложения внутри одного пакета, а это значит, что никакого сокрытия реализации тут не будет и из кода с бизнес логикой мне будут доступны даже приватные методы и поля структуры trudVsem. Не делайте так, когда пишете реальное приложение. Я же себе это позволил, потому что это снова вне темы. Просто хочу сказать, что тот сервис, который я передал ServiceKeeper на контроль, как ресурс приложения, мы должны передать в качестве сервиса в функцию выполняющуюся, как основной поток. MainFunc будет запущена строго после того, как все ресурсы будут проинициализированы и у нас есть гарантия, что trudVsem.Init к тому времени уже будет успешно выполнено.
Структура Application получает указатель на ServiceKeeper и знает только о том, что нужно запустить Init, выполнить в фоновой горутине Watch и следить за сообщениями от ОС. Вся эта логика будет запущена в то время, когда мы вызовем Run и любое из следующих трех событий позволит потоку выполнения пойти дальше:
А что там еще за logError? Это я обернул логирование ошибки в вызов функции, чтобы не сильно нагружать по коду вызовами fmt.Errorf.
func logError(err error) {
if err = fmt.Errorf("%w", err); err != nil {
println(err)
}
}
Функция appStart будет запускать HTTP сервер из стандартного пакета net/http. Я в очередной раз прошу прощения за magic в коде. Все таймауты и номера портов должны быть спрятаны под конфигами. Конфигурацию можно передать, как переменные окружения операционной системы, опции командной строки или в конфигурационном файле. В идеале следует предусмотреть все три способа передачи конфигурации, возможно, мы с вами займемся этим в будущих статьях, но сейчас для демонстрации результатов мы это опустим.
В стандартной реализации HTTP сервера уже предусмотрен процесс мягкого завершения работы (Graceful Shutdown) с помощью метода Shutdown. В документации сказано, что вызов этого метода приведет к отключению HTTP сервера без прерывания выполнения текущих запросов. Сначала будет выключен листенер, чтобы предотвратить поступление из сети новых запросов, затем будут разорваны все спящие соединения (в состоянии IDLE), а затем будет выполнено ожидание завершения обработки активных запросов и выход.
Я бы описал логику главной функции в такой последовательности: создаем сервер, запускаем на нем обработку запросов, ожидаем сигнала через halt канал и вызываем мягкое завершение работы. В действительности же вышла не очень простая функция с горутиной внутри и каналом для конкурентной передачи возникающей в процессе ошибки.
Код функции appStart(context.Context, <-chan struct{}) error
В качестве Handler для HTTP сервера мы передаем сам указатель на структуру server, для того, чтобы наша структура могла стать обработчиком HTTP запросов, мы должны имплементировать метод ServeHTTP. В качестве Addr нужно передавать адрес локального порта, на котором будем ожидать запросы. В моем случае это будет порт 8900 на всех доступных сетевых интерфейсах. И в качестве BaseContext я порекомендовал HTTP серверу отдавать контекст с которым была запущена функция appStart. Может быть, это решение не очень аккуратное, потому что хоть на данном этапе у нас и есть гарантии, что контекст не будет отменен внезапно и незапланированно, но никаких гарантий в том, что это не станет происходить в дальнейшем, когда мы или кто-то другой станет развивать пакет с runtime-контроллером. Я бы рекомендовал для обработки HTTP запросов использовать всегда чистый контекст — в нем корректная информация о статусе и мы получаем cancel только когда клиент сам закрывает соединение.
Обратите внимание на запуск горутины в середине функции. Это вынужденная необходимость, поскольку вызов ListenAndServe блокирует дальнейшее выполнение. Мы должны предусмотреть варианты вызова Shutdown в случае получения сигнала через канал halt — этот канал, напомню, закрывается, когда операционная система передала сигнал о завершении работы. Дополнительно к этому случаю я добавил еще один случай, когда мы выполняем Shutdown — при “протухании” основного контекста case <-ctx.Done(), таким образом в коде появляется select с двумя кейсами.
В нижней части функции я читаю из канала, который использую для передачи информации об ошибке мягкого завершения работы. Выполнение функции может не дойти до этого участка кода, если ListenAndServe вернет какую-то ошибку, которая немедленно будет отдана в качестве результата для вызывающей функции. Однако, если ошибки не произошло, мы можем проверить корректно ли завершилась операция Shutdown, для этого в канал errShutdown передается ошибка, если таковая возникла. Обратите внимание на то, что я сделал этот канал буферизованным, это значит, что процесс записи в него не остановит выполнение горутины, в противном случае мы рискуем “замерзнуть” в месте выполнения errShutdown <- err и получить “утечку горутины”.
err, ok := <-errShutdown
if ok {
return err
}
return nil
Напомню, что чтение из канала возвращает кортеж, вторым значением которого будет булево значение, показывающее успешность чтения данных. Простыми словами, если ok != true, значит в канале нет данных и он уже закрыт.
Мне нравится эта функция тем, что она оставляет некоторый простор для рефакторинга. Мы можем попробовать вынести из нее литерал http.Server и запуск горутины, контролирующей сигнал halt. Можем завернуть все magic numbers в конфигурацию и как-нибудь иначе выполнить синхронизацию ошибки вызова Shutdown. Но я пока просто оставлю это здесь.
Теперь у нас есть еще один checkpoint — реализация мягкого завершения полностью самодостаточна, все функции, вызываемые ниже по коду уже не должны заботиться о корректной работе сервера в целом, им достаточно будет убедиться, что их работа выполнена корректно.
Давайте начнем реализацию бизнес-логики. При получении запроса мы должны обратиться к сервису trudVsem и попросить у него случайную вакансию. Если данных нет, вернем HTTP 204 No Content, если что-то есть, выполним рендер вакансии в HTML и вернем его в качестве ответа.
Раскройте, чтобы увидеть код ServeHTTP и renderVacancy
Принимая во внимание то, что выглядит это не очень, я сделаю небольшое отступление от основной темы. У меня вышла довольно сложная для восприятия функция renderVacancy к тому же, скорее-всего, она будет в большей степени влиять на производительность. А еще код бизнес-логики вшит прямо в обработчик запросов, хотя, нам для примера сойдет. В конце-концов, чтобы немного упростить код, мы могли бы сделать следующее:
И изменить нашу логику примерно вот так:
Раскройте, чтобы поглядеть, что вышло
Да, выглядит получше, но такой рендер снизит скорость обработки запроса в два раза. Правда-правда, я проверял. Это вполне рабочий вариант, но без шаблона с одними только w.WriteString(fmt.Sprintf на моем компьютере я получаю около 220к RPS, а с шаблонизатором чуть больше 100к (нагрузочное тестирование будет дальше).
Что можно сделать еще? Чтобы увеличить производительность, мы можем попробовать заранее создавать буфер данных []byte и заполнять его с помощью append, а не w.WriteString(fmt.Sprintf. По понятным причинам такой подход еще сильнее усложнит код, а толку от него будет не очень много — мы можем снизить количество аллокаций и может даже избавимся от нескольких случаев “убегания в кучу”, но не от всех. Еще мы можем сразу писать в http.ResponseWriter, вроде как хорошая идея, но тоже не даст прироста производительности. А если сделать наоборот — чтобы упростить код, мы можем разбить рендер на отдельные блоки: блок рендера заголовка, описания компании, условий труда и отдельно блок с заработной платой. Вот и отлично, пока оставим в голове этот план и вернемся к нашим баранам.
Функция выборки случайной вакансии, которую мы использовали, но еще не описали, содержит обещанный RLock в качестве блокировки при чтении. Это позволяет множеству горутин выполнять этот код не мешая друг другу. Единственное, что заблокирует вход сюда, это Lock при обновлении списка вакансий. Выбор случайной вакансии нам поможет сделать rand.Intn(len(t.vacancies)).
func (t *trudVsem) GetRandomVacancy() (vacancy Vacancy, ok bool) {
t.mux.RLock()
defer t.mux.RUnlock()
if ok = len(t.vacancies) > 0; !ok {
return
}
vacancy = t.vacancies[rand.Intn(len(t.vacancies))]
return
}
Итак, кажется, что все готово. Пора проверить на работоспособность. Я запускаю приложение и перехожу по адресу http://localhost:8900/test. Выглядит так, как будто сработало: я вижу вакансию на должность программиста; обновляю страницу и вижу следующую вакансию. Но давайте проверим, производительность нашего приложения. Все-таки в требованиях указано 100 RPS.
Нагрузочное тестирование удобно проводить с помощью утилиты wrk. Wrk легко устанавливается и позволяет настраивать параметры нагрузочного тестирования. Для своих тестов я решил использовать 15 активных коннектов и 10 рабочих потоков. Для этого запускаю утилиту с ключами -t 10 -c 15. Первый тест сразу обрадовал, я получил результат ~224k RPS. И среднее время ответа в 68 микросекунд, а максимальное в 20 миллисекунд, что явно удовлетворяет нашим требованиям. Вот детализированные результаты тестирования:
devalio@devastator:~$ wrk -t 10 -c 15 http://localhost:8900/test
Running 10s test @ http://localhost:8900/test
10 threads and 15 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 68.69us 223.22us 20.48ms 97.01%
Req/Sec 22.52k 842.70 25.47k 76.31%
2260841 requests in 10.10s, 1.51GB read
Requests/sec: 223848.81
Transfer/sec: 153.06MB
Ну что ж, отлично! Двойной резерв по производительности, это то, что нам нужно. А среднее время ответа даже меньше миллисекунды. Но нужно ли на этом останавливаться? Кажется, я там пропустил одну функцию, реализация которой была не самым удачным примером кода. Да, были какие то мысли, как можно ее переделать, но они строились на предположениях, а не на фактах. Что-то придется с этим делать.
Ну вот, я сам себя раздразнил и поскольку уже обещал показать, как я рассуждал в процессе, придется быть честным и приступить к рефакторингу функции renderVacancy. Недолго думая, я посмотрел, какой процент времени выполнение запроса проводит в этой функции. Для этого добавил в секцию импорта _ "net/http/pprof", а в самое начало функции main вот такой вызов HTTP-листенера:
go http.ListenAndServe(":9900", nil)
Пакет net/http/pprof при подключении сам настраивает роутинг по умолчанию, поэтому сразу имею доступ ко всем полезным функциям профилировщика. Когда мы снимаем профили, обязательно нужно, чтобы приложение было нагружено, иначе мы будем видеть метрики “холостого хода”, поэтому я запускаю нагрузочный тест, увеличив время его выполнения до 20 секунд, и одновременно с этим запускаю команду на снятие профиля:
devalio@devastator:~$ go tool pprof http://localhost:9900/debug/pprof/profile?seconds=15
Fetching profile over HTTP from http://localhost:9900/debug/pprof/profile?seconds=15
Saved profile in /home/devalio/pprof/pprof.___go_build_github_com_iv_menshenin_appctl_example.samples.cpu.001.pb.gz
File: ___go_build_github_com_iv_menshenin_appctl_example
Type: cpu
Time: Nov 16, 2021 at 6:24am (MSK)
Duration: 15s, Total samples = 26.97s (179.80%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof)
Для тех, кто не пользуется go tool pprof или не знает об этом инструменте, очень рекомендую изменить свое мнение и нагуглить хорошие инструкции по работе с этим профилировщиком. А пока покажу немногое из того, что он умеет.
Конечно, первое, на что я хочу взглянуть — это диаграмма, которая доступна из профилировщика с помощью команды web — откроется страница браузера с вот такой картинкой. Неправда ли, очень наглядно. Тут показано, какое количество процессорного времени было уделено той или иной функции.
На этом графике я выделил блок, который меня интересует. Обратите внимание на то, что сама обработка запроса (суммарно за все время профилирования) заняла около 5 секунд процессорного времени, а из них чуть больше 3х секунд ушло на renderVacancy.
Следующая команда, которая мне нравится — list, позволяет показать исходный код и расставить ключевые метрики прямо напротив строки кода к которым они относятся. В качестве аргумента эта команда может принимать шаблон поиска по коду, я ввожу list ServeHTTP, чтобы найти функцию обработки HTTP-запроса. Поглядите на картинку ниже, слева от исходного кода мы увидим два столбца. Первый столбец показывает какое кол-во процессорного времени взяла на себя функция, исходный код которой мы видим на экране, без учета времени вложенных в нее функций. Второй — суммарное процессорное время с учетом вложенных вызовов. А вот и наш data, err := renderVacancy(vacancy) — обратите внимание на то, что в левом столбце пусто, а в правом 3 секунды, это значит, что время, потраченное на выполнение этой части кода, относится не к функции ServeHTTP, а ко вложенному в нее вызову renderVacancy.
Т.е. львиная доля Latency, который мы видим в нагрузочных тестах, уходит на рендер вакансии в HTML формат, что дает мне повод заняться оптимизацией в этом месте. И, конечно же, я пошел самым простым путем: решил выполнить рендер прямо в сервисе, который хранит вакансии, ведь данные вакансий не изменяются, а поэтому нам не нужно выполнять рендер “налету”.
Я добавил поле render []byte к структуре Vacancy, вынес рендер вакансии в сервис вакансий и разбил его на кусочки. Затем разбил страшную процедуру рендера на небольшие куски. Итоги рендера я сохраню в поле render и, когда мне потребуется получить вакансию, я буду сразу лить ее в HTTP-респонз вот так:
func (s *server) ServeHTTP(w http.ResponseWriter, _ *http.Request) {
vacancy, ok := s.trudVsem.GetRandomVacancy()
if !ok {
w.WriteHeader(http.StatusNoContent)
return
}
w.Header().Add("Content-Type", "text/html;charset=utf-8")
w.WriteHeader(http.StatusOK)
// сразу вливаем готовый HTML в ResponseWriter
if err := vacancy.RenderTo(w); err != nil {
logError(err)
}
}
. . .
// а эта функция находится в пакете с сервисом “Труд всем”
func (v Vacancy) RenderTo(w io.Writer) error {
_, err := w.Write(v.render)
return err
}
Раскройте, чтобы увидеть функции рендера
Еще немного поразмыслив, я понял, что теперь мне незачем хранить слайс элементов в структуре Vacancy, теперь достаточно будет хранить массив готовых HTML, и сделал еще кое-какие изменения:
type (
VacancyRender []byte
trudVsem struct {
mux sync.RWMutex
requestTime time.Time
client *http.Client
vacancies []VacancyRender // вот тут
}
)
// и тут
func (r VacancyRender) RenderTo(w io.Writer) error {
_, err := w.Write(r)
return err
}
// и вот этот кусочек вот в этой функции
func (t *trudVsem) refresh() {
. . .
var newVacancy = v.Vacancy
if rendered, err := newVacancy.renderBytes(); err == nil {
t.vacancies = append(t.vacancies, rendered)
}
. . .
Провел нагрузочное тестирование еще раз и получил прирост производительности аж на 30%. Теперь вижу следующие результаты:
10 threads and 15 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 64.87us 251.00us 9.09ms 97.39%
Req/Sec 29.48k 2.09k 34.76k 64.72%
2959186 requests in 10.10s, 1.97GB read
Requests/sec: 292990.05
Transfer/sec: 199.60MB
Хорошо. Я остался доволен производительностью этого приложения. Немного беспокоит то, что рендер теперь выполняет сервис trudVsem, а я хотел от него только получение/хранение пакета вакансий. Но с этим могу смириться, поскольку свою цель считаю достигнутой: я показал, как можно использовать пакет, который мы написали в предыдущей статье.
Начиная первую из двух статей “Пишем сервис на GO”, я задался целью: показать, как можно построить простое но полноценное веб-приложение на GO. Какие нюансы нужно учитывать при разработке веб-сервиса и на что нужно обращать внимание — это все я постарался разобрать. Да, согласен, в своей статье я описал весьма простое приложение, которое можно было уместить в 100-200 строчек кода, но мне кажется, что даже в решении такой мелкой задачи мне удалось найти и обратить внимание на определенные нюансы разработки веб-сервисов на GO.
Конечно, писать плоский и неструктурный код не задумываясь, что у приложения есть жизненный цикл — это довольно легко. И на самом деле даже может что-то получиться, но чем больше разрастается функциями наше приложение, тем сложнее нам понять, где та самая ниточка, дернув за которую мы заставим наше приложение правильно закрыться. Может для кого-то эта проблема выглядит, как из пальца высосаная, ведь есть же теперь всякие кубернетесы — все, что упало поднимут заново, ну а если наше приложение перед завершением наплодит 500-ых респонзов, то на балансировщике можно выкрутиться ретраями. Но я встречал в своей практике веб-приложение, которое закладывалось, как приложение могущее в перспективе HighLoad, но фактически не поддерживающее не только Graceful Shutdown, но и банальных ContextTimeout. Поэтому постарался вложить между строк правильное понимание структуры go-приложений — такие штучки, как каналы для синхронизации при конкурентности или мьютексы, которые могут блокировать запись и при этом разрешать одновременное чтение. А в некоторых местах попробовал спорить сам с собой, чтобы показать, что в разработке не все так однозначно — где-то нам нужен быстрый код, а где-то мы можем написать код не очень производительный, но зато более стабильный. Все-таки разработка — это процесс непрерывного появления на свет какой-то истины в форме имплементации поставленной задачи на определенном языке программирования, а что помогает рождать истину? Конечно дискуссии и споры.
Чего мы достигли в процессе разработки кода, описанного в этих статьях:
Что ж, я считаю достижение этих целей достойной наградой за потраченное время. Если кому-то статья показалась полезной, можете поставить лайк. Если есть такие, для кого эта статья разрушила последний барьер на пути к большому плаванию под эгидой “пишу микросервисы на golang с нуля”, то я более чем доволен. Прошу ознакомиться с полным кодом на моем github.
habr.com
- Выборка осуществляется из 25 последних опубликованных за прошедшую неделю вакансий по ключевому слову "программист".
- По запросу выдавать случайную вакансию из этой выборки.
- Рассчитываем на RPS близкий к 100к.
- Среднее время ответа 60 мс.
Из этих требований становится ясно, что нам нужен кеш. Мы не можем выполнять поиск вакансии “налету”, поскольку не уверены, что получим ответ за такое короткое время. Сам я, когда пробовал выполнять запросы к публичному АПИ поиска вакансий, получал среднее время ответа около 200 мс, что не соответствует нашим требованиям. Кроме того, сервис поиска вакансий не дает возможности рандомизировать ответ. Ну и последний довод, самый весомый: всегда кешируйте ответ сторонних сервисов, потому что это экономит ресурсы вашего сервера, сервера стороннего АПИ и драгоценное время пользователя, который ждет ваш ответ, а в случае когда сервис платный, вы сэкономите деньги.
Из кеширующих инструментов я не могу вам сегодня предложить такие замечательные вещи, как супербыстрые key-value базы данных наподобие Redis или memcached, просто потому, что это уведет нас от темы. И прошу меня простить за реализацию кеша в ОЗУ нашего приложения, все-таки у нас не такие сложные требования для того, чтобы собрать какую-то приличную систему, которая бы имела базу данных, очереди сообщений, деплоилась в кубернетес и автоматически масштабировалась. Однако, не огорчайтесь, те, кто подпишется на мой канал, наверняка дождутся и таких статей.
А сейчас GO пилить то, что есть…
Труд всем
Для начала разберемся, откуда будем получать информацию о вакансиях. Конечно, мы не будем генерировать ее рандомайзерами, это будут реальные данные с официального бесплатного портала. Работа России — федеральная государственная информационная система, проект Федеральной службы по труду и занятости. Этот портал помогает гражданам найти работу, а работодателям — сотрудников. Все услуги портала предоставляются бесплатно, и поэтому мы просто берем их апи и прикручиваем к своему бэкэнду в качестве ресурса.
Как сервис
Как вы помните из предыдущей статьи, ресурсы нашего бэкэнда мы держим в виде интерфейсов Service, т.е. структур, которые имплементируют следующие методы:
Service interface {
Init(ctx context.Context) error
Ping(ctx context.Context) error
Close() error
}
Определим какие поля требуются нашей структуре: мьютекс, потому у нас будет конкурентный доступ к списку вакансий, сам список вакансий, как слайс, может быть, http.Client, если мы хотим обернуть все тестами. Ну и давайте еще сохранять последнее время обновления списка вакансий, чтобы как-то выполнять инвалидацию кеша.
type trudVsem struct {
mux sync.RWMutex
requestTime time.Time
client *http.Client
vacancies []Vacancy
}
Обратите внимание на мьютекс, который я использую. Учитывая то, что кол-во запросов на чтение случайной вакансии будет во много раз превышать кол-во операций обновления этих вакансий, я сделал выбор в сторону RWMutex, который позволяет брать блокировку на чтение отдельно от блокировок на запись, предоставляя возможность одновременного чтения данных из разных горутин. Будем использовать метод RLock для блокировок при чтении, это позволит нескольким горутинам выполнять чтение одновременно, пока нет никаких операций записи. А простой Lock для блокировок при записи, позволит блокировать небезопасный конкурентный доступ к защищаемой памяти, как в обычном мьютексе (под капотом там именно обычный мьютекс).
Итак. Проштудировав документацию открытого АПИ сервиса “Работа России” я собрал структуры, необходимые для маппинга Json данных. Возможно будет немного избыточно, и некоторые поля мы вообще не задействуем в дальнейшем, но я подумал, что лучше будет удалить потом, чем постоянно сверяться с документацией и добавлять какие-то поля в процессе разработки. Кроме того, как ни крути, количество данных в сети мы изменить не сможем — чужой АПИ нам все равно будет присылать все что знает независимо от того, есть ли у нас под эти данные соответствующие поля в наших структурах или нет.
Раскройте, чтобы увидеть код этих структур
Для тех, кто знает как работает маршалинг структур в GO, тут нет ничего нового, для остальных немного пояснения: теги (текст в одинарных кавычках), прилагаемые к полям структур, не влияют непосредственно на маппинг данных или сериализацию, тут опять нет никакой магии. Теги используются для получении информации о полях структур в рантайме. Для получения доступа к ним используется пакет reflect, который еще называют рефлексией в go. Я об этом говорю, потому что если вы хотите строить легковесные и производительные алгоритмы, то не стоит использовать рефлексию и ничего, что прямо или косвенно ее использует, вместо этого есть кодогенераторы, которые, пользуясь рефлексией, создают в своем рантайме уже готовый код на языке go, который содержит все необходимые для маршалинга/демаршалинга функции, которые, в свою очередь, уже в нашем рантайме не используют рефлексию. К таким относятся, например пакет easyjson. Подход с кодогенерацией не на много сложнее, чем подход с использованием json.Decoder, но мы его использовать пока не будем в силу того, что это опять мимо темы.
Давайте же займемся реализацией интерфейса. Первым у нас будет метод Init, который должен подготовить все ресурсы сервиса к работе. Сделаем следующее: проинициализируем рандомизатор, выберем http-клиент по умолчанию и сразу выделим необходимое место в памяти под список вакансий.
func (t *trudVsem) Init(context.Context) error {
rand.Seed(time.Now().UnixNano())
t.client = http.DefaultClient
t.vacancies = make([]Vacancy, 0, prefetchCount)
return nil
}
Для новичков сделаю еще одну ремарку: использование пакета rand может быть обосновано только в алгоритмах, которые не чувствительны к качеству генератора случайных чисел, в других случаях (например, в криптографических алгоритмах), требуется использование генератора из пакета crypto/rand.
Следующим в очереди будет метод Ping, как мы помним, он должен использоваться для самодиагностики и возвращать error, если произошла критическая ошибка, которая не позволяет работать дальше. Такой случай для этого сервиса я себе представить пока не могу, поэтому будем возвращать всегда nil. Функция Ping будет вызываться контроллером рантайма, а если быть точнее, ServiceKeeper должен циклично пинговать наши сервисы с определенными промежутками времени до тех пор, пока не получит команду на завершение работы. Давайте глянем, как ее реализовать.
func (t *trudVsem) Ping(context.Context) error {
if time.Since(t.requestTime).Minutes() > 1 {
t.requestTime = time.Now()
go t.refresh()
}
return nil
}
Проверяем время обновления кеша, если прошло больше минуты, инициируем обновление кеша в фоновой горутине, чтобы не ломать процесс анализа работоспособности сервиса. Возвращаем nil. И вот вам вопрос на засыпку: какая ошибка в имплементации этой функции? Подсказка следующая: синтаксических ошибок нет, все прекрасно компилируется и замечательно работает. Давайте подискутируем об этом в комментариях?
Последняя функция имплементирующая интерфейс Service, необходимая для того, чтобы нашу структуру можно было считать сервисом и передать в ServiceKeeper под контроль. И в ней нечего обсуждать — она идеальна.
func (t *trudVsem) Close() error {
return nil
}
Обновление вакансий
Поскольку функция рефреша списка вакансий должна обновлять данные списка вакансий, то именно в ней мы должны использовать блокировку записи (чтения/записи). После выполнения t.mux.Lock() чтение списка вакансий будет недоступно, пока не выполнится t.mux.Unlock(), но мы должны будем гарантировать это выполнением t.mux.RLock() в читающей функции. Прошу обратить внимание на следующую деталь: с самого начала функции никакие блокировки не ставятся, а выполняется функция вызывающая загрузку обновленных вакансий loadLastVacancies само выполнение этой функции не приводит к обновлению списка, поэтому блокировок тут не нужно. Это кажется очевидным, но тем не менее, ситуация, когда разработчик оборачивает в Lock/Unlock лишние операции, довольно распространена. Всегда ограничивайте блокировкой наименьший участок кода, все, что можно выполнить без блокировок, нужно выполнять без блокировок. Блокировки — это всегда вынужденное зло.
func (t *trudVsem) refresh() {
vacancies, err := t.loadLastVacancies(context.Background(), "программист", 0, prefetchCount)
if err != nil {
log.Println(err)
return
}
t.mux.Lock()
t.vacancies = t.vacancies[:0]
for _, v := range vacancies {
t.vacancies = append(t.vacancies, v.Vacancy)
}
t.mux.Unlock()
}
Вероятно, все знают, почему я использовал t.vacancies = t.vacancies[:0] а не make([]Vacancy, 0, prefetchCount). Это сделано для уменьшения кол-ва аллокаций памяти. На самом деле этот участок кода не критичный и выделение памяти в этом месте не приведет к деградации даже при самых высоких нагрузках, но я позволил себе сумничать. Выражение slice[:0] просто установит длину слайса (len) в 0, оставив его вместительности (cap) прежнее значение, а это значит, что выполнение append будет наполнять слайс заново, просто перетирая старые значения новыми.
Теперь посмотрим, как выполняется загрузка вакансий, комментарии по коду четко отделяют три этапа этой функции: создание запроса, передача его по сети, парсинг ответа. Если какой-то из этапов вернет ошибку, мы просто пробросим ее в качестве ответа для вызывающей функции.
func (t *trudVsem) loadLastVacancies(ctx context.Context, text string, offset, limit int) ([]VacancyRec, error) {
// создадим HTTP-запрос для получения данных
req, err := newVacanciesRequest(ctx, text, offset, limit)
if err != nil {
return nil, err
}
// выполняется запрос данных
resp, err := t.client.Do(req)
if err != nil {
return nil, err
}
// выполняем парсинг данных
parsed, err := parseResponseData(resp)
// не забываем закрывать Body
resp.Body.Close()
return parsed.Results.Vacancies, err
}
Давайте посмотрим, как выполняется создание HTTP-запроса:
func newVacanciesRequest(ctx context.Context, text string, offset, limit int) (*http.Request, error) {
URL, err := url.ParseRequestURI(serviceURL)
if err != nil {
return nil, err
}
query := url.Values{
"text": []string{text},
"offset": []string{strconv.Itoa(offset)},
"limit": []string{strconv.Itoa(limit)},
"modifiedFrom": []string{time.Now().Add(-time.Hour * 168).UTC().Format(time.RFC3339)},
}
URL.RawQuery = query.Encode()
return http.NewRequestWithContext(ctx, http.MethodGet, URL.String(), http.NoBody)
}
И тут есть о чем подискутировать, ведь в самой первой строке я выполняю парсинг константы! Каждый раз вызов этой функции будет выполнять парсинг константы serviceURL и даже возвращать ошибку, если она возникнет. Как-то не очень умно, да? Можно же было использовать литерал url.URL структуры. А еще весьма прилично и даже наглядно будет смотреться вызов функции форматирования fmt.Sprintf, как в примере под спойлером.
Пример
Но я сейчас сам отвечу на свой же вопрос. Я хочу быть уверенным в том, что сделал минимум ошибок: в нелепом тексте ?text=%s&offset=%d&limit=%d&modifiedFrom=%s так легко допустить синтаксическую ошибку и так трудно ее искать потом. Кроме того, ошибку можно допустить, устанавливая значение константы serviceURL. Я не говорю уже о том, что не все параметры в примере с fmt.Sprintf были обернуты в url.QueryEscape и я не знаю, кто будет решать, какой параметр нужно оборачивать, а какой нет. И самое главное, я не могу дать гарантии, что доработка такого кода не сломает логики; кто-то может сломать форматирующую строку или добавить параметр, который не будет проходить через QueryEscape, и у нас выйдет какой-нибудь нелепый query injection.
Преимущества моего варианта в том, что ParseRequestURI может обнаружить некоторые синтаксические ошибки в константе serviceURL, далее литерал url.Values и вызов его метода Encode позволит правильно вписать пары ключ/значение в наш HTTP-запрос, он экранирует все недопустимые символы по всем канонам URL, и никаких ошибок тут не будет. Ну и как итог URL.String() вернет нам какую-то гарантию корректного URL. Единственное, что можно было бы сделать — вынести парсинг константы отдельно, но этот участок кода настолько нетребователен к производительности, что разделять эту логику и выносить куда-то ее часть, я считаю нецелесообразным.
Немного по поводу длинного и неприятного выражения time.Now().Add(-time.Hour * 168).UTC().Format(time.RFC3339). Его логика, думаю, всем понятна — мы получаем текущее время, уменьшаем его на 168 часов (это ровно неделя), переводим в UTC и форматируем по стандарту RFC3339 — это то, чего от нас ждет сервис вакансий. Но я хотел сказать другое. Когда мы видим в коде среди простых выражений сложное, у нас должно возникать желание упростить код. Давайте же спрячем это страшное выражение внутрь функции и вместо него будем вызывать функцию:
const hoursInWeek = 168
func modifiedFrom() string {
return time.Now().Add(-time.Hour * hoursInWeek).UTC().Format(time.RFC3339)
}
Парсинг ответа от сервиса вакансий будет состоять из демаршалинга тела http.Response в нашу структуру с помощью базового json.Decoder и минимальной проверки на валидность этих данных. Ничего такого о чем бы я хотел сказать отдельно.
func parseResponseData(resp *http.Response) (result Response, err error) {
decoder := json.NewDecoder(resp.Body)
if err = decoder.Decode(&result); err != nil {
return
}
// мы ожидаем статус 200
if result.Status != "200" {
err = errors.New("wrong response status")
return
}
// если вакансий в слайсе нет, тут явно что-то не то
if len(result.Results.Vacancies) == 0 {
err = io.EOF
}
return
}
Итак, вот наш первый checkpoint — готов единственный ресурс нашего бэкэнда. Готов сервис бесплатных вакансий. На уровне кода он плоский с единственной внешней связью в виде вызова стороннего АПИ через HTTP и никаких кешей и прочих премудростей. На верхнем уровне мы считаем, что у него все-таки есть кеш, потому что для выполнения своих функций, ему не требуется выполнять вызов стороннего апи.
Пишем бэкэнд с использованием полученного опыта
В предыдущей статье я описал код runtime-контроллера, а в главе выше описал код сервиса вакансий, который будет являться единственным ресурсом нашего бэкэнда. Теперь пора аккумулировать полученный опыт и построить работающее приложение. Вероятно, из предыдущей статьи не становится понятным, как использовать runtime-контроллер так, чтобы изнутри кода с бизнес-логикой были доступны ресурсы приложения. Но давайте сейчас посмотрим на код main:
type server struct {
// все ресурсы нашего бэкэнда перечислены здесь
trudVsem trudVsem
}
func main() {
var srv server
var svc = appctl.ServiceKeeper{
Services: []appctl.Service{
&srv.trudVsem, // регистрируем ссылку на ресурс trudVsem
},
PingPeriod: time.Millisecond * 500, // периодичность вызова Ping
}
var app = appctl.Application{
MainFunc: srv.appStart, // эта функция будет запущена с Run
Resources: &svc, // регистрируем ServiceKeeper
TerminationTimeout: time.Second * 10, // для порядка
}
// стартуем
if err := app.Run(); err != nil {
logError(err)
os.Exit(1)
}
}
Немного освежим память. Структура server понятна — она состоит всего из одного поля — структуры сервиса вакансий trudVsem. Это не интерфейс и оно не скрывает реализации, кроме того, я поместил весь код этого приложения внутри одного пакета, а это значит, что никакого сокрытия реализации тут не будет и из кода с бизнес логикой мне будут доступны даже приватные методы и поля структуры trudVsem. Не делайте так, когда пишете реальное приложение. Я же себе это позволил, потому что это снова вне темы. Просто хочу сказать, что тот сервис, который я передал ServiceKeeper на контроль, как ресурс приложения, мы должны передать в качестве сервиса в функцию выполняющуюся, как основной поток. MainFunc будет запущена строго после того, как все ресурсы будут проинициализированы и у нас есть гарантия, что trudVsem.Init к тому времени уже будет успешно выполнено.
Структура Application получает указатель на ServiceKeeper и знает только о том, что нужно запустить Init, выполнить в фоновой горутине Watch и следить за сообщениями от ОС. Вся эта логика будет запущена в то время, когда мы вызовем Run и любое из следующих трех событий позволит потоку выполнения пойти дальше:
- Возврат из функции MainFunc.
- Возврат из функции ServiceKeeper.Watch.
- Сигнал от операционной системы о завершении работы.
А что там еще за logError? Это я обернул логирование ошибки в вызов функции, чтобы не сильно нагружать по коду вызовами fmt.Errorf.
func logError(err error) {
if err = fmt.Errorf("%w", err); err != nil {
println(err)
}
}
Запуск HTTP сервера и контроль его Graceful Shutdown
Функция appStart будет запускать HTTP сервер из стандартного пакета net/http. Я в очередной раз прошу прощения за magic в коде. Все таймауты и номера портов должны быть спрятаны под конфигами. Конфигурацию можно передать, как переменные окружения операционной системы, опции командной строки или в конфигурационном файле. В идеале следует предусмотреть все три способа передачи конфигурации, возможно, мы с вами займемся этим в будущих статьях, но сейчас для демонстрации результатов мы это опустим.
В стандартной реализации HTTP сервера уже предусмотрен процесс мягкого завершения работы (Graceful Shutdown) с помощью метода Shutdown. В документации сказано, что вызов этого метода приведет к отключению HTTP сервера без прерывания выполнения текущих запросов. Сначала будет выключен листенер, чтобы предотвратить поступление из сети новых запросов, затем будут разорваны все спящие соединения (в состоянии IDLE), а затем будет выполнено ожидание завершения обработки активных запросов и выход.
Я бы описал логику главной функции в такой последовательности: создаем сервер, запускаем на нем обработку запросов, ожидаем сигнала через halt канал и вызываем мягкое завершение работы. В действительности же вышла не очень простая функция с горутиной внутри и каналом для конкурентной передачи возникающей в процессе ошибки.
Код функции appStart(context.Context, <-chan struct{}) error
В качестве Handler для HTTP сервера мы передаем сам указатель на структуру server, для того, чтобы наша структура могла стать обработчиком HTTP запросов, мы должны имплементировать метод ServeHTTP. В качестве Addr нужно передавать адрес локального порта, на котором будем ожидать запросы. В моем случае это будет порт 8900 на всех доступных сетевых интерфейсах. И в качестве BaseContext я порекомендовал HTTP серверу отдавать контекст с которым была запущена функция appStart. Может быть, это решение не очень аккуратное, потому что хоть на данном этапе у нас и есть гарантии, что контекст не будет отменен внезапно и незапланированно, но никаких гарантий в том, что это не станет происходить в дальнейшем, когда мы или кто-то другой станет развивать пакет с runtime-контроллером. Я бы рекомендовал для обработки HTTP запросов использовать всегда чистый контекст — в нем корректная информация о статусе и мы получаем cancel только когда клиент сам закрывает соединение.
Обратите внимание на запуск горутины в середине функции. Это вынужденная необходимость, поскольку вызов ListenAndServe блокирует дальнейшее выполнение. Мы должны предусмотреть варианты вызова Shutdown в случае получения сигнала через канал halt — этот канал, напомню, закрывается, когда операционная система передала сигнал о завершении работы. Дополнительно к этому случаю я добавил еще один случай, когда мы выполняем Shutdown — при “протухании” основного контекста case <-ctx.Done(), таким образом в коде появляется select с двумя кейсами.
В нижней части функции я читаю из канала, который использую для передачи информации об ошибке мягкого завершения работы. Выполнение функции может не дойти до этого участка кода, если ListenAndServe вернет какую-то ошибку, которая немедленно будет отдана в качестве результата для вызывающей функции. Однако, если ошибки не произошло, мы можем проверить корректно ли завершилась операция Shutdown, для этого в канал errShutdown передается ошибка, если таковая возникла. Обратите внимание на то, что я сделал этот канал буферизованным, это значит, что процесс записи в него не остановит выполнение горутины, в противном случае мы рискуем “замерзнуть” в месте выполнения errShutdown <- err и получить “утечку горутины”.
err, ok := <-errShutdown
if ok {
return err
}
return nil
Напомню, что чтение из канала возвращает кортеж, вторым значением которого будет булево значение, показывающее успешность чтения данных. Простыми словами, если ok != true, значит в канале нет данных и он уже закрыт.
Мне нравится эта функция тем, что она оставляет некоторый простор для рефакторинга. Мы можем попробовать вынести из нее литерал http.Server и запуск горутины, контролирующей сигнал halt. Можем завернуть все magic numbers в конфигурацию и как-нибудь иначе выполнить синхронизацию ошибки вызова Shutdown. Но я пока просто оставлю это здесь.
Теперь у нас есть еще один checkpoint — реализация мягкого завершения полностью самодостаточна, все функции, вызываемые ниже по коду уже не должны заботиться о корректной работе сервера в целом, им достаточно будет убедиться, что их работа выполнена корректно.
Обработка HTTP-запроса
Давайте начнем реализацию бизнес-логики. При получении запроса мы должны обратиться к сервису trudVsem и попросить у него случайную вакансию. Если данных нет, вернем HTTP 204 No Content, если что-то есть, выполним рендер вакансии в HTML и вернем его в качестве ответа.
Раскройте, чтобы увидеть код ServeHTTP и renderVacancy
Принимая во внимание то, что выглядит это не очень, я сделаю небольшое отступление от основной темы. У меня вышла довольно сложная для восприятия функция renderVacancy к тому же, скорее-всего, она будет в большей степени влиять на производительность. А еще код бизнес-логики вшит прямо в обработчик запросов, хотя, нам для примера сойдет. В конце-концов, чтобы немного упростить код, мы могли бы сделать следующее:
- Добавить поле template *template.Template в нашу структуру server.
- Заполнить ее при запуске программы srv.template = template.Must(template.New("render").Parse(htmlTemplate))
И изменить нашу логику примерно вот так:
Раскройте, чтобы поглядеть, что вышло
Да, выглядит получше, но такой рендер снизит скорость обработки запроса в два раза. Правда-правда, я проверял. Это вполне рабочий вариант, но без шаблона с одними только w.WriteString(fmt.Sprintf на моем компьютере я получаю около 220к RPS, а с шаблонизатором чуть больше 100к (нагрузочное тестирование будет дальше).
Что можно сделать еще? Чтобы увеличить производительность, мы можем попробовать заранее создавать буфер данных []byte и заполнять его с помощью append, а не w.WriteString(fmt.Sprintf. По понятным причинам такой подход еще сильнее усложнит код, а толку от него будет не очень много — мы можем снизить количество аллокаций и может даже избавимся от нескольких случаев “убегания в кучу”, но не от всех. Еще мы можем сразу писать в http.ResponseWriter, вроде как хорошая идея, но тоже не даст прироста производительности. А если сделать наоборот — чтобы упростить код, мы можем разбить рендер на отдельные блоки: блок рендера заголовка, описания компании, условий труда и отдельно блок с заработной платой. Вот и отлично, пока оставим в голове этот план и вернемся к нашим баранам.
Функция выборки случайной вакансии, которую мы использовали, но еще не описали, содержит обещанный RLock в качестве блокировки при чтении. Это позволяет множеству горутин выполнять этот код не мешая друг другу. Единственное, что заблокирует вход сюда, это Lock при обновлении списка вакансий. Выбор случайной вакансии нам поможет сделать rand.Intn(len(t.vacancies)).
func (t *trudVsem) GetRandomVacancy() (vacancy Vacancy, ok bool) {
t.mux.RLock()
defer t.mux.RUnlock()
if ok = len(t.vacancies) > 0; !ok {
return
}
vacancy = t.vacancies[rand.Intn(len(t.vacancies))]
return
}
Нагрузочное тестирование
Итак, кажется, что все готово. Пора проверить на работоспособность. Я запускаю приложение и перехожу по адресу http://localhost:8900/test. Выглядит так, как будто сработало: я вижу вакансию на должность программиста; обновляю страницу и вижу следующую вакансию. Но давайте проверим, производительность нашего приложения. Все-таки в требованиях указано 100 RPS.
Нагрузочное тестирование удобно проводить с помощью утилиты wrk. Wrk легко устанавливается и позволяет настраивать параметры нагрузочного тестирования. Для своих тестов я решил использовать 15 активных коннектов и 10 рабочих потоков. Для этого запускаю утилиту с ключами -t 10 -c 15. Первый тест сразу обрадовал, я получил результат ~224k RPS. И среднее время ответа в 68 микросекунд, а максимальное в 20 миллисекунд, что явно удовлетворяет нашим требованиям. Вот детализированные результаты тестирования:
devalio@devastator:~$ wrk -t 10 -c 15 http://localhost:8900/test
Running 10s test @ http://localhost:8900/test
10 threads and 15 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 68.69us 223.22us 20.48ms 97.01%
Req/Sec 22.52k 842.70 25.47k 76.31%
2260841 requests in 10.10s, 1.51GB read
Requests/sec: 223848.81
Transfer/sec: 153.06MB
Ну что ж, отлично! Двойной резерв по производительности, это то, что нам нужно. А среднее время ответа даже меньше миллисекунды. Но нужно ли на этом останавливаться? Кажется, я там пропустил одну функцию, реализация которой была не самым удачным примером кода. Да, были какие то мысли, как можно ее переделать, но они строились на предположениях, а не на фактах. Что-то придется с этим делать.
Рефакторинг
Ну вот, я сам себя раздразнил и поскольку уже обещал показать, как я рассуждал в процессе, придется быть честным и приступить к рефакторингу функции renderVacancy. Недолго думая, я посмотрел, какой процент времени выполнение запроса проводит в этой функции. Для этого добавил в секцию импорта _ "net/http/pprof", а в самое начало функции main вот такой вызов HTTP-листенера:
go http.ListenAndServe(":9900", nil)
Пакет net/http/pprof при подключении сам настраивает роутинг по умолчанию, поэтому сразу имею доступ ко всем полезным функциям профилировщика. Когда мы снимаем профили, обязательно нужно, чтобы приложение было нагружено, иначе мы будем видеть метрики “холостого хода”, поэтому я запускаю нагрузочный тест, увеличив время его выполнения до 20 секунд, и одновременно с этим запускаю команду на снятие профиля:
devalio@devastator:~$ go tool pprof http://localhost:9900/debug/pprof/profile?seconds=15
Fetching profile over HTTP from http://localhost:9900/debug/pprof/profile?seconds=15
Saved profile in /home/devalio/pprof/pprof.___go_build_github_com_iv_menshenin_appctl_example.samples.cpu.001.pb.gz
File: ___go_build_github_com_iv_menshenin_appctl_example
Type: cpu
Time: Nov 16, 2021 at 6:24am (MSK)
Duration: 15s, Total samples = 26.97s (179.80%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof)
Для тех, кто не пользуется go tool pprof или не знает об этом инструменте, очень рекомендую изменить свое мнение и нагуглить хорошие инструкции по работе с этим профилировщиком. А пока покажу немногое из того, что он умеет.
Конечно, первое, на что я хочу взглянуть — это диаграмма, которая доступна из профилировщика с помощью команды web — откроется страница браузера с вот такой картинкой. Неправда ли, очень наглядно. Тут показано, какое количество процессорного времени было уделено той или иной функции.
На этом графике я выделил блок, который меня интересует. Обратите внимание на то, что сама обработка запроса (суммарно за все время профилирования) заняла около 5 секунд процессорного времени, а из них чуть больше 3х секунд ушло на renderVacancy.
Следующая команда, которая мне нравится — list, позволяет показать исходный код и расставить ключевые метрики прямо напротив строки кода к которым они относятся. В качестве аргумента эта команда может принимать шаблон поиска по коду, я ввожу list ServeHTTP, чтобы найти функцию обработки HTTP-запроса. Поглядите на картинку ниже, слева от исходного кода мы увидим два столбца. Первый столбец показывает какое кол-во процессорного времени взяла на себя функция, исходный код которой мы видим на экране, без учета времени вложенных в нее функций. Второй — суммарное процессорное время с учетом вложенных вызовов. А вот и наш data, err := renderVacancy(vacancy) — обратите внимание на то, что в левом столбце пусто, а в правом 3 секунды, это значит, что время, потраченное на выполнение этой части кода, относится не к функции ServeHTTP, а ко вложенному в нее вызову renderVacancy.
Т.е. львиная доля Latency, который мы видим в нагрузочных тестах, уходит на рендер вакансии в HTML формат, что дает мне повод заняться оптимизацией в этом месте. И, конечно же, я пошел самым простым путем: решил выполнить рендер прямо в сервисе, который хранит вакансии, ведь данные вакансий не изменяются, а поэтому нам не нужно выполнять рендер “налету”.
Я добавил поле render []byte к структуре Vacancy, вынес рендер вакансии в сервис вакансий и разбил его на кусочки. Затем разбил страшную процедуру рендера на небольшие куски. Итоги рендера я сохраню в поле render и, когда мне потребуется получить вакансию, я буду сразу лить ее в HTTP-респонз вот так:
func (s *server) ServeHTTP(w http.ResponseWriter, _ *http.Request) {
vacancy, ok := s.trudVsem.GetRandomVacancy()
if !ok {
w.WriteHeader(http.StatusNoContent)
return
}
w.Header().Add("Content-Type", "text/html;charset=utf-8")
w.WriteHeader(http.StatusOK)
// сразу вливаем готовый HTML в ResponseWriter
if err := vacancy.RenderTo(w); err != nil {
logError(err)
}
}
. . .
// а эта функция находится в пакете с сервисом “Труд всем”
func (v Vacancy) RenderTo(w io.Writer) error {
_, err := w.Write(v.render)
return err
}
Раскройте, чтобы увидеть функции рендера
Еще немного поразмыслив, я понял, что теперь мне незачем хранить слайс элементов в структуре Vacancy, теперь достаточно будет хранить массив готовых HTML, и сделал еще кое-какие изменения:
type (
VacancyRender []byte
trudVsem struct {
mux sync.RWMutex
requestTime time.Time
client *http.Client
vacancies []VacancyRender // вот тут
}
)
// и тут
func (r VacancyRender) RenderTo(w io.Writer) error {
_, err := w.Write(r)
return err
}
// и вот этот кусочек вот в этой функции
func (t *trudVsem) refresh() {
. . .
var newVacancy = v.Vacancy
if rendered, err := newVacancy.renderBytes(); err == nil {
t.vacancies = append(t.vacancies, rendered)
}
. . .
Провел нагрузочное тестирование еще раз и получил прирост производительности аж на 30%. Теперь вижу следующие результаты:
10 threads and 15 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 64.87us 251.00us 9.09ms 97.39%
Req/Sec 29.48k 2.09k 34.76k 64.72%
2959186 requests in 10.10s, 1.97GB read
Requests/sec: 292990.05
Transfer/sec: 199.60MB
Хорошо. Я остался доволен производительностью этого приложения. Немного беспокоит то, что рендер теперь выполняет сервис trudVsem, а я хотел от него только получение/хранение пакета вакансий. Но с этим могу смириться, поскольку свою цель считаю достигнутой: я показал, как можно использовать пакет, который мы написали в предыдущей статье.
Заключение
Начиная первую из двух статей “Пишем сервис на GO”, я задался целью: показать, как можно построить простое но полноценное веб-приложение на GO. Какие нюансы нужно учитывать при разработке веб-сервиса и на что нужно обращать внимание — это все я постарался разобрать. Да, согласен, в своей статье я описал весьма простое приложение, которое можно было уместить в 100-200 строчек кода, но мне кажется, что даже в решении такой мелкой задачи мне удалось найти и обратить внимание на определенные нюансы разработки веб-сервисов на GO.
Конечно, писать плоский и неструктурный код не задумываясь, что у приложения есть жизненный цикл — это довольно легко. И на самом деле даже может что-то получиться, но чем больше разрастается функциями наше приложение, тем сложнее нам понять, где та самая ниточка, дернув за которую мы заставим наше приложение правильно закрыться. Может для кого-то эта проблема выглядит, как из пальца высосаная, ведь есть же теперь всякие кубернетесы — все, что упало поднимут заново, ну а если наше приложение перед завершением наплодит 500-ых респонзов, то на балансировщике можно выкрутиться ретраями. Но я встречал в своей практике веб-приложение, которое закладывалось, как приложение могущее в перспективе HighLoad, но фактически не поддерживающее не только Graceful Shutdown, но и банальных ContextTimeout. Поэтому постарался вложить между строк правильное понимание структуры go-приложений — такие штучки, как каналы для синхронизации при конкурентности или мьютексы, которые могут блокировать запись и при этом разрешать одновременное чтение. А в некоторых местах попробовал спорить сам с собой, чтобы показать, что в разработке не все так однозначно — где-то нам нужен быстрый код, а где-то мы можем написать код не очень производительный, но зато более стабильный. Все-таки разработка — это процесс непрерывного появления на свет какой-то истины в форме имплементации поставленной задачи на определенном языке программирования, а что помогает рождать истину? Конечно дискуссии и споры.
Чего мы достигли в процессе разработки кода, описанного в этих статьях:
- Мы написали инфраструктурный код — структуры Application и ServiceKeeper, которые помогают нам контролировать системы жизнеобеспечения нашего сервиса.
- Разработали сервис поиска случайной вакансии с использованием вызова API на удаленном сервере.
- Провели нагрузочное тестирование и ознакомились с одним из способов профилирования и оптимизации нашего кода.
Что ж, я считаю достижение этих целей достойной наградой за потраченное время. Если кому-то статья показалась полезной, можете поставить лайк. Если есть такие, для кого эта статья разрушила последний барьер на пути к большому плаванию под эгидой “пишу микросервисы на golang с нуля”, то я более чем доволен. Прошу ознакомиться с полным кодом на моем github.
Пишем сервис на GO. Backend для апплета
В первой части этой дилогии мы написали рантайм контроллер для приложения на golang. Все что он умеет делать — запускать методы интерфейса Resources и функцию MainFunc , контролировать результат их...
habr.com