<?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 Cloudside</title><link>https://cloudside.icyyan.com/tags/%E8%AF%BB%E5%90%8E%E6%84%9F/</link><description>Recent content in 读后感 on Cloudside</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 03 Jul 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://cloudside.icyyan.com/tags/%E8%AF%BB%E5%90%8E%E6%84%9F/index.xml" rel="self" type="application/rss+xml"/><item><title>架构演进的六个时代：从原始分布式到无服务</title><link>https://cloudside.icyyan.com/posts/architecture-evolution-six-eras/</link><pubDate>Fri, 03 Jul 2026 10:00:00 +0800</pubDate><guid>https://cloudside.icyyan.com/posts/architecture-evolution-six-eras/</guid><description>&lt;p&gt;作为后端程序员，架构知识通常是一点一点在工作中捡的：数据一致性踩坑了，知道了事务的重要性；服务改用 K8s 部署，真切体会到了声明式 API 给运维带来的便利性；性能遇到瓶颈了，加上缓存系统。每块都懂一点，但这些知识之间是什么关系，为什么要这么设计，一直没有形成体系化的思考，直到读到周志明老师的《凤凰架构》。这本书完整地梳理了服务端的知识地图，将 why 和 what 的问题讲得非常清楚，给了非常清晰的宏观视角。&lt;/p&gt;
&lt;p&gt;本文是第一章的总结和读后感：每一代架构风格的诞生，都是因为上一代遇到了它解决不了的具体问题。这些问题的性质各不相同，但贯穿始终的暗线是复杂度 —— 复杂度不会消失，只会转移。&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;原文出处：微信公众号「张煜中」《架构演进的六个时代：从原始分布式到无服务》，作者张煜中。本文基于该文整理，作为个人读书笔记。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;h2 id="原文内容"&gt;原文内容&lt;/h2&gt;
&lt;h3 id="原始的分布式"&gt;原始的分布式&lt;/h3&gt;
&lt;p&gt;通常我们会认为，服务架构是从单体开始的，为了逃离单体大泥球架构的地狱，才搞分布式。但历史上恰恰相反。对分布式架构的探索，从 20 世纪 70 年代就开始了。那时单机算力极其有限，16 位处理器、不到 5MHz 的主频，单机直接卡住了软件能做到的规模上限。人们不得不寻找多台计算机协作支持一套软件系统的方案。&lt;/p&gt;
&lt;p&gt;UNIX 设计风格强调：保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。&lt;/p&gt;
&lt;p&gt;理想很美 —— 远程调用应该尽可能透明，开发者无需关心自己调的是本地方法还是远程服务。但一旦触碰到&amp;quot;远程&amp;quot;二字，网络的不确定性便会带来相当的复杂度。远程的服务在哪里（服务发现），有多少个（负载均衡），网络出现分区、超时或者服务出错了怎么办（熔断、隔离、降级），方法的参数与返回结果如何表示（序列化协议），信息如何传输（传输协议），服务权限如何管理（认证、授权），如何保证通信安全（网络安全层），如何令调用不同机器的服务返回相同的结果（分布式数据一致性）—— 每一个都需要设计者耗费大量精力。&lt;/p&gt;
&lt;p&gt;这些探索催生了 RPC、DFS 等概念，人们也得到了一个价值千金的教训：某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果。&lt;/p&gt;
&lt;p&gt;原始分布式时代的故事，是一次发现复杂度的过程。探索者试图用&amp;quot;透明调用&amp;quot;把分布式的复杂度屏蔽掉，让开发者像写本地程序一样写分布式程序。但现实证明，网络带来的不确定性是无法假装不存在的 —— 服务发现、一致性、网络分区，这些问题不会因为你不看它就消失。这次失败的意义不在于产出了什么可用的系统，而在于让整个行业认清了分布式复杂度的真实面貌。&lt;/p&gt;
&lt;p&gt;于是当硬件性能随摩尔定律起飞后，人们做了一个务实的选择：既然分布式的复杂度屏蔽不了，那就别分布式了。&lt;/p&gt;
&lt;h3 id="单体系统时代"&gt;单体系统时代&lt;/h3&gt;
&lt;p&gt;软件退回到单体 —— 所有代码跑在同一个进程里，不用想网络，不用想一致性。&lt;/p&gt;
&lt;p&gt;大型的单体系统，经常是微服务书籍批判的对象。但一定要注意这里的定语 —— &amp;ldquo;大型的&amp;rdquo;。小型单体系统，不仅易于开发、测试、部署，且由于系统中各个功能、模块、方法的调用过程都是进程内调用，没有进程间通信，运行效率也很高。三个人的团队、一台机器撑得住的系统，搞微服务纯粹是给自己找麻烦。&lt;/p&gt;
&lt;p&gt;单体系统的缺陷在于，缺乏自治和隔离能力。进程内调用虽然简单高效，但故障也难以隔离，某个模块的 bug 能导致整个系统崩溃。而在大型系统中，出错几乎是必然的 —— 大型系统意味着多人协作、频繁变更，缺乏隔离就意味着一个模块的内存泄漏能拖垮整个进程，一次局部的代码升级需要整体停机重启。&lt;/p&gt;
&lt;p&gt;单体系统的设计哲学是「让每一部分都尽量不出错」，靠高质量来保证高可靠。但系统越大，出错越是必然。从「追求不出错」到正视「出错是必然」的观念转变，才是微服务架构得以挑战单体的底气所在。&lt;/p&gt;
&lt;p&gt;单体时代面对的不是分布式复杂度 —— 它根本没有分布式。它面对的是规模带来的复杂度，而这种复杂度体现在多个维度上：可维护性（一次局部改动需要整体停机重启）、团队协作（多人改同一个代码库，互相踩脚）、可靠性（单点故障拖垮全局）。系统小的时候，这些问题都不存在；但规模一旦上去，它们会同时爆发，而且在单体架构下无解 —— 因为缺乏隔离和自治能力。&lt;/p&gt;
&lt;p&gt;为了获得这种能力，人们再次走向分布式。&lt;/p&gt;
&lt;h3 id="soa-时代"&gt;SOA 时代&lt;/h3&gt;
&lt;p&gt;但在微服务之前，业界走过一段弯路 —— SOA。&lt;/p&gt;
&lt;p&gt;SOA 的野心极大，它不仅要解决技术问题，还想建立一套自上而下的软件研发方法论：如何挖掘需求、如何分解业务、如何编排服务，一揽子全包。它有 IBM、Oracle 等巨头撑腰，有 SOAP 协议族做底座，有企业服务总线（ESB）做通信管道，从技术可行性上看确实解决了分布式的主要问题。&lt;/p&gt;
&lt;p&gt;但问题恰恰出在「太完美」上。过于精密的规范带来过度的复杂性，SOAP 之上层层叠加的 ESB、BPM、SCA、SDO，让整个技术栈变成了只有少数专业人员才能驾驭的奢侈品。&lt;/p&gt;
&lt;p&gt;SOA 与 EJB 的失败如出一辙，一旦脱离人民群众，终究会淹没在群众的海洋之中。&lt;/p&gt;</description></item></channel></rss>