08.11.2020 07:41
svistunov 4 977 Источник

Привет, Хабр.

Сегодня я хочу рассказать про своё детище - платформу "qSOA.cloud", которая позволяет запускать приложения построенные по SOA в облаке по разумной цене. Например, стоимость размещения простого HTTP API сервиса, который обрабатывает ~400 000 запросов в сутки, может составлять от 3$/месяц. При этом всё устроено удобно и просто в "одном окне", так, что разработчикам сервисов не нужно думать об инфраструктурной обвязке, а нужно просто реализовывать бизнес логику. Логи, метрики, трейсинг, дискавери, рутинг, ... встроены в платформу, а сервис просто выполняет функцию, нужную бизнесу.

В SOA я очень глубоко погрузился 5 лет назад в одной E-Commerce компании из Юго-Восточной Азии. Строя там платформу, которая обрабатывает десятки тысяч RPS, мы набили много "шишек", которые были учтены в qSOA.cloud. Сейчас на платформе поддерживаются только сервисы написанные на Go, но в дальнейшем появится поддержка и других ЯП.

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

Как это устроено (кратко)

Сервис - это приложение, принимающее запросы по HTTP или gRPC. Между собой сервисы общаются по gRPC, но не напрямую, а через специальные сервисы - Runner'ы. Каждый физический сервер имеет 1 запущенный Runner, который запускает сервисы и проксирует трафик через себя, за счёт чего вся инфраструктурная логика хранится в нём. Runner отвечает за discovery, routing, так как знает какие он сервисы запустил и в каком они состоянии и знает, что запущено на других серверах, он собирает и отправляет в хранилище логи, основные метрики, кастомные метрики сервисов, ... Между собой Runner'ы общаются по gRPC с TLS. Схематично это выглядит так:

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

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

Как написать сервис

Для примера возьмём задачу:

Нужен сервис, который будет принимать по HTTP 2 числа, складывать их и возвращать пользователю сумму, при этом параметры и результат должен логироваться в БД. Чтобы было интереснее, то предположим, что сумму он считать сам не умеет и ему нужен другой сервис, который будет по gRPC принимать 2 числа и возвращать их сумму.

Чтобы немного сократить повествование, я объединю оба сервиса в один и он будет вызывать сам себя по gRPC, так, как он вызывал бы другой сервис. Также я не буду рассказывать про имплементацию HTTP и gRPC хендлеров, они тривиальны, код можно посмотреть на GitHub. Всё самое интересное в main.go, код с подробными комментариями ниже:

package main

import (
	"database/sql"
	"log"

	// Очень простая сервисная обвязка
	"gopkg.qsoa.cloud/service"
	// Сервис предоставляет gRPC
	"gopkg.qsoa.cloud/service/qgrpc"
	// Сервис предоставляет HTTP
	"gopkg.qsoa.cloud/service/qhttp"
	// Драйвер облачного MySQL
	_ "gopkg.qsoa.cloud/service/qmysql"

	// Имплементация хендлеров
	"testservice/grpc"
	"testservice/grpc/pb"
	"testservice/http"
)

func main() {
	// Подготавливаем gRPC клиент для вызова самого себя. 
	// Обратите внимание на протокол qcloud:// и / в конце.
	conn, err := qgrpc.Dial("qcloud://" + service.GetService() + "/")
	if err != nil {
		log.Fatalf("Cannot dial grpc: %v", err)
	}
	defer conn.Close()

	grpcClient := pb.NewTestClient(conn)

	// Подготавливам подключение к MySQL.
	// Не нужен DSN, только имя БД, драйвер qmysql всё сделает
	db, err := sql.Open("qmysql", "example_db")
	if err != nil {
		log.Fatalf("Cannot open mysql database: %v", err)
	}
	defer db.Close()

	// Регистрируем HTTP хендлер
	qhttp.Handle("/", http.New(grpcClient, db))

	// Регистрируем gRPC сервис
	pb.RegisterTestServer(qgrpc.GetServer(), grpc.Server{})

	// Заупскаем
	service.Run()
}

Вот и всё, отправляем в Git и запускаем в облаке.

Проекты, окружения и сервисы

