服务边界不是拆得越细越好：微服务治理真正要管什么
大家好，我是Z哥。 你有没有见过这种场景？ 一个后台 Job，因为运行时间长、资源消耗大，被提议单独拆一个服务。 一个商品详情页，因为要聚合商品、库存、营销、评价，也被提议单独建一个聚合服务。 App、H5、PC 三端字段不一样，于是有人说，那就每端一个 BFF。 再加上 CI 慢、部署慢、扩缩容策略不同、MQ Con
go-zero框架HttpCode 503错误与context canceled高相关性根因分析
当流量瞬时激增时，API会出现大量 HttpCode 为 503 的错误。与此同时，发现另一个错误 `responses.go:69 write response failed, error: context canceled` 与该错误具有很强的相关性。
手把手教你golang实践熔断
熔断是一种通用能力，可以在服务端做也可以在客户端做。我们的项目中大多数都基于 go-zero 框架实现，而使用 go-zero 框架实现的项目自带服务端熔断能力，所以本文的目的是阐述如何在客户端侧实现熔断机制。
一些微服务拆分的浅见
不管是十几年前 SOA 的流行，还是 7、8 年前微服务的大行其道，还是如今云原生的展露锋芒，背后都离不开一件事，程序拆分或者说服务拆分。否则，一个单体应用，以上的这些技术潮流好像都与它没什么关系，只是一个看客。
应对「高并发」的思路
最近正好在编写一套新的面试题，其中有一道是与高并发相关的。出题的目的是想了解一下候选人面对大流量场景下的优化思路。在出这道题的过程中，我自己也梳理了一下自己对这个问题的思路。
微服务要凉了？
近期这类信息被报道的频繁度进一步增加。这不，最近陆续又有一些国外公司宣布退出微服务架构的迭代路线，逐渐将一些小粒度的服务进行合并成一个更大粒度的服务，甚至还发明了一个新的名词——「宏服务（macroservices）」。其中不乏像Uber这样的体量的大公司。
性能优化 = 改改代码？
在一个大系统中，数据就像水，整个系统就像是一个漏斗，漏斗的每一层代表每个子程序。上层的子程序对性能的损耗越低，能流下去的水就越多，直到最后一层「数据库」处，也可以理解为是存储。
做「容量预估」可没有true和false
随着20年来互联网的蓬勃发展，一个软件系统所要面对的访问压力上限被逐渐提高。 虽然如此，但是那些 […]
纠正一个错误，分布式系统关注点第17篇
今天来纠正一个错误。先和大家说一声抱歉：D 昨晚睡觉前，惯例打开「订阅号助手」回复一些留言。有一 […]
8个月打磨，一份送给程序员的「分布式系统」合集
是的，这份礼物最佳受众是程序员。但是，如果你不是程序员，相信这些能使你更懂程序员，能更好的与他们交流。 有些小 […]