【从0开始学架构】

李运华老师（从0开始学架构）学习笔记

什么是架构

架构的定义可以按不同的角度去诠释：

• 从业务角度 ：erp的采购模块、发票模块、商品模块
  
• 从物理部署角度 ：nginx;mysql;web服务器
  
• 从开发规范角度：MVC框架：model、view、controller
  

架构计划的目标

解决软件系统复杂度带来的题目 ：分析系统的复杂度在哪，并通过架构计划来解决
复杂度的来源

高性能

单机高性能

要实现单机的高性能通常要思量的是多线程并发技术，保证cpu的运行服从
多机高性能

任务分配

多台机器实现高性能，第一个复杂度就是怎么实现任务分配

任务分配器比如是nginx。
要思量的点：任务分配的算法；任务分配器和业务服务器断开连接了怎么办。

业务哀求再次增长，任务分配器也需要增多，接纳DNS轮询（将相同域名映射到不同ip地址）将哀求打到不同的任务分配器。复杂度再次增长。
任务分解

光靠扩充机器，来实现高性能是不够的，业务越复杂，单台机器的性能就越差。需要将系统的功能变简单进而提拔性能。复杂系统变简单系统就需要任务分解，任务分解就会带来复杂度。
任务分解的复杂度紧张体现在，改怎么分？分的越细越好么？
高可用

高可用是指，不管发生什么事变，系统都能够对外提供服务，要做到这点，就需要冗余
复杂度来源

计算高可用

• 选什么任务分配器
  
• 连接断开怎么处置惩罚（任务分配器和计算服务器）
  
• 分配算法是什么
  

存储高可用

存储高可用的紧张复杂度体现在：怎样淘汰或者规避数据不一致对业务造成的影响

可扩展

复杂度来源一：猜测变革

现在用的mysql，猜测以后要用Oracle，这种是不好猜测出来的
复杂度来源二：应对变革

纵然能够猜测到变革，应对变革也是复杂的。

• 需要划分出哪个是稳定层，哪个是变革层
  
• 需要计划稳定层和变革层之间的接口。（接纳计划模式）
  

架构计划三原则

合适原则

架构计划要得当本身的业务需求，规模小就不要做什么抗住亿级并发的系统
简单原则

演化原则

演化优于一步到位
架构计划流程

识别复杂度

切入点是高性能、高可用、可扩展，然后按优先级排序，优先级最高的最先去解决
计划备选方案

针对识别出的复杂度，计划多个备选方案，但不需要详细计划，从中选择一个合适的
详细方案计划

选择出合适的方案后，针对这个方案进行详细计划
架构计划流程

高性能解决方案

高性能数据库集群

读写分离

复制延迟

• 写操作后的读操作指定主机（不建议，新来的程序员可能不知道）
  
• 读从机没有则去主机读（主机可能禁受不住而崩溃）
  
• 关键业务全部指向主机
  

分配机制

• 代码分配：接纳shardingsphere来分库分表
  
• 中心件封装
  
  
  
  

分库分表

高性能缓存

关系型数据库不能存储数据结构,并且IO服从差，查询速度慢，接纳缓存来解决
高性能负载均衡

• DNS负载均衡
  
• F5负载均衡
  
• nginx负载均衡
  

高可用解决方案

存储高可用

主备复制

长处：简单 缺点：备机只是备份作用，比力浪费；主机故障需要人工干预设置备机为主机
主从复制

长处：简单 缺点：需要人工干预设置从机为主机
双机切换

解决上述架构都需要人工干预的题目
互联式

主机同步数据的同时，同步状态，状态同步失败，则备机自动提拔为主机
中介式

模仿式

备机模仿成客户端向主机发送哀求

主主复制

得当于那些临时性、可丢失、可覆盖的数据场景。例如，用户登录产生的 session 数据（可以重新登录天生）、用户行为的日志数据（可以丢失）、论坛的草稿数据（可以丢失）等
数据分区

会合式

互备式

独立式

计算高可用

本质上照旧通过冗余来实现高可用，并使用负载均衡算法，将哀求打到不同的机器上
业务高可用

接纳异地多活，洲、国、区、城（敏感数据不异地多活，方式数据不一致导致出现题目）
可扩展解决方案

拆！

面向流程拆

面向服务拆

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。