Всем привет, я — Дмитрий Пестеха, ведущий разработчик С++ команды POS-систем в «Магните». Расскажу, как мы пилили монолитное приложение Касса на модули и отлаживали их взаимодействие на RPC-JSON. Спойлер: в процессе в мире появился новый самописный язык интерфейсов - IDL.
Касса — это не вся POS-система «Магнита», но ее значительная часть: приложение для кассира. 15 лет назад Касса представляла из себя монолит: внутри интерфейса — таблица со списком товаров, ценами и скидками. Но со временем у нее появились новые функции: интеграция с весами, пин-падами, фискальные регистраторы и т.д. Мы разделили приложение на модули, чтобы в случае “падения” одного из них по segfault вся Касса продолжала работать, хоть и с ограниченной функциональностью, предварительно сохранив при этом текущие данные для кассира. Теперь действия кассира в приложении отправляют запросы в ядро системы, которое в свою очередь получает информацию из множества модулей. POS-систему мы разработали на C++ на Linux CentOS 5+ с использованием стандартной библиотеки, Qt и Boost, а собрали при помощи GCC и CMake.
При делении на модули возник вопрос: как настроить их взаимодействие максимально эффективно? Расскажу подробно о том, какие решения принимали мы и к чему это в итоге привело.
Уход от монолита: разделяй на слои и властвуй с RPC
Мы начали с внедрения технологии удаленного вызова процедур JSON-RPC. RPC полностью подходил нам для организации взаимодействия между модулями. А формат JSON мы выбрали по нескольким причинам:
в отличие от бинарных протоколов JSON легко читаем. В случае удаленной отладки на объекте за несколько тысяч километров это — самое весомое преимущество;
JSON не такой многословный, как XML;
у нас уже была своя реализация JSON в комбинации с концептом Variant.
Variant — это такой универсальный контейнер, который мог, с одной стороны, вместить прикладные данные и структуры и сериализовать их в JSON, c другой стороны, распарсить JSON, получив оттуда структуру всех данных и тип:
Variant.fromJson()
.toString ()
.toDouble()
.toMap()
В результате мы смогли поделить Кассу на три уровня:
Транспорт, который получает и отправляет JSON, затем сериализует в Variant и передает его на следующий слой;
Обработчики RPC — слой, который достает данные и определяет вызов RPC;
Прикладной код вызова RPC.
На первый взгляд всё отлично, однако разработчику с внедрением RPC добавилось задач. Для примера возьму функцию «Поиск товара по штрихкоду»: до перехода на три уровня Кассы этот функционал уже был в ядре. «Поиск товара по штрихкоду» принимает строчку string barcode и возвращает вектор структур с информацией по найденным товарам:
vector<Art> find(string barcode)
Эту функцию разработчик хочет вынести на уровень RPC для взаимодействия с другими модулями. Представьте, что он должен сделать:
В транспортном слое, который работает только с JSON, всё без изменений;
В слое обработчиков RPC нужно добавить обработчик
on_find (Variant), который работал с транспортным слоем, затем связать его с ним, чтобы, когда от транспорта придёт вызовon_request, он понял, что это вызов RPC, которому требуется свой обработчик:
Variant core_server::on_find(const Variant& params);
Variant core_server::on_request(method, params)
{
if (method == ”find”)
return on_find(params); // Почему не core::find(string)?
}Почему разработчик не мог напрямую обратиться к функции ядра find? В нашем случае из транспорта приходил контейнер Variant. Ему нужно было сначала достать параметры вызова, потом обратиться к прикладному коду core::find. Даже получив результат, он не мог просто так передать его транспорту — он должен был сначала упаковать в Variant вектор с информацией о товарах, а только потом полученный контейнер вернуть в транспорт для отправки запрашивающему модулю:
Variant core_server::on_find(const Variant& params)
{
std::string barcode = params.toString();
vector<Art> core_result = core::find(barcode);
// необходимо поместить vector<Art> --> Variant
Variant result;
for (const Art& art : core_result) { … }
return result;
}На прикладном уровне без изменений:
vector<Art> core::find(const string& barcode) { … }Что на клиентской стороне? Примерно аналогичная история:
Транспортный слой — без изменений;
Слой обработчиков: надо определить клиента, который подключится к транспорту и определит для прикладного уровня некий вызов
find. Так как он был связан с транспортом, он также будет связан и с Variant:
class CoreClient {
public:
CoreClient() { /* код подключения к транспорту */ }
virtual Variant find(const Variant& params)
{
Variant result = trnsp::process(“find”, params);
return result;
}В прикладном коде этот вызов нужно осуществить следующим образом: сначала запаковать параметры метода в Variant, затем сделать вызов через клиента
CoreClient(обработчик, который соединился с транспортом). Полученный результат — контейнер Variant, необходимо распаковать и только потом работать дальше с этим результатом:
void Module::doSomeStuff()
{
// необходимо найти товары по Штрихкоду “4660000”
Variant params(“4660000”);
Variant result = m_core_client.find(params);
vector<Art> arts;
// извлекаем vector<Art> из Variant
arts = ……
/// работаем с результатами поиска
for (const auto& a : arts) {... }
}То есть с введением RPC разработчику пришлось:
Добавлять обработчики — рутинный процесс. Нужно их объявить и связать с транспортным уровнем. Инструментов оптимизации кроме копипаста в тулбоксе на тот момент не было. Так разработчики и поступали: Cntrl+C Cntrl+V. И это, признаюсь, было не только утомительно, но и весьма рискованно. Всегда есть риск скопировать, а затем забыть переделать скопированное под себя.
Преобразовывать параметры в Variant и доставать их из него обратно. Так как централизованного подхода к упаковке и распаковке не было, каждому программисту на каждом вызове приходилось реализовывать это локально в своем модуле.
Контролировать соответствие параметров функции. Раньше при прямом вызове компилятор проверял тип параметров и выдавал ошибки при несоответствиях. Теперь же при RPC-вызове все параметры упаковываются в Variant — как int, так и string, и структуры, и вектора. И ошибка возникает не на этапе компиляции, а в рантайме на уровне сервера, когда он получает вызов и видит несоответствие параметра:
// std::string barcode = “4600000”;
int barcode = 4600000;
// Прямой вызов
vector<Art> result = core.find(barcode); // Ошибка компиляции, ожидается string!
// Rpc вызов
Variant result = core_client.find(Variant(barcode)); // Нет ошибки компиляции, Variant содержит intСтолько накладных расходов из-за RPC нас не устраивало: мы хотели упростить разработчику жизнь, снизить риски ошибок в работе системы и увеличить её продуктивность.
Заход номер раз: макросы - это хорошо (но это еще не точно)
Сделали ставку на макросы семейства BOOST_PP_* из библиотеки Boost.
Мы создали такой инструмент: в неком хэдере объявляется define (для примера возьмем CORE_EVENTS). Он содержал перечисление всех RPC-методов. Например, наш find и еще несколько других:
#define CORE_EVENTS \
/* поиск товара по Штрихкоду */ \
(find) \
/* … */ \
(method1) \
(method2) \ В помощь разработчику с серверной стороны был определен макрос TANDER_DEFINE_SERVER(Srv, enum), который принимает на вход список событий и генерирует некий класс. Здесь определяется и код соединения с транспортным уровнем, а также все обработчики, общающиеся с транспортным уровнем через контейнер Variant.
// Серверная сторона
TANDER_DEFINE_SERVER(CoreSkeleton,
CORE_EVENTS);
class CoreSkeleton {
// пустые, виртуальные обработчики
virtual Variant on_find (const Variant& params) { }
virtual Variant on_method1(const Variant& params) { }
virtual Variant on_method2(const Variant& params) { }
};С другой стороны для клиента был создан аналогичный макрос TANDER_DEFINE_CLIENT(Clnt, enum), который при вызове на клиентской стороне генерировал клиента RPC. В нём содержались вызовы RPC и соединения с транспортным уровнем.
// Клиентская сторона
TANDER_DEFINE_CLIENT(CoreClient, CORE_EVENTS);
class CoreClient {
virtual Variant find(const Variant& params) { … }
virtual Variant method1(const Variant& params) { … }
virtual Variant method2(const Variant& params) { … }
};Наш разработчик вздохнул с облегчением. Однако всё ещё оставалось несколько недостатков.
Так как появилось централизованное место, где описывались RPC-вызовы, со временем туда переехали и описания этих вызовов. Наш файл с RPC-методами пополнился богатыми комментариями, что это за методы, какие у них параметры вызова и каким ожидать результат вызова. Вот так, к примеру, выглядит файл:
core_events.h:
#define CORE_EVENTS \
/* поиск товара по Штрихкоду */ \
/* параметры: */ \
/* string barcode */ \
/* возвращается: */ \
/* vector<Art> */ \
/* struct Art { */ \
/* string name */ \
/* string barcode */ \
/* double price } */ \
(find) \
\
\
/* другой метод method1 */ \
/* параметры: */ \
/* … */ \
(method1) \Другим недостатком была макросная магия. Макросы состояли из нескольких слоёв подмакросов. Генерируемый макросами код Вася увидеть не мог, он появлялся на препроцессинге. А разработчику в помощь шли только описания макросов с инструкциями, как их применять, и с примерами, что из них получается.
Оставалась конвертация параметров в Variant и обратно. Мы пытались создать еще макросы, которые бы решили эту проблему, но только прибавили себе сложностей.
Заход номер два: пришло время сказать «нет»
Мы ушли от макросов и создали инструмент, который больше походил на C++, чем на макросную магию: разработали наш собственный язык IDL. В него мы заложили всё лучшее:
Все максимально приближено к C++: простой синтаксис, базовые типы, виды структур (как struct, enum и тд), поддержка контейнеров vector и tuple;
Написали к нему парсер и инструмент кодогенерации для RPC-клиента и RPC-сервера. Генерация кода добавлена в систему сборки. В отличие от макросного решения, генерируемый код виден разработчику и для изучения, и для отладки;
Добавили конвертацию тех параметров, которые были описаны в интерфейсе, в Variant и из него. Если встречаем контейнеры по типу Vector, то добавляем распаковку и упаковку в контейнер.
RPC-вызовы в генерируемом коде использовали сигнатуры как при прямом вызове. Все действия по упаковке параметров в контейнеры Variant и извлечению из Variant скрывались в детализации генерируемого кода, который использовал методы конвертации всех объявленных в интерфейсе типов:
core.idl:
namespace core {
struct Art {
string name;
string barcode;
double price;
};
interface Core {
vector<Art> find(string barcode);
}
} // namespace coreА вот как выглядит сгенерированный код:
struct Art {
std::string name;
std::string barcode;
double price;
// методы для упаковки в Variant
Art(Variant v) {…}
Variant toVar() {…}
// методы для упаковки векторов в Variant
static std::vector<Art> fromVar(const Variant& v) {...}
static Variant toVar(const std::vector<Art>& v) {…}
};Наконец-то наша структура Art превращается в структуру C++, содержит 3 поля, 2 строки и число с плавающей точкой, методы преобразования в Variant и распаковки из Variant. Для контейнеров генерируется весь код по упаковке в Vector и распаковке из него в Variant.
Для серверной стороны генерируется модуль CoreSkeleton.hpp.
struct Art { … }
class CoreSkeleton {
public:
vitrual std::vector<Art> on_find(const string& barcode) = 0;
Variant on_request(string method, Variant params)
{
if (method == “find”) {
string barcode = params.toString();
// вызов обработчика
std::vector<Art> result = on_find(barcode);
// упаковка результата в Variant
return Art::toVar(result));
}
}
};Модуль содержит объявление структуры Art и код по её конвертации. Также в модуле объявлен класс CoreSkeleton, в котором в деталях скрыта работа с транспортным уровнем, упаковка и распаковка параметров в Variant. Также в классе определяется обработчик on_find, который предоставляется на верхний прикладной уровень.
Прикладной код серверной стороны упрощается следующим образом:
Вася в своем модуле, добавляет include модуля скелетона. И создает наследника от серверного скелетона, переопределив метод on_find. On_find имеет уже сигнатуру прямого вызова, а именно строковый штрих-код, и возвращает vector. И в on_find помещается прикладной код, который будет отвечать за выполнения поиска в ядре.
Core.hpp
#include <.gen/CoreSkeleton.hpp>
class Core: public CoreSkeleton
{
// переопределение обработчика
std::vector<Art> on_find(const string& barcode)
{
// реализация поиска
// результат - vector<Art>
}
};Что создаёт кодогенератор для работы клиента RPC?
Генерация всего типа Art со всей распаковкой / упаковкой в Variant;
Генерация специального класса
CoreClient, который соединяется с транспортом и берет на себя всю работу с ним.Генерация класса
CoreStubдля пользовательского прикладного уровня, который самостоятельно работает с транспортом через вспомогательный CoreClient, а для разработчика предоставляет вызовfindс сигнатурой прямого вызова, скрывая внутри упаковку параметров к контейнер Variant, и распаковку результата вызова.
Тогда прикладной клиентский код превращается в простой вызов, очень похожий на прямой. Только вместо модуля ядра у нас используется CoreStub:
CoreStub.hpp
struct Art { … };
class CoreStub { } // find(string)
Module.hpp
#include <.gen/CoreStub.hpp>
class Module {
CoreStub m_core;
void doSomeStuff()
{
std::vector<Art> result = m_core.find(“46600000”);
// обработка результата
}
};Так при помощи IDL мы свели к минимуму всю дополнительную работу с RPC.
Заход «со звездочкой»: нам мало фишек
Мы не останавливаемся на достигнутом и продолжаем добавлять возможности для разработчиков. Внедрили:
Наследование типов. Например, у разработчика есть некая структура, описывающая товар, и ему нужно более сложное описание. Допустим, добавить акцизную марку. Ему не нужно переписывать всю структуру или менять первоначальную. Он просто описывает свою структуру, наследуя от основной:
core.idl:
struct Art { };
struct AlcoArt: Art
{
string excise_mark;
};В корпоративной библиотеке есть богатая коллекция своих собственных классов, которые мы используем для передачи информации между модулями. Самые используемые мы тоже внедрили в наш язык IDL. Теперь разработчик мог описать такие структуры, как «GUID» и «Дата-время», основанные на string JSON, спецификацию «Версия» или вообще бинарные данные, которые сериализуются в Base64:
struct Data
{
GUID guid;
DateTime time_stamp;
VersionSpec version;
RawData binary_data;
};Мы уже работаем над добавлением в IDL:
Концепции модулей: опишем весь проект Кассы в рамках IDL, зафиксируем связи модулей и их роли, а также разграничим модули Клиент и Сервер;
Концепции соединения модулей: опишем транспортную часть соединения модулей. Это может быть межпроцессный пайп (конвейер), TCP-сокет или система очереди сообщений ZMQ/AMQ/*MQ. Добавим спецификацию сериализации модулей через JSON, XML, BSON, Yaml;
Кодогенерации для Python: сейчас модуль на Python может обращаться к Кассе. Но разработчику требуется писать код для упаковки всех параметров в контейнер, и потом при получении результата вызова распаковывать снова полученное. Здесь также напрашивается решение по кодогенерации для Python, чтобы избавить разработчика от упаковок и упростить добавление функциональности.
Итак, вот наш путь в три шага со звездочкой от монолита до кодогенерации. Мы оптимизировали разработку, потому что у нас получилось:
Повысить отказоустойчивость: если падает один модуль, Касса продолжает работать;
Изолировать модули: если один модуль работает из-под окружения Linux, то другой модуль может, например, запускаться из-под Windows в какой-нибудь вендорской dll-библиотеке получить информацию из COM-объекта и передать её в Кассу;
Запускать удаленные модули на кассовом сервере, обновлять справочники кассы. Раньше в монолитной структуре без использования сторонних инструментов это было невозможно на расстоянии;
Упростить разработку в условиях огромного количества нововведений. Задача разработчика сейчас — описать интерфейсы в IDL;
Внедрить инструмент для проектирования архитектуры: теперь эксперт в какой-то узкой области может описать весь интерфейс модуля, сразу разбив его на составляющие. Для этого ему необходимо описать, какие вызовы должны идти напрямую между модулями, а какие через внешний RPC. А уже затем этот интерфейс разделить на несколько разработчиков. В этом случае риск случайной поломки архитектуры исключен.
Недавно (29 ноября) мы делились историей этой разработки на Magnit.Tech++ Meetup. ВОодушевились интересом участников и теперь хотим задать вопрос вам: стоит ли нам выносить IDL в opensource? И почему вы так считаете?