<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Distributed Systems on Chen Kai Blog</title><link>https://www.chenk.top/zh/tags/distributed-systems/</link><description>Recent content in Distributed Systems on Chen Kai Blog</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Sat, 30 May 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/zh/tags/distributed-systems/index.xml" rel="self" type="application/rss+xml"/><item><title>产品思维（一）：架构设计 — 从单体到自治 Agent</title><link>https://www.chenk.top/zh/product-thinking/01-architecture/</link><pubDate>Sat, 30 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/product-thinking/01-architecture/</guid><description>&lt;h2 id="系统的形状" class="heading-anchor">系统的形状&lt;a href="#%e7%b3%bb%e7%bb%9f%e7%9a%84%e5%bd%a2%e7%8a%b6" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>每一种架构都是一场被冻结的争论。它记录的是你提交代码那一刻对问题的信念。回顾过去十八个月我构建的四个系统——一个营销内容平台（~7 万行 TypeScript）、一个零依赖技能路由引擎、一个自主研究 Agent（~31.5 万行 Python）、以及一个多模型编码编排器——我能清楚地追溯自己架构直觉的轨迹。并非总是向前，有时是横向偏移。但有一条主线：从&amp;quot;把一切放在一个进程里&amp;quot;到&amp;quot;让 Agent 自己治理自己&amp;quot;。&lt;/p></description></item><item><title>系统设计（八）：案例分析 —— 网址缩短服务、实时聊天系统、新闻信息流</title><link>https://www.chenk.top/zh/system-design/08-case-studies/</link><pubDate>Sun, 27 Jul 2025 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/system-design/08-case-studies/</guid><description>&lt;p>学习系统设计的最佳方式是动手实践。阅读关于单个组件（如缓存、消息队列、负载均衡器）的资料能帮你建立术语库，但只有亲手设计一个完整系统，才能学会如何将这些组件有机组合，构建出真正可用的系统。&lt;/p></description></item><item><title>系统设计（六）：微服务 vs 单体架构——坦诚的权衡分析</title><link>https://www.chenk.top/zh/system-design/06-microservices-vs-monoliths/</link><pubDate>Tue, 22 Jul 2025 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/system-design/06-microservices-vs-monoliths/</guid><description>&lt;p>2020 年，客户数据平台 Segment 的工程团队发布了一篇题为《告别微服务》（Goodbye Microservices）的博客文章。当时，他们已将原有单体应用拆分为 &lt;strong>140 多个微服务&lt;/strong>，但结果并非预期中的工程乌托邦。相反，团队大部分时间都在对抗分布式系统自身带来的复杂性：服务发现失败、级联超时、不一致的部署流水线，以及爆炸式增长的服务间通信缺陷。最终，他们选择回归单体架构，并报告称开发者生产力与系统可靠性均获得显著提升。&lt;/p></description></item><item><title>数据库（七）：分布式事务——两阶段提交、Saga 模式，以及为何共识如此困难</title><link>https://www.chenk.top/zh/databases/07-distributed-transactions/</link><pubDate>Sun, 28 Apr 2024 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/databases/07-distributed-transactions/</guid><description>&lt;p>第 3 篇文章中关于事务的所有内容，均基于单数据库服务器假设——一台机器、一份事务日志、一个锁管理器。一旦数据分布到多台机器上——例如实施分片（sharding）、采用微服务架构（各服务独享数据库）或启用强一致性复制——便直面分布式系统最棘手的问题：&lt;strong>多台机器如何就某个值达成一致？&lt;/strong>&lt;/p></description></item><item><title>数据库（六）：复制与分片——突破单机限制的扩展之道</title><link>https://www.chenk.top/zh/databases/06-replication-and-partitioning/</link><pubDate>Fri, 26 Apr 2024 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/databases/06-replication-and-partitioning/</guid><description>&lt;p>一台数据库服务器能承载惊人的负载——一个调优良好的 PostgreSQL 实例每秒可处理数万次查询。但终究会遇到瓶颈：可能是读吞吐量超出了单颗 CPU 的能力，需要数据在数据中心火灾中幸存，又或者数据集已经超出单块磁盘的容量。此时，你就需要&lt;strong>复制（Replication）&lt;strong>与&lt;/strong>分片（Partitioning / Sharding）&lt;/strong>。&lt;/p></description></item></channel></rss>