【转】架构设计原则总结

转自https://zhuanlan.zhihu.com/p/150168153--极简码农

架构设计原则

常见架构设计方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。在评估这些质量属性时，需要遵循架构设计原则：1.合适原则，2简单原则，避免贪大求全，基本上某个质量属性能够满足以 一定时期业务发展就可以了。

属性 | 集群方案 | 拆分方案 | 备注 ---|---|---|--- 性能 | 中，继续扩展下去，MySQL会成为瓶颈 | 高，系统拆分为子系统，子系统又可以做成集群方案 | 拆分方案优 | 复杂度 | 低，只需要引入Nginx做负载均衡 | 高，需要对系统和数据库进行拆分 | 集群方案优 成本 | 中，需要增加web服务器 | 中，需要增加web服务器和MySQL服务器，单MySQL服务器物流上可以共用，逻辑上分开即可| 集群方案稍微优一点 可扩展 | 低，所有的功能继续在同一个系统实现，系统会越来越复杂，扩展越来越难 | 高，系统按照追责拆分为多个字系统，每个子系统可单独扩展 | 拆分方案优 可用性| 中，web服务器是集群模式，单MySQL是单点的，MySQL故障回你导致整个业务不可用 | 高，子系统是独立的，某个子系统故障不会导致整个业务不可用 | 拆分方案优

Eg:架构师选择了Elasticsearch作为全文搜索解决方案，前提必须是架构师自己对Elasticsearch的设计原理有深入的理解，比如索引、副本、集群等技术点；而不能道听途说Elasticsearch很牛，所以你选择它，更不能成为把“细节我们不讨论”这句话挂在嘴边的“PPT架构师”。

架构设计流程总结：

• 设计架构的时候，首先要分析出系统的复杂性。
• 架构师根据自己对业务的理解，挑选合适的架构模式进行组合，再对组合后的方案进行修改和调整。
• 新技术都是在现有技术的基础上发展起来的，现有技术又源于先前的技术。
• 备选方案的数量以3～5个备选方案为最佳。
• 备选方案的差异要比较明显。
• 备选方案的技术不要只局限于已经熟悉的技术。
• 通过360度环评的方式来评估备选方案。
• 按照质量属性的优先级来判断备选方案的优劣。
• 架构师需要对技术的细节和原理有较深入的理解，避免成为“PPT架构师”。
• 通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度。
• 采取设计团队的方式来进行设计，可以博采众长，汇集团队经验，减少思维和经验盲区。

存储高性能总结：

• 高性能数据库集群的第一种方式是“读写分离”，其本质是将访问压力分散到集群中的多个节点，但是没有分散存储压力。
• 数据库读写分流需要考虑“复制延迟”带来的复杂性。
• 数据库读写分离的分配机制有两种方式：程序代码封装和中间件封装。
• 高性能数据库集群的第二种方式是“分库分表”，就可以分散访问压力，又可以分散存储压力。
• 业务分库指的是按照业务模块将数据分散到不同的数据库服务器。
• 业务分库会引起join操作问题、事务问题、成本问题三个复杂度相关的问题。
• 数据库分表分为垂直分表和水平分表。
• 垂直分表引入的复杂性主要体现在表操作的数量要增加。
• 水平分表引入了路由、join操作、count()操作、order by操作等复杂度问题。
• K-V存储在数据结构方面相比关系型数据库具备较大优势。
• 文档数据库最大的特点就是no-schema，可以存储和读取任意的数据。
• 列式存储在某些场景下能够大大节省I/O。
• 列式存储具备很高的压缩比，能够节省存储空间。
• 全文搜索引擎的基本源流是倒排索引。
• 为了让全文搜索引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。
• 缓存穿透是指业务系统查询的数据在缓存系统中没有的时候，每次查询都会访问存储系统。
• 缓存雪崩是指当缓存失效（过期）后引起系统性能急剧下降的情况。
• 缓存热点指大部分甚至所有业务请求都命中同一份缓存数据。

