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

文章目录

    • 一、架构基础
      • 1.1、概念与基础
      • 1.2、架构设计原则
      • 1.3、架构设计流程
    • 二、高性能架构
      • 2.1、存储高性能
        • 2.1.1、关系数据库
        • 2.1.2、NoSQL
        • 2.1.3、缓存
      • 2.2 、计算高性能
        • 2.2.1 单机计算高性能:5种网络模型
        • 2.2.2 集群计算高性能
    • 三、高可用架构
      • 3.1、CAP理论
      • 3.2、FMEA
      • 3.3、存储高可用
      • 3.4、计算高可用
      • 3.5、业务高可用
    • 四、可扩展架构
      • 4.1、可扩展模式
      • 4.2、SOA架构与微服务
      • 4.3、微内核

一、架构基础

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架构、规则引擎架构

你可能感兴趣的:(设计模式,读书笔记)