《非暴力沟通》& 《凤凰架构》精读笔记

目标:读完这份笔记 = 掌握两本书的 80% 精华,并且知道怎么用。 说明:以下所有内容都是我基于两本书核心思想的提炼和延展,并非原书文字复制。

---

📖 第一部:《非暴力沟通》Marshall B. Rosenberg

全书总览

一个核心模型(NVC 四要素)贯穿全书:

观察 → 感受 → 需要 → 请求

Observation → Feeling → Need → Request

所有 13 章都是围绕这个公式在不同场景下的展开。掌握了这四个词,你就掌握了这本书的 70%。剩下的 30% 是各种场景下怎么用。

一句话理解 NVC:不去评判对错,而是去表达自己、理解别人——从"谁错了"切换到"谁需要什么"。

---

第 1 章:让爱融入生活

核心观点

• 语言本身就有暴力属性:评判、比较、命令、回避责任。我们从小习得,却不自知。
• NVC 不是技巧,是一种意识转向:把关注点从"对错"转到"需要"上。
• 四要素不是顺序公式,而是一个内在的思考框架。

适用场景

• 你发现自己总和家人/伴侣/同事争吵,但事后想不起来到底吵什么
• 你讲道理没人听,反而关系越来越差
• 你压抑情绪,积累成暴躁

技巧 / 最佳实践

1. 读完本章后做一个练习:回想本周一次冲突,用 NVC 四要素重新叙述一遍。
2. 把这四个词写在便签贴在显示器上,坚持 30 天。

拓展

• 心理学延伸:Carl Rogers 人本主义心理学(罗森伯格的导师)
• 进阶书:《感受爱》(The 5 Love Languages 作者延伸)

---

第 2 章:是什么蒙蔽了爱

核心观点

四类"异化的沟通方式"在偷偷摧毁关系:

1. 道德评判:"你就是自私"——给人贴标签
2. 比较:"你看别人家孩子"——让双方都痛苦
3. 回避责任:"我不得不这么做"——把主动变成被动
4. 强人所难:"你必须……否则……"——用威胁换服从

适用场景

• 教育子女/下属时不自觉说教
• 跟父母沟通时的典型对话模式
• 职场里"为你好"式的建议

技巧 / 最佳实践

1. 自查表:每天睡前花 2 分钟,回顾今天说过的话,有没有这四种?
2. 替换练习:
   • "你太懒了" → "我看到你这周三次没完成任务,我有点担心我们的进度"
   • "你让我很生气" → "我感到愤怒,因为我需要被尊重"

拓展

• 相关概念:基本归因错误(心理学):我们总把别人的行为归因于性格,自己的归因于情境
• 哲学延伸:阿德勒心理学的"课题分离"(《被讨厌的勇气》)

---

第 3 章:区分观察和评论

核心观点

• 观察是摄像机能拍到的事实;评论是你对事实的解读。
• 印度哲学家克里希那穆提说过类似的话:不带评论的观察是人类智力的最高形式。
• 90% 的沟通冲突都起于:一方说的是评论,却以为自己在陈述事实。

适用场景

• 给别人提反馈/批评时
• 夫妻吵架"你总是..."、"你从不..."
• 面试/绩效评估

技巧 / 最佳实践

评论 ❌	观察 ✅
你最近太消极了	你这周的三次会议中都没有主动发言
你工作不认真	这份报告里我看到了 5 个错别字
他人很好	他上周主动帮我搬了三次东西

关键词禁用清单:"总是、从不、经常、懒、聪明、好、坏"——这些都是评论。

拓展

• 《关键对话》中的"事实 vs 故事" 是同一个概念
• 商业应用:OKR 和 KPI 的设计本质也是这个——要可观察、可量化

---

第 4 章:体会和表达感受

核心观点

• 中国人尤其男性没有感受词汇库,只会说"我不爽""我还好"。
• 区分感受(情绪)和想法(判断):
  • "我觉得你不在乎我"——这是想法,披着"感受"的外衣
  • "我感到孤单"——这才是感受
• 表达脆弱比表达愤怒需要更大的勇气,但也更有效。

适用场景

• 跟伴侣谈心
• 心理咨询/自我觉察
• 职场里被冒犯时的有效反馈

技巧 / 最佳实践

1. 建立自己的情绪词汇库:下载一张"情绪轮盘"(Emotion Wheel),贴在墙上。
2. 每天记录三次情绪:现在我感到 ___,强度 1-10。
3. 常用感受词:
   • 需求得到满足:喜悦、感激、放松、兴奋、平静、满足、好奇
   • 需求未被满足:焦虑、失望、孤独、沮丧、困惑、恐惧、愤怒、委屈

拓展

• 工具:Feelings Wheel 情绪轮(谷歌搜索)
• 书籍:《情绪急救》Guy Winch、《非暴力沟通实践篇》
• INFP 读者特别推荐:Marc Brackett《Permission to Feel》

---

第 5 章:感受的根源

核心观点

这是全书最反直觉也最有力的一章:

别人不是你感受的原因,你的需要才是。

