Реализован iproto-сервер, который осуществляет операции над стораджем.
<packet> ::= <request> | <response>
<request> ::= <header><body>
<response> ::= <header><return_code><body>
<header> ::= <func_id><body_length><request_id>
<func_id> ::= <uint32> - идентификатор вызываемой функции (см. раздел API)
<body_length> ::= <uint32> - длина тела запроса
<request_id> ::= <uint32> - идентификатор запроса, возвращается в ответе, нужен для асинхронной работы с сервером
<return_code> ::= <uint32> - код ответа (см. раздел API)
<body> ::= <byte>... - закодированная в MsgPack (см. раздел API) последовательность байт длиной <body_length>
Data [1000]string
StorageState uint8
Mutex sync.RWMutex
Сторадж может находится в следующих состояних:
READ_ONLY- доступен только на чтениеREAD_WRITE- доступен на чтение и записьMAINTENANCE- сторадж недоступен
return_code:
0- успех, в этом случае клиент получает вbodyрезультат, описанный в таблице ниже!= 0- ошибка, в этом случае клиент получает вbodymsgpack-encoded строку - текстовое описание ошибки.
Тела запросов и ответов закодированы в формате MsgPack. Спецификация формата: https://github.com/msgpack/msgpack/blob/master/spec.md
func_id |
Имя обработчика | Схема тела запроса | Схема тела ответа | Описание |
|---|---|---|---|---|
0x00010001 |
ADM_STORAGE_SWITCH_READONLY |
<nil> |
<nil> |
переводит сторадж в состояние READ_ONLY |
0x00010002 |
ADM_STORAGE_SWITCH_READWRITE |
<nil> |
<nil> |
переводит сторадж в состояние READ_WRITE |
0x00010003 |
ADM_STORAGE_SWITCH_MAINTENANCE |
<nil> |
<nil> |
переводит сторадж в состояние MAINTENANCE |
0x00020001 |
STORAGE_REPLACE |
<int><string> |
<nil> |
записывает в сторадж строку по индексу |
0x00020002 |
STORAGE_READ |
<int> |
<string> |
возвращает строку из стораджа по индексу |
- DEBUG
- INFO
- WARNING
- ERROR
- FATAL
- PANIC
- Мониторинг горутин: количество запущенных горутин (go_goroutines)
- Метрики производительности: использование ресурсов (например, памяти и CPU) (process_cpu_seconds_total, process_open_fds, process_start_time_seconds, process_virtual_memory_bytes, process_virtual_memory_max_bytes, etc)
- Метрики профилирования: количество успешно отработанных запросов для чтения/записи (storage_successful_reads_writes_total)
- Метрики стабильности: количество ошибок и сбоев для чтения/записи (storage_error_reads_writes_total)
- Метрики распределения запросов: распределение запросов по эндпоинтам (api_call_total)
- Метрики количества подключений (active_connections)
- Метрики задержки (RPC_request_duration_seconds)
P.S. Я считаю подсчет изменений состояния отдельно для ReadOnly, ReadWrite, Maintenance, т.к. в случае реализации метрики как флага состояния, если между сборами prometheus при больших значениях скраппинг интервала в API состояние изменилось и потом вернулось обратно, то prometheus не зафиксирует изменение состояния.
Полный набор метрик можно посмотреть http://localhost:8088/metrics
Build image and run container:
docker build -t iproto .
docker run -p 80:8080 -e "LOG_LEVEL=<LOG_LEVEL>" iproto
Or pull image from docker hub and than run:
docker pull k0styaa/vk_iproto
docker run -p 80:8080 -e "LOG_LEVEL=<LOG_LEVEL>" vk_iproto
type Header struct {
FuncID uint32
BodyLength uint32
RequestID uint32
}
type Request struct {
Header Header
Body []byte
}
type Response struct {
Header Header
ReturnCode uint32
Body []byte
}
req := Request {...}
var resp models.Response
client, err := rpc.Dial("tcp", "localhost:80")
err := client.Call("MyService.MainHandler", request, &response)
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent