我心飞翔

对于 pprof，相信熟悉 Go 语言的程序员基本都不陌生，一般线上的问题都是靠它可以快速定位。但是实际项目中，很多时候我们为了性能都不会开启它，但是出了问题又要靠它来分析。好在 go-zero 已经帮我们很好的集成进来了，我们只需要像开关一样去开启、关闭它即可，这样我们就可以配合运维监控，当出现 cpu、内存等异常情况时候，自动开始开启收集（比如大半夜你睡的正香的时候），那么第二天可以通过分析当时的采样还原现场，那我们看看 go-zero 是如何做的。

熔断原理分析与源码解读熔断机制（Circuit Breaker）指的是在股票市场的交易时间中，当价格的波动幅度达到某一个限定的目标（熔断点）时，对其暂停交易一段时间的机制。此机制如同保险丝在电流过大时候熔断，故而得名。熔断机制推出的目的是为了防范系统性风险，给市场更多的冷静时间，避免恐慌情绪蔓延导致整个市场波动，从而防止大规模股价下跌现象的发生。同样的，在高并发的分布式系统设计中，也应该有熔断的机制。...

负载均衡原理分析与源码解读上一篇文章一起学习了Resolver的原理和源码分析，本篇继续和大家一起学习下和Resolver关系密切的Balancer的相关内容。这里说的负载均衡主要指数据中心内的负载均衡，即RPC间的负载均衡。...

彻底搞懂服务发现在微服务架构中，有许多绕不开的技术话题。比如服务发现、负载均衡、指标监控、链路追踪，以及服务治理相关的超时控制、熔断、降级、限流等，还有RPC框架。这些都是微服务架构的基础，只有打牢这些基础，才敢说对微服务是有了一点理解，出门也好意思和别人打招呼了，被人提问的时候也能侃侃而谈了，线上出了问题往往也能寻根溯源内心不慌了，旁边的女同事小芳看着你的时候也是满眼的小可爱了。和和大家一起学习微服务架构的方方面面，主要形式是理论+源码+案例，如果时间允许也可能会加上配套视频。...

对于很多初创公司来说，业务的早期我们更应该关注于业务价值的交付，并且此时用户体量也很小，`QPS` 也非常低，我们应该使用更简单的技术架构来加速业务价值的交付，此时单体的优势就体现出来了。

在go-zero中SingleFlight的作用是：将并发请求合并成一个请求，以减少对下层服务的压力。

我们用一个系列来讲解从需求到上线、从代码到k8s部署、从日志到监控等各个方面的微服务完整实践。整个项目使用了go-zero开发的微服务，基本包含了go-zero以及相关go-zero作者开发的一些中间件，所用到的技术栈基本是go-zero项目组的自研组件，基本是go-zero全家桶了。实战项目地址：https://github.com/Mikaelemmmm/go-zero-looklook1、鉴权服务1.1 identity-apiidentity主要是用来做鉴权服务的，前面我们n

上篇文章开始，我们通过一个系列文章跟大家详细展示一个 go-zero 微服务示例，整个系列分十篇文章，目录结构如下： 环境搭建 服务拆分（本文） 用户服务 产品服务 订单服务 支付服务 RPC 服务 Auth 验证 服务监控 链路追踪 分布式事务 期望通过本系列带你在本机利用 Docker 环境利用 go-zero 快速开发一个商城系统，让你快速上手微服务。完整示例代码：GitHub - nivin-st

本文开始，我们会出一个系列文章跟大家详细展示一个 go-zero 微服务示例，整个系列分十篇文章，目录结构如下： 环境搭建（本文） 服务拆分 用户服务 产品服务 订单服务 支付服务 RPC 服务 Auth 验证 服务监控 链路追踪 分布式事务 期望通过本系列带你在本机利用 Docker 环境利用 go-zero 快速开发一个商城系统，让你快速上手微服务。完整示例代码：GitHub - nivin-stud

