如何解决IPC 微服务 AMQP 和弹性
我正在为我在 Kubernetes 上运行的微服务平台创建架构。
我目前的架构看起来像：
说明：
- 我使用 Flask 创建 API RESTful。
- 对于我的 IPC 机制和事件驱动，我使用 RabbitMQ。
- 微服务包含用于调用生产者和消费者 RabbitMQ 的代码。
- 当 Flask 应用程序启动时，消费者在子进程中被实例化（使用多处理库）。在主应用程序（flask）的所有存活状态期间，进程不会被加入，也不会被杀死。
- 仅在调用请求 (POST/PUT) 时才会实例化生产者。
我想知道，如果我的 RabbitMQ 崩溃了怎么办：
- 微服务中的消费者将不再存活，因为它会引发连接rabbitMQ的异常
- 微服务 API (FLASK) 将继续存在
所以我的问题如下：
将消费者进程分离到一个独立的容器中是一个好习惯吗？
-> 容器将在同一个 pod 中与主应用程序一起运行。
-> sidecar 消费者会有一个 liveness 端点，所以如果 RabbitMQ 再次崩溃，Kubernetes 将只启动这个容器。
-> sidecar 消费者将有权访问数据库以写入事件。
-> 生产者可以留在主应用（flask），对我来说更有弹性。
这样做是否正确？
解决方法
是的，我认为这是一个很好的方法，因为您依靠 Kubernetes 来检查该容器是否已启动（使用活性探测器），而不是从应用程序中执行此操作。
您还可以使用集群的可观察性堆栈来监控/提醒此类事件（已关闭的容器）。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
