Свободная касса: как мы ушли от монолита и настроили межмодульное взаимодействие на RPC

Всем привет, я — Дмитрий Пестеха, ведущий разработчик С++ команды POS-систем в «Магните». Расскажу, как мы пилили монолитное приложение Касса на модули и отлаживали их взаимодействие на RPC-JSON. Спойлер: в процессе в мире появился новый самописный язык интерфейсов - IDL.

Касса — это не вся POS-система «Магнита», но ее значительная часть: приложение для кассира. 15 лет назад Касса представляла из себя монолит: внутри интерфейса — таблица со списком товаров, ценами и скидками. Но со временем у нее появились новые функции: интеграция с весами, пин-падами, фискальные регистраторы и т.д.  Мы разделили приложение на модули, чтобы в случае “падения” одного из них по segfault вся Касса продолжала работать, хоть и с ограниченной функциональностью, предварительно сохранив при этом текущие данные для кассира. Теперь действия кассира в приложении отправляют запросы в ядро системы, которое в свою очередь получает информацию из множества модулей. POS-систему мы разработали на C++ на Linux CentOS 5+ с использованием стандартной библиотеки, Qt и Boost, а собрали при помощи GCC и CMake.

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

Уход от монолита: разделяй на слои и властвуй с RPC

Мы начали с внедрения технологии удаленного вызова процедур JSON-RPC. RPC полностью подходил нам для организации взаимодействия между модулями. А формат JSON мы выбрали по нескольким причинам:

1. в отличие от бинарных протоколов JSON легко читаем. В случае удаленной отладки на объекте за несколько тысяч километров это — самое весомое преимущество;

2. JSON не такой многословный, как XML;

3. у нас уже была своя реализация JSON в комбинации с концептом Variant.

Variant — это такой универсальный контейнер, который мог, с одной стороны, вместить прикладные данные и структуры и сериализовать их в JSON, c другой стороны, распарсить JSON, получив оттуда структуру всех данных и тип:

Variant.fromJson()

.toString ()

.toDouble()

.toMap()

В результате мы смогли поделить Кассу на три уровня:

1. Транспорт, который получает и отправляет JSON, затем сериализует в Variant и передает его на следующий слой;

2. Обработчики RPC — слой, который достает данные и определяет вызов RPC;

3. Прикладной код вызова RPC.

На первый взгляд всё отлично, однако разработчику с внедрением RPC добавилось задач. Для примера возьму функцию «Поиск товара по штрихкоду»: до перехода на три уровня Кассы этот функционал уже был в ядре. «Поиск товара по штрихкоду» принимает строчку string barcode и возвращает вектор структур с информацией по найденным товарам:

vector<Art> find(string barcode)

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

1. В транспортном слое, который работает только с JSON, всё без изменений;

2. В слое обработчиков 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;
}

3. На прикладном уровне без изменений:

vector<Art>  core::find(const string& barcode) { … }

Что на клиентской стороне? Примерно аналогичная история:

1. Транспортный слой — без изменений;

2. Слой обработчиков: надо определить клиента, который подключится к транспорту и определит для прикладного уровня некий вызов find. Так как он был связан с транспортом, он также будет связан и с Variant:

class CoreClient {
public:
CoreClient() { /* код подключения к транспорту */ }
virtual Variant find(const Variant& params)
{ 
Variant result = trnsp::process(“find”, params);
return result;
}

3. В прикладном коде этот вызов нужно осуществить следующим образом: сначала запаковать параметры метода в 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 разработчику пришлось:

1. Добавлять обработчики — рутинный процесс. Нужно их объявить и связать с транспортным уровнем. Инструментов оптимизации кроме копипаста в тулбоксе на тот момент не было. Так разработчики и поступали: Cntrl+C Cntrl+V. И это, признаюсь, было не только утомительно, но и весьма рискованно. Всегда есть риск скопировать, а затем забыть переделать скопированное под себя.

2. Преобразовывать параметры в Variant и доставать их из него обратно. Так как централизованного подхода к упаковке и распаковке не было, каждому программисту на каждом вызове приходилось реализовывать это локально в своем модуле.

3. Контролировать соответствие параметров функции. Раньше при прямом вызове компилятор проверял тип параметров и выдавал ошибки при несоответствиях. Теперь же при 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) { … }
};

Наш разработчик вздохнул с облегчением. Однако всё ещё оставалось несколько недостатков.

1. Так как появилось централизованное место, где описывались RPC-вызовы, со временем туда переехали и описания этих вызовов. Наш файл с RPC-методами пополнился богатыми комментариями, что это за методы, какие у них параметры вызова и каким ожидать результат вызова. Вот так, к примеру, выглядит файл:

core_events.h:
#define CORE_EVENTS                                  \
/* поиск товара по Штрихкоду */                      \
/* параметры:                  */                    \
/*     string barcode         */                     \
/* возвращается:               */                    \
/*     vector<Art>              */                   \
/*     struct Art {            */                    \
/*        string name           */                   \
/*        string barcode       */                    \
/*        double price }        */                   \
(find)                                                                                                                        \
                                                                                                                                                           \
                                                                                \