Перед тем, как запустить сервис в qSOA.cloud, надо создать проект. Проект объединяет в себе набор сервисов (сервисы из разных проектов не видят друг друга) и набор окружений. Окружения нужны для того, чтобы иметь несколько наборов сервисов с разными версиями. Например есть стабильное окружение - Production, в нём протестированные версии сервисов, к которым обращаются реальные пользователи, есть тестовое окружение, куда выкладываются готовые к тестированию версии сервиса и в которое ходят тестировщики, и так далее. Структурно это выглядит так:

Сервисы из разных окружений не видят друг друга. Внутри одного окружения одновременно могут быть запущены разные версии одного сервиса.

Из git в облако

Для примера я создал проект Example с ID example. Теперь в нём нужно создать новый сервис:

Если код лежит в приватном репозитории, то адрес можно передать в формате https://<login>:<password>@<domain>/<repo>.

После этого его нужно скомпилировать:

Для этого нужно кликнуть по иконке молотка справа от версии. Версии могут быть в любом формате, задаются тегами в git. Процесс сборки и ошибки можно посмотреть в логе:

В случае наличия GoDep.* файлов будет выполнено go dep ensure.

После успешной сборки сервис готов к запуску, для этого нужно создать окружение, например Production. После создания окружения надо кликнуть по кнопке Deploy:

В появившемся меню выбрать сервис и нужную версию, кликнуть в окне на кнопку Deploy и через короткое время сервис будет запущен:

