发表于 | 分类于

1. Etcd冷启动

1.1 初始化主流程

Etcd的启动类为 父目录的main.go文件。其启动过程调用如下：

1
2
3
4
5
6
main.go
|- etcdmain/main.go(暂且忽略`gateway`和`proxy`模式启动)
    |- checkSupportArch // 检查是否是支持的处理器架构
    |- startEtcdOrProxyV2 // 解析参数并根据参数决定启动etcd节点还是按Proxy模式启动（这里按etcd节点形式启动）
        |- 生成默认参数`newConfig()`解析参数 `cfg.parse(os.Args[1:])`解析命令行启动参数
        |- startEtcd(&cfg.ec)// 启动过程最核心的地方

startEtcd中执行etcd启动的主要过程：

1
2
3
4
5
6
7
8
9
10
11
12
embed.startEtcd(inCfg *Config)
|- inCfg.Validate() //校验配置，检查url是否是以ip地址开头的，否则报错终止流程
|- configurePeerListeners(cfg) // 根据配置初始化peerListener结构体（为`peer`服务的服务器配置）
|- configureClientListeners(cfg) // 根据配置初始化clientListener结构体，（为`client`服务的服务器配置）
|- 通过判断是否有 `wal`文件来判断是否已经有其他节点信息
    |- cfg.PeerURLsMapAndToken("etcd")方法，其用于解析出其他节点的信息。
    |- etcd集群模式有三种启动方式，其具体实现即实现在其内部。（`后续我们将详细分析`）
|- etcdserver.NewServer(srvcfg) // 执行etcdServer初始化
|- e.Server.Start() // 启动 etcdServer
|- e.servePeers() // 启动 监听etcd节点间请求的GRPC服务
|- e.serveClients() // 启动监听客户端请求的GRPC服务
|- e.serveMetrics() // 启动Metrics Http服务，供外部查询Metrics信息

通过 cfg.PeerURLsMapAndToken(“etcd”) 逻辑，了解到etcd有三种方式来获取集群中其他节点信息：

1
2
3
4
5
switch {
	case cfg.Durl != "":// etcd自发现模式：配置 “discovery”参数设置。这里没有真正获取集群所有节点。比较trick的作用，等后面来处理。
	case cfg.DNSCluster != "":// 通过DNS自发现模式，配置”discovery-srv“
  default:// 默认的静态配置方式，通过参数 "initial-cluster"进行设置
}

准备好创建etcd节点后开始初始化节点信息：

1
2
3
4
5
6
etcdserver/NewServer(srvcfg)
|- fileutil.TouchDirAll(cfg.DataDir) //检查是否可以获取目录权限：DataDir:"集群名.etcd"
|- fileutil.TouchDirAll(cfg.SnapDir()) // 检查是佛偶可以获取快照目录权限 ”集群名.etcd/member/snap“
|- snap.New(cfg.Logger, cfg.SnapDir()) //创建快照管理器
|- be := openBackend(cfg) // 创建数据库后端，其底层使用boltDB存储数据，然后在其之上进行了一次封装：包括批量提交事务。（关于存储的内容，我们后面讲单独讲解）
|- rafthttp.NewRoundTripper(cfg.PeerTLSInfo, cfg.peerDialTimeout()) // 创建一个RoundTripper，其作用是封装一个具有执行一次http事务，为一个http request获取response的对象
阅读全文 »

发表于 | 分类于

0. ETCD简介

本文将从以下几个方面来分析 ETCD （v3.3.12）。

  1. 整体架构
  2. 启动过程
  3. 数据存储
  4. 通信方式
  5. TTL实现原理
  6. Lease实现原理
  7. 单次事务过程
  8. 线性一致性读过程
  9. Watch机制

在介绍上面所有过程之前，我们先来介绍下 ETCD的整体架构以及相关名词术语。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
- Node：一个Raft状态机节点；
- Proxy：etcd的一种模式，为etcd集群提供反向代理服务；
- Member： etcd集群中的一个节点。它可以与其他节点进行交互且为客户端提供服务；
- Cluster：由多个Member组成的etcd集群；
- Peer：对处在相同集群中其他节点的称呼；
- Client： 请求客户端；
- Candidate	候选人
- Leader	领导者
- Follower	跟随者
- Term	选举任期，每次选举之后递增1
- Index：索引号，Raft中通过Term和Index来定位数据。
- Vote	选举投票(的ID)
- Commit	提交
- Propose	提议
- WAL：预写式日志
- SoftState：软状态，软状态易变且不需要保存在WAL日志中的状态数据，包括：集群leader、节点的当前状态
- HardState：硬状态，与软状态相反，需要写入持久化存储中，包括：节点当前Term、Vote、Commit
- ReadStates：用于读一致性的数据，后续会详细介绍
- Entries：在向其他集群发送消息之前需要先写入持久化存储的日志数据
- Snapshot：需要写入持久化存储中的快照数据
- CommittedEntries：需要输入到状态机中的数据，这些数据之前已经被保存到持久化存储中了
- Messages：在entries被写入持久化存储中以后，需要发送出去的数据

