Ты сказал, что хочешь

make the system can handle more incoming requests.

разве это не зависит от машины?

Я думаю, что в вашем случае вам следует подумать о том, чтобы сделать ваши приложения масштабируемыми со всеми сервисами.

В облаке или создайте самостоятельно.

Как Кубернет. https://kubernetes.io/

Или KNative, построенный на Kubernetes. https://cloud.google.com/knative/

Также Amazon Web Services обеспечивает масштабируемость.

Привет, масштабирование очень зависит от нагрузки, которую вы собираетесь обрабатывать:

Но вы можете обрабатывать несколько запросов, используя этот шаблон шины событий:

1) Служба A: опубликует сообщение в шине событий (тема/обмен)
2) Broker(ActiveMq/RabbitMq/etc..): перенаправит эти сообщения в очереди.
3) Сервис B: прослушивание из очереди и обновление записей в MySQL.

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

Просто я могу разделить ваш вопрос на две подтемы.

But I plan to make it more expandable. It should be able to start more instance of each service and make the system can handle more incoming requests.

Чтобы сделать ваше приложение более отзывчивым на входящий запрос, вам необходимо

• Сокращение времени обработки запросов
• Масштабируйте вашу систему вертикально или горизонтально

Если вы рассматриваете первый подход, вы можете просто ввести более мощное оборудование, оптимизировать использование протокола транспортного уровня или просто удалить ненужные этапы обработки (например, вместо использования шагов B и C вы можете просто ввести Kafka, как брокер сообщений, и надежно сохранять сообщения в нем). , Так что тогда вы можете удалить зависимость Redis)

Чтобы оптимизировать управление сетью и использование протоколов в вашей системе, обратитесь к книге Высокопроизводительная браузерная сеть.

Для масштабирования просто используйте Docker swarm или Kubernetes с учетом нагрузки. Самое главное, вы можете упростить свои зависимости в приложении для повышения производительности и простоты использования.

Как всегда, решений одной проблемы может быть больше. Следующие предложения основаны на моей повседневной работе и опыте архитектора программного обеспечения.

Факты

Ваша система состоит из трех (микро) служб (A, B и C), брокера сообщений (RocketMQ), кеша (Redis) и базы данных (MySQL). В комментариях вы также упоминаете, что планируете запустить его на оборудовании F5 и Docker.

Предложения

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

Чтобы включить автоматическое масштабирование контейнеров Docker, вам понадобится инструмент оркестровки (например, Kubernetes), который будет масштабировать вашу систему на основе настроенных показателей. Также подумайте о системных ресурсах, которые может использовать масштабируемая система.

Также сервисы B и C можно легко масштабировать. Оцените, можно ли объединить функции услуги B и услуги C в единая услуга. Вместо того, чтобы B просто помещал новые данные в Redis, он также мог бы хранить их в MySQL. Это зависит от того, насколько вам нужна фрагментация и как вы будете справляться с дополнительной сложностью, связанной с фрагментацией. B уже будет реагировать на опубликованный контент, в то время как служба C, похоже, постоянно объединяет кеш Redis для количества записей (это можно решить с помощью уведомлений о пространстве ключей).

Будьте осторожны, когда вы читаете данные из Redis, сохраняете их в MySQL и сбрасываете. Вы можете легко пропустить или сбросить некоторые данные, которые не были сохранены в MySQL, когда или если вы используете один ключ Redis для всех экземпляров служб, которые в него записываются.

При работе с асинхронной обработкой вы часто имеете дело с окончательная согласованность, что означает, что данные, которые обрабатывает служба A, не будут сразу доступны для других служб, которые могут захотеть прочитать их из MySQL (просто мысль для более широкой картины, важность варьируется от случая к случаю) .