<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>架构 on LeoChu Space</title>
    <link>https://leochu.work/blog/tags/%E6%9E%B6%E6%9E%84/</link>
    <description>Recent content in 架构 on LeoChu Space</description>
    <generator>Hugo</generator>
    <language>zh-cn</language>
    <lastBuildDate>Sun, 03 Aug 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://leochu.work/blog/tags/%E6%9E%B6%E6%9E%84/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>凤凰架构</title>
      <link>https://leochu.work/blog/reading/%E5%87%A4%E5%87%B0%E6%9E%B6%E6%9E%84/</link>
      <pubDate>Sun, 03 Aug 2025 00:00:00 +0000</pubDate>
      <guid>https://leochu.work/blog/reading/%E5%87%A4%E5%87%B0%E6%9E%B6%E6%9E%84/</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;周志明《凤凰架构》。核心观点：架构不是炫技，不是堆名词，而是在约束条件下持续支持业务演进的系统设计。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id=&#34;核心观点&#34;&gt;核心观点&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;架构首先服务于演进。&lt;/strong&gt; 一个系统最重要的能力，不是初版多优雅，而是变化来临时能否低成本调整。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;分布式不是目标，只是代价高昂的手段。&lt;/strong&gt; 很多问题在单体阶段并不存在，一旦走向分布式，复杂性、调用链、事务一致性、运维成本都会急剧上升。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;架构决策必须对应具体问题。&lt;/strong&gt; 如果没有明确的性能瓶颈、组织边界或交付约束，很多“先进架构”都只是过度设计。&lt;/p&gt;
&lt;h2 id=&#34;印象较深的部分&#34;&gt;印象较深的部分&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;技术选型背后总有交换。&lt;/strong&gt; 性能、可维护性、可扩展性、团队认知成本，永远不可能同时最优。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;架构能力的一部分是克制。&lt;/strong&gt; 什么时候不拆、什么时候不分布式、什么时候保留简单方案，往往比“会多少框架”更重要。&lt;/p&gt;
&lt;h2 id=&#34;读后感&#34;&gt;读后感&lt;/h2&gt;
&lt;p&gt;这本书好在它不太谈抽象的“架构之美”，而是不断把问题拉回现实：业务规模、团队能力、系统约束、演进成本。&lt;/p&gt;
&lt;p&gt;这本书最后落下来的判断很明确：好的架构师不只是会设计复杂系统，更重要的是知道复杂性应该从哪里开始，又该在哪停下来。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
