7.1、简介

​ 连接池很多同学都肯定接触过，也都使用过。连接池的主要作用就是连接复用，每次访问从池子里获取已经创建好的连接，这样可以减少创建，回收等一系列的操作所产生的的资源消耗，可以极大的提升服务的性能。我们通过分析go-mico的gRPC连接池的实现来总结连接池设计的方法论。

7.2、gRPC的传输基于什么协议？

gRPC是基于HTTP/2的，为什么是HTTP/2，大家可以直接Google，有很多博主的回答都很优秀。总结下来主要是：

• 连接非阻塞的，多路复用的。
• 头部压缩，基于二进制协议的传输协议。
• stream概念。
• 最重要的另一个原因就是，通用。移动终端设备也是最先使用HTTP/2。

6.1、简介

​ 在流量突增的情况下，为了保证服务的可用性，能做些什么呢？例如活动运营平台，平时流量不是很多，3台机器就可以解决。但是突然上线了一个奖励非常大的奖品，3台服务均到达高负载的状态，直接造成雪崩效应，应对这种突发流量，为了保证服务的可用性，引入一个新的概念，服务限流。

6.2、限流算法

​ 什么是服务限流？其实就是字面意思，限流请求的流量，达到一个快速拒绝的效果，保证服务的可用性，尽管会有部分用户请求失败，但是比全部用户不能访问，还是更友好一些。

限流为了限制单位时间内最大的处理速度。保证在服务不被压垮的情况下，以最大速率处理请求。以下场景可能会触发限流

• 拒绝服务，感知流量暴增的情况下，限制一些高频请求的客户端。
• 延时处理，缓冲队列中积压了大量的请求，并且已经达到队列上限。此时应该做限流处理。
• 服务降级，cpu等资源负载，此时应该触发限流。

主流的限流算法为以下几种：

• 计数器
• 队列
• 漏斗算法
• 令牌通算法

关于更详细的介绍请看之前关于弹性服务设计的总结：分布式之弹性：服务限流

5.1、简介

​ 集群服务中的节点ip不会永远不变，如果变化了怎么办？1台机器处理不过来，扩容了3台，如何让新增的3台快速投入使用，流量如何很快的流入新增的机器。集群中出现有问题的机器，如何下线呢？解决这些问题需要引入一个新的概念，服务发现

​ 服务发现需要解决以下问题：

• 服务IP与端口的确定方式。
• 服务注册与发现。
• 服务下线
• 服务健康监测。
• 节点加入或退出，如何通知订阅者变化。
• 查看应用的订阅列表，发布列表，以及订阅节点。

当A节点访问B集群的机器，这次访问究竟应该访问哪个节点？基于什么策略如何确定的？这又涉及到另一个概念，负载均衡，它是提供高可用服务的关键基础组件，核心作用就是将大量请求以合理的方式分配到多个执行单元上去执行，达到最优化的资源使用方式，避免多个单元同时发生过载。

比如我们从注册中心查询到10个可用节点，通过负载均衡器，可以将我们的10个请求，以一种策略打散到不同的可执行节点上，保障可用性。

关于基于etcd的服务发现与负载均衡算法可以先了解下。

• 服务发现
• 负载均衡算法

rpc_demo

对gRPC实践后，可以跟着调用链路分析下gRPC的调用流程。

这里抛几个问题：

• gRPC调用经历了哪些过程？
• gRPC内部调用的实现是什么样？
• gRPC底层传输依赖什么协议？
• client端如何发起的请求？
• server如何接收的请求？

这里抛几个问题：

• RPC服务目录结构怎么设计？
• 代码仓库如何处理？
• 协议仓库如何处理？
• 对外如何提供接口服务？

3.1、gRPC

​ gRPC是一个现代的开源高性能RPC框架，可以在任何环境下运行。它可以有效地连接数据中心内和数据中心之间的服务，并支持可插拔的负载平衡、跟踪、运行状况检查和身份验证。它也适用于分布式计算、移动应用程序和浏览器连接到后端服务。

