Una Google Cloud risorsa è qualsiasi componente che crei o utilizzi all'interno di the Google Cloud. Queste risorse costituiscono i blocchi predefiniti delle applicazioni e dei sistemi in esecuzione sulla piattaforma.
Le risorse in Managed Service per Apache Kafka includono le seguenti:
Cluster
Argomento
Gruppo di consumer
ACL
Registro di schema
Contesto (all'interno di un registro di schema)
Oggetto (all'interno di un registro di schema o di un contesto)
Versione (versioni di uno schema in un oggetto)
Schema (identificato dall'ID, associato a uno o più oggetti e versioni)
Per ulteriori informazioni sulla denominazione delle risorse generali, vedi Nomi delle risorse. Google Cloud L'API del registro di schema per Managed Service per Apache Kafka è stata progettata per la compatibilità con un'API open source esistente, pertanto alcune convenzioni di denominazione potrebbero differire dagli standard API tipici.
Formato del nome della risorsa
Di seguito sono riportati i formati per le diverse risorse:
Cluster:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/clusters/{CLUSTER_ID}Argomento:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/clusters/{CLUSTER_ID}/topics/{TOPIC_ID}Gruppo di consumer:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/clusters/{CLUSTER_ID}/consumerGroup/{CONSUMER_GROUP_ID}ACL:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/clusters/{CLUSTER_ID}/acl/{ACL_ID}Registro di schema:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/schemaRegistries/{SCHEMA_REGISTRY_ID}Contesto:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/schemaRegistries/{SCHEMA_REGISTRY_ID}/contexts/{CONTEXT_ID}Oggetto:
- Nel contesto predefinito:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/schemaRegistries/{SCHEMA_REGISTRY_ID}/subjects/{SUBJECT_ID} - In un contesto specifico:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/schemaRegistries/{SCHEMA_REGISTRY_ID}/contexts/{CONTEXT_ID}/subjects/{SUBJECT_ID}
- Nel contesto predefinito:
Schema (identificato dall'ID):
- Nel contesto predefinito:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/schemaRegistries/{SCHEMA_REGISTRY_ID}/schemas/ids/{SCHEMA_ID} - In un contesto specifico:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/schemaRegistries/{SCHEMA_REGISTRY_ID}/contexts/{CONTEXT_ID}/schemas/ids/{SCHEMA_ID}
- Nel contesto predefinito:
Versione (identificata dal numero di versione in un oggetto):
- Nel contesto predefinito:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/schemaRegistries/{SCHEMA_REGISTRY_ID}/subjects/{SUBJECT_ID}/versions/{VERSION_ID} - In un contesto specifico:
projects/{PROJECT_ID}/locations/{LOCATION_NAME}/schemaRegistries/{SCHEMA_REGISTRY_ID}/contexts/{CONTEXT_ID}/subjects/{SUBJECT_ID}/versions/{VERSION_ID}
- Nel contesto predefinito:
Nelle sezioni successive viene fornita un'analisi dettagliata di ogni componente.
ID progetto
Il valore deve essere l'ID progetto o il numero di progetto, disponibile da
la Google Cloud console. Ad esempio, my-cool-project è un ID progetto, mentre 123456789123 è un numero di progetto.
Località
Il valore deve essere una delle località di Managed Service per Apache Kafka supportate. Per un elenco di località disponibili, consulta Località di Managed Service per Apache Kafka.
ID
ID è l'ultimo segmento del percorso della risorsa. Le variabili come
{CLUSTER_ID}, {TOPIC_ID}, {CONSUMER_GROUP_ID},
{SCHEMA_REGISTRY_ID}, {CONTEXT_ID}, e
{SUBJECT_ID} devono essere conformi alle seguenti linee guida:
Non iniziare con la stringa
googIniziare con una lettera
Vincoli di lunghezza:
ID cluster: contengono da 3 a 255 caratteri.
ID argomento, gruppo di consumer: qualsiasi lunghezza consentita da Apache Kafka. I nomi degli argomenti Apache Kafka sono limitati a 249 caratteri.
ID registro di schema: contiene fino a 255 caratteri.
ID contesto: contiene fino a 255 caratteri.
ID oggetto: contiene fino a 255 byte UTF-8.
Vincoli dei caratteri:
ID cluster: devono corrispondere all'espressione regolare
^[a-z]([-a-z0-9]*[a-z0-9])?. Ciò significa lettere minuscole, numeri e trattini. Deve iniziare con una lettera e non può terminare con un trattino.ID argomento, gruppo di consumer: la convalida viene eseguita da Kafka. I caratteri consentiti sono `[a-zA-Z0-9.-], che include alfanumerici ASCII, punti (.), trattini bassi () e trattini (-).
ID registro di schema: lettere (maiuscole o minuscole), numeri e trattini bassi
_.ID contesto: lettere (maiuscole o minuscole), numeri e i seguenti caratteri speciali: trattini
-, punti., trattini bassi_, tilde~, segni di percentuale%o segni più+.ID oggetto: lettere (maiuscole o minuscole), numeri e i seguenti caratteri speciali: trattini
-, punti., trattini bassi_, tilde~, segni di percentuale%o segni più+.
Caratteri speciali
Puoi utilizzare i caratteri speciali elencati nella sezione precedente negli ID risorsa senza codifica URL. Tuttavia, devi assicurarti che qualsiasi altro carattere speciale sia codificato o decodificato correttamente quando viene utilizzato negli URL.
Ad esempio, mi-tópico è un ID non valido se ó non è un carattere consentito
per quel tipo di ID risorsa specifico. Tuttavia, mi-topico sarebbe valido se sono consentite solo le lettere latine di base. Questo formato è importante quando si effettuano chiamate REST.
Se fai riferimento a un argomento dalle librerie client Kafka, non viene utilizzato il percorso completo della risorsa. Viene utilizzato solo il nome dell'argomento. Allo stesso modo, quando interagisci con gli schemi utilizzando le integrazioni client Kafka come serializzatori o deserializzatori, in genere utilizzi il nome dell'oggetto anziché il percorso completo della risorsa.
Strategie di denominazione degli oggetti
Quando lavori con il registro di schema, in particolare con le integrazioni client Kafka come serializzatori e deserializzatori, il nome dell'oggetto è fondamentale. La strategia di denominazione degli oggetti determina la modalità di registrazione e recupero di uno schema dal registro di schema. Le diverse strategie offrono vari livelli di flessibilità e controllo sull'evoluzione dello schema.
Puoi configurare la strategia di denominazione degli oggetti impostando la proprietà key.subject.name.strategy o value.subject.name.strategy nella configurazione del client Kafka.
TopicNameStrategy
Questa è la strategia predefinita per le librerie client Kafka open source.
Il nome dell'oggetto viene derivato direttamente dal nome dell'argomento Kafka, a cui viene aggiunto key per le chiavi dei messaggi o value per i valori dei messaggi. Se auto.register.schema
è impostato su true, i client produttori utilizzano topicName-value o topicName-key
per un argomento denominato topicName.
Ecco alcuni esempi:
- Nome argomento:
orders - Oggetto per i valori dei messaggi:
orders-value - Oggetto per le chiavi dei messaggi:
orders-key
Di seguito è riportato un elenco dei vantaggi dell'utilizzo di TopicNameStrategy:
È una strategia semplice, quindi adatta a molti casi d'uso.
Gli schemi sono collegati direttamente a un argomento, il che ti consente di evolvere i tipi di record all'interno di un singolo argomento in modo indipendente.
Di seguito è riportato un elenco degli svantaggi dell'utilizzo di TopicNameStrategy:
- Ogni argomento può gestire in modo efficace un solo tipo di messaggio basato sullo schema dei valori. Questo perché il nome dell'oggetto è fisso al nome dell'argomento. Se devi inviare diversi tipi di record allo stesso argomento, questa strategia non funzionerà.
RecordNameStrategy
Questa strategia utilizza il nome completo della classe del record Avro o Protobuf come nome dell'oggetto.
Ecco alcuni esempi:
- Nome dello schema Avro:
com.example.data.Customer - Nome del messaggio Protobuf:
com.example.data.Order - Oggetto per lo schema
customer:com.example.data.Customer - Oggetto per lo schema
order:com.example.data.Order
Di seguito è riportato un elenco dei vantaggi dell'utilizzo di RecordNameStrategy:
Poiché il nome dell'oggetto non è legato all'argomento, puoi inviare diversi tipi di record allo stesso argomento Kafka. Ciò è possibile a condizione che ogni tipo di record abbia il proprio nome completo univoco e lo schema corrispondente registrato.
Uno schema per un tipo di record specifico, ad esempio
com.example.common.Address, può essere utilizzato in più argomenti e la sua evoluzione viene gestita centralmente in un singolo oggetto.
Di seguito è riportato un elenco degli svantaggi dell'utilizzo di RecordNameStrategy:
- Devi utilizzare lo stesso oggetto e la stessa versione per tutti gli argomenti che utilizzano un determinato tipo di record. Questo può essere restrittivo se hai bisogno di versioni diverse dello stesso tipo di record in argomenti diversi.
TopicRecordNameStrategy
Questa strategia combina aspetti di TopicNameStrategy e RecordNameStrategy.
Il nome dell'oggetto è una combinazione del nome dell'argomento Kafka e del nome completo della classe del record, nel formato TOPIC_NAME-FULLY_QUALIFIED_CLASS_NAME.
Ecco alcuni esempi:
Argomento:
user-eventsNome completo:
com.example.events.PageViewNome dell'oggetto per questa combinazione:
user-events-com.example.events.PageViewUn altro argomento:
product-interactionsNome completo:
com.example.events.PageViewNome dell'oggetto per questa combinazione:
product-interactions-com.example.events.PageView
Di seguito è riportato un elenco dei vantaggi dell'utilizzo di TopicRecordNameStrategy:
Analogamente a
RecordNameStrategy, puoi inviare diversi tipi di record allo stesso argomento.A differenza di
RecordNameStrategy, questa strategia ti consente di evolvere lo schema per un tipo di record specifico in modo indipendente all'interno di ogni argomento. Ciò significa chemy-topic-com.example.project.MyRecordpuò evolversi in modo diverso daanother-topic-com.example.project.MyRecord.
Di seguito è riportato un elenco degli svantaggi dell'utilizzo di TopicRecordNameStrategy:
- I nomi degli oggetti possono diventare piuttosto lunghi a causa della combinazione del nome dell'argomento e del nome completo del record.