计算高性能总结：

• RPC模型：每次有新的连接就新建一个进程去专门处理这个连接请求。
• TPC模型：每次有新的连接就新建一个线程去专门处理这个连接的请求。
• Reactor模型的基础是I/O多路复用。
• Proactor模型是非阻塞异步网络模式。
• 常见的负载均衡系统有3种：DNS负载均衡、硬件负载均衡和软件负载均衡。
• 硬件负载均衡用于实现集群级别的负载均衡。
• 软件负载均衡用于实现机器级别的负载均衡。
• 负载均衡算法分为：任务平分类、负载均衡类、性能最优类和Hash类。

CAP总结：

• CAP理论三个核心要素：一致性、可用性和分区容忍性。
• CAP理论指分布式系统中涉及读写操作时，一致性、可用性、分区容忍性三个要素只能保证两个，另外一个必须被牺牲。
• 分布式系统理论上不可能选择CA架构，只能选择CP或AP架构。
• CAP关注的粒度是数据，而不是整个系统。
• CAP是忽略网络延迟的。
• 正常运行的情况下，不存在CP和AP的选择，可以同时满足CA。
• CAP中放弃某个要素并不等于什么都不做，需要为分区恢复后做准备。
• ACID的应用场景是数据库事务，CAP关注的是分布式系统数据读写。
• BASE是CAP理论中的AP方案的延伸。

FMEA总结：

• FMEA是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确保失效对于系统的最终影响。
• FMEA分析方法很简单，就是一个FMEA分析表。
• FMEA分析中的“功能点”是从用户的角度来看的，而不是从系统各个模块功能点划分来看的。
• FMEA分析中的“故障模式”的描述要尽量精确，多使用量化描述，避免使用泛化的描述。
• FMEA分析中的“严重程序”指站在业务的角度，故障的影响程度一般分为“致命/高/中/低/无“五个档次。
• FMEA分析中不同的”故障原因“发生概率、检测手段和处理措施可能不同。
• FMEA分析中的”风险程度“就是综合严重程度和故障概率来一起判断某个故障的最终等级。
• FMEA分析中不一定所有的问题都要解决，采取规避措施也可以。

存储高可用总结：

• 主备架构中的”备机“主要还是起一个备份作用，并不承担实际的业务读写操作。
• 主从架构中的主机负责读写操作，从机只负责读操作，不负责写操作。
• 主备倒换和主从倒换架构的复杂点主要体现在：状态判断、倒换决策和数据冲突修复三方面。
• 主主复制架构必须保证数据能够双向复制，而很多数据是不能双向复制的。
• 根据集群中机器承担的不同角色来划分，集群可以分为两类：数据集中集群、数据分散集群。
• 数据集中集群可以看作一主多备或一主多从，但复杂度比主备或主从要高出很多。
• 数据分散集群中每台服务器都会负责存储一部分数据和同时也会备份一部分数据。
• 数据分区主要应对地理级别的故障。
• 数据分区的复制规则分为集中式、互备式和独立式。

计算高可用总结：

• 主备架构时计算高可用最简单的架构，可以细分为冷备结构和温备架构，常用温备架构。
• 计算高可用的主备架构也比较适合与内部管理系统、后台管理系统这类使用人数不多、使用频率不高的业务，不太适合在线的业务。
• 主从架构与主备架构相比，发挥了硬件的性能，但设计要复杂一些。
• 高可用计算的集群根据集群中服务器节点角色的不同，可以分为对称集群和非对称集群。
• 对称集群中每台服务器的角色都是一样的，都可以执行所有任务。
• 非对称集群中的服务器分为多个不同的角色，不同角色执行不同的任务。
• 非对称集群相比负载均衡集群，设计复杂度主要体现在任务分配策略和角色分配策略会更加复杂。

业务高可用总结：

