从0开始学架构-知识点整理

通过68元的课程是不可能成为架构师的！不过通过大师梳理好的思路去学习并对有些问题深度思考还是很有收获的。例如”架构设计流程”，我们遇到技术问题，也可以以这样的思路合理应对。文章后面主要是在从0开始学架构>课程中本人觉得比较重要的知识点，不是很详细。以后会结合工作对部分知识点详细解读。恩，这是一个知识点！(广告)

架构基础

系统：一群关联个体按某种规则组合并相互协作完成个体不能完成的功能，而架构是系统的顶层设计。

框架是面向编程的半成品；

组件是从技术维度的复用；

模块是从业务维度职责的划分；

架构设计的主要目的是为了解决软件系统复杂性带来的问题。

理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行设计

可参考复杂点类似的解决方案

解决业务的关键功能，不需要面面俱到，不需要花太多精力到一些边缘细节，架构设计要紧贴业务，不要过度设计

软件系统常见的复杂度来源

1.高性能: 尽可能提高服务性能

2.高可用: 无间断提供服务

3.可扩展: 为应对需求而有的一种扩展能力。正确预测变化，完美封装变化

4.低成本

5.安全性

6.规模

怎么去解决这些复杂度带来的问题呢？我们先了解工程师解决复杂问题的三种能力: 分治，知识，抽象。

分治：作为解决复杂度及规模问题的有效策略，分治必须满足两个条件：1. 分割后的各个部分足够小，以便一个人可以单枪匹马就能解决它们；2.必须考虑将各个部分装配为整体。那些被封装的部分理解起来越容易，将各个部分组成整体方案时，所跟踪的细节就越少。至少可以暂时忘记其他部分的内部细节。这使得开发者更容易推断各部分之间的协作方式。

知识：软件开发者运用从先前问题中习得的知识来解决当前问题。

抽象：抽象能够精简问题空间，而且问题越小越容易理解，因而能够有效解决软件的复杂度。

开发者把问题分割为规模更小切易于处理的若干子问题，这样他们就可以运用相似问题的知识来解决某些子问题，而且使用抽象有助于他们进行推理和判断。分治，知识，抽象可以帮助我们在不变的智力条件下理解复杂度不断增长的问题。

架构设计三原则

合适原则: 合适优于业界领先

简单原则: 简单优于复杂

演化原则: 演化优于一步到位

架构设计流程

1.识别复杂度

将主要的复杂度问题列出来，然后根据业务，技术，团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题

2.设计备选方案

反模式：

设计最优秀的方案

只做一个方案

备选方案过于详细

一些建议：

备选方案一般3-5个最佳

备选方案的差异要比较明显

备选方案的技术不要局限于已经熟悉的技术

3.评估和选择备选方案

列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估这个方案，再综合挑选适合当时情况的最优方案

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

4.详细方案设计

架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解。

通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度，方案本身的复杂度越高，某个细节推翻整个方案的可能性就越高，适当降低复杂性，可以减少这种风险。

如果方案本身就很复杂，那就采取设计团队的方式来进行设计，博采众长，汇集大家的智慧和经验，防止只有1~2个架构师可能出现的思维盲点或者经验盲区。

下面主要针对常见的复杂度来源高性能，高可用，可扩展进行讨论，提出了解决复杂度的模式。

高性能架构模式

读写分离

将数据库读写操作分散到不同的节点上。引入的复杂度有复制延迟，分配机制

如何解决延迟问题？ 1. 写操作后的读操作指定发给数据库主服务器 2. 读从机失败后再读一次主机 3. 关键业务读写都执行主库，非关键业务采用读写分离

如何解决分配机制？ 1. 程序代码封装 2. 中间件封装(mysql proxy, 360 Atlas)

分库分表

业务分库: 按照业务模块将数据分散到不同的数据库服务？引入的问题有 1. Join操作问题 2. 事务问题 3. 成本问题

分表: 分垂直分表，水平分表两种。路由，count，join等问题

常见的Nosql方案

