Dai Wei

微服务外部流量需要统一入口。本文整理网关的核心职责、能力边界与选型思路，帮助区分哪些逻辑该放网关、哪些必须回到业务服务或 BFF，避免网关膨胀成第二套单体。 要解决什么问题服务拆分后，认证、限流、日志若在每个服务重复实现，代码冗余且策略难统一。客户端直连多服务还暴露内部拓扑，协议和安全策略也难以集中治理。大促前若要调整全站限流阈值，没有网关就需要逐服务发版，风险高、回滚慢，观测也无法在入口层做统一大盘。 核心原理网关位于客户端与后端之间，核心做两件事：请求转发（动态路由、负载均衡、协议转换）和请求过滤（身份认证、权限校验、限流熔断、日志监控）。典型链路是客户端→前置负载均衡→网关集群→注册发现→目标服务。网关本身也要多实例部署，否则会成为新的单点；与 RPC 层分工是：网关面向南北向外部流量，RPC 面向东西向内部调用。 方案权衡Spring Cloud Gateway 与 Spring 生态集成好，基于 WebFlux 异步 IO；Kong、APISIX 偏高性能与插件生态，适合多语言栈。Zuul 1.x 已进入维护模式，新项目不建议选用。网关应承载协议级、通用型、跨服务的...

服务间调用是微服务血脉。RPC 专题梳理从 stub 代理到服务治理的完整链路，并指出与 HTTP API 的边界分工。 要解决什么问题拆分后进程间需像本地方法一样调用远程服务，涉及序列化、寻址、负载均衡、超时重试、熔断和 tracing。裸 HTTP+JSON 能通但缺少稳定 IDL、服务发现和治理策略，团队会在每个项目重复造轮子。 核心原理RPC 链路：Client stub→序列化→网络→Server 反序列化→执行→返回。注册中心维护 provider 列表；客户端 LB 选实例；框架统一 timeout、retry、filter 链。Dubbo 偏 Java 生态私有协议；gRPC 用 HTTP/2+Protobuf 跨语言。与 HTTP REST 比，RPC 更重契约和性能，REST 更重通用性和缓存语义。 方案权衡内部高频调用倾向 RPC；对外公开 API 倾向 REST/GraphQL。HTTP/3 和 gRPC 演进中，选型看语言栈和网关能力。过度细粒度 RPC 导致 chatty interface 和级联延迟，需 batch...

理论专题是分布式底层的”为什么”。本文梳理协议类文章的学习顺序与内在联系，避免把共识算法和一致性哈希混为一谈。 要解决什么问题CAP、Paxos、Raft 等名词堆叠，初学者难见全貌。实际上它们分别回答：分区时如何取舍、如何在故障下对日志达成一致、如何把 key 均匀映射到节点。缺少导读容易只背结论而不懂问题域。 核心原理建议路径：CAP/BASE 建立取舍观→协调模式（Leader/Quorum/Gossip）→拜占庭拓展故障模型→Paxos/Raft/ZAB 共识→一致性哈希做数据分片。Raft 易Teaching，Paxos 经典，ZAB 贴近 ZK。Gossip 是 epidemic 传播，不是严格共识，常用于成员与 Cassandra 反熵。 方案权衡不必三类共识全精通到证明，但需知道 etcd/Raft、ZK/ZAB、Chubby/Paxos 映射。一致性哈希解决扩缩容迁移量，与共识解决 log 顺序是不同层。时间投入应匹配目标：后端开发重 CAP/锁/事务，基础架...