• 异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，多活就是指不同地理位置上的系统都能够提供业务服务。
• 异地多活虽然功能很强大，但也不是每个业务不管三七二十一都要上异地多活。
• 如果业务规模很大，能够做异地多活的情况下尽量实现异地多活。
• 异地多活架构可以分为同城异区、跨城异地、跨国异地。
• 异地多活设计技巧：保证核心业务的异地多活、保证核心数据最终以执行、采用多种手段同步数据、只保证绝大部分用户的异地多活。
• 接口级故障的主要应对方案：降级、熔断、限流、排队。
• 降级的核心思想就是丢车保帅，优先保证核心业务。
• 限流指只允许系统能够承受的用户量进来访问，超出系统访问能力的用户将被抛弃。
• 排队实际上是限流的一个变种，限流是直接拒绝用户，排队是让用户等待很长水间。

可扩展模式总结：

• 软件系统与硬件和建筑系统最大的差异在于软件是可扩展的。
• 真正有生命力的软件系统都是在不断迭代和发展的。
• 所有可扩展性架构设计，背后的基本思想都可以总结为一个字：拆。
• 面向流程拆分：分层架构
• 面向服务拆分：SOA、微服务。
• 面向功能拆分：微内核架构。
• 不同的拆分方式将得到不同的系统架构。

分层架构总结：

• 分层架构是很常见的架构模式，也叫N层架构，通常情况下，N至少是2层，一般不超过5层。
• C/S架构、B/S架构划分的对象是整个业务系统，划分的维度是职责，将不同的职责划分到独立层。
• MVC架构、MVP架构划分的对象是单个业务子系统，划分的维度是职责，将不同的职责划分到独立层。
• 逻辑分层架构划分的对象可以是单个业务子系统，也可以是整个业务系统，划分的维度也是职责。
• 无论采用何种分层维度，分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰，边界足够明显。
• 分层架构之所以能够较好地支撑系统扩展，本质在于：隔离关注点。
• 分层架构的一个特点就是层层传递。
• 分层架构一个典型的缺点就是性能。

SOA架构总结：

• SOA提出的背景是企业内部的IT系统重复建设且效率低下。
• SOA更多是在传统企业（例如，制造业、金融业等）落地和推广，在互联网行业并没有多大规模的时间和推广。
• SOA三个关键概念：服务、ESB和松耦合。
• SOA架构中，每项业务功能都是一项服务，服务就意味着对外提供开放的能力。
• SOA使用ESB来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。
• SOA解决了传统IT系统重复建设和扩展效率低的问题，但其本身也引入了更多的复杂性，SOA最广为人诟病的就是ESB。
• SOA的ESB设计也是无奈之举，企业在应用SOA时，各种异构的IT系统都已经踩在很多年了，完全重写或者按照统一标准进行改造的成本是非常大的，只能通过ESB方式其适配已经存在的各种异构系统。

微服务架构总结

• 微服务概念的历史要早得多，也不是Martin Flower创造出来的，Martin只是将微服务进行了系统的阐述。
• 微服务是一种和SOA相似但本质上不同的架构理念。
• 微服务的三个关键词 : small（微小的）、lightweight(轻量的)、automated（自动化）。
• 微服务和SOA不存在孰优孰劣，只是应用场景不同。
• 微服务并不是没有代价，而是会带来系统复杂度、运维复杂度、性能下降等问题。
• 微服务拆分的粒度遵循“三个火枪手”原则。
• 真正决定微服务成败的，恰恰是那个被大部分人都忽略的“automated”，而不是“lightweight”和“small”。
• 微服务并不是很多人认为的那样又简单又轻量级，要做好微服务，基础设施是必不可少的。

微内核架构总结

• 微内核架构也被称为插件化架构(Plug-in-Architecture)，是一种面向功能进行拆分的可扩展性架构。
• 微内核架构通常用于实现基于产品的应用
• 微内核架构包含两类组件:核心系统(core system) 和插件模块(plug-in modules)。
• 微内核的核心系统设计的关键技术有几部分: 插件管理、插件连接和插件通信。
• Eclipse采用OSGi标准后，OSGi更是成为首选的插件化标准。