令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。

如果你写一个 bug 管理系统，用了这个 PeriodLimit 你就可以限制每个测试人员每天只能给你提一个 bug。工作是不是就轻松很多了？:P如今微服务架构大行其道本质原因是因为要降低系统的整体复杂度，将系统风险均摊到子系统从而最大化保证系统的稳定性，通过领域划分拆成不同的子系统后各个子系统能独立的开发、测试、发布，研发节奏和效率能明显提高。但同时也带来了问题，比如：调用链路过长，部署架构复杂度提升，各种中间件需要支持分布式场景。为了确保微服务的正常运行，服务治理就不可或缺了，通常包括：...

什么是流处理如果有 java 使用经验的同学一定会对 java8 的 Stream 赞不绝口，极大的提高了们对于集合类型数据的处理能力。intsum=widgets.stream().filter(w->w.getColor()==RED).mapToInt(w->w.getWeight()).sum();Stream 能让我们支持链式调用和函数编程的风格来实现数据的处...

我为啥给项目取 go-zero 这个名字，我希望解决问题的时候是我们回到原点去思考，而不是遇到钉子就找锤子。正所谓：做正确的事，正确的做事！

分布式锁，是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。

为什么需要布隆过滤器想象一下遇到下面的场景你会如何处理： 手机号是否重复注册 用户是否参与过某秒杀活动 伪造请求大量 id 查询不存在的记录，此时缓存未命中,如何避免缓存穿透 针对以上问题常规做法是：查询数据库，数据库硬扛，如果压力并不大可以使用此方法，保持简单即可。改进做法：用 list/set/tree 维护一个元素集合，判断元素是否在集合内，时间复杂度或空间复杂度会比较高。如果是微服务的话可以用 redis 中的 list/set 数据结构, 数据规模非常大此方案

为什么需要一致性哈希首先介绍一下什么是哈希Hash，一般翻译做散列，或音译为哈希，是把任意长度的输入（又叫做预映射pre-image）通过散列算法变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来确定唯一的输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。在分布式缓存服务中，经常需要对服务进行节点添加和删除操作，我们希望的是节点添加和删除操作尽量减少数据-节点之

微服务集群中，调用链路错综复杂，作为服务提供者需要有一种保护自己的机制，防止调用方无脑调用压垮自己，保证自身服务的高可用。

为什么需要熔断微服务集群中，每个应用基本都会依赖一定数量的外部服务。有可能随时都会遇到网络连接缓慢，超时，依赖服务过载，服务不可用的情况,在高并发场景下如果此时调用方不做任何处理，继续持续请求故障服务的话很容易引起整个微服务集群雪崩。 比如高并发场景的用户订单服务，一般需要依赖一下服务： 商品服务 账户服务 库存服务 假如此时 账户服务 过载，订单服务持续请求账户服务只能被动的等待账户服务报错或者请求超时，进而导致订单请求被大量堆积，这些无效请求依然会占用系统资源：cp

为什么需要超时控制？很多连锁故障的场景下的一个常见问题是服务器正在消耗大量资源处理那些早已经超过客户端截止时间的请求，这样的结果是，服务器消耗大量资源没有做任何有价值的工作，回复已经超时的请求是没有任何意义的。超时控制可以说是保证服务稳定性的一道重要的防线，它的本质是快速失败(fail fast)，良好的超时控制策略可以尽快清空高延迟的请求，尽快释放资源避免请求的堆积。服务间超时传递如果一个请求有多个阶段，比如由一系列 RPC 调用组成，那么我们的服务应该在每个阶段开始前检查截止时间以避免做