同一件事,满足你需要时你开心,没满足时你痛苦——事不变,感受却变,说明感受来自你。

• 听到批评时的四种反应:
  1. 责怪自己(陷入自责)
  2. 指责对方(陷入愤怒)
  3. 体会自己的感受和需要 ← NVC 的路径
  4. 体会对方的感受和需要 ← NVC 的路径

适用场景

• 你总觉得"是别人让我生气"
• 你习惯性讨好,把自己的需要放最后
• 你需要停止情绪内耗

技巧 / 最佳实践

1. "因为我需要..."句式改造:

   • ❌ "你没回消息让我很失望"
   • ✅ "你没回消息,我感到失望,因为我需要被在意"

2. 需要清单(普世需要):

   • 连接类:爱、理解、尊重、归属、亲密
   • 自主类:选择、自由、空间
   • 意义类:贡献、成长、创造、目标
   • 生存类:安全、休息、健康、食物

拓展

• 马斯洛需求层次理论(直接对应)
• 《习惯的力量》:情绪其实是习惯性反应,可以重塑
• INFP 尤其需要读这章:你的"玻璃心"不是缺点,而是你需要被看见、被理解的信号

---

第 6 章:请求帮助

核心观点

• 请求 ≠ 命令。区别在于:对方说"不"时你的反应。
• 请求必须具体、可执行、正面(做什么而不是不做什么)。
• "别吵了" ❌ → "你能把音量调到 5 以下吗?" ✅

适用场景

• 给下属分配任务
• 跟伴侣提要求
• 跟父母沟通期望

技巧 / 最佳实践

一个好请求的三要素:

1. 具体:可执行、不模糊
2. 正面:"请做什么",不是"请不要做什么"
3. 确认:"你能重复一下我刚才说的吗?"(不是质问,是确保理解一致)

反例 vs 正例:

❌ 失败的请求	✅ 有效的请求
你能多关心我一点吗?	这周每天睡前聊 10 分钟好吗?
你别这么消极	下次开会你能主动分享一个想法吗?
你要变勤快点	你能每晚 9 点前把家务做完吗?

拓展

• 程序员用法:提需求给产品经理 / 给老板提涨薪——都是请求的艺术
• 相关书:《高难度谈话》Difficult Conversations

---

第 7 章:用全身心倾听

核心观点

我们几乎从不真正倾听别人——我们只是在等对方说完好轮到自己说。

倾听的 6 个误区:

1. 建议("你应该...")
2. 比较("我比你更惨...")
3. 说教("你要明白...")
4. 安慰("这没什么大不了的")
5. 分析("你这是因为小时候...")
6. 调查("发生什么了?为什么?怎么..."连环问)

适用场景

• 朋友找你倾诉
• 伴侣抱怨工作
• 下属吐槽公司

技巧 / 最佳实践

1. 同理心倾听四步:

   • 他观察到什么?(发生了什么事)
   • 他感受到什么?(情绪是什么)
   • 他需要什么?(未被满足的需要)
   • 他请求什么?(想让我怎么做)

2. 最简万能回应:

   "听起来你……(感受),因为你……(需要)?" 例:"听起来你有点失望,因为你希望被认可,是吗?"

3. INFP 的倾听优势:你天生共情强,不要讲道理、不要解决问题,80% 的倾诉者只是需要被听见。

拓展

• 书:《高效人士的七个习惯》第五习惯"知彼解己"讲的是同一件事
• 心理咨询技术:Carl Rogers 的"无条件积极关注"

---

第 8 章:倾听的力量

核心观点

• 当有人对你发泄愤怒时,他们要的不是道歉,而是被理解。
• "对方需要被听见"是 NVC 最深的洞察之一。听完了,愤怒会自己消散。
• 在自己情绪失控时,"给自己急救"是先听自己。

适用场景

• 客户投诉
• 伴侣吵架
• 下属抱怨/离职面谈
• 自己陷入负面情绪

技巧 / 最佳实践

1. "复述 + 感受猜测"法:

   对方:"这个项目设计得太烂了,根本用不了!" 你:"你对这个设计很失望,是因为你希望它能真正解决问题,对吗?"

2. 沉默也是倾听。允许对方有空间说下去。中国人尤其不习惯沉默,但沉默本身就在传递"我在这里,没走"。

拓展

• 工具:谷歌亚里士多德项目研究发现,高绩效团队的关键特质是"心理安全感"——本质就是倾听能力
• 书:《Radical Candor》(坦诚)

---

第 9 章:爱自己

核心观点

• 对自己的"暴力"比对别人的暴力更常见:"我真蠢"、"我怎么这么废"。
• 自责不等于负责。自责是攻击自己,负责是理解自己的需要。
• 羞愧、内疚是改变的最差动力。

适用场景

• 搞砸事情后的自我攻击
• 拖延 + 自责 + 更拖延的循环
• INFP 典型的"我什么都做不好"时刻

技巧 / 最佳实践

