Quarkus 弹性最佳实践
我有一个如下的用例：
一个 Quarkus 微服务负责与其他几个固定 API（例如 ArgoCD REST API、标准企业驱动 API）进行通信，以使整个系统处于所需状态。
整个请求需要事务性，这意味着所有 API 请求要么都需要成功，要么在出现任何错误时回滚。
如果 API 返回错误，那么情况对我来说就很清楚了。 “只需恢复之前所做的一切即可”，但是如果我的 Quarkus 应用程序崩溃了怎么办？
示例：
Quarkus 应用程序在端点上收到 POST 请求，该请求将启动以下任务：
- 读取 REST-API 1 上的资源
- 在 REST-API 2 (ArgoCD API) 上创建资源
- 在 REST-API 3 (标准企业 API) 上创建资源）
如果我的 Quarkus 应用程序在第二步之后终止，它将使我的应用程序处于不一致的状态。
例如，我的第二个请求将使用其 REST API 创建一个 ArgoCD 应用程序，如果第三个请求失败，我必须再次删除创建的应用程序以使系统恢复到一致状态。
LRA 方法不适用这里是因为 ArgoCD Rest API 没有实现 LRA API。
所以至少，我必须在 Quarkus 应用程序中维护状态和补偿逻辑。但是，我需要在任何地方保留事务的状态，以便在发生故障后从中恢复。
我当前的解决方案使用 Redis 数据库来保存每个事务的状态直到其完成，但我想知道我是否错过了一些与我的用例相匹配的标准解决方案。
I have a use case like the following:
One Quarkus microservice is responsible for talking with several other fixed APIs (e.g. ArgoCD REST API, Standard Corporate Driven API) to bring the whole system in the desired state.
The whole request needs to transactional, which means that either all API requests need to be successful or rolled back in case of any error.
If the APIs give errors back, the case is clear for me. "Just revert everything you had done before", but what happens if my Quarkus application crashes?
An example:
Quarkus application receives a POST request on an endpoint which starts the following tasks:
- read a resource on REST-API 1
- create a resource on REST-API 2 (ArgoCD API)
- create a resource on REST-API 3 (Standard Corporate API)
If my Quarkus application dies after step two, it will leave my application in an inconsistent state.
For example, my second request will create an ArgoCD-Application using its REST API, if then the 3rd request fails, I have to delete the created application again to bring the system back to a consistent state.
The LRA approach is not applicable here because the ArgoCD Rest API does not implement the LRA API.
So at least, i have to maintain the state and the compensation logic within my Quarkus application. However, I need to persist the state of my transaction anywhere to recover from it after a failure.
My current solution uses a Redis database besides to persist the state of each transactions until it is finished, but I was wondering if I missed some standard solution matching my use case.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为没有简单的方法可以实现您所寻求的目标。当然，这取决于您的业务可接受的弹性或隔离级别。实际上有一个名为 LRA< 的专用 MicroProfile 规范/a>（长时间运行的动作）只是为了解决这个问题。它是 SAGA 模式的实现。
问题是仅仅依靠调用这些 API 的回滚是不够的。如果这些回滚失败以及许多其他情况怎么办？在这种情况下，总是需要有一个协调员来协调整个过程。您可以在上面的链接甚至 LRA 的 Quarkus 扩展 中阅读更多相关信息。
我知道，如果您无法访问这些 API 的源代码来添加 LRA 注释，那么可能没有必要解决您的问题，但我希望它能给您一些关于人们通常解决此问题的方式的想法。
I think there is no easy way to achieve what you're looking for. Of course, it depends on the level of resiliency or isolation that is acceptable on your business. There is actually a dedicated MicroProfile specification named LRA (long running action) only to solve this problem. It's an implementation of the SAGA pattern.
The problem is that it's not enough to only rely on calling the rollback on those APIs. What if those rollbacks fail and many other cases. There is always a need to have a coordinator in such cases to orchestrate the whole process. You can read more about it in the links above or even the Quarkus extension for LRA.
I know it may not necessary solve your problem if for example you don't have access to those API's source to add LRA annotations, but I hope it would give you some ideas about the way people typically solve this.