/* другой метод method1         */                   \
/* параметры:                  */                    \
 /* …                           */                   \
 (method1)                                           \

2. Другим недостатком была макросная магия. Макросы состояли из нескольких слоёв подмакросов. Генерируемый макросами код Вася увидеть не мог, он появлялся на препроцессинге. А разработчику в помощь шли только описания макросов с инструкциями, как их применять, и с примерами, что из них получается.

3. Оставалась конвертация параметров в Variant и обратно. Мы пытались создать еще макросы, которые бы решили эту проблему, но только прибавили себе сложностей.

Заход номер два: пришло время сказать «нет»

Мы ушли от макросов и создали инструмент, который больше походил на C++, чем на макросную магию: разработали наш собственный язык IDL. В него мы заложили всё лучшее:

1. Все максимально приближено к C++: простой синтаксис, базовые типы, виды структур (как struct, enum и тд), поддержка контейнеров vector и tuple;

2. Написали к нему парсер и инструмент кодогенерации для RPC-клиента и RPC-сервера. Генерация кода добавлена в систему сборки. В отличие от макросного решения, генерируемый код виден разработчику и для изучения, и для отладки;

3. Добавили конвертацию тех параметров, которые были описаны в интерфейсе, в Variant и из него. Если встречаем контейнеры по типу Vector, то добавляем распаковку и упаковку в контейнер.

4. 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?

1. Генерация всего типа Art со всей распаковкой / упаковкой в Variant;

2. Генерация специального класса CoreClient, который соединяется с транспортом и берет на себя всю работу с ним.

3. Генерация класса 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. 

Заход «со звездочкой»: нам мало фишек

Мы не останавливаемся на достигнутом и продолжаем добавлять возможности для разработчиков. Внедрили:

1. Наследование типов. Например, у разработчика есть некая структура, описывающая товар, и ему нужно более сложное описание. Допустим, добавить акцизную марку. Ему не нужно переписывать всю структуру или менять первоначальную. Он просто описывает свою структуру, наследуя от основной:

core.idl:
struct Art {  };
struct AlcoArt: Art 
{
string excise_mark;
};

2. В корпоративной библиотеке есть богатая коллекция своих собственных классов, которые мы используем для передачи информации между модулями. Самые используемые мы тоже внедрили в наш язык IDL. Теперь разработчик мог описать такие структуры, как «GUID» и «Дата-время», основанные на string JSON, спецификацию «Версия» или вообще бинарные данные, которые сериализуются в Base64: 

struct Data 
{
GUID            guid;
DateTime      time_stamp;
VersionSpec version;
RawData       binary_data;
};

Мы уже работаем над добавлением в IDL:

1. Концепции модулей: опишем весь проект Кассы в рамках IDL, зафиксируем связи модулей и их роли, а также разграничим модули Клиент и Сервер;

2. Концепции соединения модулей: опишем транспортную часть соединения модулей. Это может быть межпроцессный пайп (конвейер), TCP-сокет или система очереди сообщений ZMQ/AMQ/*MQ. Добавим спецификацию сериализации модулей через JSON, XML, BSON, Yaml;

3. Кодогенерации для Python: сейчас модуль на Python может обращаться к Кассе. Но разработчику требуется писать код для упаковки всех параметров в контейнер, и потом при получении результата вызова распаковывать снова полученное. Здесь также напрашивается решение по  кодогенерации для Python, чтобы избавить разработчика от упаковок и упростить добавление функциональности.

Итак, вот наш путь в три шага со звездочкой от монолита до кодогенерации. Мы оптимизировали разработку, потому что у нас получилось:

1. Повысить отказоустойчивость: если падает один модуль, Касса продолжает работать;

2. Изолировать модули: если один модуль работает из-под окружения Linux, то другой модуль может, например, запускаться из-под Windows в какой-нибудь вендорской dll-библиотеке получить информацию из COM-объекта и передать её в Кассу;

3. Запускать удаленные модули на кассовом сервере, обновлять справочники кассы. Раньше в монолитной структуре без использования сторонних инструментов это было невозможно на расстоянии;

4. Упростить разработку в условиях  огромного количества нововведений. Задача разработчика сейчас — описать интерфейсы в IDL;

5. Внедрить инструмент для проектирования архитектуры: теперь эксперт в какой-то узкой области может описать весь интерфейс модуля, сразу разбив его на составляющие. Для этого ему необходимо  описать, какие вызовы должны идти напрямую между модулями, а какие через внешний RPC. А уже затем этот интерфейс разделить на несколько разработчиков. В этом случае риск случайной поломки архитектуры исключен.

Недавно (29 ноября) мы делились историей этой разработки на Magnit.Tech++ Meetup.  ВОодушевились интересом участников и теперь хотим задать вопрос вам: стоит ли нам выносить IDL в opensource? И почему вы так считаете?