rest框架概览我们先通过 go-zero 自带的命令行工具 goctl 来生成一个 api service，其 main 函数如下：funcmain(){flag.Parse()varcconfig.Configconf.MustLoad(*configFile,&c)ctx:=svc.NewServiceContext(c)server:=rest.MustNewServer(c.RestConf)deferserver.Stop()...

延迟队列：一种带有 延迟功能 的消息队列 延时 → 未来一个不确定的时间 mq → 消费行为具有顺序性 这样解释，整个设计就清楚了。你的目的是 延时，承载容器是 mq。背景列举一下我日常业务中可能存在的场景： 建立延时日程，需要提醒老师上课 延时推送 → 推送老师需要的公告以及作业 为了解决以上问题，最简单直接的办法就是定时去扫表：服务启动时，开启一个异步协程 → 定时扫描 msg table，到了事件触发事件，调用对应的 handler几个缺..

什么是服务注册发现？对于搞微服务的同学来说，服务注册、服务发现的概念应该不会太陌生。简单来说，当服务A需要依赖服务B时，我们就需要告诉服务A，哪里可以调用到服务B，这就是服务注册发现要解决的问题。 Service B 把自己注册到 Service Registry 叫做 服务注册 Service A 从 Service Registry 发现 Service B 的节点信息叫做 服务发现 服务注册服务注册是针对服务端的，服务启动后需要注册，分为几个部分： 启动注..

## 背景在选择负载均衡算法时，我们希望满足以下要求：1. 具备分区和机房调度亲和性 - 每次选择的节点尽量是负载最低的 - 每次尽可能选择响应最快的节点2. 无需人工干预故障节点 - 当一个节点有故障时，负载均衡算法可以自动隔离该节点 - 当故障节点恢复时，能够自动恢复对该节点的流量分发基于这些考虑，`go-zero` 选择了 `p2c+EWMA` 算法来实现。## 算法的核心思想### p2c`p2c (Pick Of 2 Choices)` 二选一: ...

在 go-zero 的分布式缓存系统分享里，Kevin 重点讲到过一致性hash的原理和分布式缓存中的实践。本文来详细讲讲一致性hash的原理和在 go-zero 中的实现。以存储为例，在整个微服务系统中，我们的存储不可能说只是一个单节点。 一是为了提高稳定，单节点宕机情况下，整个存储就面临服务不可用； 二是数据容错，同样单节点数据物理损毁，而多节点情况下，节点有备份，除非互为备份的节点同时损毁。 那么问题来了，多节点情况下，数据应该写入哪个节点呢？hash所以本质来讲：

在 Golang 中的 map 结构，在删除键值对的时候，并不会真正的删除，而是标记。那么随着键值对越来越多，会不会造成大量内存浪费？首先答案是会的，很有可能导致 OOM，而且针对这个还有一个讨论：[https://github.com/golang/go/issues/20135](https://github.com/golang/go/issues/20135)。大致的意思就是在很大的 `map` 中，`delete` 操作没有真正释放内存而可能导致内存 OOM。所以一般的做法：就是 **重建

在服务端程序更新或重启时，如果我们直接 `kill -9` 杀掉旧进程并启动新进程，会有以下几个问题：1. 旧的请求未处理完，如果服务端进程直接退出，会造成客户端链接中断（收到 `RST`）2. 新请求打过来，服务还没重启完毕，造成 `connection refused`3. 即使是要退出程序，直接 `kill -9` 仍然会让正在处理的请求中断很直接的感受就是：在重启过程中，会有一段时间不能给用户提供正常服务；同时粗鲁关闭服务，也可能会对业务依赖的数据库等状态服务造成污染。所以我们服务重

1. Dockerfile一些额外注意点选择最简单的镜像比如alpine，整个镜像5M左右设置镜像时区RUN apk add --no-cache tzdataENV TZ Asia/Shanghai2. 多阶段构建第一阶段构建否则构建出可执行文件，确保构建过程独立于宿主机第二阶段将第一阶段的输出作为输入，构建出最终的极简镜像3. 完整Dockerfile编写过程首先安装 goctl 工具GO111MODULE=on GOPROXY=https://goproxy.cn/