读 《从零开始学架构》

零、学习的过程

读 《从零开始学架构》_第1张图片

一、概念

1、系统

  • 关联:发动机、地盘和车架组合才能成为汽车
  • 规则:发动机产生动力,经过变速器和传动轴到车轮,有规则运作而不是各自为政
  • 能力:发动机、变速器和车轮每单独一个都不能走,组合才能产生行走的能力

2、子系统:是不同维度的系统,比如微信有聊天、登录、支付、朋友圈等子系统,朋友圈又分评论、动态、点赞等子系统

3、模块:系统的组成部分,系统的逻辑区分,比如登录注册模块、个人信息模块

4、组件:系统的组成部分,系统的物理区分,比如nginx、mysql、web服务器的层面

5、框架:组件的一种规范,spring框架

6、架构:软件的一种结构,比如 ssh架构,它是子系统、模块、组件的一个集合体

二、架构产生的起因

1、系统规模大,耦合严重,开发效率低,维护扩展困难

三、目的

1、不一定都要架构设计,关键看业务

2、架构设计要适当,而不是约大约好,且不能一味模仿,不然工期延误且难落地

3、目的是解决软件系统复杂度带来的问题

四、解决复杂度

1、高性能:简单系统更容易做高性能,单任务扩展做到高性能

  • 单机复杂度:操作系统和硬件的限制,出现了多进程和多线程
  • 集群复杂度:任务分配(网络设备、负载均衡、连接方式、分配算法)

2、高可用:基本都是通过“冗余”

  • 计算高可用:不同机器都能一样处理业务
  • 存储高可用:如何减少或者规避数据不一致的影响
  • 状态决策:独裁式、协商式、民主式

3、可扩展

  • 预测变化:适当预测,但不能每个点都考虑
  • 应对变化:稳定层与变化层、抽象层与实现层
  • 扩展标准:可复用和松耦合

4、低成本:硬件的成本,用新技术弥补

5、安全

  • 功能安全:防小偷,XSS攻击、CSRF攻击、SQL注入、windows漏洞、密码破解
  • 架构安全:防强盗,防火墙

6、规模:功能和数据导致复杂

五、设计3个原则

1、合适原则:人力、积累和业务要合适

2、简单原则:过多组件会导致联系多,出问题难查找

3、演化原则:架构是不断更新迭代的

六、设计流程

 

七、数据层面

1、读写分离:主从集群,一主一/多从,主负责写,从负责读,主复制数据到从

  • 主从复制延迟:①写后的读发给主 ②读从失败再读主 ③关键业务读写都主
  • 分配机制:①数据访问层/中间层封装(TDDL) ②中间件技术(mysql proxy、Atlas)

2、分库分表

  1. 业务分库:如电商系统的数据分用户、商品、订单(join问题、事务问题,成本问题)
  2. 单表拆分:
  • 垂直分表:拆分列,拆分不常用且较大数据的列
  • 水平分表:拆分行
  • 路由:范围路由、Hash路由、配置路由
  • join:业务代码或中间件合并
  • count:①分表count后再相加 ②记录数表
  • order by:业务代码或中间件排序

3、NoSQL

  1. K-V存储(存储数据结构):redis,事务只能保证IC,不能保证AD
  • string、hash、list、set、sorted set、bitmap、hyperloglog,
  1. 文档:MongoDB,不支持事务,多用存储一个json
  2. 列式:HBase,多用于某一列海量数据统计分析,但更新多个列会比较慢
  3. 全文搜索:Elasticsearch,是一种倒排/反向索引(索引的是单词和文档,关系数据库索引的是键和行)

4、缓存

  1. 缓存穿透:就是缓存没发挥效果,可能是数据不存在也可能是缓存生成时较久导致访问时失效了
  2. 缓存雪崩:就是在缓存过期后重新生成时耗时,此时又有多请求,压力导致数据库宕机,连锁反应致使系统崩溃
  • 更新锁:更新缓存加锁
  • 后台更新:用后台线程更新缓存而不是业务线程,缓存设置永久,但后台线程定时更新

       3. 缓存热点

八、服务器层面

1、服务器性能:管理连接和处理请求

  1. PPC:用新进程处理新连接
  2. TPC:共享进程,线程处理
  3. Reactor:反应堆,建立进程池,并用IO多路复用(select/epoll/kqueue),如Netty、Memcache、Nginx
  • 单Reactor 多线程
  • 多Reactor 多进程/线程

2、负载均衡

  1. 分类:DNS负载均衡、硬件负载均衡、软件负载均衡:Nginx,LVS
  2. 算法:轮询、加权轮询、负载最低优先(用连接池的时候不适合)、性能最优、Hash类(同ip访问同服务器)

九、存储架构

1、思考:数据如何复制、节点职责、处理复制延迟、处理复制中断

2、双机架构

  1. 主备复制:优点是对用户透明、只复制数据不用判断状态,缺点是只做备份浪费硬件、故障后需要人工处理
  2. 主从复制:主读写从读,优点是主坏从可读、充分发挥了硬件的性能,缺点是客户端需判断读写来选择主从、复制延迟、故障需人工
  3. 双机切换:主从/主备切换,需要进行状态判断、切换决策(时机、策略、自动程度)、数据冲突解决
  • 互连式:主备建立状态传递的渠道
  • 中介式:主备间加入中介(Zookeeper和keepalived)
  • 模拟式:备模拟请求主来判断主的状态

     4. 主主复制:适用于临时、可丢失、可覆盖的数据,比如session或日志,类似用户id或者商品库存复制后可能就出现问题了

3、多机架构

  1. 数据集群
  • 数据集中集群:一主多备/多从
  • 数据分散集群:多机集群,每台存储一部分数据

     2.数据分区

十、计算高可用

1、任务调度

  • 哪些可以执行任务:①所有机器 ②只有主机
  • 如何重新执行任务:①失败不处理 ②任务管理器

2、常见架构

  • 主备:①冷备:备机系统没启动,需要时再启动切换请求 ②温备:备机系统已启动,需要时直接切换
  • 主从:主从执行不同的任务
  • 集群:①对称集群(负载均衡集群):不同服务器执行相同任务 ②非对称集群:不同服务器执行不同任务,如Master-Slaver

3、异地多活

  1. 模式:同城异区、跨城异地、跨过异地
  2. 设计技巧:
  • 保证核心业务异地多活
  • 核心数据最终一致性
  • 多种手段同步(消息队列、二次读取、存储系统同步、回源读取、重生成数据)
  • 只保证绝大部分用户的异地多活(挂公告、事后补偿、补充体验)

      3. 异地多活设计思路

  • 业务分级(访问量、收入)
  • 数据分类(数据量、唯一性、实时性、可丢失性、可恢复性)
  • 数据同步(存储系统、消息队列、重复生成)
  • 异常处理(多通道同步、同步和访问结合、日志记录、用户补偿)

4、接口级故障

  1. 原因:程序Bug导致死循环、数据库查询慢、程序逻辑导致内存占用高、外部攻击
  2. 解决
  • 降级:应付内部异常
  • 熔断:应付依赖项目异常
  • 限流:应付用户访问压力(请求限流和资源限流)
  • 排队:由排队模块和调度模块组成

十一、架构可扩展

1、基本思想:拆

  • 面向流程拆:如展示层、业务层、数据层、存储层
  • 面向服务拆:如注册、登录、信息管理、安全设置等服务
  • 面向功能拆:如登录服务拆成手机号登录、账号密码登录、邮箱登录

 

 

 

 

你可能感兴趣的:(书)