谈谈分布式系统架构

目录

• 基本概念
  • 拆分重组
  • 架构的分类
    • 业务架构
    • 应用架构
    • 技术架构
  • 架构师
  • 架构中的常见算法
    • 一致性hash
    • cache命中率
    • LRU Least Recently Used
  • 架构中常见名词
    • 分布式系统CAP理论
    • BASE理论
    • 柔性事务
    • QPS
    • 降级
    • 限流
    • 熔断
    • CPU密集型IO密集型应用
  • 信息技术的常识
    • CPU核心与线程数关系
    • CPU指标
  • 常见trick
    • 读写分离
    • 池化技术
• 常见案例
  • 秒杀
  • 支付
  • 聊天
  • 直播
  • 撮合交易
• 失败案例
  • 宕机是如何发生的
• 组件
  • Tomcat

基本概念

架构的作用：解决系统的无序性。

好的架构体现在哪儿？
好的架构就是一个好的系统。
架构首先是为人服务的，业务概念清晰、应用逻辑合理、人好理解是第一位的（即系统有序度高）。

拆分重组

已有系统实现架构的手段：对系统进行有序化重构的方法主要是，分和合，先把系统打散，然后重新组合。

拆分重组的步骤：
1、罗列（包含子系统，模块，组件）
2、定位（定位清晰，才能有边界）
3、重组
拆分是最难的

拆分重组带来的好处：
1、对于开发人员，业务聚焦、技能聚焦，实现开发敏捷
2、对于系统，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。

架构的分类

架构一般可分业务架构、应用架构、技术架构。

三者的关系：
技术架构为应用架构和业务机构提供支撑，一个不好的业务架构可以把技术架构给拖垮。

业务架构

业务架构是真实世界的业务在IT世界的表现形式。

业务架构从概念层面帮助开发人员理解系统。

动态业务：
业务流 / 节点 / 输入输出

静态业务：
业务领域 / 模块 / 实体 / 对象 / 角色

应用架构

应用架构包含应用种类 / 应用形式 / 数据交互关系 / 交互方式等。

应用架构承上启下:
1、一方面承接业务架构的落地，
2、一方面影响技术选型

一个系统中可以有一到多个应用：
1、系统中应用之间交互的形式可以有单体式、分布式、SOA架构。
2、系统中应用划分的方式有水平和垂直：
水平划分相当于应用分层。
垂直划分相当于按照按照业务广度的划分。

技术架构

技术架构解决了系统服务能力和服务水平的问题，如系统响应时间，吞吐量等。

技术架构包括了技术平台选型（操作系统 / 中间件 / 设备等）、部署方式等。

架构师

1、要多看主流公司的系统设计
要非常了解，知道优劣长短，碰到实际问题，很快有多种方案可供评估。

2、技术的广度（多领域知识），又有深度（技术前瞻）

3、兼具思维的高度（抽象思维）和深度（问题到本质）

4、兼具感性（沟通）和理性（平衡）

架构中的常见算法

一致性hash

一致性哈希解决了简单哈希算法在分布式哈希表( Distributed Hash Table，DHT) 中存在的动态伸缩等问题。
todo

cache命中率

todo
高命中率是衡量cache的一个重要指标。

LRU Least Recently Used

todo

架构中常见名词

分布式系统CAP理论

Consistency 一致性
一致性指“all nodes see the same data at the same time”，即所有节点在同一时间的数据完全一致。

Availability 可用性
可用性指“Reads and writes always succeed”，即服务在正常响应时间内一直可用。

Partition Tolerance分区容错性
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。

对于涉及到钱财这样不能有一丝让步的场景，C必须保证。
大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。

1. 舍弃A，保留CP
   让用户保持等待，一直到系统数据一致了之后，再恢复服务。

2. 舍弃C，保留AP
   这种是大部分的分布式系统的设计，保证高可用和分区容错，但是会牺牲一致性。比如淘宝购物以及12306购票等等，前面说过淘宝可以做到全年可用性5个9的超高级别，但是此时就无法保证数据一致性了。
   比如12306的假的缓存余票。

3. 舍弃P，保留CA
   很遗憾，这种情况几乎不存在。因为分布式系统，网络分区是必然的。如果要舍弃P，那么就是要舍弃分布式系统，CAP也就无从谈起了。可以说P是分布式系统的前提，所以这种情况是不存在的。

BASE理论

BASE理论是Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。

其核心思想是：
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

柔性事务

分布式事务属于柔性事务，满足BASE理论。
支付宝所说的柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型几种 参考。

• 两阶段提交：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。很典型。
• 补偿型，TCC（Try/Confirm/Cancel）型事务：支持取消操作
• 异步确保型， 将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用。比如热点资源的批量更新、异步更新的处理。
• 最大努力型， 通过通知服务器（消息通知）进行，允许失败，有补偿机制（或重发机制）。

解决的问题：某个操作发生了异常，如何通过内部机制将这个异常产生的「不一致」状态消除掉。
只要通过额外的方式解决了问题都可以理解为是「补偿」。

补偿的手段包括： 「事务补偿」和重试，前者是一个逆向操作，而后者则是一个正向操作。