后端进阶绕不开分布式，但名词太多容易学散。本文把 JavaGuide 分布式专题按四条主线重新整理，帮助你在面试和工程选型时快速定位该读哪一块、各组件如何协作。 要解决什么问题单体应用在流量、存储和可用性到达瓶颈后，系统会被拆成多节点协作。此时 CAP、共识、RPC、锁、事务等概念不再孤立，而是围绕”多节点如何可靠协作”展开。入门者常困惑该从哪读起、各篇文章如何串联，若缺少地图就容易把 Raft 和 Redis 锁当成互不相关的内容分别死记。 核心原理JavaGuide 将分布式知识分为四条线：理论线（CAP、协调、共识）、调用线（RPC、网关）、一致性线（ID、锁、事务）、协调组件线（配置中心、ZooKeeper）。理论线解释分区发生时的取舍；调用线解决服务间与南北向流量如何进入系统；一致性线处理跨节点写入与互斥；组件线提供可复用的协调基础设施。四条线交叉处最多，例如锁依赖协调语义，事务依赖 CAP 取舍。 方案权衡不必按目录顺序死读。面试导向可先刷面试题清单建立考点，再回溯专题；工程导向可先补 RPC 和锁，遇到一致性问题再读 CAP 和事务。overview 的价值在于...

分布式不是”加机器”这么简单。本文重新梳理：什么算分布式、为什么拆、拆完麻烦从哪来，并给出可执行的学习顺序，避免一头扎进共识算法却说不清业务为什么需要多节点。 要解决什么问题一台机器能跑通的业务，拆成多服务后，本地方法调用变成网络请求，超时不再等于失败，事务不再天然原子。团队常在未遇瓶颈时过早拆分，复杂度先涨、收益滞后。电商下单链路一旦跨库存、订单、支付多个服务，重复消息、部分失败和响应丢失都会变成日常问题，而单体时代这些麻烦往往被本地事务掩盖。 核心原理分布式系统由多个独立计算单元经网络协作对外提供完整服务。核心变化包括：通信走网络、故障可局部发生、无瞬时全局视图、时钟不可完全对齐。典型演进是单体应用→多实例负载均衡→按业务域拆服务→引入消息队列与分库分表。每个阶段解决一类压力，也引入新的协调成本，这是后续 CAP、锁、事务等专题存在的背景。 方案权衡拆分带来独立扩容和故障隔离，也引入跨服务一致性、链路追踪和运维成本。单体开发调试简单，分布式适合高并发、大数据量和多团队并行。CAP 和分布式事务是后续专题，入门阶段只需知道它们处理”分区与协作”类麻烦，并能在架构评审时判断当...

入门 ZK 先搞懂”树形命名空间 + 事件通知”这套模型，再谈选举和锁。本文用场景驱动方式整理 ZNode 类型与 Watcher 语义。 要解决什么问题多进程需要共享配置、感知成员上下线、竞争独占资源。轮询数据库效率低且延迟大；ZK 提供层次化协调原语和推送式 Watcher，但 API 一次性触发、session 绑定等语义若不理解，容易出现”丢事件”或”惊群”问题。 核心原理ZNode 分持久、临时、顺序及其组合。临时节点随 session 消失，适合服务注册；顺序临时节点用于公平锁和 Leader 选举（序号最小者胜出）。Watcher 一次性，触发后需重新注册；getData/exists/getChildren 均可设 watch。ACL 控制 per-node 读写管理权限。读默认可能略旧，强一致读可在写后 sync。 方案权衡ZK 写路径线性一致，读从 local 可能滞后；Watcher 轻量但不保证中间每一变更都送达若客户端处理慢。数据量应小、变更频率适中；高频大 payload 不适合。与 etcd watch 相比，ZK Watch...

ZooKeeper 是经典分布式协调组件，Dubbo、Kafka 早期版本都重度依赖它。本文梳理专题结构及推荐学习顺序，便于分阶段掌握概念、协议与实战。 要解决什么问题分布式系统需要选主、配置同步、命名服务和分布式锁，自研协调逻辑成本高且易错。ZK 提供类文件系统的数据模型和顺序一致写入，但 Watcher、session、ZAB 等概念叠加，初学者容易在 API 层面会用却不理解失效行为。 核心原理ZK 核心是层次化 ZNode、一次性 Watcher 通知、ACL 和 ZAB 协议。典型用途：服务注册（临时节点）、配置（持久节点+watch）、Leader 选举（顺序临时节点）、分布式锁。专题分三篇：intro 讲模型与场景，plus 讲 ZAB 与选举，in-action 讲部署与 Curator。Curator Recipes 封装了常见协调模式，生产应优先使用。 方案权衡ZK 偏 CP，写吞吐有限，单节点数据应 KB 级，不适合当业务数据库。etcd 在 K8s 生态更主流，但 ZK 面试与 legacy 系统仍多。与 Redis 协调比，ZK 强在顺序和 ephe...

