Практикум: устройство продакшен-сервера gRPC¶
Настоящие локальные gRPC-вызовы проверяют ограничения размера сообщений и числа вызовов, смену состояния и таймаут health check, отмену, клиентский дедлайн, завершение запросов при остановке, TLS и mTLS. Хранилище работает в памяти; метрики и отчёты об ошибках сохраняются в списки. База данных, аккаунт Sentry и Docker не нужны.
Проверка параллелизма различает ожидание свободного потока на одном HTTP/2-соединении и отказ по общему лимиту сервера через отдельное соединение. В обоих случаях нового чтения хранилища нет. Health service сообщает NOT_SERVING, но не блокирует прямой прикладной RPC. При дедлайне клиент получает DEADLINE_EXCEEDED, а отменённый серверный обработчик записывает метрику CANCELLED.
При остановке проверяется, что общее хранилище закрывается после освобождения ресурса обработчиком: и при завершении запроса в пределах grace period, и при отмене по его истечении. Сертификаты на один день создаются во временном каталоге через cryptography; отдельный openssl не нужен. Неудачные TLS-подключения намеренно вызывают диагностические сообщения gRPC.
Неверный PEM-файл отклоняется. Проверка Unix-прав ключа запускается только на Unix; на Windows она пропускается, поскольку библиотека полагается на Windows ACL. Соединения TLS и mTLS проверяются на обеих платформах.
Нужен uv. Запустите из каталога docs/blog/lab/2026-09-07-production-grpc-server:
Версии закреплены в requirements.txt: grpc-server-kit 0.2.0, servicewright 0.13.1, grpcio 1.84.0, FastAPI 0.141.1, Uvicorn 0.53.0, HTTPX 0.28.1 и cryptography 50.0.1.
Фрагменты статьи взяты из invoice_domain.py и grpc_flow.py. lab_support.py содержит имитаторы, tls_support.py создаёт сертификаты. Запрос и ответ метода передаются байтами через generic handler; генерация protobuf-классов не требуется.