Приложение Spring Boot может обрабатывать тонны запросов

Question

Я использую Spring-boot или Spring-Cloud Framework для разработки веб-приложения.Система будет в основном обрабатывать запросы HTTP Restful со стороны клиента, а затем сохранять их в базе данных MySQL.

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

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

Что я делаю, это:

1. Служба A получает запросы в свой контроллер, а затем асинхронно записывает ихв RocketMQ.RocketMQ используется для отсечения пика.

2. Служба B затем подписывает тему RocketMQ, в которую Служба A записывает и кэширует сообщения в Redis в формате списка.

3. Сервис C запускает поток демона, проверяя номера сообщений в Redis.Если размер списка кэша достигает определенного значения, он извлекает все сообщения и сохраняет их в MySQL, а затем очищает кэш в Redis.

Answer 1

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

Факты

Ваша система состоит из трех (микро) сервисов (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 для всех экземпляров служб, которые в него записывают.

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

Answer 2

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

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

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

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

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

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

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

Answer 3

Вы сказали, что хотите

make the system can handle more incoming requests.

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

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

В облаке или построй свой собственный.

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

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

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

Answer 4

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

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

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

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