Хабрахабр

[Перевод] Организация эффективного взаимодействия микросервисов

В последнее время микросервисные архитектуры пользуются определённой популярностью. От того, как взаимодействуют микросервисы, может зависеть производительность и масштабируемость решений, основанных на них. Это взаимодействие может быть синхронным или асинхронным. В материале, перевод которого мы представляем вашему вниманию сегодня, рассматриваются синхронные методы взаимодействия микросервисов. А именно, речь пойдёт об исследовании двух технологий: HTTP/1.1 и gRPC. Первая технология представлена стандартными HTTP-вызовами. Вторая основана на использовании высокопроизводительного RPC-фреймворка от Google. Автор материала предлагает взглянуть на код, необходимый для реализации взаимодействия микросервисов с использованием HTTP/1.1 и gRPC, провести замеры производительности, и выбрать технологию, которая позволяет организовать обмен данными между микросервисами наилучшим образом.

Приложение, работающее в обычном режиме

Начнём с малого и создадим систему из двух микросервисов, которые могут взаимодействовать друг с другом. Обратите внимание на то, что здесь не используется кластерный режим. Вот схема нашего приложения.

Архитектура приложения, работающего в обычном режиме

Приложение состоит из следующих компонентов:

  • Средство для тестирования системы (Load testing tool): jMeter.
  • Сервис А (Service A): микросервис, который выполняет запросы к сервису B и возвращает полученные от него ответы.
  • Сервис B (Service B): микросервис, отправляющий в ответ на запросы статические JSON-данные после 10-миллисекундной задержки, используемой для всех его API.
  • Виртуальные машины (VM 1 и VM 2): экземпляры Amazon EC2 t2.xlarge.

▍HTTP/1.1

HTTP/1.1 — это стандартная технология организации взаимодействия микросервисов, которая применяется при использовании любых HTTP-библиотек вроде axios или superagent.

Вот код сервиса B, реализующий API нашей системы:

server.route(); }, 10); }); return h.response(response); },
});

Вот код сервиса А, который обращается к сервису B, используя HTTP/1.1:

server.route({ method: 'GET', path: '/', handler: async (request, h) => { try { const response = await Axios({ url: 'http://localhost:8001/', method: 'GET', }); return h.response(response.data); } catch (err) { throw Boom.clientTimeout(err); } },
});

Запустив эти микросервисы, мы можем воспользоваться возможностями jMeter для выполнения тестов производительности. Выясним, как система ведёт себя при работе с ней 50 пользователей, каждый из которых выполняет по 2000 запросов. Как можно видеть на следующем рисунке, медиана результатов измерения равна 37 мс.

Результаты исследования системы, работающей в обычном режиме и использующей HTTP/1.1, с помощью jMeter

▍gRPC

gRPC использует по умолчанию технологию Protocol Buffers. Поэтому, применяя gRPC, в дополнение к коду двух сервисов, нам понадобится написать и код proto-файла, который описывает интерфейс взаимодействия модулей системы.

syntax = "proto3"; service SampleDataService { rpc GetSampleData (Empty) returns (SampleData) {}
} message SampleData { int32 id = 1; string name = 2; bool enjoys_coding = 3;
} message Empty {}

Теперь, так как теперь мы планируем использовать gRPC, надо переписать код сервиса B:

const grpc = require('grpc'); const proto = grpc.load('serviceB.proto');
const server = new grpc.Server(); const GetSampleData = (call, callback) => { setTimeout(() => { callback(null, { id: 1, name: 'Abhinav Dhasmana', enjoys_coding: true, }); }, 10);
}; server.addService(proto.SampleDataService.service, { GetSampleData,
}); const port = process.env.PORT;
console.log('port', port); server.bind(`0.0.0.0:${port}`, grpc.ServerCredentials.createInsecure()); server.start();
console.log('grpc server is running');

