Обнаружить сбой сервера GRP C в NodeJS - PullRequest
Новая
       71

Обнаружить сбой сервера GRP C в NodeJS

2 голосов
/ 26 марта 2020

Framing: опытный инженер / разработчик, впервые работающий с GRP C и HTTP2 и впервые за долгое время занимавшийся потоковым программированием.

О каких событиях мне нужно знать, чтобы успешно обнаружить «сбой» (сервер неожиданно отключается, сервер неожиданно отключается, сервер имеет тайм-аут и отключается, и т. Д. c.) на сервере GRP C при использовании пакета @grpc/grpc-js?

То есть - у нас есть служба GRP C, использующая протобуферы, и мы можем вызвать / настроить поток как-то так 

const protoLoader = require('@grpc/proto-loader')

const packageDefinition = protoLoader.loadSync(
  __dirname + '/path/to/v1.proto',
  {keepCase: true,
    longs: String,
    enums: String,
    defaults: true,
    oneofs: true
  })

const packageDefinition = grpc.loadPackageDefinition(packageDefinition).com.foo.bar.v1
const client = new packageDefinition.IngestService(
  'server.url.here.com:443',
  grpc.credentials.createSsl()
)

const stream = client.recordSpan(metadata)

На данный момент stream является ClientDuplexStreamImpl объектом , который имеет собственный узел Duplex в качестве родительского класса / объекта.

Объект Duplex реализует потоковые интерфейсы writable и readable, что означает, что он может излучать close, drain, error, finish, pipe, unpipe события (доступные для записи) или close, data, end, error, pause, readable, resume события (доступные для чтения) ). Похоже, что для объекта ClientDuplexStreamImpl также есть metadata и status событие .

Что я хочу сделать, это настроить поток, который является устойчивым. На мой взгляд, это так просто: «Если по какой-либо причине поток отключится, я уничтожу объект и попробую снова подключиться с помощью алгоритма отката».

Проблема, с которой сталкивается мой наивный разум, заключается в том, что неясно, в чем разница между close и end, или если канал error просто сообщает мне произошла ошибка или если произошла ошибка и все прошло.

Кроме того, поскольку это потоковые события, также неясно, будут ли отражаться все виды отключения сервера в потоке и нужно ли мне смотреть на разные объекты (какие это будут объекты?), Чтобы обнаружить фактическое состояние соединения с сервером.

Стоит также упомянуть, что это для сервера, реализацией которого я не управляю.

Итак, повторяю вопрос: что мне делать, как клиент / потребитель службы GRP C, нужно ли убедиться, что я обнаружил, что сервер "ушел" и что я должен попытаться восстановить соединение?

1 Ответ

2 голосов
/ 26 марта 2020

Короткий ответ: вызов gRP C обычно заканчивается на status с status.code, равным grpc.status.UNAVAILABLE, так что вы должны быть в состоянии выполнить sh то, что вы Я хочу прослушать состояние / ошибку с этим кодом и восстановить поток, когда это произойдет.

Сначала я хочу объяснить общий жизненный цикл запроса gRP C. После запуска запроса вы обычно сначала получаете событие metadata, содержащее заголовки ответа. Затем вы выполните некоторое количество write операций и получите некоторое количество data событий. Затем поток закончится, и сработают несколько полуизбыточных событий. Событие end указывает на то, что больше нет данных для чтения, но нет дополнительной информации. Здесь также может сработать событие close, но я никогда не использую его. Событие status предоставляет объект состояния , который сообщает, как закончился поток. .code, равный grpc.status.OK, указывает, что поток завершен успешно. В любом другом случае событие error также будет отправлено, и объект error будет дополнительно иметь все те же поля, что и состояние. Вы всегда должны слушать событие error, потому что, если вы этого не сделаете, и один из них будет отправлен, Node автоматически вызовет его и выдаст как глобальное исключение.

Если поток заканчивается по какой-либо причине, включая отключение сервера, оно закончится событием status. Сетевые ошибки, включая отключение сервера, обычно обозначаются кодом состояния UNAVAILABLE. Этот код также используется, когда соединение вообще не может быть установлено.

По большей части gRP C в любом случае является абстракцией над соединениями. Один клиент gRP C может быть поддержан несколькими TCP-соединениями, и в случае сброса соединения gRP C автоматически попытается восстановить sh соединение.

...