分布式架构汇总

ゞ浴缸里的玫瑰 2022-05-24 02:30 212阅读 0赞

在互联网大行其道的今天，各种分布式系统已经司空见惯。搜索引擎、电商网站、微博、微信、O2O平台。。凡是涉及到大规模用户、高并发访问的，无一不是分布式。

关于分布式系统，并没有一个标准答案，说某某架构一定是最好的。不同的业务形态所面对的挑战不一样，使用的架构设计也不一样，通常都需要具体业务具体分析。

但不管那种业务，不管何种分布式系统，有一些基本的思想还是相通的。本文将对这些基本思想进行一个梳理汇总。

# 分拆 #

### 系统分拆 ###

微信的架构师说过一句话：“大系统小做“。对于一个大的复杂系统，首先想到的就是对其分拆，拆成多个子系统。每个子系统自己的存储/Service/接口层，各个子系统独立开发、测试、部署、运维。   
从团队管理角度讲，也可以不同团队用自己熟悉的语言体系，团队之间基于接口进行协作，职责清晰，各司其职。

### 子系统分拆 ###

拆成子系统之后，子系统内部又可以分层，分模块。当然，这里“系统“，“子系统“，“层“，“模块“ 都只是一个相对概念。在一个系统里面，某个模块复杂到一定程度，会把它抽出来，单独做成一个系统；而在初期，很大简单模块，可能不回拆分，集中在一个系统里面。   
这就像一个生物组织，自身是在不断成长、演化、有分有合，不断变化发展的。

### 存储分拆 ###

Nosql：对于Nosql数据库，比如MongoDB，其天生就是分布式的，很容易实现数据的分片。   
Mysql: 对于Mysql，或者其它关系型数据库，就会设计到分库分表。而分库分表，就会涉及到几个关键性的问题：切分维度，join的处理，分布式事务

### 计算分拆 ###

计算的分拆有2种思路：   
数据分拆：一个大的数据集，拆分成多个小的数据集，并行计算。   
比如大规模数据归并排序

任务分拆：把一个长的任务，拆分成几个环节，各个环节并行计算。

Java中多线程的Fork/Join框架，Hadoop中的Map/Reduce，都是计算分拆的典型框架。其思路都是相似的，先分拆计算，再合并结果。

再比如分布式的搜索引擎中，数据分拆，分别建索引，查询结果再合并。

# 并发 #

最常见的就是多线程，尽可能提高程序的并发度。   
比如多次rpc顺序调用，通过异步rpc转化为并发调用；   
比如数据分片，你的一个Job要扫描全表，跑几个小时，数据分片，用多线程，性能会加快好几倍。

# 缓存 #

缓存大家都不陌生，遇到性能问题，大家首先想到的就是缓存。关于缓存，一个关键点就是：缓存的粒度问题。

比如Tweet的架构，缓存的粒度从小到大，有Row Cache, Vector Cache, Fragment Cache, Page Cache。

粒度越小，重用性越好，但查询需要多次，需要数据拼装；   
粒度越大，越容易会失效，任何一个小的地方改动，都可能造成缓存的失效。

# 在线计算 vs. 离线计算 / 同步 vs. 异步 #

在实际的业务需求中，并不是所有需要都需要完全实时的：   
比如内部针对产品、运营开发的各种报表查询、分析系统；   
比如微博的传播，我发了一个微博，我的粉丝延迟几秒才看到，这是可以接受的，因为他并不会注意到晚了几秒；   
比如搜索引擎的索引，我发了一篇博客，可能几分钟之后，才会被搜索引擎索引到；   
比如支付宝转帐、提现，也并非这边转出之后，对方立即收到；   
。。。

这类例子很多。这种“非实时也可以接受“的场景，就为架构的设计赢得了充分的回旋余地。

因为非实时，我们就可以做异步，比如使用消息队列，比如使用后台的Job，周期性处理某类任务；

也因为非实时，我们可以做读写分离，读和写不是完全同步，比如Mysql的Master-Slave。

# 全量 ＋ 增量 #

全量/增量其实也是在线/离线的思路：   
比如搜索引擎的全量索引 ＋ 增量索引，前者是为了吞吐，后者为了实时；   
比如OceanBase数据库，每次更新存在一个小表里面，定期merge；

