为什么需要schema registry？
首先我们知道:
Kafka将字节作为输入并发布
没有数据验证
但是：
如果Producer发送了bad data怎么办？
如果字段被重命名怎么办?
如果数据类型改变了怎么办？
这些情况都会导致consumer break
所以：
我们需要数据能够自我描述
我们需要能够在不破坏下游消费者的情况下演化数据
能够拒绝坏数据
为什么不在kafka broker收到消息时验证消息，而是使用schema registry？
由下面两幅图可以看到，schema registry是独立于kafka的一个组件。
Kafka Core：
Confluent Components -Schema Registry：
为什么schema registry不集成在kafka broker，因为这样会打破kafka一些优秀的特性:
Kafka不解析或读取你的数据(没有使用CPU)
Kafka将字节作为输入，而不需要事件将它们加载到内存中(称为零拷贝) 。什么是零拷贝，移步至https://www.cnblogs.com/fangjb/p/13271886.html
就Kafka而言，它甚至不知道你的数据是否是整数或是字符串。
所以：
Schema Registry需要是独立的组件
生产者和消费者需要能够与之对话
必须商定通用的数据格式
它需要支持schema
它需要支持进化
它需要是轻量级的
Solution:
Confluent Schema Registry
Apache Avro as the data format
Apache Avro& Avro Schema介绍
Apache Avro是一个数据序列化系统。
可以将Avro看作是JSON附带一个schema
Avro schema使用Json来定义
Avro依赖于schema
Avro优点：
1.丰富的数据结构
2.使用快速的压缩二进制数据格式
3.schema随数据一起出现
4.schema可以以安全的方式随时间进化(schema evolution)
5. Document嵌入到schema中
Avro缺点：
1.某些语言对Avro的支持可能缺乏
2.不使用avro工具就不能“打印”数据(因为压缩了和序列化)
数据类型
Schema 定义了基本数据类型和复杂数据类型，其中复杂数据类型包含不同属性。通过各种数据类型用户可以自定义丰富的数据结构
基本类型：
类型
含义
null
没有值
boolean
布尔值
int
32位有符号整数
long
64位有符号整数
float
单精度（32位）的IEEE 754浮点数
double
双精度（64位）的IEEE 754浮点数
bytes
8位无符号字节序列
string
字符串
复杂类型
Avro提供了6种复杂类型。分别是Record，Enum，Array，Map，Union和Fixed。
Record类型：
Record类型使用的类型名字是 “record”，还支持其它属性的设置：
name(必填)：record类型的名字
namespace：命名空间(可选)，相当于java中的包名
doc：这个类型的文档说明(可选)
aliases：record类型的别名，是个字符串数组(可选)
fields(必填)：record类型中的字段，是个对象数组。每个字段需要以下属性：
name(必填)：字段名字
doc：字段说明文档(可选)
type(必填)：一个schema的json对象或者一个类型名字
default：默认值(可选)
order：排序(可选)，只有3个值ascending(默认)，descending或ignore
aliases：别名，字符串数组(可选)
一个record例子：
{ "type": "record", "namespace": "com.aaa", "name": "Employee", "fields": [ { "name": "id", "type": "string"}, { "name": "first_name", "type": "string", "default": ""}, { "name": "last_name", "type": "string", "default":""} ] }