Перенос потоковых соединений во время обновлений

Question

Я работаю над приложением, которое использует Amazon Kinesis, и одна из вещей, которые меня интересуют, - это как можно пролонгировать приложение во время обновления без потери данных в потоках. Я слышал о таких вещах, как сине-зеленые развертывания и тому подобное, но мне было интересно, как лучше всего обновить службу потоковой передачи данных, чтобы вы не теряли данные из своих потоков.

Например, мое приложение имеет конечную точку HTTP, которая принимает данные в виде последовательности операций POST. Если я хочу заменить службу более новой версией, как мне управлять потоковой передачей существующего приложения на мою конечную точку?

Answer 1

Одним из распространенных способов является использование программного балансировщика нагрузки (LB) с виртуальным IP; за этим LB будут как минимум две конечные точки приема HTTP во время нормальной работы. Во время обновления каждая конечная точка объявляется и обновляется по очереди. LB гарантирует, что трафик не будет перенаправлен на объявленную конечную точку.

(Сами конечные точки могут находиться на отдельных виртуальных машинах, контейнерах Docker или физических узлах).

Конечно, поток должен быть конечным; сокет TCP / поток HTTP принадлежит одной из конечных точек. Однако до тех пор, пока поток может быть корректно остановлен, работает следующий поток, предполагая, что конечной точке A принадлежит текущее потребление:

1. Скажите конечной точке A не принимать новые потоки. Все новые потоки будут перенаправлены только в конечную точку B LB.
2. Изящно остановите существующие потоки в конечной точке А.
3. Обновление А.
4. Объявить назад.
5. Промыть и повторить с конечной точки B.

В качестве побочной точки вам понадобятся две конечные точки с балансировкой нагрузки (или ведущим / ведомым), если вам требуются разумные сроки безотказной работы и гарантии надежности.

Существуют и другие специальные методы, которые позволяют выполнять горячую замену кода на одной и той же конечной точке, но они более индивидуальны и зависят от конкретного внутреннего проекта (например, отдельный процесс между сетью и стеком обработки, соединенным IPC).