Русская версия (рекомендуется)
Sogou C++ Workflow
Как C++ серверный движок компании Sogou, Sogou C++ Workflow поддерживает почти все серверные службы компании Sogou, включая все поисковые сервисы, облачную клавиатуру, онлайн рекламу и т.д., обрабатывая более чем 10 миллиардов запросов каждый день. Это корпоративный программный движок, выполненный в легком и элегантном дизайне, который удовлетворяет большинство требований к разработке серверной части на C++.
Вы можете использовать его:
- Для быстрого создания HTTP сервера:
#include <stdio.h>
#include "workflow/WFHttpServer.h"
int main()
{
WFHttpServer server([](WFHttpTask *task) {
task->get_resp()->append_output_body("<html>Hello World!</html>");
});
if (server.start(8888) == 0) { // запустить сервер на порту 8888
getchar(); // нажмите "Enter", чтобы завершить.
server.stop();
}
return 0;
}
- В качестве мультифункционального асинхронного клиента, поддерживающего протоколы
HTTP, Redis, MySQL и Kafka.
- Протокол
MySQL также поддерживает MariaDB и TiDB.
- Для реализации клиентского/серверного взаимодействия на пользовательском протоколе и создания своего собственного системы RPC.
- Проект srpc основан на этом и является самостоятельным открытым проектом, поддерживающим протоколы srpc, brpc, trpc и thrift.
- Для создания асинхронного рабочего процесса; поддержка общих последовательностей и параллелизма, а также любых DAG структур.
- В качестве инструмента параллельного вычисления. Кроме сетевых задач, Sogou C++ Workflow также включает планирование вычислительных задач. Все типы задач могут быть помещены в одну последовательность.
- В качестве инструмента асинхронного ввода-вывода файлов в системе
Linux, с высокой производительностью, превышающей любое системное вызов. Дисковая операция ввода-вывода тоже является задачей.
- Для реализации любого высокопроизводительного и высокоэффективного серверного сервиса с сложными отношениями между вычислениями и сетью.
- Для создания системы микросервисов.
- Этот проект имеет встроенные возможности управления службой и балансировки нагрузки.
О компиляции и среде выполнения
- Проект поддерживает операционные системы
Linux, macOS, Windows, Android и другие.
- Версия для
Windows доступна как отдельная ветка, использующая iocp для реализации асинхронной сети. Все пользовательские интерфейсы совместимы с версией для Linux.
- Поддерживает все платформы ЦПУ, включая 32 или 64-битные
x86 процессоры, большие или малые конечные arm процессоры, loongson процессоры.
- Основная ветка требует SSL и рекомендует использование
OpenSSL 1.1 или выше. Совместимо со всеми версиями BoringSSL. Если вам не нужен SSL, вы можете выбрать ветку nossl.
- Использует стандарт
C++11 и поэтому должна компилироваться с компилятором, поддерживающим C++11. Не зависит от библиотек boost или asio.
- Нет других зависимостей. Однако если вам необходим протокол
Kafka, следует установить некоторые библиотеки сжатия, такие как lz4, zstd и snappy.
Начало работы (Linux, macOS):
git clone https://github.com/sogou/workflow
cd workflow
make
cd tutorial
make
С использованием инструмента SRPC (НОВОЕ!):
https://github.com/sogou/srpc/blob/master/tools/README.md
С помощью apt-get на Debian Linux, Ubuntu:
Sogou C++ Workflow упакован для Debian Linux и Ubuntu 22.04.
Чтобы установить библиотеку Workflow для целей разработки:
sudo apt-get install libworkflow-dev
Для установки библиотеки Workflow для развертывания:
sudo apt-get install libworkflow1
С помощью dnf на Fedora Linux:
Sogou C++ Workflow упакован для Fedora Linux.
Чтобы установить библиотеку Workflow для целей разработки:
sudo dnf install workflow-devel
Для установки библиотеки Workflow для развертывания:
sudo dnf install workflow
С помощью xmake
Если вы хотите использовать xmake для сборки workflow, вы можете посмотреть документацию по xmake
Уроки* Клиент
Программная парадигма
Мы считаем, что типичная серверная программа = протокол + алгоритм + рабочий процесс и должна разрабатываться полностью независимо.
- Протокол
- В большинстве случаев пользователи используют встроенные общие сетевые протоколы, такие как HTTP, Redis или различные RPC.
- Пользователи также могут легко создать пользовательский сетевой протокол. При создании они должны предоставить функции сериализации и десериализации для определения своего клиента/сервера.
- Алгоритм
- По нашему мнению, алгоритм - это понятие, симметричное протоколу.
- Если вызов протокола - это RPC, то вызов алгоритма - это APC (Asynchronous Procedure Call).
- Мы предоставляем несколько общих алгоритмов, таких как сортировка, слияние, psort, reduce, которые можно использовать сразу.
- В отличие от пользовательского протокола, пользовательский алгоритм гораздо более распространен. Любое сложное вычисление с четко определенными границами должно быть упаковано в виде алгоритма.
- Рабочий процесс
- Рабочий процесс - это фактическая бизнес-логика, которая заключается в том, чтобы поместить протоколы и алгоритмы в граф для использования.
- Типичный рабочий процесс - это замкнутая последовательность-параллельность. Сложная бизнес-логика может быть представлена неконечной DAG.
- Граф рабочего процесса может быть создан напрямую или динамически генерирован на основе результатов каждого шага. Все задачи выполняются асинхронно.
Основные задачи, фабрика задач и сложные задачи
- Наша система содержит шесть основных задач: сетевые, файловые, CPU, GPU, таймеры и счетчики.
- Все задачи создаются фабрикой задач и автоматически удаляются после обратного вызова.
- Задача сервера - это особый вид сетевой задачи, созданной фреймворком, который вызывает фабрику задач, передавая её пользователю через функцию процесса.
- В большинстве случаев задача, созданная пользователем через фабрику задач, является сложной задачей, которая остаётся невидимой для пользователя.
- Например, HTTP запрос может включать много асинхронных процессов (DNS, переадресация), но для пользователя это просто сетевая задача.
- Сортировка файлов кажется алгоритмом, но она действительно включает множество сложных взаимодействий между файловым вводом-выводом и вычислениями на CPU.
- Если представить бизнес-логику как сборку электронных компонентов, то каждый компонент может быть сложной схемой.
Асинхронность и упаковка на основе C++11 std::function
- Не основано на корутине пользователя. Пользователям нужно знать, что они пишут асинхронную программу.
- Все вызовы выполняются асинхронно, и практически нет операций, которые занимают поток.
- Хотя мы также предоставляем некоторые средства с полусинхронными интерфейсами, они не являются ключевыми функциями.
- Мы стараемся избегать выводов пользователей и упаковываем поведение пользователя с помощью
std::function, включая:
- Обратный вызов любой задачи.
- Любой процесс сервера. Это соответствует идеологии
FaaS (Функция как услуга).
- Реализация алгоритма - это просто
std::function. Но алгоритм также может быть реализован путём наследования.
Механизм рециклинга памяти
- Каждое задание будет автоматически возвращено после обратного вызова. Если задание создано, но пользователь не хочет его выполнять, пользователю следует освободить его с помощью метода dismiss.
- Любые данные в задании, такие как ответ сетевого запроса, также будут переиспользоваться вместе с заданием. В этот момент пользователь может использовать
std::move() для перемещения необходимых данных.
- SeriesWork и ParallelWork — это два типа объектов фреймворка, которые тоже переиспользуются после обратного вызова.
- Когда серия является ветвлением параллели, она будет переиспользована после обратного вызова параллели, к которой она принадлежит.
- Этот проект не использует
std::shared_ptr для управления памятью.
Есть ли ещё вопросы?Вы можете проверить список часто задаваемых вопросов (FAQ) и списка проблем (issues), чтобы узнать, нет ли там ответа на ваш вопрос.
Вы всегда можете отправить проблемы, с которыми вы столкнулись при использовании, на страницу проблем (issues), и мы постараемся ответить вам как можно скорее. При этом больше проблем также поможет новым пользователям.
Комментарии ( 0 )