围绕“Docker 实战”，本文不按原目录复述，而是把内容整理为问题、机制、实践和取舍四层。阅读时可从“Docker 介绍、什么是 Docker、为什么要用 Docker、Docker 的安装”几个切面建立自己的判断框架。 核心认识开发工具的价值是让构建、运行和协作可重复。理解状态、依赖、版本与执行阶段，比记忆命令更重要；工具异常通常也应沿这些边界排查。 镜像是分层只读模板，容器是带可写层的运行实例，关键数据应放入外部卷。生产镜像宜多阶段构建、固定基础版本、非 root 运行并配置资源和健康检查。 学习这类主题时，应先写清对象、边界和衡量指标，再讨论具体组件或技巧。同一方案放在不同流量、数据规模与团队能力下，结论可能相反；设计说明必须保留前提。 工程实践团队应固定工具入口与关键版本，让本地和 CI 执行同一流程。配置变更要能通过日志、依赖图或产物校验验证，并保留安全的回退方式。 实施建议采用小步验证：记录变更前基线，一次只调整少量关键变量，通过日志、指标和测试判断收益。上线后继续观察长尾与异常路径，并把操作步骤沉淀成可执行预案。 权衡与边界自动化提高效率，也可能隐藏隐式行为和...

围绕“Gradle 核心概念总结”，本文不按原目录复述，而是把内容整理为问题、机制、实践和取舍四层。阅读时可从“Gradle 介绍、Groovy 介绍、Gradle 优势、Gradle Wrapper 介绍”几个切面建立自己的判断框架。 核心认识开发工具的价值是让构建、运行和协作可重复。理解状态、依赖、版本与执行阶段，比记忆命令更重要；工具异常通常也应沿这些边界排查。 Gradle 在初始化、配置、执行三个阶段构造并运行任务图。Wrapper 固定版本，任务声明输入输出才能利用缓存；配置阶段应避免昂贵 IO 和隐式副作用。 学习这类主题时，应先写清对象、边界和衡量指标，再讨论具体组件或技巧。同一方案放在不同流量、数据规模与团队能力下，结论可能相反；设计说明必须保留前提。 工程实践团队应固定工具入口与关键版本，让本地和 CI 执行同一流程。配置变更要能通过日志、依赖图或产物校验验证，并保留安全的回退方式。 实施建议采用小步验证：记录变更前基线，一次只调整少量关键变量，通过日志、指标和测试判断收益。上线后继续观察长尾与异常路径，并把操作步骤沉淀成可执行预案。 权衡与边界自动化提高...

围绕“Docker 专题：容器、镜像、仓库、数据卷、网络与容器化部署”，本文不按原目录复述，而是把内容整理为问题、机制、实践和取舍四层。阅读时可从“适合谁看、学习重点、建议阅读顺序、核心文章”几个切面建立自己的判断框架。 核心认识开发工具的价值是让构建、运行和协作可重复。理解状态、依赖、版本与执行阶段，比记忆命令更重要；工具异常通常也应沿这些边界排查。 镜像是分层只读模板，容器是带可写层的运行实例，关键数据应放入外部卷。生产镜像宜多阶段构建、固定基础版本、非 root 运行并配置资源和健康检查。 学习这类主题时，应先写清对象、边界和衡量指标，再讨论具体组件或技巧。同一方案放在不同流量、数据规模与团队能力下，结论可能相反；设计说明必须保留前提。 工程实践团队应固定工具入口与关键版本，让本地和 CI 执行同一流程。配置变更要能通过日志、依赖图或产物校验验证，并保留安全的回退方式。 实施建议采用小步验证：记录变更前基线，一次只调整少量关键变量，通过日志、指标和测试判断收益。上线后继续观察长尾与异常路径，并把操作步骤沉淀成可执行预案。 权衡与边界自动化提高效率，也可能隐藏隐式行为和供...