Обратите внимание на некоторые особенности этого кода:

  • Командой const server = new grpc.Server(); мы создаём grpc-сервер.
  • Командой server.addService(proto... мы добавляем сервис к серверу.
  • Команда server.bind(`0.0.0.0:${port}... служит для привязки порта и учётных данных.

Теперь перепишем сервис A с использованием gRPC:

const protoPath = `${__dirname}/../serviceB/serviceB.proto`;
const proto = grpc.load(protoPath); const client = new proto.SampleDataService('localhost:8001', grpc.credentials.createInsecure());
const getDataViagRPC = () => new Promise((resolve, reject) => { client.GetSampleData({}, (err, response) => { if (!response.err) { resolve(response); } else { reject(err); } });
}); server.route({ method: 'GET', path: '/', handler: async (request, h) => { const allResults = await getDataViagRPC(); return h.response(allResults); },
});

Среди особенностей этого кода можно отметить следующие:

  • Командой const client = new proto.SampleDataService... мы создаём grpc-клиент.
  • Удалённый вызов выполняется с помощью команды client.GetSampleData({}....

Теперь протестируем то, что у нас получилось, с помощью jMeter.

Результаты исследования системы, работающей в обычном режиме и использующей gRPC, с помощью jMeter

1. Проведя несложные расчёты, можно выяснить, что решение, использующее gRPC, оказывается на 27% быстрее решения, использующего HTTP/1.

Приложение, работающее в кластерном режиме

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

Архитектура приложения, работающего в кластерном режиме

Если сравнить эту архитектуру с рассмотренной ранее, можно отметить следующие изменения:

  • Здесь имеется балансировщик нагрузки (Load Balancer), в роли которого используется NGINX.
  • Сервис B теперь присутствует здесь в трёх экземплярах, которые прослушивают разные порты.

Подобная архитектура характерна для реальных проектов.

1 и gRPC в новой среде. Исследуем HTTP/1.

▍HTTP/1.1

При использовании в кластерной среде микросервисов, применяющих HTTP/1.1, их код менять не придётся. Нужно лишь настроить nginx для организации балансировки трафика сервиса B. В нашем случае, для того, чтобы это сделать, нужно привести файл /etc/nginx/sites-available/default к такому виду:

upstream httpservers { server ip_address:8001; server ip_address:8002; server ip_address:8003; }
server { listen 80; location / { proxy_pass http://httpservers; }
}

Запустим теперь то, что у нас получилось, и посмотрим на результаты тестирования системы с использованием jMeter.

Результаты исследования системы, работающей в кластерном режиме и использующей HTTP/1.1, с помощью jMeter

Медиана в данном случае равна 41 мс.

▍gRPC

Поддержка gRPC появилась в nginx 1.13.10. Поэтому нам понадобится самая свежая версия nginx, для установки которой обычная команда sudo apt-get install nginx не подходит.

Также тут мы не используем Node.js в кластерном режиме, так как в таком режиме gRPC не поддерживается.

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

sudo apt-get install -y software-properties-common
sudo add-apt-repository ppa:nginx/stable
sudo apt-get update
sudo apt-get install nginx

Кроме того, нам понадобятся SSL-сертификаты. Самоподписанный сертификат можно создать с помощью openSSL:

openssl req -x509 -newkey rsa:2048 -nodes -sha256 -subj '/CN=localhost' \ -keyout localhost-privatekey.pem -out localhost-certificate.pem

Для использования gRPC нужно отредактировать файл /etc/nginx/sites-available/default:

upstream httpservers { server ip_address:8001; server ip_address:8002; server ip_address:8003; }
server { listen 80; location / { proxy_pass http://httpservers; }
}

Теперь всё готово для того, чтобы испытать кластерное gRPC-решение с помощью jMeter.

Результаты исследования системы, работающей в кластерном режиме и использующей gRPC, с помощью jMeter

1-решения, на 31% быстрее. В данном случае медиана равна 28 мс, а это, в сравнении с аналогичным показателем, полученным при исследовании кластерного HTTP/1.

Итоги

Результаты исследования показывают, что приложение, основанное на микросервисах, и использующее gRPC, оказывается примерно на 30% производительнее аналогичного приложения, в котором для обмена данными между микросервисами используется HTTP/1.1. Исходный код проектов, рассмотренных в этом материале, можно найти здесь.

Уважаемые читатели! Если вы занимаетесь разработкой микросервисов, просим рассказать о том, как вы организуете обмен данными между ними.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть