|
|
@@ -0,0 +1,26 @@
|
|
|
+Preview Feature: Support for Version 2 Bridge Design
|
|
|
+
|
|
|
+- Introduction of Bridge v2 with a new 'connector' concept
|
|
|
+
|
|
|
+ - In the original Bridge v1 design, each connector was exclusively tied to a single bridge.
|
|
|
+ This design prioritized error isolation and performance but posed challenges for users setting up multiple bridges to the same service.
|
|
|
+ For instance, setting up 10 bridges to a single Kafka cluster required the same configuration to be repeated for each bridge.
|
|
|
+
|
|
|
+ - The revamped Bridge v2 design provides more flexibility and better scalability:
|
|
|
+ - Users have the option to either share a connector across multiple bridges or retain it exclusively for one bridge, as in v1.
|
|
|
+ - For the majority of data bridges, sharing a connector among too many bridges might lead to performance degradation but avoids
|
|
|
+ overloading the external system with too many connections if the number of bridges is very high.
|
|
|
+ - In some cases, specific data bridges always utilize dedicated connections, even when the connector is shared.
|
|
|
+ Right now these are:
|
|
|
+ - Kafka Producer
|
|
|
+ - Azure Event Hub Producer
|
|
|
+
|
|
|
+- Management of Connectors
|
|
|
+ - Connectors can now be managed separately, bringing in more flexibility.
|
|
|
+ - New API endpoints have been introduced under the `/connectors` path for connector management.
|
|
|
+ - Version 2 bridges can be managed via the `/bridges_v2` endpoint.
|
|
|
+
|
|
|
+- Limitations in e5.3.1
|
|
|
+
|
|
|
+ - Currently, only the Kafka and Azure Event Hub producer bridges have been upgraded to the v2 design.
|
|
|
+ - The v2 bridge feature is accessible through config files and HTTP APIs. However, it's not yet available on the dashboard UI.
|