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

Question

Ищет исходные данные для решения проблемы дизайна. Мы модернизируем наш существующий сервер, который до сих пор работал хорошо, но не будет масштабироваться в будущем.

Текущий дизайн: Это один сервер (мы запускаем несколько экземпляров одного и того же сервера) который имеет множество рабочих процессов. Назовем эти рабочие процессы A, B, C, D обрабатываемыми внутри сервера. До сих пор над этим сервером работала одна команда разработчиков, что упростило обработку выпусков. Производительность также приличная, потому что мы используем кэширование памяти.

Будущий дизайн: Теперь у нас несколько команд (каждая команда обрабатывает один рабочий процесс, команда A обрабатывает рабочий процесс A, команда B обрабатывает рабочий процесс B и скоро). С этой новой структурой команды и текущим дизайном мы не можем масштабировать наши выпуски (поскольку у нас один сервер, у нас есть только одна команда, выпускающая в любой момент времени, что снижает общую эффективность команды). Необходима изоляция, чтобы команды могли выпускать свои изменения в рабочие процессы независимо друг от друга. Кроме того, мы ожидаем, что на этот сервер будет встроено больше рабочих процессов.

Любые дизайнерские идеи о том, как мы можем решить эту проблему постоянного увеличения рабочих процессов

Мое текущее решение: Разделите сервер на 4 сервера, чтобы каждая команда могла управлять рабочими процессами индивидуально. Недостатком такого подхода является управление кодом. Большинство из этих рабочих процессов имеют общую базу кода. Кроме того, разделение сервера приводит к тому, что мы теряем кеш (что не является проблемой с текущим дизайном).

Надеемся услышать ваши предложения.

Answer 1

Разделение на разные рабочие процессы для разных команд имеет смысл. Некоторые преимущества, которые приходят на ум:

1. Независимые выпуски, как вы упомянули.
2. Сбои / утечки памяти / перегрузка ресурсов из рабочего процесса A не повлияет на рабочий процесс B
3. Каждый сервер Workflow можно масштабировать независимо. Популярный рабочий процесс A можно масштабировать, чтобы указать больше серверов, в то время как редко используемый рабочий процесс B может работать только с 1 сервером.

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

Как бороться с недостатками - попробуем разобраться на примере системы управления библиотеками. Допустим, нам нужны рабочие процессы для того, чтобы участник заимствовал книгу, участник возвращает книгу, регистрирует нового участника.

Most of these workflow share common code base

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

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

the server causes us to lose out on cache

Очень важно, что именно нужно кэшировать и каково его поведение.

Достаточно статичный c кеш (например, кеш-член) может быть настроен для распределенного кеша, такого как redis. Скажем, существует рабочий процесс, который определяет крайние сроки для заимствованных книг и отправляет этим участникам электронные письма с напоминаниями. После того, как идентификаторы участников определены, их электронные письма можно будет искать в кэше Redis.

Рабочий процесс также может иметь персонализированный кеш. Например, во время поиска книг в библиотеке с указанным именем результат может быть кэширован на сервере рабочего процесса только в памяти с TTL и может быть обработан, если такой же запрос будет задан в ближайшем будущем.

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