偶然间在朋友书架上看到这本书，从浅读到深度，受益匪浅，做笔记进行整理。

《架构师的自我修炼 -技术、架构和未来》

根据当时做的笔记，简单整理进行梳理：

1.这部分个人理解主要偏向技术，属于技术梳理和总结的一些介绍。

1.前几章从操作系统，数据结构，到java的jvm垃圾回收机制，属于程序员的基础。

2.第四章将网络的基础进行描述，提到dubbo分布式服务框架，dns，http，链路层负载均衡（LVS：虚拟IP+链路层实现负载均衡方案）。

3.文件系统原理，inode结构4kb，raid硬盘阵列（Raid0~Raid5）,HDFS(hadoop分布式文件系统，一分钟写TB级的文件)。

4.描述了数据库的原理 sql语句—》连接器—》语法分析器（生成AST树）—》语义分析与优化器—》执行引擎（innoDb,Myisam,memory等多种）。

提到了使用预编译的方式，防止sql注入，同时使用占位符的方式生成执行计划，供引擎直接执行，提升效率。

提到数据库底层存储和索引的原理。 使用B+树，不同的索引存储方案（聚簇索引，非聚簇索引） ===》这里可以思考索引和主键的区别，思考存储和识别过程。

5.提到编程语言的发展：汇编语言—》高级语言—》面向对象的思想----》元编程的思想----》微服务、云原生、大数据等。

这里是否可以再扩展了解（结构化编程、泛型模板编程、函数式编程等）

2.初入门，软件设计思路

1.软件建模的意义在于解决现实中的领域问题：

2.如何写一个架构设计文档（规范了自己潜意识的一些设计思路）。

使用4+1视图指导我们考虑对业务和软件建模的角度，使用UML图配合其他图对系统进行描述。

同时这里描述了一个软件架构设计的示例文档，大概总结思路为：

​ 1.设计概述。（目标）

​ 2.功能概述。（内容）