K-V存储, 文档数据，列式数据库，全文搜索引擎

缓存常见的复杂度

缓存穿透: 访问不存在的key导致请求全量打向DB, 可以缓存空值解决。

缓存雪崩: 高并发访问缓存失效导致大量请求重构缓存，导致压垮DB。

解决方案: 1. 更新锁机制 2.后台更新机制

缓存热点: 可以将热度特别高的数据，缓存多份副本，将请求分散到多个缓存服务器上，减轻缓存热点导致的单台服务器压力

单服务并发模型

PPC (Process Per Connection)

TPC (Thread Per Connection)

Reactor与Proactor

负载均衡分类

DNS负载均衡

硬件负载均衡

软件负载均衡

负载均衡算法

任务平分类

负载均衡类

性能最优类

Hash类

高可用架构模式

CAP

C一致性是当访问多个节点时能得到同样的值。

A可用性意味着每个请求都能获得响应。

P分区容忍性是指集群中的某些节点在无法联系后，集群整体还能继续进行服务。

AP:最终一致性

CP:拒绝服务

CA:单机支持，非分布式

ACID是数据库事务完整性的理论，CAP是分布式设计理论，Base是对CAP中AP方案的延伸。

FMEA方法

在架构设计领域，FMEA的具体分析方法是：

给出初始的架构设计图。

假设架构中某个部件发生故障。

分析此故障对系统功能造成的影响。

根据分析结果，判断架构是否需要进行优化。

存储高可用方案的本质都是通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用，其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。

计算高可用的主要设计目标是当出现部分硬件损坏时，计算任务能够继续正常运行。因此计算高可用的本质是通过冗余来规避部分故障的风险，单台服务器是无论如何都达不到这个目标的。所以计算高可用的设计思想很简单：通过增加更多服务器来达到计算高可用。计算高可用架构的设计复杂度主要体现在任务管理方面，即当任务在某台服务器上执行失败后，如何将任务重新分配到新的服务器进行执行

异地多活架构模式

同城异区

关键在于搭建高速网络将两个机房连接起来，达到近似一个本地机房的效果。架构设计上可以将两个机房当作本地机房来设计，无须额外考虑。

跨城异地

关键在于数据不一致的情况下，业务不受影响或者影响很小，这从逻辑的角度上来说其实是矛盾的，架构设计的主要目的就是为了解决这个矛盾。

跨国异地

主要是面向不同地区用户提供业务，或者提供只读业务，对架构设计要求不高。

异地多活四大技巧:

1. 保证核心业务的异地多活

2. 保证核心数据最终一致性

3. 采用多种手段同步数据

4. 只保证绝大多数用户的异地多活

异地多活四步走:

1. 业务分级

2. 数据分类

3. 数据同步

4. 异常处理

接口级故障的应对方案:

降级

熔断

限流

排队

可扩展架构模式

主要思路:拆

面向流程拆分: 分层架构

面向服务拆分: SOA, 微服务

面向功能拆分: 未内核架构

分层的本质在于隔离关注点。需要保证各层之间的差异足够清晰，边界足够明显。让人看到架构图后就能看懂整个架构

微服务的反模式

1. 服务划分过细，服务间关系复杂

2. 服务数量过多，团建效率急剧下降

3. 调用链太长，性能下降

4. 调用链太长，问题定位困难

5. 没有自动化支撑，无法快速交付

三个火枪手原则，三个人负责一个系统

拆分方法

1. 基于业务逻辑拆分

2. 基于可扩展拆分(区分稳定服务与变动服务)

3. 基于可靠性拆分(避免非核心服务故障影响核心服务)

4. 基于性能拆分

微服务基础设施

架构实战

互联网架构模板

参考与推荐

恰如其分的软件架构

人月神话

unix编程艺术

异类

系统之美

技术的本质

微服务设计

微信公众号:

溜溜技术

简介:

来自各大移动互联网服务端程序员的思想碰撞平台。技术、逻辑、思辩、进步、创新。有没有干货，拉出来溜溜！

投稿联系:

oscersong007