​ 并且gRPC的资料很多，实践的文章也很多，后面统一使用gRPC作为我们了解RPC框架的实践。

这里抛出几个问题：

• RPC是什么？
• 本地函数调用的流程是什么？
• RPC与HTTP，TCP有什么关系？
• 一个标准的RPC包含哪些流程？
• 什么是协议？

2.1、简介

​ RPC框架全称Remote Procedure Call，翻译过来就是远程调用，RPC出现的原因主要是为了解决分布式系统中不同系统之间的接口调用。RPC使子系统接口的实现和调用可以分布在不同的机器上，RPC的调用非常方便，就像本地调用接口实现一样，RPC调用对于调用者来说，基本上属于黑盒。

1.1、简介

从客户端转后台开发已经快两年了，决定沉淀一些系统性的东西，想了很多题目，最终决定写一篇关于RPC框架相关的吧。

准备从概念，应用，到实践总结出一个系列。

1.2、涉及知识

• 以gRPC为示例，分析什么是RPC框架，已经RPC框架原理
• 弹性设计相关：服务限流、服务重试、服务熔断、服务隔离、服务降级，服务状态
• 服务注册，服务发现、健康检查

所有的概念尽量配合demo描述，从工业化实践出发总结。

1.3、风格

所有的文章均以先抛出问题，然后整篇文章已解决问题为主。

1.3、总结

希望今年上半年能够完成这个系列的总结。也是给自己一个系统性整理的机会。这里所有的概念很多人都讲过，但是本次我自己的总结尽量达到能够帮助新同学做到入门的一个效果。

1.1、kubernetes 安装

安装kubernetes的方法有很多，这里推荐使用minikube，是一个可以在本地快速构建kubernetes集群的命令行工具。

tips：计算机必须在 BIOS 中启用 VT-x 或 AMD-v 虚拟化。

检查方法：

• Mac：如果输出中包含VMX

1

sysctl -a | grep -E --color 'machdep.cpu.features|VMX'

• linux：输出非空

1

grep -E --color 'vmx|svm' /proc/cpuinfo

• windows：提示比较详细，这里就不贴出来了。

1

systeminfo

3.1、简介

​ 之前的文章分别介绍了prometheuss是如何采集数据以及如何对采集目标做服务发现的，本篇文章分析prometheus是如何将采集后的数据做保存的。

一、Prometheus源码分析之：数据采集) 描述了通过scrapeLoop的run方法采集指标数据。之后scrapeLoop调用append进行指标的保存。

3.2、scrapeCache

​ 真正存储指标的是storage.Appender，在scrape与storage之间有一层缓存。缓存主要的作用是过滤错误的指标。

1
2
3
4
5
6
7
8
9
10
11

type scrapeCache struct {
  iter uint64                           // scrape批次
	successfulCount int                   // 成功保存的元数据数
	series map[string]*cacheEntry         // 缓存解析的相关数据
	droppedSeries map[string]*uint64      // 缓存无效指标
	seriesCur  map[uint64]labels.Labels 	// 本次采集指标
	seriesPrev map[uint64]labels.Labels   // 上次采集指标

	metaMtx  sync.Mutex
	metadata map[string]*metaEntry
}

​ 上一篇文章一、Prometheus源码分析之：数据采集)，分析promentheus是如何采集target的指标数据的，接下来分析下，Prometheus的服务发现能力。在1.3版本后，服务发现能力成为独立模块。

2.1、简介

​ Prometheus通过pull拉取target数据，在上一篇文章中，target是通过静态文件配置的，难道后面增加一个target就需要手动配置，然后重新加载配置吗？其实加载target还支持一种方式：动态发现。

​ Prometheus目前支持以下平台的动态发现能力：

• 容器编排系统：kubernetes
• 云平台：EC2、Azure、OpenStack
• 服务发现：DNS、Zookeeper、Consul 等。