1. "用 NVC 对自己说话":

   • ❌ "我怎么又熬夜了,太没自控力了"
   • ✅ "我注意到我今天凌晨 2 点才睡(观察),我感到疲惫和自责(感受),因为我需要健康和早睡(需要),下次我能 11 点前放下手机吗?(请求)"

2. "哀悼"过去的自己:接受当时的自己是基于当时的需要做出了选择,而不是因为"太蠢"。

3. "我选择……因为我想……"改造:

   • "我不得不加班" → "我选择加班,因为我想维持收入和职业发展"
   • 主动感回来了,怨气就少了。

拓展

• 书:《自我关怀的力量》Kristin Neff(Self-Compassion)——最重要的互补书
• 概念:成长型思维(Carol Dweck)
• 对 INFP 特别重要:不要用"理想自我"碾压"现实自我"

---

第 10 章:充分表达愤怒

核心观点

• 愤怒是一个信号,告诉你:有个重要需要没被满足。
• 表达愤怒不等于发泄愤怒。发泄会破坏关系,表达能建立连接。
• 愤怒的真正原因永远不是那个人,而是你被触发的未满足需要。

适用场景

• 伴侣冷暴力时
• 被领导当众批评
• 路怒症、熊孩子场景

技巧 / 最佳实践

表达愤怒四步:

1. 停下来,深呼吸(不说话,不做反应)
2. 识别你在谴责对方的什么("他居然...")
3. 体会你的真实需要("我其实是希望被尊重")
4. 表达感受和需要,不是指责

例子:

• ❌ "你老是打断我,你什么毛病!"
• ✅ "刚刚连续 3 次被打断,我感到很受挫,因为我需要被听完。你能让我把话说完吗?"

拓展

• 书:《愤怒》(Thich Nhat Hanh)
• 佛学视角:愤怒是"苦"的一种表现,根在执着和未满足

---

第 11 章:运用强制力避免伤害

核心观点

• 强制力(惩罚、约束)有两种:保护性(防止当下伤害)vs 惩罚性(报复)。
• NVC 不反对强制力,反对惩罚心态。
• 例如:孩子要冲上马路,拉住他是保护性;回家打一顿是惩罚性。

适用场景

• 育儿
• 下属犯错
• 法律、司法制度思考

技巧 / 最佳实践

1. 行动前自问:我这个行为是为了防止伤害,还是为了让对方痛?
2. 惩罚的代价:对方会害怕,但也会疏远、怨恨、学会隐瞒。短期有效,长期破坏关系。

拓展

• 育儿书:《正面管教》(Positive Discipline)——整本书就是这一章的展开
• 管理学:心理安全感 vs 恐惧文化

---

第 12 章:重获生活的热情

核心观点

• 很多人的生活是"我应该"构成的,不是"我想要"。
• "应该"背后通常藏着恐惧和匮乏,"想要"背后是需要和愿景。
• NVC 不仅是沟通工具,也是自我重新连接的工具。

适用场景

• 职业倦怠
• 中年迷茫
• "我这辈子是不是就这样了"

技巧 / 最佳实践

1. "应该"清单改造:

   • 写下你本周所有"我应该"的事
   • 每一项问:"如果去掉这个'应该',我真的想做吗?是什么需要在驱动它?"
   • 决定:继续做 / 换方式做 / 不做

2. 程序员自救:

   • "我应该加班" → 我想获得认可 → 有没有更好的路径?
   • "我应该学 xxx 技术" → 我害怕落伍 → 这个恐惧真实吗?

拓展

• 书:**《当下的力量》**埃克哈特·托利
• 存在主义心理学:Viktor Frankl《活出生命的意义》

---

第 13 章:表达感激

核心观点

• 感激 ≠ 表扬。表扬是评判的一种(即使是正面的),会让对方为"维持好形象"而疲惫。
• 真正的感激 = 具体事实 + 对方行为满足了我的什么需要 + 我现在的感受。

适用场景

• 夸下属/孩子/伴侣
• 写感谢信
• 年度总结

技巧 / 最佳实践

三要素感激公式:

1. 具体行为:"你昨晚 10 点给我发的那条消息"
2. 满足了什么需要:"我当时需要支持"
3. 我的感受:"我感到被爱、很温暖"

对比:

• ❌ "你人真好"(空洞的评判)
• ❌ "你是个好员工"(让人焦虑怎么继续是"好")
• ✅ "你上周主动整理了项目文档(具体),让我省下好几个小时去做规划(需要),我觉得很安心、也很感激(感受)。"

拓展

• 积极心理学:感恩日记(Gratitude Journal)——每晚记 3 件今天感激的事,坚持 21 天能显著提升幸福感
• 书:《积极情绪的力量》Barbara Fredrickson

---

《非暴力沟通》实战应用表

场景	最关键的章节
跟父母吵架	3、4、5、7
伴侣关系	4、5、7、10、13
职场沟通	3、6、11、13
情绪管理	9、10、12
自我和解	5、9、12

INFP 读者特别路径:9 → 5 → 4 → 12 → 7 → 其他

---

---

📘 第二部:《凤凰架构:构建可靠的大型分布式系统》周志明

全书总览

这本书的核心命题:

