go-zero

链路追踪是每个微服务架构下必备的利器，go-zero 当然早已经为我们考虑好了，只需要在配置中添加配置即可使用。

前言 对于 pprof，相信熟悉 Go 语言的程序员基本都不陌生，一般线上的问题都是靠它可以快速定位。但是实际项目中，很多时候我们为了性能都不会开启它，但是出了问题又要靠它来分析。

熔断机制（Circuit Breaker）指的是在股票市场的交易时间中，当价格的波动幅度达到某一个限定的目标（熔断点）时，对其暂停交易一段时间的机制。此机制如同保险丝在电流过大时候熔断，故而得名。熔断

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

在微服务架构中，有许多绕不开的技术话题。比如服务发现、负载均衡、指标监控、链路追踪，以及服务治理相关的超时控制、熔断、降级、限流等，还有RPC框架。

gRPC 服务要加 HTTP 接口？ go-zero 给大家带来极简的 RESTful 和 gRPC 服务开发体验的同时，我想只写一次代码 既要 gRPC 接口 也要 HTTP 接口

代码不光是要实现功能，很重要的一点是代码是写给别人看的，所以我们对代码的质量要有一定的要求，要遵循规范，可以参考go官方的代码review建议。

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

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

在前几篇的文章中，我们花了很大的篇幅介绍如何利用缓存优化系统的读性能，究其原因在于我们的产品大多是一个读多写少的场景，尤其是在产品的初期，可能多数的用户只是过来查看商品，真正下单的用户非常少。

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

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

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

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

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

可能大家在工作中都遇到过这样的场景，就是代码更新了但是文档没有更新，从而产生一些问题导致一些扯皮事情的发生。这个问题的本质是服务和文档是割裂的。我们期望的是文档即协议，协议即服务。

微服务架构是一种架构风格，它将一个大的系统构建为多个微服务的集合，这些微服务是围绕业务功能构建的，服务关注单一的业务功能，这些服务具有以下特点： 高度可维护和可测试 松散的耦合 可独立部署。

现代的互联网产品随时都有面对突发大流量的可能，比如我们的商城平时可能业务流量比较平稳，但某一天运营突然说要做一次秒杀活动来推广，如果没有提前做好应对高并发的准备，我们的服务很可能是扛不住的。

goctl 的最早功能是为了解决 GRPC 内网调试问题，大约是在 2019 年，在我们的生产环境中，rpc 是内网隔离的，不可通过外网访问，为了快速 mock 一些线上 RPC client 的请求

对 Gopher 来说，虽然我们基本都是在写代码让别人来请求，但是有时候，我们也需要去请求第三方提供的 RESTful 接口，这个时候，我们才能感受到前端同学拼接 HTTP 请求参数的痛苦。