共计 3662 个字符，预计需要花费 10 分钟才能阅读完成。
0 专辑概述
etcd 是云原生架构中重要的根底组件，由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅能够作为服务注册与发现，还能够作为 key-value 存储的中间件。
《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实际、API 接口、实现原理、源码剖析，以及实现中的踩坑教训等几方面具体开展介绍 etcd。预计会有 20 篇左右的文章，笔者将会每周继续更新，欢送关注。
1 Etcd API 概述
本文将会开始介绍 etcd3 API 的外围设计，次要针对常见的 API 接口服务。对于了解 etcd 根本思维有很大的帮忙。所有 etcd3 API 均在 gRPC 服务中定义，该服务对 etcd 服务器能够了解的近程过程调用（RPC）进行分类。
2 proto3
etcd v3 的通信基于 gRPC，proto 文件是定义服务端和客户端通信接口的规范。即客户端该传什么样的参数，服务端该返回什么样子的参数，客户端该怎么调用，是阻塞还是非阻塞，是同步还是异步。在进行外围 API 的学习之前，gRPC 举荐应用 proto3，咱们须要对 proto3 的根本语法有初步的理解。proto3 是原有 Protocol Buffer 2(被称为 proto2)的降级版本，删除了一部分个性，优化了对挪动设施的反对，另外减少了对 android 和 ios 的反对，使得 gRPC 能够顺利的在挪动设施上应用。
2.1 Protocol Buffer 是什么
Protocol buffer 是一个灵便、高效、自动化的结构化数据序列化机制 – 相似于 xml，然而更小、更快并且更简略。一旦定义好数据如何结构，就能够应用非凡生成的源代码轻松地在各种数据流中应用各种语言编写和读取结构化数据。甚至能够更新之前定义的数据结构而不突破已部署的应用 ” 旧有 ” 格局编译的程序。
2.2 定义音讯类型
首先让咱们来看一个非常简单的例子。假设咱们有这样的需要，咱们要定义一个搜寻申请音讯，每个音讯都蕴含一个查问字符串，和你感兴趣的特定页面编号，以及每个页面的命中个数。
syntax = “proto3”;
message SearchRequest {
string query = 1;
int32 page_number = 2;
int32 result_per_page = 3;
}
文件的第一行指定了你应用的是 proto3 的语法：如果你不指定，protocol buffer 编译器就会认为你应用的是 proto2 的语法。这个语句必须呈现在.proto 文件的非空非正文的第一行。
咱们看到，搜寻申请音讯构造中定义指定了三个字段（name/value pairs）。每个字段都有一个名称和类型。
2.3 指定字段类型
在上述例子中，所有的字段都是值类型：两个整形(page_number and result_per_page) 和一个字符串 (query)。然而，你也能够指定你的字段的组合类型，包含枚举和其余音讯类型。
2.4 调配标识——tag
音讯中的每个字段都有一个惟一的数字标识。这些标识用来在音讯的二进制格局中辨认你的字段，并且，一旦你的音讯投入使用，这些标识就不应该再被批改。
留神，标识是由 1 到 15 应用一个字节来编码，包含标识数字和字段类型（你能够在 Protocol Buffer 编码中查看更多具体）。
标识 16 到 2047 占用两个字节。所以你应该保留 1 到 15，用作呈现最频繁的音讯类型的标识。记得为未来会持续减少并可能频繁呈现的元素留一点儿标识区间，也就是说，不要一下子把 1—15 全副用完，为未来留一点儿哦。
你能够指定的最小的标识数字是 1，最大是 228，或者 536,870,911。你也不能应用 19000 到 19999 之间的数字(FieldDescriptor::kFirstReservedNumber through FieldDescriptor::kLastReservedNumber)，因为它们被 Protocol Buffers 保留应用——如果你在本人的.proto 文件中应用了一个保留数字，protocol buffer 编译器将会提醒。同样的，你不能应用任何之前保留的标识。
2.5 指定字段规定
音讯字段能够是下边中的一种：
singular(单个)：合乎语法规定的音讯蕴含零个或者一个这样的字段（最多一个）。
repeated(反复)：一个字段在非法的音讯中能够反复呈现肯定次数（包含零次）。反复呈现的值的秩序将被保留。在 proto3 中，反复呈现的值类型字段默认采纳压缩编码。
2.6 增加更多音讯类型
多个音讯类型能够定义在一个.proto 文件中。这个在你定义多个关联的音讯的时候十分有用，——这样，举个例子吧，如果你想定义你的搜寻音讯类型的响应音讯格局，你能够在同一个.proto 文件中增加如下的内容：
message SearchRequest {
string query = 1;
int32 page_number = 2;
int32 result_per_page = 3;
}
message SearchResponse {
…
}
2.7 增加正文
在你的 .proto 文件中增加正文, 应用 C /C++- 格调的 // 语法，像下边这样：
message SearchRequest {
string query = 1;
int32 page_number = 2; // Which page number do we want?
int32 result_per_page = 3; // Number of results to return per page.
}
2.8 保留字段
如果你通过删除整个字段更新了音讯类型，或者将整个字段其正文掉，将来用户在编写新的类型的时候可能复用这些正文掉的标识数字。然而，这会引起一些重大的问题，如果他们起初加载了同一个.proto 的旧版，包含数据损坏，平安隐衷 bug 等等。一个确保这种问题不会产生的方法是，保留你要删除的字段的标识。Protocol buffer 编译器将会提醒当前用户应用这些保留的字段标识。
message Foo {
reserved 2, 15, 9 to 11;
reserved “foo”, “bar”;
}
留神不要混同同一个保留语句中的字段名称和标识。
2.9 .proto 编译之后会生成什么
一个 .proto 文件的编译之后，编译器会为你抉择的语言生成代码。你在文件中形容的音讯类型，包含获取和设置字段的值，序列化你的音讯到一个输入流，以及从一个输出流中转换出你的音讯。
对于 C++，编译器会为每个 .proto 文件生成一个 .h 和一个 .cc 的文件，为每一个给出的音讯类型生成一个类。
对于 Java，编译器会生成一个 java 文件，其中为每一个音讯类型生成一个类，还有非凡的用来创立这些音讯类实例的 Builder 类，
Python 编译器生成一个模块，其中为每一个音讯类型生成一个动态的形容器，在运行时，和一个 metaclass 一起应用来创立必要的 Python 数据拜访类。
对于 Go，编译器为每个音讯类型生成一个 .pb.go 文件。
2.10 值类型
值类型的音讯字段能够是一下类型中的一种——这个表格展现了能够在.proto 文件中应用的类型，以及主动生成的相应语言的类型：
3 gRPC 服务
发送到 etcd 服务器的每个 API 申请都是一个 gRPC 近程过程调用。etcd3 中的 RPC 接口定义依据性能分类到服务中。
解决 etcd 键值的重要服务包含：
KV 服务，创立，更新，获取和删除键值对。
监督，监督键的更改。
租约，耗费客户端放弃流动音讯的基元。
锁，etcd 提供分布式共享锁的反对。
选举，裸露客户端选举机制。
3.1 申请和响应
etcd3 中的所有 RPC 都遵循雷同的格局。每个 RPC 都有一个函数名，该函数将 NameRequest 作为参数并返回 NameResponse 作为响应。例如，这是 Range RPC 形容：
service KV {
Range(RangeRequest) returns (RangeResponse)
…
}
3.2 响应头
etcd API 的所有响应都有一个附加的响应标头，其中包含响应的群集元数据：
message ResponseHeader {
uint64 cluster_id = 1;
uint64 member_id = 2;
int64 revision = 3;
uint64 raft_term = 4;
}
Cluster_ID – 产生响应的集群的 ID。
Member_ID – 产生响应的成员的 ID。
Revision – 产生响应时键值存储的订正版本号。
Raft_Term – 产生响应时，成员的 Raft 称呼。
应用服务能够通过 Cluster_ID 和 Member_ID 字段来确保，以后与之通信的正是预期的那个集群或者成员。
应用服务能够应用订正号字段来知悉以后键值存储库最新的订正号。当应用程序指定历史修订版以进行时程查问并心愿在申请时晓得最新修订版时，此性能特地有用。
应用服务能够应用 Raft_Term 来检测集群何时实现一个新的 leader 选举。
4 小结
本篇次要介绍了 Etcd API 中波及的 proto3 和 gRPC 申请响应相干的内容，理解这些是咱们学习 Etcd RPC 调用的前提。上面的文章开始介绍 etcd 中这几个重要的服务和接口。