peer间通信消息类型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
- MsgHup            // 不用于节点间通信，仅用于发送给本节点让本节点进行选举
- MsgBeat           // 心跳消息
- MsgProp           // raft库使用者提议（propose）数据
- MsgApp            // 用于leader向集群中其他节点同步数据的消息
- MsgAppResp        // 消息同步回复
- MsgVote           // 请求投票
- MsgVoteResp       // 投票反馈
- MsgSnap           // 用于leader向follower同步数据用的快照消息
- MsgHeartbeat      // 心跳消息
- MsgHeartbeatResp  // 心跳回复消息
- MsgTransferLeader // 转移主节点
- MsgReadIndex      // 用于线性一致性读
- MsgReadIndexResp  
- MsgPreVote        // 请求预先投票
- MsgPreVoteResp

Etcd整体架构图如下：

下面将简单介绍下：

  1. etcd面向client和peer节点开放http服务以及grpc服务，对于像watch机制就是基于grpc的stream通信模式实现的；
  2. EtcdServer是etcd上层结构体，其负责对外提供服务，且负责应用层的实现，比如操作应用层存储器，管理leassor、watch；
  3. raftNode负责上层与raft层的衔接。其负责将应用的需求传递到raft中进行处理（通过Step函数）、在消息发送到其他节点前将消息保存到WAL中、调用传输器发送消息；
  4. raft是raft协议的承载者；
  5. raftLog用于存储状态机信息：memoryStorge保存稳定的记录，unstable保存不稳定的记录。
阅读全文 »

发表于 | 分类于

MCP协议&Galley

[TOC]

MCP协议

  • MCP协议全称是 Mesh Configuration Protocol。
  • 在Istio历史版本里，基于k8s来存储数据导致其与k8s耦合，限制了Istio的拓展性（非k8s机制则无法使用）。
  • MCP协议的出现即是为了解决与k8s耦合的问题。MCP定义了一套配置订阅与下发的标准协议，Pilot和Mixer 作为MCP client，任何实现了MCP协议的Server(如Galley)通过 MCP协议向Pilot下发配置。

MCP中对配置生生产者和消费者进行了如下抽象：

  • source：配置源，即Istio的Galley(配置中心)，对应的是Grpc中定义的 Service: ResourceSource；
  • sink：配置消费者，即Istio中的Pilot、Mixer，对应的Grpc中定义的ResourceSink；
  • resource：配置资源的抽象定义。
  1. 通常情况下，source作为Grpc的server，提供ResourceSource服务；sink作为Grpc的client，提供ResourceSink服务，sink主动向source发起连接，请求资源。当有资源更新时source将信息push给sink；
  2. 但MCP也支持一些特殊场景，Source 作为Client 向Sink Server建立新连接，然后Sever向Client发起资源请求（实际还是Sink请求Source，只是Sink作为Server，让Source连上来）。

MCP中Sink与Source交互接口定义：

阅读全文 »

发表于 | 分类于

Pilot

Pilot是Istio的控制中枢，它负责sidecar的生命周期管理并负责向Sidecar下发控制数据。

[TOC]

下面将从以下几个方面来分析Pilot:

  • 整体架构
  • 启动过程
  • Sidecar 初始拉取过程 & 信息下发过程
  • 拓展性

整体架构

Pilot 内部整体架构如下：

  • 实现 Grpc Server 对Envoy提供查询配置以及服务发现服务；
  • 支持配置控制器、服务控制器
  • 配置控制器支持聚合多种类型配置源，如 K8s、基于文件系统的内存配置源、Galley 以及其他的实现MCP协议的拓展配置中心服务；
  • 服务控制器同样支持多种类型服务注册中心，如 K8s、Consul以及可以拓展MCP协议实现的注册中心服务
  • 另外，通过ControlZ服务对外暴露 Pilot 内部配置&运行时信息的查询和修改接口

启动分析

阅读全文 »

发表于 | 分类于

Istio

Istio 是An open platform to connect, manage, and secure microservices.（用于连接、管理、保护微服务的开发平台)。由Google|Lyft|IBM联合开发，是当下开源社区最火的ServiceMesh项目。
由于作者从事ServiceMesh相关研发工作，因此决定抽出时间来细致研究Istio核心原理，并落地本系列文章。
本系列文章将详细讲解如下内容：
1. Istio 整体架构&核心工作流程
2. Pilot 控制中枢源码解析
2. Galley&MCP源码解析
3. Mixer 原理解析
4. Envoy 原理解析
5. 总结&讨论

特别说明，本文内容基于Istio@1.4.2进行的源码分析。

阅读全文 »