配置中心与动态配置：配置为什么会成为线上风险点
很多人刚开始做服务时，会把配置理解成几个固定文件或者几条环境变量。只要程序能读到数据库地址、端口和几个开关，好像就够用了。但当服务数量增多、环境数量增多、功能开关增多以后，配置就不再只是“程序启动时要...
标签：服务治理
熔断、降级与限流：系统扛压时为什么不能硬撑
一个系统在低压状态下能稳定运行，并不意味着它在高峰、异常或者下游故障时也能稳定运行。很多线上事故的共同点并不是功能写错了，而是系统在超出承受范围后还在“硬撑”，结果把局部问题拖成了整体雪崩。 所以到了...
超时、重试与幂等：调用链稳定性的第一层保障
一个请求只要开始跨服务流转，稳定性问题就几乎一定会出现。网络可能抖动，下游可能短暂不可用，某个依赖可能偶尔响应很慢，某个调用可能在高峰期出现大量失败。这时，系统就不能只依赖“每次调用都刚好成功”，而必...
负载均衡原理：流量分发为什么不是“平均”这么简单
当一个服务有多个实例时，系统就要面临一个非常直接的问题：这一批请求应该发给谁。如果所有流量都打到同一个实例上，那扩容就失去了意义；如果实例之间分发策略不合理，即便节点数量不少，也可能出现有的机器很忙、...
服务注册与发现：服务之间到底是怎么找到彼此的
在单体服务里，模块之间调用通常只是函数调用。你知道它在哪个包、哪个文件、哪个接口，引用过来就能用。但当系统开始拆分成多个服务以后，问题一下子就变了：一个服务如果想调用另一个服务，它首先要知道对方在哪里...
从单体到多服务：为什么问题会从代码复杂变成系统复杂
很多团队在系统刚起步时，都会从一个单体服务开始。这是非常正常、也非常合理的选择。因为单体部署简单、调试直接、调用链清晰，开发和排查都相对低成本。问题往往不是单体本身，而是当业务不断增长以后，原本只需要...
写在前面：为什么服务治理与云原生不是“平台组的事”
在前一组 Go 后端工程化 里，我们解决的是一个服务怎么搭、怎么跑、怎么排查、怎么上线。那一组内容更像是在回答一个问题：当你手里只有一个服务时，怎样把它做得像一个真正可以交付的项目。 但服务一旦变多，...
从单体服务到 RPC 与微服务：Go 工程化下一步怎么走
当你把一个 Go HTTP 服务的基础工程化能力逐步补齐以后，通常会自然遇到下一个问题：如果业务继续增长，一个服务开始承担越来越多职责，或者系统之间需要更稳定地互相调用，后面应该怎么走？这时你会逐渐从...