ContacteDecisió del clúster EventHub
Navegació
| ⬅️ estandar-schemas-eventhub | Aplicació del cas d’ús ➡️ |
|---|
Quan he de consultar aquesta guia?
Consulta aquesta guia quan:
- el cas d’ús pot executar-se en més d’un clúster EventHub,
- existeixen consumidors en diferents entorns (on‑prem / cloud),
- cal prendre una decisió arquitectònica prèvia abans del desplegament.
Objectiu
Definir els criteris de decisió arquitectònics per seleccionar el clúster EventHub (Kafka) on s’ha d’ubicar un cas d’ús, en escenaris on conviuen entorns on‑premise i cloud.
Principi arquitectònic clau
La selecció del clúster principal es basa sempre en la ubicació dels consumidors.
- Els productors no decideixen clúster segons la seva ubicació.
- Tots els productors publiquen al clúster principal.
- El clúster principal és el punt d’origen de la replicació cap a altres entorns.
Resum operatiu de decisió
| Escenari | Clúster principal | Productors | Replicació |
|---|---|---|---|
| Tots els consumidors en un entorn (onpremise, Azure o AWS) | Aquell entorn | Es connecten al principal | No cal |
| Consumidors en diversos entorns | L’entorn del grup de consumidors més crític | Es connecten al principal | Sí, des del principal als secundaris |
| Entorn secundari amb un sol consumidor (sense previsió de creixement) | El principal per criticitat | Es connecten al principal | No obligatòria: el consumidor es connecta directament al principal |
Flux de decisió pas a pas
- Identificar on es troben els consumidors.
- Si estan tots en un entorn → aquest és el clúster principal.
- Si estan en diversos entorns:
- Agrupar consumidors per entorn.
- Identificar el grup més crític (funcionalment o per volum).
- Definir aquest entorn com a principal.
- Connectar tots els productors al clúster principal, independentment de la seva ubicació.
- Replicar cap als clústers secundaris quan hi hagi consum rellevant.
- Evitar replicació si el consum és marginal i no hi ha creixement previst.
Criteris generals de decisió
- Si tots els consumidors resideixen en un únic entorn, aquest entorn es defineix com a clúster principal.
- Si els consumidors estan distribuïts en diversos entorns:
- s’agrupen per entorn,
- s’identifica el grup més crític (funcionalment o per volum),
- l’entorn corresponent es defineix com a clúster principal.
Com determinar quin entorn és més crític:
Es considera més crític l’entorn on l’impacte d’una latència elevada o d’una pèrdua de missatges seria major (per volum, per SLA o per impacte funcional de negoci). En cas d’empat entre dos entorns amb criticitat similar, es prioritza l’entorn on resideix el productor principal del cas d’ús.
- La replicació s’utilitza per apropar el consum als entorns secundaris quan sigui necessari.
Excepció per criteri d’eficiència
Quan en un entorn secundari existeix un únic consumidor i no es preveu creixement, es pot evitar la replicació i permetre que aquest consumidor accedeixi directament al clúster principal.
Aquesta decisió ha de prioritzar:
- simplicitat operativa,
- cost d’infraestructura,
- reducció de dependències entre clústers.
Exemples pràctics
Exemple 1: tots els consumidors en onpremise
Una aplicació CRM (onpremise) publica altes de client. Tres aplicacions onpremise les consumeixen. Una aplicació a Azure també vol consumir.
- Clúster principal: onpremise (grup crític de consumidors).
- El productor CRM es connecta a onpremise.
- L’aplicació d’Azure es connecta directament a onpremise (1 sol consumidor, sense previsió de creixement → no cal replicació).
Exemple 2: consumidors distribuïts
Una aplicació de Pagaments (AWS) publica transaccions. Tres aplicacions a AWS i dues aplicacions onpremise les consumeixen.
- Clúster principal: AWS (grup més crític per volum).
- Tots els productors es connecten a AWS.
- Es replica d’AWS a onpremise perquè les dues aplicacions onpremise consumeixin localment.
Conclusió
Aquest model de decisió permet aplicar criteris homogenis en la ubicació de casos d’ús, reduint ambigüitats de disseny i facilitant una arquitectura d’EventHub més clara, eficient i governada.
La concreció d’aquesta decisió s’aplica operativament a Aplicació del cas d’ús.