从零开始学架构--读书笔记

一、架构基础

1.1、概念与基础

架构是为了应对软件系统复杂度而提出的一种解决方案。

架构设计的真正目的：解决复杂度带来的问题。

复杂度的来源：

• 高性能：分为单机内部高性能带来的复杂度和集群高性能带来的复杂度。
  单机需要考虑的技术点：多进程/多线程、进程通信、多线程并发等。
  集群需要考虑的技术点：负载均衡、任务分配、任务分解等等。
• 高可用：本质都是通过"冗余"来实现。
• 可扩展：应对将来需求变化而提供的扩展能力，需要满足两个基本条件–正确预测变化和完美封装变化。
  预测变化的复杂性在于：不能每个设计点都考虑扩展性、也不能完全不考虑扩展性、所有的预测都存在出错的可能性。
  应对变化的复杂性在于：如何分层、熟练使用设计模式等。
• 低成本：往往只有"创新"才能达成低成本的目标。

1.2、架构设计原则

共性的原则：合适原则、简单原则、演化原则

• 合适原则：合适优于业界领先。
• 简单原则：简单优于复杂
• 演化原则：演化优于一步到位

1.3、架构设计流程

1. 有的放矢—识别复杂度，优先解决当前面临的最主要的复杂度问题。
2. 按图索骥—设计备选方案，
3. 深思熟虑—评估和选择备选方案
4. 精雕细琢—设计详细方案

二、高性能架构

2.1、存储高性能

2.1.1、关系数据库

1. 读写分离：主从复制，要应对数据同步的延迟问题。
   解决方案：读从机失败再读一次主机、关键业务读写全部交给主机，非关键业务读写交给从机。
2. 分库分表：
   分库，带来跨库join问题、事务问题等。
   分表又分为垂直分表和水平分表。垂直分表使得表操作的次数增多。水平分表带来路由问题、跨表join、跨表count()、order by操作等。

2.1.2、NoSQL

NoSQL分为K-V存储、文档数据库、列式数据库、全文搜索引擎。

2.1.3、缓存

提高读性能，带来缓存穿透、缓存击穿、缓存雪崩等问题。

2.2 、计算高性能

2.2.1 单机计算高性能：5种网络模型

2.2.2 集群计算高性能

负载均衡：

1. DNS负载均衡：优点，简单成本低，就近访问，速度快。缺点，更新不及时，扩展性差，分配策略比较简单。
2. 硬件负载均衡：优点，功能强大，性能高。缺点，价格昂贵，扩展性差。
3. 软件负载均衡：优点，简单，便宜，灵活。缺点，性能一般。

常见负载均衡算法：轮询，加权轮询，负载最低优先，一致性hash，普通hash，crush算法等等。

三、高可用架构

3.1、CAP理论

CAP理论的粒度是数据，而不是整个系统。所以需要将系统内的数据按照不同的应用场景和要求进行分类，每类数据采用不同的策略(CP或者AP)，而不是直接限定整个系统所有数据采用同一策略。

同时CAP是忽略网络延迟的，所以有些场景下即便选择CP，也无法保证完美的一致性。

正常运行情况下，不存在AP和CP的选择，可以同时满足AC。正常运行情况下，系统不存在分区，这就要求架构设计的时候既要考虑分区发生时选择AP还是CP，也要考虑无分区时如何保证CA。

而且放弃也不代表着什么都不做，当我们放弃A、C中的一个时，不代表我们完全放弃。系统整个运行周期中，大部分时间都是正常的，发生分区的时间并不多。分区期间放弃C或者A，但是我们可以在分区期间做一些操作(例如记录日志)，当分区故障恢复后，根据这些操作重新让系统达到AC状态。

CAP中的C表示强一致性。而BASE理论则核心思想是即使无法做到强一致性，但可以采用合适的方式达到最终一致性。BA表示基本可用，S表示软状态，E表示最终一致性。BASE是AP方案的延伸。

3.2、FMEA

FMEA是一种可用性分析方法，具体分析方法如下：

1. 给出初始的架构设计图
2. 假设架构某个部件发生故障
3. 分析此故障对系统功能造成的影响
4. 根据分析结果，判断架构是否需要进行优化

3.3、存储高可用

存储高可用需要考虑的问题：

• 数据如何复制
• 各个节点的职责是什么
• 如何应对复制延迟
• 如何应对复制中断

具体方案：

• 主备：主机存储数据，通过复制通道将数据发给备机，备机不提供读写。
  优点：对于客户端不需要感知备机的存在，主备之间只需进行数据复制即可，无需进行状态判断和主备倒换等。
  缺点：备机仅仅是备份，故障后需要人工干预，且延迟较大时，没来得及复制到备机的数据会丢失。

• 主从：主机提供读写，并复制数据到从机，从机提供读。
  优点：主机故障，读服务不受影响，提高了性能
  缺点：可能从从机上读到过期的数据

• 主主：都是主机，互相将数据复制给对方，都提供读写服务。
  优点：都是主机，都能提供读写服务
  缺点：数据必须可以双向复制，很多类型的数据双向复制会导致逻辑错误。

• 集群：

3.4、计算高可用

3.5、业务高可用

四、可扩展架构

4.1、可扩展模式

可扩展背后的基本思想总结为一个字：拆。

常见的拆分思路：

1. 面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。(分层架构，MVC等等)
2. 面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。(SOA、微服务)
3. 面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。(微内核架构)

4.2、SOA架构与微服务

微服务与SOA的区别：SOA和微服务仅是在服务上有一些交集，但是二者有本质区别，是两种架构思想。
微服务的服务粒度更小，通讯更加轻量,服务交付快。

微服务的坑：
1、服务划分太细，服务间关系复杂
2、服务数量太多
3、调用链太长，性能下降，问题定位困难
4、如果没有自动化支撑，则无法快速交付
5、没有服务治理，则服务数量多了以后管理混乱

4.3、微内核

微内核架构又称为插件化架构，是面向功能进行拆分的可扩展性架构。
包含两类组件：核心系统、插件模块

设计关键点：

1. 插件管理，核心系统需要知道哪些插件可用以及如何加载。最常见实现方法为插件注册表
2. 插件连接，插件如何接入核心系统
3. 插件通信，插件之间如何进行通信

常见架构：OSGi架构、规则引擎架构