让不可靠的组件组合成一个可靠的系统。 就像凤凰浴火重生——任何单点都可以死,但系统永生。

全书 5 大部分,16 章:

1. 演进中的架构——历史视角:为什么会有微服务?
2. 架构师的视角——横向能力:RPC、事务、分流、安全
3. 分布式的基石——核心理论:共识、服务化、流量、通讯、观测
4. 不可变基础设施——云原生落地:容器、网络、存储、调度、网格
5. 技术方法论——方法论:如何决策是否上微服务

一句话理解:从"怎么写代码"到"怎么让一堆代码在成千上万台不可靠机器上稳定跑 10 年"。

---

第一部分:演进中的架构

第 1 章:服务架构演进史

这一章讲"软件架构为什么会变成今天的样子"。不了解历史,你学的所有技术都是碎片。

---

1.1 原始分布式时代(1970s-1980s)

核心观点:

• 人们很早就想搞分布式,但硬件贵、网络差,失败了。
• 历史教训:分布式不是"更好",只是"不得不"。

适用场景/理解:

• 面试答"为什么要分布式"时,不要说"因为微服务好",要说"因为单机顶不住了"。

拓展:

• 关键论文:《A Note on Distributed Computing》(Waldo 等,1994)——8 条分布式谬论

---

1.2 单体系统时代

核心观点:

• 单体不是贬义词。小系统写单体是正确的。
• 单体的真正痛点:一个小 bug 能拖垮整个进程、团队大了编译部署慢。

最佳实践:

• 团队 < 20 人,业务 < 5 条线,绝对不要上微服务。
• 单体不等于烂代码,模块化做好(Modular Monolith)是个被严重低估的架构。

拓展:

• Martin Fowler: 《MonolithFirst》
• Shopify 案例:年 GMV 千亿美元,至今主系统是 Rails 单体

---

1.3 SOA 时代

核心观点:

• SOA 是微服务的"前辈",思想相同但工具太重(ESB、SOAP、WS-*)。
• 失败原因:厂商主导、规范泛滥、难落地。

场景:

• 搞懂 SOA 你就知道为什么"别迷信规范",工具链比规范重要。

拓展:

• 术语对比:SOA 的"服务" vs 微服务的"服务"——大小、独立性、通讯方式都不同

---

1.4 微服务时代

核心观点:

• 微服务 = SOA 的思想 + HTTP/JSON 的轻量 + DevOps 的工具链。
• Martin Fowler 的微服务 9 特征:服务拆分、自动化部署、智能端点、去中心化治理、数据独立、基础设施自动化、容错、演进式设计、产品思维。

适用场景:

• 团队 > 50 人、多业务线、需要独立部署时才真正需要。

最佳实践:

• 康威定律:组织架构 = 软件架构。没有适配的团队结构,拆微服务必失败。
• 不要按技术分层(前端、后端、DB)拆,要按业务能力(DDD 限界上下文)拆。

拓展:

• 书:《微服务设计》Sam Newman(必读)
• 《领域驱动设计》Eric Evans(DDD)

---

1.5 后微服务时代

核心观点:

• 微服务催生了无数基础设施问题:服务发现、配置、熔断、监控……早期用 Spring Cloud 类代码库解决。
• 后微服务时代:把这些问题下沉到基础设施(K8s、Istio)——代码不需要再关心。

最佳实践:

• 新项目直接上 Kubernetes + Service Mesh,别再写 Spring Cloud 那一套。
• 业务代码 + 声明式配置就够了,容错、路由交给基础设施。

拓展:

• 关键词:Sidecar Pattern、Service Mesh、Cloud Native

---

1.6 无服务时代(Serverless)

核心观点:

• FaaS(函数即服务)+ BaaS(后端即服务)= 连服务器都不用想了。
• Serverless 不是"没服务器",是"不用管服务器"。

适用场景:

• 流量波峰波谷剧烈(电商大促)
• 事件驱动型业务(上传图片→触发处理)
• 初创快速验证

不适用:

• 长时间运行(超过 15 分钟)
• 延迟敏感(冷启动问题)
• 强状态依赖

拓展:

• AWS Lambda、阿里云函数计算、Cloudflare Workers
• 关键术语:冷启动、异步链路、事件总线

---

第二部分:架构师的视角

第 2 章:访问远程服务

2.1 远程服务调用(RPC)

核心观点:

• RPC 的终极目标:让远程调用像本地调用一样自然——但这是不可能完全达到的。
• 性能、异构、安全、错误处理——本地调用没这些问题,远程调用都有。

主流 RPC 框架对比:

框架	协议	特点
gRPC	HTTP/2 + Protobuf	强类型、跨语言、性能好
Thrift	自定义	Facebook 开源,老牌
Dubbo	Dubbo/Triple	阿里系,中文文档好
Spring Cloud OpenFeign	HTTP/JSON	Java 生态

最佳实践:

• 跨语言/高性能场景选 gRPC
• Java 独占场景可选 Dubbo
• 内外部混合场景用 REST

拓展:

