search

dotnetcore / CAP

Distributed transaction solution in micro-service base on eventually consistency, also an eventbus with Outbox pattern
http://cap.dotnetcore.xyz
MIT License
6.69k stars 1.29k forks source link

Ability to set version per queue & keep same exchange name as is #1338

Closed shkarface closed 1 year ago

shkarface commented 1 year ago

Hello dears,

I haven't been able to find a way to specify versions per CapSubscribe method, I have a use case where I want one of my subscribers to handle v1 events and another subscriber to handle v2 events, but currently there is only a global version that will be appended to all queues.

On a side note, when changing the global version, we don't want it to affect the exchange name, for example, we have an exchange name that is called payment-system, this exchange name is used by multiple microservices not necessarily written in .NET, but when we change the version from the CAP options, it appends the version to the exchange name like payment-system.v2 which breaks compatibility with other microservices.

yang-xiaodong commented 1 year ago

Hi @shkarface ,

Discussing our experiences over the past few years concerning multi-version interfaces, we have identified certain drawbacks in the traditional practice of maintaining multiple API versions within a single application or service. As versions increase, the number of interfaces also grows, leading to a reduction in code maintainability. Over time, the task of removing outdated interfaces becomes challenging.

Based on our experiences, we find that in a new architecture based on Kubernetes, it is entirely possible to isolate versions using namespaces or pod versions. Subsequently, different route requests can be forwarded to different services through the gateway, thereby achieving a simplified server-side code structure. After a period, old API versions are phased out. The only tasks necessary are to clean up resources in the gateway and Kubernetes, leaving the code clean.

In the above context, the Version configuration item in CAP is merely used for version isolation. The event of a new version will only be received by another new version service. This has no relation to the old versions of the api service.

shkarface commented 1 year ago

This is totally understandable, and a new version will handle the v2 messages, the problem is with the exchange name also changes to v2 while it should stay the same since all different micro services will be using the same exchange