暂且把事务补偿称为回滚：一种叫「显式回滚」（调用逆向接口），一种叫「隐式回滚」（无需调用逆向接口）。

重试：
「重试」的适用场景相比 回滚 更少一些。
我们第一步首先要判断，当前场景是否适合「重试」：临时状态适合重试，比如「请求超时」、「被限流中」；业务错误不需要重试，Http503、404等没有何时恢复的预期的时候，也不需要重试。
「重试策略」：增量间隔，指数间隔，全抖动。
重试的「幂等性」：唯一请求号标识，或者业务判断是否执行过或正在执行中。
其它：重试一定要有终止策略

两阶段提交原理参考：

QPS

QPS（Query Per Second，每秒请求数）
响应时间（Response Time，RT）

理论上的 总 QPS =（1000ms / 响应时间）× 线程数量
响应时间是单线程的响应时间。
QPS不是随着线程数量线性增加的，到了一定程度QPS会掉头向下。

降级

降级是在重要与重要功能之间选择性的服务，是一种取舍。
为了保证基本重要的服务能正常运行，对一些不重要的服务或任务进行延迟使用暂停使用。

业务降级的例子：功能开关，禁用某些耗费性能的功能（比如模糊查询，分页）
服务降级：某个不重要的服务关闭掉

限流

限制流量大小，超出服务能力之前的一种保护措施

如何知道服务能力是多大呢？
可以通过QPS来衡量，思路是一秒我能处理多少请求，对于超过我请求能力的请求采用排队或者拒绝的方式处理就可以了。

要做好对被限流请求的处理：可以是排队等待，也可以粗暴的拒绝服务。
1、排队，要考虑如何排队，尽量减少资源的占用。
2、拒绝，用户体验不友好，要在代码中实现拒绝的逻辑。

限流方法：
1、计数器限流
单位时间超过指定数量的请求被拒绝处理
2、令牌桶限流
请求执行前要取令牌，通过放入速率来变相实现控制请求限流
3、

熔断

也称服务隔离
属于降级的一种，算是服务降级，区别于业务功能降级。

服务熔断对服务提供了proxy，防止服务不可能时，出现串联故障（cascading failure），导致雪崩效应。服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；

降级熔断区别：
触发原因不一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
自愈能力要求不一样，服务熔断在发生后有自愈能力，而服务降级没有该职责；
熔断是每个微服务都需要的，是一个框架级的处理。服务降级一般是关注业务，对业务进行考虑，抓住业务的层级。

CPU密集型IO密集型应用

服务器资源分为两部分计算和等待，分别对应了CPU和IO（内存，网络，磁盘）。

牵涉大量计算的是CPU密集型。
而场景的互联网大部分web业务应用都是IO密集型，计算量不大，大部分时间都在等待IO返回。

区分二者的关键在于请求占用CPU时间多，还是用在IO访问和等待的时间多。

理论上，IO密集型可以支持更多线程，因为等待的时候是不浪费资源的，仅仅多了一个信号量，还可以提高CPU的利用率；
CPU密集型应用设置更少的线程，防止线程之争抢CPU浪费调度资源，让CPU主要精力用在真正的计算，而不是线程之间的调度上。

信息技术的常识

千兆带宽下 10KB 数据的极限 QPS 为 1.25 万 QPS=1000Mbps/8/10KB
网络结构（交换机 / 网卡的限制）、TCP/IP、虚拟机（内存 /CPU/IO 等资源的限制）和应用本身的一些瓶颈等。

CPU核心与线程数关系

跟阻塞系数有关系[9]

IO密集型：线程数等于2倍CPU核心数，2Ncpu

计算密集型：线程数等于 Ncpu核心数量

CPU指标

1、负载load：
uptime[10]
2、使用率

todo

常见trick

读写分离

mysql数据库读写分离。
mysql写，redis或者solr读。

带来的问题：
数据同步延迟，带来的数据不一致问题。
实际使用中，通过业务上的权衡和产品的优化，应该选择谨慎的使用读写分离技术。

池化技术

池化技术用在资源使用时间很短，创建销毁很频繁的场景。
池化技术通过把资源统一管理的方式，大大减少资源的创建销毁次数，达到提高资源利用效率的目的。

数据库连接池：

对象池：
tomcat对象池

线程池：
线程数量是有限的资源，需要数量的上限，可以把待处理的任务放入到队列里，排队处理

常见案例

秒杀

许令波-如何设计一个秒杀系统学习笔记

支付

聊天

直播

撮合交易

失败案例

宕机是如何发生的

todo

组件

Tomcat

学习笔记

参考
王庆友：首席架构师眼里的架构本质
架构可细分为业务架构、应用架构、技术架构
互联网三高架构之高并发和高性能的理解
CPU密集型操作与IO密集型操作区分
简易RPC框架-客户端限流配置
限流的四种策略
服务限流：tomcat请求数限制
【8】微服务-高并发下接口如何做到优雅的限流
【9】根据CPU核心数确定线程池并发线程数
【10】系统服务监控指标 -- load(负载)
【11】99%的人都能看懂的「补偿」以及最佳实践