如何让gRPC具备微服务治理能力

[TOC]

近期比较火的开源项目go-zero是一个集成了各种工程实践的包含了Web和RPC协议的功能完善的微服务框架，今天我们就一起来分析一下其中的RPC部分zRPC。

zRPC底层依赖gRPC，内置了服务注册、负载均衡、拦截器等模块，其中还包括自适应降载，自适应熔断，限流等微服务治理方案，是一个简单易用的可直接用于生产的企业级RPC框架。

阅读全文 »

基于gRPC的注册发现与负载均衡的原理和实战

[TOC]

gRPC是一个现代的、高性能、开源的和语言无关的通用RPC框架，基于HTTP2协议设计，序列化使用PB(Protocol Buffer)，PB是一种语言无关的高性能序列化框架，基于HTTP2+PB保证了的高性能。go-zero是一个开源的微服务框架，支持http和rpc协议，其中rpc底层依赖gRPC，本文会结合gRPC和go-zero源码从实战的角度和大家一起分析下服务注册与发现和负载均衡的实现原理。

阅读全文 »

熔断原理与实现Golang版

[TOC]

在微服务中服务间依赖非常常见，比如评论服务依赖审核服务而审核服务又依赖反垃圾服务，当评论服务调用审核服务时，审核服务又调用反垃圾服务，而这时反垃圾服务超时了，由于审核服务依赖反垃圾服务，反垃圾服务超时导致审核服务逻辑一直等待，而这个时候评论服务又在一直调用审核服务，审核服务就有可能因为堆积了大量请求而导致服务宕机

阅读全文 »

go-zero 如何应对海量定时/延迟任务？

[TOC]

一个系统中存在着大量的调度任务，同时调度任务存在时间的滞后性，而大量的调度任务如果每一个都使用自己的调度器来管理任务的生命周期的话，浪费cpu的资源而且很低效。

本文来介绍 go-zero 中 延迟操作，它可能让开发者调度多个任务时，只需关注具体的业务执行函数和执行时间「立即或者延迟」。而 延迟操作，通常可以采用两个方案：

1. Timer：定时器维护一个优先队列，到时间点执行，然后把需要执行的 task 存储在 map 中
2. collection 中的 timingWheel ，维护一个存放任务组的数组，每一个槽都维护一个存储task的双向链表。开始执行时，计时器每隔指定时间执行一个槽里面的tasks。

方案2把维护task从 优先队列 O(nlog(n)) 降到 双向链表 O(1)，而执行task也只要轮询一个时间点的tasks O(N)，不需要像优先队列，放入和删除元素 O(nlog(n))。

阅读全文 »

微服务过载保护原理与实战

[TOC]

连锁故障

在微服务中由于服务间相互依赖很容易出现连锁故障，连锁故障可能是由于整个服务链路中的某一个服务出现故障，进而导致系统的其他部分也出现故障。例如某个服务的某个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例像多米诺骨牌一样一个个全部出现故障，这种连锁故障就是所谓的雪崩现象。

比如，服务A依赖服务C，服务C依赖服务D，服务D依赖服务E，当服务E过载会导致响应时间变慢甚至服务不可用，这个时候调用方D会出现大量超时连接资源被大量占用得不到释放，进而资源被耗尽导致服务D也过载，从而导致服务C过载以及整个系统雪崩。

阅读全文 »

通过MapReduce降低服务响应时间

[TOC]

在微服务中开发中，api网关扮演对外提供restful api的角色，而api的数据往往会依赖其他服务，复杂的api更是会依赖多个甚至数十个服务。虽然单个被依赖服务的耗时一般都比较低，但如果多个服务串行依赖的话那么整个api的耗时将会大大增加。

那么通过什么手段来优化呢？我们首先想到的是通过并发来的方式来处理依赖，这样就能降低整个依赖的耗时，Go基础库中为我们提供了 WaitGroup 工具用来进行并发控制，但实际业务场景中多个依赖如果有一个出错我们期望能立即返回而不是等所有依赖都执行完再返回结果，而且WaitGroup中对变量的赋值往往需要加锁，每个依赖函数都需要添加Add和Done对于新手来说比较容易出错

基于以上的背景，go-zero框架中为我们提供了并发处理工具MapReduce，该工具开箱即用，不需要做什么初始化，我们通过下图看下使用MapReduce和没使用的耗时对比:

阅读全文 »