Уроки создания микросервиса

Mar 10 2023

В прошлом году Teachable начал свой путь к микросервисам, и мне посчастливилось быть частью команды, которая работала над одним из первых сервисов. В течение последних восьми месяцев я разрабатывал сервис электронной почты для авторов (CES), персонализированный сервис электронной почты, который позволяет нам общаться с нашими создателями способом, адаптированным к их взаимодействию на нашей платформе.

Сервис был написан на Golang и использовал существующую инфраструктуру AWS Elastic Kubernetes Service (EKS) нашей материнской компании Hotmart. Путешествие было сложным, но полезным, и в этом посте я хотел бы поделиться некоторыми ключевыми уроками и препятствиями, с которыми мы столкнулись на этом пути. В первую очередь я сосредоточусь на проблемах, не связанных с Golang, поскольку они заслуживают отдельного поста.

Путь к Привет Мир

Первой задачей было развернуть приложение с конечной точкой /helloworld (для тестирования) и /healthcheck в Kubernetes (K8s). В то время наша документация по микросервисам была скудной, поэтому нам приходилось экспериментировать методом проб и ошибок. Это подводит меня к первому полученному уроку, который может быть очевидным, но его трудно всегда воплощать в жизнь.

Урок 1: Не бойтесь погружаться в незнакомые кодовые базы.

Hotmart предоставил множество пользовательских действий Github и диаграмм Helm, которые упростили подключение и работу. Однако если возникали какие-то сложные вопросы, то мы оказывались в тупике. Я не хотел бомбардировать нашу команду по инфраструктуре вопросами, не выполняя работы, поэтому я просмотрел эти модули и попытался понять входы/выходы. Вдобавок к этим модулям, мы также много работали над инфраструктурным кодом, например Terraform (HCL), чтобы выделить ресурсы для нашего микросервиса.

Путь к дислокации был на виду:

Настройте репозиторий Github с соответствующей структурой проекта, вдохновленной стандартами golang .
Подключите HTTP-сервер и соответствующие конечные точки.
Создайте конвейер CI/CD с помощью Github Actions.
Развернуть на стейджинг!

Создание ресурсов AWS (например, роли AWS IAM, секреты хранилища, домен и т. д.).
Докеризация вашего приложения и отправка этого образа в реестр AWS Elastic Container Registry (ECR).
Развертывание приложения на K8s с помощью образа, созданного выше.

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

Работа с ресурсами AWS

Для CES мы создавали службу, управляемую событиями, и нам нужен был способ захвата событий создателя (например, публикация курса, изменение подписки и т. д.). Мы хотели отойти от нашей существующей системы на основе Kafka, поскольку она была тесно связана с другими системами. Поскольку наша инфраструктура является родной для AWS, имело смысл использовать Simple Notification Service ( SNS ), управляемую службу уведомлений, в качестве начального узла для публикации событий через Topic . На этом этапе мы могли бы заставить нашу тему отправлять эти события напрямую в CES, но это связало бы нашу службу с SNS. Если бы когда-либо был простой сервиса, мы бы пропустили события.

Наше решение состояло в том, чтобы интегрировать простую службу очередей ( SQS ), которая была бы подписана на нашу тему SNS и получала бы эти события. Затем CES может опрашивать очередь событий по мере их поступления. В случае простоя CES события будут поставлены в очередь, и после резервного копирования CES (надеюсь, в течение разумного промежутка времени) она будет считывать события.

Создание ресурсов SQS/SNS с соответствующими разрешениями заняло немного больше времени, чем ожидалось, из-за характера ролей IAM. Было несколько элементов, которые требовали разрешений, таких как:

Чтение CES из SQS
Fedora, наше монолитное приложение, поддерживающее Teachable, запись в SNS
Промежуточные/тестовые среды, записывающие в SNS

Урок 2. Работа с облачной инфраструктурой может быть утомительной, но полезной.

Работа с облачной инфраструктурой может показаться волшебством. Многое абстрагируется от конечного пользователя, что хорошо, но также требует, чтобы вы верили, что все работает так, как задумано. В течение нескольких часов у нас была готовая к использованию система pub/sub и очереди.

