我正在使用 Spring-boot 或 Spring-Cloud Framework 来开发 Web 应用程序。系统将主要处理来自客户端的 HTTP Restful 请求，然后将它们保存到 MySQL 数据库中。
但我计划使其更具可扩展性。它应该能够启动每个服务的更多实例，并使系统可以处理更多的传入请求。
但是我不确定我做的是否正确，有没有人可以帮我检查一下我目前的方法是否合理，或者在我的方法中提出任何潜在的风险。
我正在做的是：
服务 A 在其控制器中接收请求，然后将它们异步写入 RocketMQ。RocketMQ 用于削峰。
然后服务 B 订阅服务 A 写入的 RocketMQ 主题，并将消息以列表的形式缓存到 Redis 中。
服务 C 启动一个守护线程检查 Redis 中的消息编号。如果缓存列表大小达到一定值，它会将所有消息拉取并保存到 MySQL 中，然后刷新 Redis 中的缓存。
与往常一样，一个问题可以有更多的解决方案。以下建议基于我作为软件架构师的日常工作和经验。
您的系统由三个（微）服务（A、B 和 C）、消息代理（RocketMQ）、缓存（Redis）和数据库（MySQL）组成。在评论中，您还提到您计划在 F5 硬件和 Docker 上运行它。
服务 A 在前端公开以处理 HTTP 请求。异步处理用于管理负载，但是效率仍然受限于服务 A 的性能。因此，服务 A 应该是可扩展的，以实现更高的吞吐量。必须评估单个单元的性能（查看性能测试、压力测试......）以确定缩放。
要启用 Docker 容器的自动扩展，您将需要编排工具（例如 Kubernetes），该工具将根据配置的指标扩展您的系统。还要考虑扩展系统可以使用的系统资源。
服务 B 和 C 也可以轻松扩展。评估服务 B 和服务 C 的功能是否可以合并到一个服务中。除了 B 将新数据放入 Redis 之外，它还可以将其存储在 MySQL 中。这取决于您需要多少碎片以及如何管理碎片带来的额外复杂性。B 已经对发布的内容做出反应，而服务 C 似乎不断地汇集 Redis 缓存以获取条目数（这可以通过键空间通知来解决）。
从 Redis 读取数据时要小心，将其存储到 MySQL 并刷新它。当您对写入其中的所有服务实例使用一个 Redis 键时，您很容易丢失或刷新一些未存储在 MySQL 中的数据。
在处理异步处理时，您通常会处理最终一致性，这意味着服务 A 处理的数据将无法立即用于可能想要从 MySQL 读取它的其他服务（只是为了更广泛的图景，重要性因情况而异）。
简单地说，我可以将您的问题分为两个子主题。
但我计划使其更具可扩展性。它应该能够启动每个服务的更多实例，并使系统可以处理更多的传入请求。
为了使您的应用程序对传入请求更敏感，您需要
如果您考虑第一种方法，您可以简单地引入更强大的硬件，优化传输级协议的使用或简单地删除不必要的处理步骤（例如：而不是使用步骤 B 和 C，您可以简单地引入类似于消息代理的 Kafka 并在其中可靠地持久化消息.那么你就可以去掉Redis依赖了)
为了优化系统内的网络控制和协议使用，请参阅高性能浏览器网络一书。
对于扩展，考虑到负载，只需使用 Docker swarm 或 Kubernetes。最重要的是，您可以简化应用程序中的依赖关系，以获得更好的性能和易于处理。
你说你想
make the system can handle more incoming requests.
这不取决于机器吗？
我认为在您的情况下，您应该考虑使您的应用程序具有所有服务可扩展性。
在云端或您自己构建。
就像 Kubernetes。 https://kubernetes.io/
或基于 Kubernetes https://cloud.google.com/knative/构建的 KNative
Amazon Web Services 还提供可扩展性。
嗨，缩放与您要处理的负载非常相关：
但是您可以使用此事件总线模式处理多个请求：
1）服务A：将消息发布到事件总线（主题/交换）
2）代理（ActiveMq/RabbitMq/etc..）：将这些消息转发到队列。
3）服务B：从队列中监听并更新MySQL中的记录。
下游服务（服务 B）的多个实例将按需提供可扩展性（如果负载更多，则部署更多实例，如果负载更少，则部署更少实例）。