Для каждого сервиса можно и нужно запускать несколько копий (instance'ов). Они будут распределяться по разным физическим серверам и, в дальнейшем, ДЦ для повышения отказоустойчивости. Но при этом балансировка запросов будет происходит к оптимальным instance'ам.

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

Доступ из Internet

Сейчас запущенный сервис живёт внутри облака и может обращаться сам к себе, но из внешнего мира к нему не добраться. Для открытия доступа надо создать шлюз. При создании проекта выделяется домен вида <project_id>.qsoa.cloud, можно использовать его или его поддомены для организации доступа к сервису:

При создании шлюза просто выбираете окружение, сервис и пишите доменное имя. Домен может быть своим, не обязательно в зоне <project_id>.qsoa.cloud.

После создания можно открыть https://example.qsoa.cloud, сертификат выпишется и будет перевыпускаться автоматически через Let's Encrypt. Это работает и для кастомных доменов:

Базы данных

По условиям задачи, сервис должен логировать в БД аргументы с суммой. Создадим БД с нужным именем:

Базы данных можно использовать в нескольких окружениях, поэтому при создании нужно выбрать в каких из них она будет доступна, в нашем случае только в Production.

В платформу встроен простейший UI для управления БД, сейчас он пригодится для создания таблички:

Его также можно использовать для вывода данных:

Внутри имена баз данных не совпадают с запрошенными, поэтому имя БД в выводе странное.

Трейсинг и логи

Теперь сервис полностью готов к эксплуатации. Если отправить запрос на https://example.qsoa.cloud/?n1=10&n2=20, то получите ответ:

В заголовках ответа можно найти x-span-id и x-trace-id, используя их в интерфейсе платформы можно проследить весь путь, который прошли данные от первого запроса к шлюзу через все внутренние сервисы и обратно.

Базовый интерфейс предоставляет список span'ов:

В таком виде он сейчас полезен для, например, поиска медленных запросов. Фильтр поддерживает сложные выражения, включая скобки, подробности можно посмотреть кликнув на знак ?

Для анализа одного конкретного трейса есть древовидное представление:

В нём, помимо стандартных полей span'ов, можно увидеть их иерархию и какое влияние оказывает каждый вложенный span на длительность родителя (тонкая жёлтая линия).

Используя OpenTracing разработчики сервисов могут добавлять свои span'ы и отслеживать важные для бизнеса вещи.

Помимо трейсинга, на соседней вкладке можно посмотреть логи, причём как и те, что пришли из span'ов, так и те, что просто были выведены в STDOUT/STDERR. В данный момент сервис ничего не выводит, поэтому там пусто:

Метрики

Для любого запущенного сервиса собираются базовые метрики по запросам/ответам и производительности:

Counters:

  • Counters:

    • grpc_messages_in [from, env, service, instance, runner]

    • grpc_messages_out [from, env, service, instance, runner]

    • grpc_streams_close [from, env, service, instance, runner]

    • grpc_streams_errors [from, env, service, instance, runner]

    • grpc_streams_open [from, env, service, instance, runner]

    • grpc_out_messages_in [to, env, service, instance, runner]

    • grpc_out_messages_out [to, env, service, instance, runner]

    • grpc_out_streams_close [to, env, service, instance, runner]

    • grpc_out_streams_errors [to, env, service, instance, runner]

    • grpc_out_streams_open [to, env, service, instance, runner]

    • http_requests [env, service, instance, runner]

    • http_responses [code, env, service, instance, runner]

    • hw_cpu [type, env, service, instance, runner]

    • hw_mem [env, service, instance, runner]

  • Summaries:

    • grpc_messages_in_sz [from, service, instance, runner]

    • grpc_messages_out_sz [from, service, instance, runner]

    • grpc_streams_dur [from, service, instance, runner]

    • grpc_out_messages_in_sz [to, service, instance, runner]

    • grpc_out_messages_out_sz [to, service, instance, runner]

    • grpc_out_streams_dur [to, service, instance, runner]

    • http_requests_sz [service, instance, runner]

    • http_responses_dur [code, service, instance, runner]

    • http_responses_sz [code, service, instance, runner]

Посмотреть их можно на встроенных дашбордах:

Набор дашбордов можно редактировать, пока без редактора, в виде JSON:

Помимо стандартных метрик, можно делать свои, используя клиента Prometheus, они также будут доступны для построения графиков по префиксу prometheus вместо internal.

Язык запросов поддерживает сложные выражения, плейсхолдеры и будет развиваться в будущем.

Конец

Вот и всё, с помощью простых шагов сервис написан, запущен, для него доступны инструменты анализа, при этом разработчик не задумывался о том как настроть Nginx, Docker, Kubernetes, Prometheus, Grafana, ..., или где найти DevOps'а, который это сделает.

История и текущее состояние проекта

Проектом я начал заниматься больше года назад в качестве pet'а. Сейчас его можно классифицировать как MVP, в нём работают несколько моих сервисов, Текущее состояние - хороший "скелет", на который нужно наращивать "тело", но для понимания в какую сторону двигаться мне нужны внешние живые проекты. Есть большой бэклог, из ближайших планов в нём:

  • Инфраструктура:

    • Хостинг для статических файлов (CDN), сейчас их приходится встраивать в сервис, например с помощью генератора.

    • Новые ЯП для сервисов.

    • Новые БД: Postgres, Clickhouse, Mongo, …

    • Мониторинги и алерты.

    • CI/CD

    • Local runner: возможность запускать сервисы на локальной машине, но при этом имеющие доступ к определённому окружению в облаке и обратно. Будет удобно для разработки.

    • Собственные NS с редактором

    • ...

  • Возможности интерфейса

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

    • OpenAPI UI client: возможность вызывать методы конкретных инстансов с приятным интерфейсом

    • gRPC UI client: аналогичный OpenAPI клиент, но для gRPC, для определения структур данных использует рефлексию.

    • Инструмент для поиска корреляций на графиках: можно взять какой-то период на графике где произошло что-то плохое и найти другие метрики, где в этот момент происходило что-то похожее, причём не важно, были ли корреляция прямая или обратная. Это плзволяет легче определить корень проблем.

    • Генератор сервисов из *.proto файлов: по proto-описанию создаётся сервис, в котором нужно только реализовать gRPC методы.

    • ...

  • Сервисы для сервисов:

    • Distributed locks

    • Event bus

    • Distributed cache

    • Cloud SQL

    • ...

Планов очень много и есть огромное желание дальше развивать qSOA.cloud, для этого нужны живые проекты и дополнительные руки и головы. Сейчас прямой регистрации на сайте нет, но если платформа заинтересовала, то со мной можно связаться через ЛС Хабра или любыми другими способами, указанными на https://svistunov.pro. Я буду рад пообщаться по любым формам сотрудничества.