• 八大分布式谬论(Deutsch)——RPC 设计的底层陷阱
• 书:《Google SRE》

---

2.2 REST 设计风格

核心观点:

• REST 不是协议,是架构风格。大多数号称 RESTful 的 API 其实只是 HTTP + JSON。
• Roy Fielding 的 REST 成熟度模型(Richardson Maturity Model):
  • L0:HTTP 只当通道(RPC over HTTP)
  • L1:引入资源
  • L2:使用 HTTP 方法(GET/POST/PUT/DELETE)
  • L3:HATEOAS(超媒体驱动,真正的 REST)

最佳实践:

• 做到 L2 就够用于大多数业务。
• 资源命名用名词(/users/123 ✅),不用动词(/getUser ❌)。
• 状态码要规范(200/201/204/400/401/403/404/409/500)。

拓展:

• 书:《RESTful Web APIs》
• GraphQL 是 REST 的替代方案,适合前端聚合场景

---

第 3 章:事务处理

这是本书最硬核也最有价值的章节之一。

3.1 本地事务

核心观点:

• ACID(原子、一致、隔离、持久)的实现原理:WAL(预写日志) + MVCC(多版本并发控制)。
• 隔离级别四层:读未提交 → 读已提交 → 可重复读 → 串行化。
• 并发问题三种:脏读、不可重复读、幻读。

最佳实践:

• MySQL 默认可重复读,很多场景其实用读已提交更好(减少锁等待)。
• 长事务是数据库杀手,控制在 1 秒以内。

拓展:

• 书:《数据库系统概念》(DB 圣经)
• MySQL 专项:《MySQL 实战 45 讲》丁奇

---

3.2 全局事务(XA)

核心观点:

• XA 是两阶段提交(2PC)的标准化实现。
• 所有参与者都 OK 才提交,任何一个失败全回滚。
• 缺点:协调者单点、阻塞、性能差、不适合微服务。

场景:同一数据库的不同 Schema、单数据中心内的金融强一致。

拓展:

• 术语:2PC、3PC、Paxos Commit
• 现实中 XA 用得越来越少

---

3.3 共享事务

核心观点:

• 多个服务共用一个数据库事务——听起来很美好,实际是个反模式。
• 本质是数据库耦合。

不推荐使用。作者特意写这一章是告诉你别这么干。

---

3.4 分布式事务(重点!)

核心观点:

• CAP 定理:一致性(C)、可用性(A)、分区容忍性(P),三者最多得两。
• 真实世界(网络会分区),P 必选,所以要在 C 和 A 之间取舍。
• 强一致牺牲可用性;最终一致性牺牲强一致保可用。

四种主流分布式事务方案:

方案	特点	适用场景
2PC/XA	强一致、阻塞、性能差	传统金融、同库多表
TCC(Try-Confirm-Cancel)	手写补偿、性能好、侵入业务	核心交易、资金
SAGA	长事务拆短、最终一致	订单流程、跨业务链
可靠消息(本地消息表/事务消息)	异步解耦、吞吐高	通知类、状态同步

最佳实践:

• 优先用可靠消息——80% 场景够用
• 核心资金用 TCC 或 SAGA
• 尽量让业务设计避免分布式事务(比如合并服务)

拓展:

• 经典论文:《Life beyond Distributed Transactions》(Pat Helland)
• 开源框架:Seata(阿里)、DTM
• 相关:BASE 理论(Basically Available, Soft state, Eventually consistent)

---

第 4 章:透明多级分流系统

这一章讲:请求从用户点击到数据库,中间要经过多少层?每层怎么优化?

4.1 客户端缓存

核心观点:

• HTTP 缓存机制:强制缓存(Expires、Cache-Control)+ 协商缓存(Last-Modified、ETag)。

最佳实践:

• 静态资源(JS/CSS/图片):Cache-Control: max-age=31536000, immutable + 文件名带 hash
• HTML:no-cache 让浏览器每次验证
• API:根据业务决定

拓展:

• 工具:Chrome DevTools → Network → 看缓存行为

---

4.2 域名解析(DNS)

核心观点:

• DNS 不只是"解析域名",还是最早的负载均衡。
• HTTPDNS 解决运营商劫持和跨网延迟问题(移动端必备)。

场景:CDN 调度、多活架构

拓展:阿里云 HTTPDNS、腾讯 HTTPDNS

---

4.3 传输链路

核心观点:

• HTTP/1.1 的问题:队头阻塞、TCP 慢启动、头部冗余。
• HTTP/2 的改进:二进制分帧、多路复用、头部压缩(HPACK)。
• HTTP/3(QUIC):基于 UDP,解决 TCP 层队头阻塞。

最佳实践:

• 现在新项目都应该上 HTTP/2,静态资源 HTTP/3。
• TLS 1.3 是性能 + 安全的甜点。

拓展:《HTTP 权威指南》、Cloudflare 博客

---

4.4 内容分发网络(CDN)

核心观点:

• CDN 的本质:把内容缓存在离用户最近的节点。
• 核心技术:DNS 调度 + 缓存策略 + 回源机制。