Докеризация вашего приложения

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

Вот тут-то и появляется Dockerization . Приложение может иметь множество зависимостей и служб, которые должны быть запущены и работать, чтобы оно функционировало, например, база данных, уровень кэширования, сервер приложений, фоновый рабочий процесс и т. д. Без Docker поддержание согласованного опыта разработчиков может быть затруднено. быть сложной и вызывать значительные трения. Несогласованные версии зависимостей и конфигурации приложений в тестовых/промежуточных средах — это лишь несколько примеров потенциальных проблем. С помощью Docker вы можете обеспечить переносимость, масштабируемость и воспроизводимость опыта разработчиков по всем направлениям.

Для CES двоичный файл приложения выполняется на предварительно созданном образе Linux и зависит от следующих служб, которые все могут быть Dockerized:

postgres (существующий общедоступный образ )
сервер Redis (существующий публичный образ )
Redis Worker (отдельный скомпилированный двоичный файл, работающий на предварительно собранном образе Linux, поддерживаемом Hotmart).

В результате докеризации CES мы смогли быстро подключить инженеров к нашему проекту, поскольку они смогли развернуть локальную среду разработки за считанные минуты и отправить PR в течение нескольких часов.

Визуал высокого уровня:

Урок 3. Отдайте приоритет докеризации вашего приложения на ранней стадии, чтобы ускорить жизненный цикл разработки.

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

K8s + Магия Шлема

Kubernetes произвел революцию в том, как мы упаковываем, развертываем контейнерные приложения и управляем ими. Многих инженеров (включая меня) сложность K8s может обескуражить, особенно если вы не работали в контейнерной облачной среде.

Когда я впервые начал копаться в кодовой базе нашей инфраструктуры, чтобы понять, как мы развертываем приложения, я узнал, что у Hotmart есть обширный набор инструментов для развертывания приложений на K8s. Благодаря уже существующим диаграммам Hotmart Helm нам не нужно было создавать манифесты K8s (чертеж приложения) с нуля.

Helm можно рассматривать как менеджер пакетов, такой как yarn или pip, но вместо того, чтобы управлять пакетами программного обеспечения на одной машине (например, на вашем ноутбуке), он управляет приложениями K8s в кластере машин. В Hotmart есть диаграмма Helm приложения, которая оснащена предварительно настроенными настройками и позволяет добавлять любые пользовательские конфигурации через отдельный файл YAML. Затем этот файл передается в пользовательское действие Github, которое запускает необходимые команды управления для развертывания приложения в кластере K8s. Это включает в себя создание/обновление репозитория Helm с вашим приложением, создание новой версии со всеми вашими последними изменениями, создание/обновление соответствующих манифестов K8s и т. д.

Визуал высокого уровня:

Урок 4. Использование абстракций может помочь ускорить разработку и развертывание, но важно понимать, что происходит внутри.

Сначала мне было трудно понять, как Github Actions, Helm и K8s сочетаются друг с другом, чтобы получить развернутое приложение, потому что оно казалось абстрактным и подавляющим. Очевидно, они служат разным целям, но то, как они взаимодействовали, было не сразу понятно. При этом я с облегчением узнал, что многие из этих абстракций по сути были командами оболочки (через AWS + Helm + API K8s), которые запускаются исполнителями, размещенными на GitHub или самостоятельно, чтобы получить необходимые ресурсы, подготовленные/развернутые в AWS. /К8с. Инфраструктура каждой команды уникальна, поэтому очень важно найти инструменты и процессы, которые лучше всего подходят для вашей команды и вашей компании.

Краткое содержание

На этом пути было получено много других знаний, включая методы наблюдения, K9, структурированное/неструктурированное ведение журнала и многое другое. Эти знания предназначены для инженеров, которые плохо знакомы с микросервисами. Они довольно высокого уровня, но могут служить полезным руководством во время разработки.

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

PS Особая благодарность нашим мастерам инфраструктуры (включая инженеров Hotmart), которые оказали огромную поддержку на этом пути. Также привет команде роста за всю любовь и поддержку!