第1章 架构基础
系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。
子系统也是由一群有关联的个体所组成的系统，多半是更大的系统中的一部分。
软件模块（Module）是一套一致而互相紧密关联的软件组织。它分别包含了程序和数据结构两部分。
软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
软件框架（Software Framework），通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软组件规范时，提供规范所要求之基础功能的软件产品。
软件架构指软件系统的顶层结构。
同一款软件系统从不同的角度进行分解，会得到不同的架构。
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
主要的软件系统复杂度有高性能、高可用、可扩展、低成本、安全、规模几种。
第2章 架构设计原则
架构设计原则1：适合原则，适合的架构优于业界领先的架构。
真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。
架构设计原则2：简单原则，简单的架构优于复杂的架构。
软件领域的复杂性体现在两方面：结构的复杂性、逻辑的复杂性。
架构设计原则3：演化原则，架构需要随着业务的发展而不断演化。
对应建筑来说，永恒是主题；而对于软件来说，变化才是主题。
软件架构设计类似于生物演化。
第3章 架构设计流程
架构设计的时候，首先要分析出系统的复杂性。
架构师根据自己对业务的理解，挑选适合的架构模式进行组合，再对组合后的方案进行修改和调整。
新技术都是在现有技术的基础上发展起来的，现有技术又来源于先前的技术。
备选方案的数量以 3~5 个备选方案为最佳。
备选方案的差异要比较明显。
备选方案的技术不要只局限于已经熟悉的技术。
通过 360 度环评的方式来评估备选方案。
按照质量属性的优先级来判断备选方案的优劣。
架构师需要对技术的细节和原理有较深入的理解，避免成为“PPT架构师”。
通过分析步骤、分阶段、分系统等方式，尽量降低方案复杂度。
采取设计团队的方式来进行设计，可以博采众长，汇集团队经验，减少思维和经验盲区。
第4章 存储高性能
高性能数据库集群的第一种方式是“读写分离”，其本质是讲访问压力分散到集群中的多个节点，但是没有分散存储压力。
数据库读写分离需要考虑“复制延迟”带来的复杂性。
数据库读写分离的分配机制有两种实现方式：程序代码封装和中间件封装。
高性能数据库集群的第二种方式是“分库分表”，既可以分散访问压力，又可以分散存储压力。
业务分库指的是按照业务模块讲数据分散到不同的数据库服务器。
业务分库会引入 join 操作问题、事务问题、成本问题三个复杂度相关的问题。
数据库分表分为垂直分表和水平分表。
垂直分表引入的复杂性重要体现在表操作数据要增加。
水平分表引入了路由、join 操作、count() 操作、order by 操作等复杂问题。
K-V 存储在数据结构方面相比关系型数据库具备较大的优势。
文档数据库最大的特点就是 no-schema，可以存储和读取任意的数据。
列式存储在某些场景下能够大大节省 I/O。
列式存储具备很高的压缩比，能够节省存储空间。
全文搜索引擎的基本原理是倒排索引。
为了让全文索引引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。
缓存穿透是指当业务系统查询的数据在存储系统中没有的时候，每次查询都会访问存储系统。
缓存雪崩是指当缓存失效（过期）后引起系统性能急剧下降的情况。
缓存热点是指大部分甚至所有业务请求都命中同一份缓存数据。
第5章 计算高性能
PPC 模型：每次有新的连接就新建一个进程去专门处理这个连接的请求。
TPC 模型：每次有新的连接就新建一个线程去专门处理这个连接的请求。
Reactor 模型的基础是 I/O多路复用。
Proactor 模型是非阻塞异步网络模式。
常见的负载均衡系统有3种：DNS 负载均衡、硬件负载均衡和软件负载均衡。
DNS 是最简单的也是最常见的负载均衡方式，一般用来实现地理级别的均衡。
硬件负载均衡用于实现集群级别的负载均衡。
软件负载均衡用于实现机器级别的负载均衡。
负载均衡的算法分为：任务平分类、负载均衡类、性能最优类和 Hash 类。
第6章 CAP
CAP 理论三个核心要素：一致性、可用性、和分区容忍性。
CAP 理论指分布式系统中涉及读写操作时，一致性、可用性、分区容忍性三个要素只能保证两个，另外一个必须被牺牲。
分布式系统理论上不可能选择 CA 架构，只能选择 CP 或 AP 架构。
CAP 关注的粒度是数据，而不是整个系统。
CAP 是忽略网络延迟的。
正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足 CA。
CAP 中放弃某个要素并不等于什么都不做，需要为分区恢复后做准备。
ACID 的应用场景是数据库事务，CAP 关注的是分布式系统数据读写。
BASE 是 CAP 理论中 AP 方案的延伸。
第7章 FMEA
FMEA 是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响。
FMEA 分析方法很简单，就是一个 FMEA 分析表。
FMEA 分析中的“功能点”是从用户的角度来看的，而不是从系统各个模块功能点划分来看的。
FMEA 分析中的“故障模式”的描述要尽量精确，多使用量化描述，避免使用泛化的描述。
FMEA 分析中“严重程序”指站在业务的角度，故障的影响程度一般分为“致命/高/中/低/无”五个档次。
FMEA 分析中不同的“故障原因”发生概率、检测手段和处理措施可能不同。
FMEA 分析中的“风险程度”就是综合严重程度和故障概率来一起判断某个故障的最终等级。
FMEA 分析中不一定所有的问题都要解决，采取规避措施也可以。
第8章 存储高可用
主备架构中的“备机”主要还是起一个备份作用，并不承担实际的业务读写操作。
主从架构中的主机负责读写操作，从机只负责读操作，不负责写操作。
主备倒换和主从倒换架构的复杂点主要体现在：状态判断、倒换决策和数据冲突修复三个方面。
主主复制架构必须保证数据能够双向复制，而很多数据是不能双向复制的。
根据集群中机器承担的不同角色来划分，集群可以分为两类：数据集中集群、数据分散集群。
数据集中集群可以看作一主多备或一主多从，但复杂度比主备或主从要高出很多。
数据分散集群中每台服务器都会负责存储一部分数据，同时也会备份一部分数据。
数据分区主要应对地理级别的故障。
数据分区的复制规则分为集中式、互备式和独立式。
第9章 计算高可用
主备架构是计算高可用最简单的架构，可以细分为冷备架构和温备架构，常用温备架构。
计算高可用的主备架构也比较适合与内部管理系统、后台管理系统这类使用人数不多、使用频率不高的业务，不太适合在线的业务。
主从架构与主备架构相比，发挥了硬件的性能，但设计要复杂一些。
高可用计算的集群根据集群中服务器节点角色的不同，可以分为对称集群和非对称集群。
对称集群中每个服务器的角色都一样的，都可以执行所有任务。
非对称集群中的服务器分为多个不同的角色，不同角色执行不同的任务。
非对称集群比负载均衡集群，设计复杂度主要体现在任务分配策略和角色分配策略会更加复杂。
第10章 业务高可用
异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，多活就是指不同地理位置上的系统都能提供业务服务。
异地多活虽然功能强大，但也不是每个业务不管三七二十一都要上异地多活。
如果业务规模很大，能够做异地多活的情况尽量实现异地多活。
异地多活架构可以分为同城异地、跨城异地、跨国异地。
同城异区指的是将业务部署在同一个城市不同区的多个机房。
同城异区的两个机房能够实现和同一个机房内几乎一样的网络传输速度，这就意味着虽然是两个不同地理位置上机房，但逻辑上我们可以将它们看作是同一个机房。
跨城异地指的是业务部署在不同城市的多个机房，而且距离最好远一些。
跨城异地距离较远带来的网络传输延迟问题，给业务多活架构设计带来了复杂性。
跨国异地指的是将业务部署在不同国家的多个机房。
跨国异地主要适应两种场景：为不同地区的用户提供服务，为全球用户提供只读服务。
异地多活设计技巧一：保证核心业务的异地多活。
异地多活设计技巧二：保证核心数据最终一致性。
异地多活设计技巧三：采用多种手段同步数据。
异地多活设计技巧四：只保证绝大部分用户的异地多活。
接口级故障的主要应对方案：降级、熔断、限流、排队。
降级的核心思想就是丢车保帅，优先保证核心业务。
限流指只允许系统能够承受的用户量进来访问，超出系统访问能力的用户将被抛弃。
排队实际上是限流的一种变种，限流是直接拒绝用户，排队是让用户等待很长时间。
第11章 可扩展模式
软件系统与硬件系统和建筑系统最大的差异在于软件是可扩展的。
真正有生命力的软件系统都是在不断迭代和发展的。
所有可扩展性架构设计，背后的基本思想都可以总结为一个字：拆。
拆分软件系统的方式有三种：面向流程拆分、面向服务拆分和面向功能拆分。
不同的拆分方式将得到不同的系统架构。
第12章 分层架构
分层架构是很常见的架构模式，也叫N层架构，通常情况下，N至少是2层，一般不超过5层。
C/S架构、B/S架构划分的对象是整个业务系统，划分的维度是用户交互。
MVC架构，MVP架构划分的对象是单个业务子系统，划分的维度是职责，将不同的职责划分到独立层。
逻辑分层架构划分的对象可以是单个业务子系统，也可以是整个业务系统，划分的维度也是职责。
无论采用何种分层维度，分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰，边界足够明显。
分层架构之所以能够较好地支撑系统扩展，本质在于：隔离关键点。
分层架构的一个特点就是层层传递。
分成架构一个典型的缺点就是性能。
第13章 SOA 架构
SOA 提出的背景是企业内部的IT系统重复建设且效率低下。
SOA 更多的是在传统企业（例如，制造业、金融业等）落地和推广，在互联网行业并没有大规模的实践和推广。
SOA 三个关键概念：服务、ESB和松耦合。
SOA 架构中，每项业务功能都是一项服务，服务就意味着要对外提供开发的能力。
SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。
SOA 解决了传统 IT 系统重复建设和扩展效率低的问题，但其本身也引入了更多的复杂性，SOA 最广为人诟病的就是 ESB。
SOA 的 ESB 设计也是无奈之举，企业在应用 SOA 时，各种异构的IT系统都已经存在很多年了，完全重写或按照统一标准进行改造的成本是非常大的，只能通过 ESB 方式去适应已经存在的各种异构系统。
第14章 微服务
微服务概念的历史要早得多，也不是 Martin Flower 创造出来的，Martin 只是将微服务进行了系统的阐述。
微服务是一种和SOA相似但本质上不同的架构理念。
微服务的三个关键词：small、lightweight、automated。
微服务和SOA不存在孰优孰劣，只是应用场景不同。
微服务并不是没有代价，而且会带来系统复杂度、运维复杂度、性能下降等问题。
微服务拆分的粒度遵循“三个火枪手”原则。
真正决定微服务成败的，恰恰是那个被大部分人都忽略的“automated”，而不是“small”和“lightweight”。
微服务并不是很多人认为的那样又简单又轻量级，要做好微服务，基础设施是必不可少的。
第15章 微内核架构
微内核架构也被称为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构。
第16章 消息队列设计实战
识别复杂度对架构师来说是一项挑战，因为原始的需求中并没有哪个地方会明确地说复杂度在哪里，需要架构师在理解需求的基础上进行分析。
有经验的架构师可能一看需求就知道复杂度大概在哪里，如果经验不足，则只能采取“排查法”，从不同的角度逐一进行分析。
架构师关注的不是一天的数据，而是一秒的数据，即 TPS 和 QPS。
备选方案的选择和很多因素相关，并不单单考虑性能高低、技术是否优越这些纯技术因素，业务的需求特点、运维团队的经验、已有的技术体系、团队人员的技术水平都会影响备选方案的选择。
架构设计的目的不是证明自己（参考架构设计原则1：适合原则），而是更快更好地满足业务需求。
第17章 互联网架构演进
产品类业务：技术创新推动业务发展。
“服务”类业务：业务发展推动技术的发展。
架构师需要基于业务发展阶段判断出系统当前面临的主要复杂度。
互联网业务千差万别，但都具有“规模决定一切”的特点。
互联网业务发展一般分为几个时期：初创期、快速发展期、竞争期、成熟期。
互联网业务发展第一个主要方向就是“业务越来越复杂”。
互联网业务发展的第二个主要方向就是“用户量越来越大”。
互联网业务发展带来复杂度的本质原因其实都是“量变带来质变”。
第18章 物联网架构模板
NoSQL 不是 No SQL，而是 Not Only SQL，即 NoSQL 是 SQL 的补充。
NoSQL 发展到一定规模后，一般都是走集群路线。
在开源方案的基础上封装一个小文件存储平台并不是太难的事情。
大数据存储和处理反而是最简单的，因为你别无选择，只能用这几个流行的开源方案。
框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技术！
互联网行业基本上都是“拿来主义”，挑选一个流行的开源服务即可。
配置中心主要为了解决系统数量增多后配置管理复杂和效率低下的问题。
服务中心目的是解决跨系统依赖的“配置”和“调度”问题。
消息队列目的是为了实现跨系统异步通知。
DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。
Nginx & LVS & F5 用于同一地点内机器级别的负载均衡。
CDN 是为了解决用户网络访问时的“最后一公里”效应，本质上是一种“以空间换时间”的加速策略。
多机房设计最核心的设计因素就是如何处理时延带来的影响。
多中心必须以多机房为前提，但从设计的角度来看，多中心相比多机房是本质上的飞越，难度也高出一个等级。
用户管理系统两个核心职责：单点登录和第三方授权登录。
消息推送主要包含 3 个功能：设备管理（唯一标识、注册和注销）、连接管理和消息管理。
除非 BAT 级别，一般不建议自己再重复造轮子了，直接买图片云和存储云服务可能是最快又最经济的方式。
业务层降低复杂性最好的方式就是“拆”，化整为零、分而治之，将整体复杂性分散到多个子业务或子系统里面去。
运维平台核心的职责分为四大块：配置、部署、监控和应急。
测试平台的核心目的是提升测试效率，从而提升产品质量，其设计关键就是自动化。
数据平台的核心职责主要包括三个部分：数据管理、数据分析和数据应用。
管理平台的核心职责就是权限管理。
第19章 架构重构
期望通过架构重构来解决所有问题当然是不现实的。
架构师的首要任务是从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有问题。
真正推动一个架构重构项目启动，需要花费大量的精力进行游说和沟通。
架构重构沟通协调时，将技术语音转换为通俗语言，以事实说话，以数据说话，是沟通的关键。
架构重构涉及关联方配合时，有效的沟通策略是“换位思考、合作双赢、关注长期”。
架构重构需要采取“分段实施”策略，将要解决的问题根据优先级、重要性、实施难度等划分为不同阶段，每个阶段聚焦于一个整体的目标。
真正的架构师，必须具备一定的项目经理技能，但更重要的还是技术能力。
第20章 开源系统
选开源方案时，聚焦于是否满足业务，而不需要过于关注开源方案是否优秀。
选择开源项目时，尽量选择成熟的开源项目。
选择开源项目时，除了关注技术指标，还要关注运维能力。
开源项目不能简单“拿来主义”，而要深入研究和仔细测试。
使用开源项目时对线上环境和风险要有敬畏之心，小心应用，灰度发布。
无论什么开源方案，都需要考虑应急的备选方案。
如果需要修改开源系统，不要改动原系统，而是要开发辅助系统。
选与不选开源项目，核心还是成本和收益问题，并不是说选择开源项目就一定是最优的方案。
网友评论