Arquitectura tècnica i components
Navegació
| ⬅️ Marc estratègic i principis | Seguretat i observabilitat ➡️ |
|---|
Visió general
L’arquitectura tècnica d’EventHub es basa en un model distribuït orientat a esdeveniments que permet la integració entre sistemes on-premise i entorns cloud sota un marc tecnològic homogeni.
La plataforma actua com a infraestructura comuna per a la publicació, consum i processament d’esdeveniments corporatius.
Components principals
L’arquitectura es compon dels següents elements:
1. Broker (Apache Kafka)
Nucli de la plataforma responsable de:
- Gestió de topics i particions
- Persistència i durabilitat dels esdeveniments
- Escalabilitat horitzontal
- Desacoblament entre productors i consumidors
La coordinació interna del clúster utilitza el controlador integrat de Kafka (KRaft), que elimina la dependència externa de ZooKeeper. Aquest detall és transparent per a les aplicacions i no requereix cap configuració addicional.
2. Schema Registry
Servei encarregat de la gestió dels contractes de dades.
Permet:
- Versionat d’esquemes
- Validació de compatibilitat
- Evolució controlada dels formats d’esdeveniment
3. Kafka Connect
Mecanisme d’integració amb sistemes externs.
Facilita:
- Ingesta de dades cap a la plataforma
- Exposició d’esdeveniments a altres sistemes
- Integració mitjançant connectors homologats
4. Processament en temps real (ksqlDB / Flink)
Capacitats per a:
- Transformació i enriquiment d’esdeveniments
- Agregacions i filtratge
- Generació d’esdeveniments derivats
5. Polítiques de retenció
La plataforma permet definir polítiques de retenció segons:
- Requisits funcionals
- Obligacions normatives
- Criteris operatius
Aquestes polítiques s’apliquen a nivell de topic segons configuració establerta.
Com se sol·licita i s’opera cada element
Els serveis de plataforma els gestiona la plataforma; l’aplicació no els sol·licita. Els recursos els demana l’equip d’aplicació amb la plantilla i JIRA (vegeu CRQ i Desplegament i Autoservei governat).
Serveis de plataforma
| Servei | Funció | Sol·licita | Valida | Executa | CRQ |
|---|---|---|---|---|---|
| Broker (Kafka/KRaft) | Nucli de missatgeria | Oficina EventHub | Oficina EventHub | CPD4 (on-prem) / Oficina (cloud) | Sí |
| Schema Registry | Servei de contractes de dades | Oficina EventHub | Oficina EventHub | CPD4 (on-prem) / Oficina (cloud) | Sí |
| Kafka Connect | Servei d’integració | Oficina EventHub | Oficina EventHub | CPD4 (on-prem) / Oficina (cloud) | Sí |
| Motor de stream processing (ksqlDB/Flink) | Servei de processament en temps real | Oficina EventHub | Oficina EventHub | CPD4 (on-prem) / Oficina (cloud) | Sí (Flink només cloud) |
Recursos (els demana l’equip d’aplicació)
| Recurs | Funció | Sol·licita | Valida | Executa | CRQ |
|---|---|---|---|---|---|
| Topic | Canal d’esdeveniments | Equip propietari | Oficina + equip | CPD4 (on-prem) / Oficina (cloud) | Sí (PRO); PRE segons impacte |
| Schema | Contracte del topic | Equip propietari | Oficina + equip | CPD4 (on-prem) / Oficina (cloud) | Sí (PRE i PRO) |
| Client Kafka | Identitat i permisos | Equip propietari | Oficina + equip | CPD4 (on-prem) / Oficina (cloud) | Sí (PRO); + ACOGICAR (OAuth) |
| Connector | Integració amb BBDD/sistemes | Equip propietari | Oficina + equip | CPD4 (on-prem) / Oficina (cloud) | Sí (PRE i PRO) |
| Stream (ksqlDB/Flink) | Processament en temps real | Equip propietari | Oficina + equip | CPD4 (on-prem) / Oficina (cloud) | Sí (PRE i PRO); Flink només cloud |
La retenció no és un element independent: és un atribut del topic que es defineix a la fitxa de sol·licitud.
Topologia de clústers EventHub
La plataforma opera amb múltiples clústers distribuïts en quatre entorns:
| Entorn | Tipus | Components principals |
|---|---|---|
| On-premise | Infraestructura pròpia (CPD4) | Broker, Schema Registry, Kafka Connect, ksqlDB |
| AWS | Confluent Private Network | Kafka Cluster, Connect Cluster |
| Azure | Confluent Private Network | Kafka Cluster, Connect Cluster |
| Internet | Confluent Public Network | Kafka Cluster (accés públic gestionat) |
Confluent Private Network vs Public Network
- Confluent Private Network (AWS i Azure): el clúster s’executa dins de la xarxa privada de la Generalitat. El tràfic no surt a Internet públic. És el model estàndard per a aplicacions corporatives.
- Confluent Public Network (Internet): el clúster és accessible per a aplicacions que operen fora de la intranet corporativa. Requereix configuració específica de seguretat i és l’excepció, no la norma.
La selecció del clúster on ubicar un cas d’ús segueix els criteris definits a Decisió del clúster EventHub.

Figura – Components tècnics de l’Arquitectura EventHub