# Push vs. Pull #

在所有分布式系统中，都涉及到一个基本问题：节点之间（或者2个子系统之间）的状态通知。比如一个节点状态变更了，要通知另外一个节点，都有2种策略：   
Push: 节点A状态变了， push给节点B   
Pull: 也就是轮询。节点B周期性的去询问节点A的状态。

这个问题不光出现在分布式系统中，可以说是编写代码的一个基本问题。对应到面向对象的编程中，也就是常说的“双向关联”这种耦合问题。

A调用B，B再回调A，这种情形，在系统开发中经常出现。再复杂一点，多个模块之间，彼此调用，调用关系跟蜘蛛网一样。

这个问题的出现，就和Push/Pull的策略密切相关：   
A调用B，那逻辑就会写在B这边；B调用A，逻辑就会写在A这边。所以是采用主动调用的pull方式，还是回调的push方式，会严重影响职责在各个模块或者子系统里面的分配。

# 批量 #

批量其实也是在线/离线的一种思想，把实时问题，转化为一个批量处理的问题，从而降低对系统吞吐量的压力   
比如Kafka中的批量发消息；   
比如广告扣费系统中，把多次点击累积在一起扣费；   
。。

# 重写轻读 vs 重读轻写 #

重写轻读，本质就是“空间换时间“。你不是计算起来耗时，延迟高吗，那我可以提前计算，然后存储起来。取的时候，直接去取。

我们通常对Mysql的用法，都是重读轻写，写的时候，简单；查的时候，做复杂的join计算，返回结果。这样做的好处是容易做到数据的强一致性，不会因为字段冗余，造成数据的不一致。但是性能可能就是问题。

而微博的Feeds架构，就是典型的重写轻读。我要去看Feeds，按通常的mysql的做法，我要先去查我关注的所有的人，然后把所有人的消息排序，分页返回。很显然，在大数据量下，这个会很耗时。   
而如果采用重写轻读，怎么做呢？你不是要看Feeds吗，那就为每个人准备一个Feeds，或者说收件箱。某个人发了微博之后，把他的微博扩散到所有人的收件箱，这个扩散是异步的，在后台扩散。这样每个人看自己的Feeds的时候，直接去自己的收件箱取就可以了。

# 读写分离 #

同样，对传统的单机Mysql数据库，读和写是完全同步的。写进去的内容，立马就可以读到。   
但在很多业务场景下，读和写并不需要完全同步。这个时候，就可以分开存储，写到一个地方，再异步的同步到另一个地方。这样就可以实现读写分离。   
比如Mysql的Master/Slave就是个典型，Slave上面的数据并不是和Master实时同步的；   
再比如各种报表分析，OLTP/OLAP，线上/线下数据分离，线上数据定期同步到Hive集群，再做分析。

# 动静分离 #

动静分离的典型例子就是网站的前端，动态的页面，放在web服务器上；静态的css/jss/img，直接放到CDN上，这样既提高性能，也极大的降低服务器压力。

按照这个思路，很多大型网站都致力于动态内容的静态化，静态化之后，就可以很容易的缓存。

# 冷热分离 #

比如定期把mysql中的历史数据，同步到hive

# 限流 #

现在很多电商都会有秒杀活动，秒杀的一个特点就是商品很少，但短时间内流量暴增，服务器完全处理不了这么多请求。

应对这类问题的一个基本思路就是限流，既然处理不了那么多请求，既然很大人进去了，也是抢不到的。那索性不要放那么多人进去。

这个和我们日常生活中，节假日，某个景点人数过多，限制人流量是同样的道理。

# 服务熔断与降级 #

服务降级是系统的最后一道保险。在一个复杂系统内部，一个系统往往会调用其它很大系统的服务。在大流量的情况下，我们可能会在保证主流程能正常工作的情况下，对其它服务做降级。

所谓降级，也就是当某个服务不可用时，干脆就别让其提供服务了，直接返回一个缺省的结果。虽然这个服务不可用，但它不至于让整个主流程瘫痪，这就可以最大限度的保证核心系统可用。