Метка «thrift»

в 10:59, , рубрики: linux, thrift, метки: , ,

Приветствую, уважаемый читатель.

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

Были сделаны клиентские приложения (своего рода драйверы), которые используют соответствующие SDK и умеют получать команды от тестирующего сервиса вида «сходи на сервер, сделай то», или «дай мне такой-то результат для проверки». Команды клиент получает, используя Thrift(wiki). И все было хорошо, пока мы не добрались до портирования SDK на Си и не обнаружили, что толкового мануала для Си у Apache'а нету. Нашли тикет на создание оного мануала и скудный пример там же. После успешного применения Thrift'а в Си, было решено написать небольшой ликбез на эту тему.

Цели, которые мы поставили:
— Клиент должен получать команды от тестирующего сервиса, используя Thrift;
— Команды это отлично, но нужно еще и с сервером общаться;
— Клиент должен работать в одном потоке.
Читать полностью »

Игра в прятки: кодогенерация против JSON Страшно подумать, но ещё каких-то десять лет назад разработка системы самого заштатного RPC была целым праздником в жизни разработчика. Болезненным и длительным праздником, как свадьба для лошади: голова в цветах, зад в мыле. Это было страшно увлекательно и одновременно невероятно запарно. Один выбор протокола чего стоил. Я уж не говорю о борьбе с могучими и чудовищными фреймворками, типа DCOM или CORBA. Реализация транспортного уровня вообще была уделом людей с длинными бородами.

В наше счастливое время жизнь программиста под iOS должна быть легка и приятна. Транспорт давно перестал быть проблемой. А RPC? Легко: достаём из кобуры Apache Thrift или на худой конец Google Protocol Buffers и пожалуйста, с минимальным напряжением головного мозга готов и протокол, и сервер, и клиент. Подавляющему количеству приложений в AppStore только это и нужно: простой и понятный интерфейс к удаленным процедурам, желательно в приятных обертках из нативных классов, и такая же простая и понятная обработка ошибок. Всё.

Но. К сожалению, и Thrift, и Protobuf заточены под одновременную разработку клиента и сервера. А такая удача случается в карьере программиста не часто. Читать полностью »

В начале прошлого года мне пришла в голову идея написать собственный язык интерфейсов (IDL), который был бы похож на Protobuf или Thrift, но предназначался бы для веба. Я надеялся закончить его где-нибудь месяца за три. До первой стабильной версии прошло чуть больше года.

Pdef (пидеф, protocol definition language) — это статически типизированный язык описания интерфейсов, который поддерживает JSON и HTTP RPC. Он позволяет один раз описать интерфейсы и структуры данных, а потом сгенерировать код для конкретных языков программирования. Пидеф подходит для публичных апи, внутренних сервисов, распределенных систем, конфигурационных файлов, как формат для хранения данных, кеша и очередей сообщений.

Основная функциональность:

  • Развитая система пакетов, модулей и пространств имен.
  • Поддержка циклических импортов и зависимостей типов (с некоторыми ограничениями).
  • Простая система типов, основанная на четком разделении интерфейсов и структур данных.
  • Наследование сообщений (аналог struct'ов) и интерфейсов.
  • Поддержка цепочек вызовов, например, github.user(1).repos().all().
  • JSON как формат данных и HTTP RPC для передачи данных.
  • Возможность использовать другие форматы и RPC.
  • Подключаемые кодогенераторы (официально поддерживаются Java, Python и Objective-C).
  • Опциональность кодогенерации, т.е. Пидеф позволяет сериализовать данные и отправлять запросы руками.

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

Пример описания сообщения:

message Human {
    id          int64;
    name        string;
    birthday    datetime;
    sex         Sex;
    continent   ContinentName;
}

Примеры использования (примеры сгенерированного кода):

Json

{
    "id": 1,
    "name": "Ivan Korobkov",
    "birthday": "1987-08-07T00:00Z",
    "sex": "male",
    "continent": "europe"
}

Java

Human human = new Human()
    .setId(1)
    .setName("John")
    .setSex(Sex.MALE)
    .setContinent(ContinentName.ASIA)

String json = human.toJson();
Human another = Human.fromJson(json);

Python

human = Human(id=1, name="John")
human.birthday = datetime.datetime(1900, 1, 2)

s = human.to_json()
another = Human.from_json(s)

Objective-C

Human *human = [[Human alloc]init];
human.id = 1;
human.name = @"John";
human.sex = Sex_MALE;
human.continent = ContinentName_EUROPE;

NSError *error = nil;
NSData *data = [human toJsonError:&error];
Human *another = [Human messageWithData:data error:&error];

Читать полностью »

Привет, коллеги.
Хочу в этом топике выложить инструкцию, как быстро прикрутить Thrift, к своим поделкам.
Thrift — технология для организации межпроцессного взаимодействия между компонентами системы. Была разработана где то в недрах Facebook. Посути это кросс-языковой фреймворк для создания RPC сервисов, на бинарном протоколе. С помощью этого решения можно «подружить» компоненты написанные на разных языках C#, C++, Delphi, Erlang, Go, Java, PHP, Python, Ruby, итд. Описание сигнатур сервисов и данных осуществляется с помощью специального IDL — языка. Технология, по своей сути, похожа на COM, но без всей этой обвязки с регистрацией компонент. Так же не будем забывать, что COM это технология только для Windows, в то время как Thrift — кросплатформенна.

Вобщем решил поэкспериментировать, попробовать вынести часть нагруженной-вычислительной логики из Java в С++, в надежде что нативный С++ код будет немного производительней, и за одно опробовать Thrift RPC, в надежде что это быстрее чем REST.
Как и положено, без бубнов и граблей не обошлось!
Читать полностью »

Читая обзоры и сравнения NoSQL решений, я нередко натыкался на мнение о том, что у Cassandra проблемы с документацией. Пока я знакомился с архитектурой и CLI-командами системы, проблема с документаций казалась устаревшей. Но первая же попытка что-то сделать в Erlang сразу уперлась в долгие часы гугления. По сему, для облегчения своей, и не только, дальнейшей трудовой деятельности выкладываю простенький «how to» по осуществлению базовых операций с Cassandra в Erlang.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js