最佳实践:

• 图片、视频、JS/CSS 全走 CDN
• API 也可以走 CDN(边缘缓存 GET 接口)
• 动态内容用 Edge Computing(Cloudflare Workers、AWS Lambda@Edge)

拓展:阿里云 CDN、Cloudflare、Akamai

---

4.5 负载均衡

核心观点:

• 四层(L4):TCP/UDP 层,基于 IP+端口,LVS/F5——快
• 七层(L7):HTTP 层,基于 URL/Header,Nginx/HAProxy——灵活
• 算法:轮询、加权轮询、最少连接、一致性哈希

最佳实践:

• 入口:LVS(L4) + Nginx(L7) 组合拳
• K8s 环境:Ingress Controller(Nginx/Traefik)

拓展:一致性哈希原理、P2C 算法(Power of Two Choices)

---

4.6 服务端缓存(重点!)

核心观点:

• 缓存三大问题:穿透、击穿、雪崩。
• 缓存不是万能药,缓存一致性是分布式系统最难的问题之一。

最佳实践:

问题	解决方案
穿透(查不存在的 key)	布隆过滤器 / 空值缓存
击穿(热点 key 过期)	互斥锁 / 永不过期 + 异步刷新
雪崩(大量 key 同时过期)	过期时间加随机 / 多级缓存

• 先更新 DB 再删缓存(Cache-Aside 模式)
• 延迟双删应对并发
• 高并发场景引入本地缓存(Caffeine) + Redis 两级

拓展:《Redis 设计与实现》黄健宏、《凤凰架构》这一章特别值得反复读

---

第 5 章:架构安全性

5.1 认证(Authentication)

核心观点:

• 认证 = 你是谁。方式:密码、短信、生物、Token、证书。
• 三要素:知道的(密码)、拥有的(手机)、本身是(指纹)。MFA = 至少两种。

最佳实践:

• 密码:bcrypt / argon2 存储,绝不明文/MD5
• Token:JWT(注意签名、过期)
• 2FA:TOTP(Google Authenticator)

---

5.2 授权(Authorization)

核心观点:

• 授权 = 你能干什么。
• 主流模型:ACL(访问控制列表)、RBAC(基于角色)、ABAC(基于属性)。
• OAuth 2.0 是授权协议不是认证协议,OIDC 是基于 OAuth 的认证。

最佳实践:

• 业务系统内部:RBAC 够用
• 第三方登录/开放平台:OAuth 2.0 / OIDC
• 细粒度复杂权限:ABAC / PBAC

拓展:OAuth 2.0 四种授权模式(授权码、隐式、密码、客户端凭证)

---

5.3 凭证(Credentials)

核心观点:

• Session vs JWT:
  • Session:服务端存,易注销,分布式场景需要共享存储
  • JWT:无状态,难注销,适合跨域/多服务

最佳实践:

• 大多数 Web 应用:Session + Redis 依然是最稳妥方案
• 微服务/SPA:JWT + 短过期 + Refresh Token
• 绝对不要把敏感信息放 JWT payload

---

5.4 保密

核心观点:

• 分对称加密(AES)和非对称加密(RSA/ECC)。
• 永远不要自己实现加密算法。
• 哈希 ≠ 加密(哈希单向,加密双向)。

最佳实践:

• 密码用 bcrypt/argon2(不是 SHA256)
• 敏感数据传输 TLS,存储 AES-256
• 密钥管理用 KMS / Vault

---

5.5 传输

核心观点:

• TLS 握手流程:交换密钥 → 验证证书 → 协商对称密钥。
• HTTPS = HTTP over TLS。

最佳实践:

• 全站 HTTPS(Let's Encrypt 免费)
• TLS 1.2+ 起步,TLS 1.3 优先
• HSTS 头强制 HTTPS

---

5.6 验证

核心观点:防止被篡改、防止重放攻击。

最佳实践:

• API 签名:HMAC-SHA256 + 时间戳 + Nonce
• 防重放:Nonce 入库 + 时间窗口

---

第三部分:分布式的基石

第 6 章:分布式共识算法

核心观点:

分布式系统的终极难题:多个节点怎么就一件事达成一致? 答案就是共识算法。

6.1 Paxos

• 分布式共识的理论起点。Lamport 提出,出了名的难懂。
• 核心思想:两阶段——准备(Prepare)、接受(Accept)。
• 现实中几乎没人直接用 Paxos,都用它的变种。

6.2 Multi-Paxos / Raft

• Raft 是 Paxos 的工程化版本,为了"让人能懂"而生。
• 三个角色:Leader、Follower、Candidate。
• 两个关键机制:Leader 选举 + 日志复制。

最佳实践:

• 理解 Raft 的动画演示:https://raft.github.io
• 使用场景:etcd、TiKV、Consul 都用 Raft

6.3 Gossip 协议

• 最终一致性的代表。节点之间"传八卦"——每轮随机选几个节点同步。
• 优点:去中心化、高可用、容错好。
• 缺点:收敛慢、消息冗余。

应用:Cassandra、Consul、Redis Cluster 节点发现。

拓展:

• 论文:《In Search of an Understandable Consensus Algorithm》(Raft)
• 工具:etcd、Nacos、Zookeeper

---

第 7 章:从类库到服务

7.1 服务发现

核心观点:

• 微服务地址动态变化,需要"通讯录"服务。
• 两种模式:客户端发现(Eureka)vs 服务端发现(K8s Service)。

最佳实践:

• K8s 环境:原生 Service + DNS
• 非 K8s:Nacos / Consul

---

7.2 网关路由

核心观点:

• 网关 = 系统入口 = 第一道防线。
• 职责:路由、限流、鉴权、熔断、协议转换。

主流网关:Nginx、Kong、Spring Cloud Gateway、APISIX、Envoy

最佳实践:

• 云原生首选 APISIX 或 Envoy
• 不要在网关做业务逻辑

---

7.3 客户端负载均衡

核心观点:客户端自己决定调哪个实例。和服务端 LB 的区别是去中心化。

应用:Ribbon、gRPC 客户端 LB、Istio Sidecar

---

第 8 章:流量治理

8.1 服务容错(必学!)

核心观点:分布式系统,故障不是意外,是日常。

五大模式:

模式	作用
重试(Retry)	临时故障恢复
熔断(Circuit Breaker)	故障扩散阻断
降级(Fallback)	部分功能不可用时返回兜底
隔离(Bulkhead)	线程池/资源隔离
超时(Timeout)	避免资源耗尽

最佳实践:

• 超时一定要设(最容易忘)
• 重试用指数退避 + 抖动
• 熔断看 Sentinel、Resilience4j
• 别无脑重试,幂等接口才能重试

拓展:《Release It!》(Michael Nygard)——容错设计圣经

---

8.2 流量控制

核心观点:限流算法:

• 计数器:简单但临界问题
• 滑动窗口:精准
• 漏桶:匀速输出
• 令牌桶:允许突发

最佳实践:

• 单机:Guava RateLimiter、Resilience4j
• 分布式:Sentinel、Redis + Lua 脚本
• 网关层:APISIX、Nginx limit_req

---

第 9 章:可靠通讯

9.1 零信任网络

核心观点:

传统:内网 = 可信。 零信任:永远不相信,永远验证(Never Trust, Always Verify)。

最佳实践:

• Google BeyondCorp 模型
• 所有内部通讯 mTLS
• 基于身份而非 IP 的访问控制

---

9.2 服务安全

核心观点:

• 服务间通讯三要素:加密、认证、授权。
• 服务网格(Istio)可以自动提供这些。

---

第 10 章:可观测性

核心观点:

三大支柱:日志(Logging)、追踪(Tracing)、度量(Metrics)。 缺一不可。

10.1 事件日志

• 结构化日志(JSON)而不是字符串
• 分级:DEBUG/INFO/WARN/ERROR
• 采集:Filebeat → Kafka → Logstash → Elasticsearch → Kibana(ELK)

10.2 链路追踪

• OpenTelemetry 是新一代标准(合并了 OpenTracing + OpenCensus)
• 实现:Jaeger、Zipkin、SkyWalking
• 核心概念:Trace、Span、TraceID 贯穿整个调用链

10.3 聚合度量

• Prometheus + Grafana 是事实标准
• 四个黄金信号(Google SRE):延迟、流量、错误、饱和度
• Prometheus 的 Pull 模型 + 时序数据库

最佳实践:

• 每个服务必备:健康检查 + 关键业务指标 + 性能指标
• 告警原则:症状告警(用户体验到了)而不是原因告警(CPU 100%)
• 打好 TraceID,排查速度 10 倍提升

拓展:

• 书:《SRE: Google 运维解密》(必读)
• OpenTelemetry 官网

---

第四部分:不可变基础设施

核心理念:服务器不再"修",而是"换"。

第 11 章:虚拟化容器

11.1 容器的崛起

• 虚拟机 vs 容器:VM 虚拟化硬件,容器虚拟化操作系统。
• Docker 做的事:镜像(不可变)+ 容器(运行时) + 仓库(分发)。
• 技术底层:Linux namespace(隔离)+ cgroups(限制)+ UnionFS(镜像分层)。

11.2 以容器构建系统

• 单容器 → 多容器 → 编排需求 → Kubernetes。

11.3 以应用为中心的封装

• Helm(K8s 包管理)、Kustomize(配置管理)、Operator(应用自动化)。

最佳实践:

• Dockerfile 多阶段构建,镜像越小越好
• 不要用 latest 标签,固定版本
• 容器内跑单进程

拓展:《深入剖析 Kubernetes》张磊、《Docker 实战》

---

第 12 章:容器间网络

12.1 Linux 网络虚拟化

• veth、bridge、iptables、netfilter 是容器网络基石。
• 理解这些才能真正理解为什么 K8s 网络这样设计。

12.2 容器网络与生态(CNI)

• CNI 是 K8s 网络插件标准。
• 主流方案:Flannel(简单)、Calico(性能 + 网络策略)、Cilium(eBPF,最新潮)。

拓展:eBPF 技术,容器网络的未来方向

---

第 13 章:持久化存储

13.1 Kubernetes 存储设计

• Volume、PV、PVC、StorageClass 四层抽象。
• 有状态应用用 StatefulSet。

13.2 容器存储与生态(CSI)

• CSI 是存储插件标准。
• 主流方案:Ceph、Longhorn、OpenEBS、云厂商块存储。

最佳实践:

• 数据库尽量不要跑 K8s(或者跑 Operator)
• 无状态服务 vs 有状态服务要严格区分

---

第 14 章:资源与调度

核心观点:

• K8s 调度器(Scheduler)的决策:过滤(Predicates) → 打分(Priorities)。
• 资源请求(request)vs 资源限制(limit):request 影响调度,limit 影响运行。
• 超售(Overcommit)是常态。

最佳实践:

• 一定要设 request/limit,否则一个坏 Pod 拖垮节点
• CPU 建议不设 limit(被限流影响大),内存必须设
• 使用 HPA(水平扩容)、VPA(垂直扩容)

---

第 15 章:服务网格

15.1 透明通信的涅槃

核心观点:

• Sidecar 模式:在业务容器旁边塞一个代理(Envoy),业务不知情。
• 服务治理能力(熔断、限流、追踪、认证)从代码下沉到代理。

15.2 服务网格与生态

• Istio 是主流,但学习曲线陡
• Linkerd 轻量,Rust 写的
• Consul Connect

最佳实践:

• 服务少于 20 个不建议上 Istio,收益不覆盖复杂度
• 大规模微服务场景 Istio 是神器

拓展:《Istio 实战指南》 、eBPF-based 网格(Cilium Service Mesh)

---

第五部分:技术方法论

第 16 章:向微服务迈进

这一章是全书最有价值的"总结陈词"。如果你是技术决策者,先读这一章。

16.1 目的:微服务的驱动力

核心观点:

• 不要为了微服务而微服务。
• 真正的驱动力:团队规模过大、业务需要独立演进、扩展性瓶颈。
• 错误驱动力:KPI、技术炫耀、"别人都上了"。

16.2 前提:微服务需要的条件

• DevOps 能力(CI/CD、自动化运维)
• 监控告警体系
• 容器化 + 编排
• 服务治理能力(发现、熔断、限流)
• 组织架构适配(康威定律)

没有以上前提,上微服务就是上战场不带枪。

16.3 边界:微服务的粒度

• 太大 → 跟单体没区别
• 太小 → 分布式事务爆炸、调用链爆炸

粒度原则:

• 团队原则:一个团队负责 1-3 个服务
• 两周原则:重写这个服务不超过 2 周
• DDD 限界上下文:一个上下文一个服务

16.4 治理:理解系统复杂性

核心观点:

• 微服务把代码复杂度换成了架构复杂度。
• 总复杂度不会减少,只会转移。
• 治理好 = 把复杂度放在正确的地方。

最佳实践:

• 新项目:Modular Monolith 起步,按需拆分
• 现有单体:绞杀者模式(Strangler Pattern)逐步迁移
• 治理要有专职的"平台团队"(SRE / Infra)

拓展:

• 书:《从零开始学架构》李运华
• 概念:绞杀者模式、反腐层(ACL)、防腐层 vs 适配器

---

《凤凰架构》学习路径建议

第一轮(1 周) — 建立全局观:

• 读 1.1-1.6(架构史) + 16.1-16.4(方法论)
• 目标:理解"为什么"

第二轮(2-3 周) — 横向能力:

• 读第 2-5 章(架构师视角)
• 目标:掌握通用问题域

第三轮(3-4 周) — 分布式深度:

• 读第 6-10 章(分布式基石)
• 目标:可以自信地谈容错、观测、共识

第四轮(持续学习) — 云原生实战:

• 读第 11-15 章 + 配套动手实验
• 配合 K8s + Istio 实操

---

两本书的共通智慧

最后留一个思考:

《非暴力沟通》的 4 要素模型:观察 → 感受 → 需要 → 请求 《凤凰架构》的核心方法论:现象 → 分析 → 驱动力 → 决策

两本书教的其实是同一件事:

先搞清楚"发生了什么"和"真正需要什么",再决定"怎么做"。

不管是和人说话,还是设计系统,最大的错误都是——没搞清楚问题就开始写代码/发脾气。

---

📚 延伸书单

沟通方向:

• 《高难度谈话》Difficult Conversations
• 《关键对话》Crucial Conversations
• 《被讨厌的勇气》(NVC 的哲学补充)
• 《自我关怀的力量》(NVC 第 9 章的延伸)

架构方向:

• 《深入理解 Java 虚拟机》(同作者,Java 深度)
• 《设计数据密集型应用》Designing Data-Intensive Applications(DDIA)——分布式必读
• 《微服务设计》Sam Newman
• 《Google SRE》
• 《Release It!》
• 《架构整洁之道》Clean Architecture

---

祝学习愉快。这两本书读透,沟通和架构这两张牌都有了底气。