熔断机制（Circuit Breaker）指的是在股票市场的交易时间中，当价格的波动幅度达到某一个限定的目标（熔断点）时，对其暂停交易一段时间的机制。此机制如同保险丝在电流过大时候熔断，故而得名。熔断机制推出的目的是为了防范系统性风险，给市场更多的冷静时间，避免...

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

在微服务架构中，有许多绕不开的技术话题。比如服务发现、负载均衡、指标监控、链路追踪，以及服务治理相关的超时控制、熔断、降级、限流等，还有RPC框架。这些都是微服务架构的基础，只有打牢这些基础，才敢说对微服务是有了一点理解，出门也好意思和别人打招呼了，...

gRPC 服务要加 HTTP 接口？go-zero 给大家带来极简的 RESTful 和 gRPC 服务开发体验的同时，社区又给我们提出了新的期望：我想只写一次代码既要 gRPC 接口也要 HTTP 接口既要。。。也要。。。也有道理嘛！你看用户怎么说：用户A：一套逻辑，api和rpc一起用户B：go-ze...

本篇是整个系列的最后一篇了，本来打算在系列的最后一两篇写一下关于k8s部署相关的内容，在构思的过程中觉得自己对k8s知识的掌握还很不足，在自己没有理解掌握的前提下我觉得也很难写出自己满意的文章，大家看了可能也会觉得内容没有干货。我最近也在学习k8s的一些最...

在分布式应用场景中，分布式事务问题是不可回避的，在目前流行的微服务场景下更是如此。比如在我们的商城系统中，下单操作涉及创建订单和库存扣减操作两个操作，而订单服务和商品服务是两个独立的微服务，因为每个微服务独占一个数据库实例，所以下单操作就涉及到分...

上一篇文章中引入了消息队列对秒杀流量做削峰的处理，我们使用的是Kafka，看起来似乎工作的不错，但其实还是有很多隐患存在，如果这些隐患不优化处理掉，那么秒杀抢购活动开始后可能会出现消息堆积、消费延迟、数据不一致、甚至服务崩溃等问题，那么后果可想而知。本...

在前几篇的文章中，我们花了很大的篇幅介绍如何利用缓存优化系统的读性能，究其原因在于我们的产品大多是一个读多写少的场景，尤其是在产品的初期，可能多数的用户只是过来查看商品，真正下单的用户非常少。但随着业务的发展，我们就会遇到一些高并发写请求的场景，...

前两篇文章我们介绍了缓存使用的各种最佳实践，首先介绍了缓存使用的基本姿势，分别是如何利用go-zero自动生成的缓存和逻辑代码中缓存代码如何写，接着讲解了在面对缓存的穿透、击穿、雪崩等常见问题时的解决方案，最后还重点讲解了如何保证缓存的一致性。因为缓存对...

你有同感吗？当大家在开发服务端代码的时候，会不会经常有如下疑问？纳闷 MySQL 连接池到底有多少连接？每个连接的生命周期持续多久？连接异常断开的时候到底是服务端主动断的，还是客户端主动断的？当长时间没有请求的时候，底层库是否有 KeepAlive 请求？复杂网络...

只要我们使用缓存，就必然会面对缓存和数据库间的一致性问题。如果缓存中的数据和数据库的数据不一致，那么业务应用从缓存中读取的数据就不是最新的数据，对业务的影响可想而知。比如我们把商品的库存数据存在缓存中，如果缓存中库存数据不对，那么可能就会影响下单...

缓存是高并发服务的基础，毫不夸张的说没有缓存高并发服务就无从谈起。本项目缓存使用Redis，Redis是目前主流的缓存数据库，支持丰富的数据类型，其中集合类型的底层主要依赖：整数数组、双向链表、哈希表、压缩列表和跳表五种数据结构。由于底层依赖的数据结构的高...

上一篇文章我们把整个项目的架子搭建完成，服务在本地也已经能运行起来了，顺利成章的接下来我们就应该开始写业务逻辑代码了，但是单纯的写业务逻辑代码是比较枯燥的，业务逻辑的代码我会不断地补充到 lerbon 项目中去，关键部分我也会加上注释。

<!-- go-zero微服务实战系列（三、API定义和表结构设计）-->前两篇文章分别介绍了本系列文章的背景以及根据业务职能对商城系统做了服务的拆分，其中每个服务又可分为如下三类：api服务 - BFF层，对外提供HTTP接口rpc服务 - 内部依赖的微服务，实现单一的业务功...

微服务架构是一种架构风格，它将一个大的系统构建为多个微服务的集合，这些微服务是围绕业务功能构建的，服务关注单一的业务功能，这些服务具有以下特点：

在社区中经常看到有人问有没有基于 go-zero 的比较完整的项目参考，该类问题本质上是想知道基于 go-zero 的项目的最佳实践。完整的项目应该是一个完整的产品功能，包含产品需求、架构设计、关键流程的编码、表设计以及各种性能优化和数据一致性等，是一个真正贴近生...

goctl 的最早功能是为了解决 GRPC 内网调试问题，大约是在 2019 年，在我们的生产环境中，rpc 是内网隔离的，不可通过外网访问，为了快速去 mock 一些线上 RPC client 的请求，就简单的实现了第一版本的代码生成，主要目的是去访问 RPC Server 做一些调试。

本文是对泛型的基本思想及其在 Go 中的实现的一个比较容易理解的介绍，同时也是对围绕泛型的各种性能讨论的简单总结。首先，我们来看看泛型所解决的核心问题。

对于很多初创公司来说，业务的早期我们更应该关注于业务价值的交付，而单体服务具有架构简单，部署简单，开发成本低等优点，可以帮助我们快速实现产品需求。我们在使用单体服务快速交付业务价值的同时，也需要为业务的发展预留可能性，所以我们一般会在单体服务中清...

本文是对泛型的基本思想及其在 Go 中的实现的一个比较容易理解的介绍，同时也是对围绕泛型的各种性能讨论的简单总结。首先，我们来看看泛型所解决的核心问题。