​ 3.非功能约束(描述该系统目标，描述性能，功能可用性、安全性、持久性等指标要求（边界）。

​ 4.部署与整体设计（系统部署图（部署图模块解释），系统序列图（根据业务进行区分）；子系统组件图（拆分系统）、组件序列图（根据场景进行划分）；组件类图（按组件划分）、类对象序列图（根据场景划分）、类对象状态图；直到描述完各个模块。）

​ 5.其他概述性，收尾性内容

3.用设计原则规避糟糕的代码（封装、继承、多态的应用）

尽量用抽象等方案设计代码架构，而不是用过多的if…else…。

开闭原则：（模块、类、函数等）对扩展开放，对修改关闭。

====》实际上还是利用抽象的概念，对抽象接口进行扩展。

====》待探索使用策略模式、适配器模式、观察者模式、模板模式实现开闭原则。

依赖倒置原则：高层模块不依赖底层模块，二者都依赖抽象；抽象不应依赖具体实现，具体实现依赖抽象。

====》可以探究市场上已有的一些tomcat、MVC框架、Web应用对该原则的使用。

====》使用抽象，避免使用多变的具体实现类；依赖抽象类，尽量不要依赖具体实现类（维护难）；不要重写具体实现的函数。

里氏替换原则：对继承的思考，正方形能继承长方形吗？

====》子类型必须能够替换掉基类型（代码中所有使用基类的地方可以被子类替换）。

====》子类不能比父类更严格（会导致父类不能替换子类的接口，也是违法该原则）。

====》用继承还是用组合（只是用接口推荐用组合，而不是滥用继承）。

单一职责原则：代码不要过多，职责要单一。（过多的职责，让依赖时有不必要的暴漏）

====》一个类应该只有一个引起他变化的原因。

====》从web演变、MVC、以及sql引擎的优化看待这个问题。

接口隔离原则：不应该强迫用户依赖他们不需要的接口。

====》使用委托（适配器）、或者继承的方法，实现该原则。

====》待探究该原则在迭代器设计中的使用。

4.思考设计模式（封装、继承、多态（精髓是多态的应用））

​ 精通设计模式，就是忘了设计模式，首先了解装饰模式，这里聊到一个术语：除了单例和工厂模式，更喜欢适配器和观察者模式，另外，组合模式在树形结构很有用，模板模式和策略模式也是最常用的，处理xxx问题。。。

这里在看到这时，使用ai帮助看看这几个设计模式：

对比项	组合模式	装饰器模式	访问者模式
目的	统一处理单个和整体	动态添加职责	分离操作和结构
是否改变接口	否（统一接口）	否（包装）	是（双分派）
是否支持递归	是	否	是
典型场景	菜单、组织架构	日志、权限增强	报表统计、AST 遍历

5.框架：设计模式的应用（指导开发出框架）

最多的是基于设计原则、设计模式，指导设计、开发出各种开发框架（如tomcat、spring、Mybatis、Junit等，框架规定了软件的整主主体架构，支撑软件的整体或者局部的架构形式），而log4j这类，只能称为工具。

web容器主要使用策略模式，tomcat是其中一种。

Junit是单元测试框架，主要用到模板方法模式（这里其实多种模式配合一起用，待探究）

反应式编程框架（flower框架、微服务、akka中的actor）,异步编程方案，基于多线程（协程）、异步方法调用、异步io访问等技术。

6.组件/模块设计原则（高内聚，低耦合）

一个模块只干一件事（高内聚），一个模块只被最少的人知道（低耦合）。

组件内聚原则：复用发布等同原则（最小粒度发布、版本管理），共同封闭原则（将有修改的尽量放在一个组件中），共同复用原则（不要因为不必要的依赖引起组件的变化，尽可能把相关的功能放到一起。）

组件耦合原则：无循环依赖原则（循环依赖会导致不稳定），稳定依赖原则（不稳定的组件依赖稳定的组件），稳定抽象原则（用抽象的方式，把具体的、不稳定的组件变得抽象、稳定（依赖倒置原则、如JDBC组件的设计））

7.领域驱动设计（DDD）

事务脚本模式（Controller ---->Service(封装了接口)------->Dao（数据库操作）），这里Service封装了所有。

领域模型对象是合并了数据和行为的领域的对象模型（通过领域模型对象实现业务的交互，这里是以业务为对象进行构造吧？）

一个系统实际上是很大的模块，实际上需要按照业务领域，把整体拆分成多个子业务领域，通过多个子域的交互，进行领域模型对象的设计：

领域实体被放在领域层，可以通过适配器等其他方式对领域对象进行调用。（可以了解六边形架构等领域模型设计架构方式）

8.架构师的架构修炼方式

8.1 缓存架构

考虑垂直伸缩和水平伸缩的方案。

单机部署===》数据和应用分离部署===》使用缓存的架构 =》负载均衡集群架构=》数据库读写分离架构===》使用CDN、反向代理、消息队列、NoSql、分布式（缓存）数据库、微服务的架构。

使用缓存方案减少服务器并发请求压力：通读缓存（缓存模块控制读数据库，返回给程序，CDN、反向代理都属于通读缓存），旁路缓存（应用程序读数据库，存到缓存中，对象缓存属于旁路缓存 本地缓存/分布式缓存）。

memcached分布式对象缓存架构，通过路由算法，解决一致性哈希问题（扩容、缩容处理方案，虚拟节点的意义）。

注意处理脏读问题（过期失效（定时失效，如商品信息容忍失效短时不一致）、失效通知等方案）。

8.2 异步架构（增加个消息队列）

基于消息队列的点对点，发布订阅，事件驱动（基于发布订阅的高级用法）方案。

异步架构改善响应，便于集群扩缩，消峰填谷、隔离失败、解耦。

8.3 负载均衡架构

http重定向负载均衡、DNS负载均衡、反向代理负载均衡（nginx提供这种功能）、ip负载均衡、数据链路层负载均衡（linux的LVS是基于ip负载均衡和数据链路层负载均衡实现）

考虑负载均衡的相关算法：轮询、随机、最小连接。

8.4 存储架构（数据读写瓶颈）

数据库主从复制（一主多从,实现读写分离，从binlog复制到relaylog中），主主复制（对主从复制只有一个主的保障，binlog和relaylog互相复制）.

数据库分片 （解决存储不够的问题，了解mycat分布式数据库，考虑分片方案的扩缩方案）

nosql数据库主要解决大规模分布式数据的存储问题。（分布式存储系统的cap原理：一致性（数据一致，不应过期）、可用性（保证可用，不失去响应）、分区耐受性（网络原因引起的分区失效问题） 了解最终一致性解决方案，写时三写二，读时三读二。

8.5 搜索引擎架构（感觉更偏向算法）

倒排索引+缓存+PageRank计算权重的算法

8.6 微服务架构

单体架构的困难和挑战：编译部署困难、代码分支管理困难、数据库连接耗尽、新增业务困难、发布困难。

微服务架构：SOA架构（服务注册中心+服务提供者+服务调用者） ===》dubbo架构

微服务与业务强相关，使用时要注意需求及模块化设计。

8.7 高性能架构（性能指标、测试方式、优化方案）

响应时间：发出请求到收到最后响应的时间。

并发数：系统同时处理请求数（多线程模拟请求，能处理的数量）。

吞吐量：单位时间内系统处理的请求数，系统处理能力（每秒http请求数hps,每秒事务数TPS,每秒查询数QPS）。

性能技术器：系统负载、对象和线程数、内存使用、cpu使用、磁盘、网络io等指标。

性能测试、负载测试、压力测试 ===》对性能不同阶段的测试，初始性能要求，最大负载，最大压力（导致崩溃）。

性能优化方案：数据中心优化、硬件优化（网卡等硬件）、操作系统优化、虚拟机优化（如JVM）、基础组件优化（连接池、MVC框架、中间件等）、架构优化（缓存、消息队列、集群）、代码优化（线程池、连接池、设计模式等方式优化代码）。

8.8 高可用架构（各种异常情况下都可用）

热升级，高可用度量标准（可用性标准：（1-年度不可用时间/年度总时间）**100%，两个9、三个9、四个9；故障分：故障时间*故障权重），

实现高可用：多个服务器实现的冗(rong)余备份、失败隔离（消息队列）、限流降级（限流：限制用户接入。降级：关闭非核心功能）、异地多活（停电等不可控因素）。

高可用运维方案：自动化测试；自动化监控；预发布；灰度发布。

=====》考虑如何热升级。

8.9 安全性架构（加密+防攻击）

数据加密和解密（单向散列加密（MD5）、对称加密、非对称加密）

防攻击：sql注入攻击（sql预编译）、XSS攻击（检查语句中是否存在脚本）

====》本质还是程序员代码问题。

8.10 大数据架构（更多计算机解决大规模数据计算要求）

HDFS分布式文件存储架构（hadoop的部分）

MapReduce大数据计算架构 （hadoop的部分）

Hive(sql语句转换成MapReduce计算的攻击)

Spark对MapReduce进行改进。

基于这些技术的大数据引擎架构（flink、Spark Streaming）

数据采集===》数据处理===》数据输出 ，构建大数据平台架构

8.11 AI和物联网架构

机器学习算法对大数据之间的关系进行描述，实现平台整合，算法推荐：如用的最多的基于人口统计的推荐、基于商品属性的推荐、基于用户的协同过滤推荐、基于商品的协同过滤推荐等根据场景构造算法。

配合物联网配合采集和大数据部署。

区块链技术：实际上就是使用一系列手段保证顺序性以及防伪（前面工作量的唯一+hash控制+签名等其他手段，通过大量计算保证唯一（矿工））。

9：架构师的思维修炼

9.1 技术阶段

德雷夫斯模型：新手 =》高级新手=》胜任者===》精通者===》专家。 （让我对技术阶段有了明确认知）

为了跨越高级新手的阶段，需要培养自己的能力：勇于承担责任（大牛都是实践反思出来的）、帮助他人、构建影响力，真正的技术能力（持续挑战），关注场景问题（关注问题和收益，而不是技术）

9.2 技术进阶

软件从业人员的等级体系：啥也不是（80%）=》团队影响力（20%中的80%：架构师、技术经理、技术骨干）=》公司影响力（技术方向抉择）=》全国影响力（传播技能）=》全球影响力===》关键开创者（json解析器、单元测试框架、分布式框架开创者）=》领域开创者（java web技术栈领域的开发）=》行业开创者（hadoop，linux等行业开创者）。

要提升自己的影响力：需要不断提升自己的技能，勇于承担责任，多去帮助他人，多发博客、演讲等。

9.3 正确面对问题

技术的目的是为了解决问题，考虑真正的问题是什么：

​ x-y问题，构建会议解决问题的前提是，理解问题到底是什么，而不是基于问题之上的偏差；

​ 不要去解决别人的问题，提醒他的问题存在即可（自己角色无法有效解决，其他角色能轻易解决）；

​ 去解决那些被人们习以为常而忽略了的问题（鱼儿看不到水一样，适应了问题，进入新环境发现问题，是自己的机会（刚好和自己的现状有点类似，入职的新公司让自己显得暴戾，反思中））。

​ ===》这里有个公式：问题=期望-体验。

9.5 解决问题：沟通很重要

用人的最高境界是用上司：让有能力解决问题的人意识到问题所在（提出解决方案，让上司参与解决，而不是直接让他处理；对于下属，应该让他自由发挥再把关，不应该陷入在你的决策中。）。

直言有讳：可以直言，但是要避讳，对事不对人。（这里谈论到的是一个和别人有不同观点时沟通的技巧，不能对人，可以考虑先接纳再反对，可以适当逃避、可以提升讨论门槛（换个时间专门会议）等手段）

亡羊补牢式暴露问题：在自己无法做决策时，让上层更快的意识到问题，你的缝缝补补可能让问题更隐蔽。

共鸣的一段话：管理者对待问题的视角和态度决定了下属会成为什么样的人，管理者的眼光和判断会决定团队做事的风格和方向，也决定了什么样的人会加入团队、什么样的人会选择离开，最终，整个团队的人都变成这种类型的人（不填试卷得不了分，我们其实都是在解帮上司解决问题，但是如果你觉得是严重问题的问题，领导不觉得是问题，这就不是你的问题）。

9.6 技术管理（个人和公司角色、团队）

彼得定律：人一直晋升到自己不能胜任得岗位，需要自己全部精力投入才为止（最高阶段还是源于自身专业能力和综合素养、持续学习和专业训练的环境）。

我在反思当下自己和公司的角色时，最终得到最佳结论是，完成着工作内容，同时能明显感觉到技能得提升实现自我价值。 这里谈到一段话：对公司而言，真正有价值得是你为公司解决了多少问题，而不是完成了多少工作，工作本身是没有意义的，解决问题才有意义；对你自己而言，真正有价值得不是你获得多快的晋升、多高的加薪，而是你获得多少持续高强度训练的机会。 ===》公司和个人的发展本质是一致的。

目标驱动：不让团队纠结于问题之中，而是着眼于未来和解决方案本身。

====》关注于目标的解决方案，不是当下问题。

====》可以对比问题驱动型管理和流程驱动型管理。

====》看到这时，我想起来有提到：团队对软件项目管理正确方式是以完整一致性目标为导向，这是很重要的。

ORK管理方式：目标驱动管理的一种，以目标和周期关键结果进行关联管理。

9.7 第一性原理（技术广度是技术深度的副产品）

看到第一性原理时，我第一想法就是”技术广度是技术深度的副产品“。

这里描述的是所有的软件产品，架构，都是基于最底层的操作系统、网络、内存等底层基本技术实现的，我们应该关注这些核心技术，关注本质技术原理，然后基于这些推动思维再理解上层新技术。

需要建立职业规划，不能限于舒适区，用明确的目标给予自己充足的驱动力。

提到几个项目描述架构之美：GPS的获时系统，四川都江堰水利工程（引流、防洪、排沙），苹果架构（体现了约束，但失去自由和创造），google\微软架构（体现自由，创造力）

10：附录（指导什么是好的架构师，好的领导，反思。。。）

一个杰出的架构师，团队几乎感觉不到他的存在；次一点的架构师，大家都爱戴他；再次一点，大家都怕他；而最糟的，大家都鄙视他。

架构师任事务按自身的规律发展，他让自己的行为符合事物的本质，同时他又跳出束缚，让他的设计照亮自己。

架构师用心旁观这个世界，而他坚信他内心的映像，他的心像天空一样开阔，任世间万物来来往往。

优秀架构师不会夸夸其谈，他只是做；当任务完成时，整个团队都会说：天啊，我们居然做到了，全都是我们自己做的。

架构师的权利是这样的，他让事物自由发展。毫不费力，也不强求。他从不失望，他的精神也就永不衰老。

懂的人不说，说的人不懂，没有头绪的人还在讨论过程，明白的人已经开始做了。

优秀架构师乐于用一个例子说明想法，而不是强加他的意愿；他会指出问题而不是戳穿他们，他是坦率地，也是柔顺的，他的眼睛闪着锋芒，却依然温和。

如果你想成为一个杰出的领导，就不要试图去控制什么。带着一个弹性的计划和概念推进，团队会管好他们自己；你越是强加禁令，团队越是没有纪律；你越是强制，大家越是没有安全感；你越是从外面寻求帮助，团队越是不能独立自主。