架构物语二

最新推荐文章于 2022-04-22 18:15:19 发布

代码最诚实的朋友

最新推荐文章于 2022-04-22 18:15:19 发布

阅读量175

点赞数

分类专栏：架构设计文章标签：后端

本文链接：https://blog.csdn.net/matt8/article/details/117405475

版权

架构设计专栏收录该内容

13 篇文章 0 订阅

订阅专栏

架构是什么

软件架构指软件系统的顶层结构。

首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等；架构需要明确系统包含哪些“个体”。

其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。

举个生活中的例子：

搬砖的：“头，我们要造什么？”；（做什么系统？）

工程师：“龙之梦商城”；（XXX系统，比如微博系统）

搬砖的：“图纸画出来了嘛？”；（架构是怎么设计的？）

工程师：“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”；（相当于微博系统中的各个子系统，比如评论子系统、动态子系统、消息子系统）

搬砖的：“头，说人话”；

工程师：“一楼有卖衣服、化妆品的，二楼有唱歌、看电影的，三楼有吃的”；（【模块】按照逻辑区分，比如存储数据模块、搜索模块、消息推送模块）

搬砖的：“有没有很知名的店啊？”；

工程师：“有的，一楼有香奈儿、优衣库...、二楼有好乐迪、万达影院....、三楼有海底捞、避风塘.....”；（【组件】按照物理区分，存储数据模块对应Mysql、搜索模块对应ElasticSearch、消息推送模块对应Kafka）

搬砖的：“对了，头，商城大门有啥需要叮嘱的施工规范不？或有啥简化施工工艺的新技术嘛？”；（有框架的可以用吗？）

工程师猛吸了一口烟，把烟头扔在地上，用皮鞋左右撵了两下，缓缓从嘴里崩出四个字。
“老样子吧”。（Spring全家桶甩起来）

提炼：框架是面向编程或配置的半成品；组件是从技术维度上的复用；模块是从业务维度上职责的划分；系统是相互协同可运行的实体。

架构设计的目的

架构设计的主要目的是为了解决软件系统复杂度带来的问题。

这么多需求，从哪里开始下手进行架构设计呢？通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
架构设计要考虑高性能、高可用、高扩展……这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间！架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。
我们的系统一定要做到每秒 TPS 10 万！如果系统的复杂度不是在性能这部分，TPS 做到 10 万并没有什么用。
淘宝的架构是这么做的，我们也要这么做！淘宝的架构是为了解决淘宝业务的复杂度而设计的，淘宝的业务复杂度并不就是我们的业务复杂度，绝大多数业务的用户量都不可能有淘宝那么大。
Docker 现在很流行，我们的架构应该将 Docker 应用进来！Docker 不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂度根本不是在这方面，引入 Docker 没有什么意义。

复杂度的来源

高性能

软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

单机复杂度

单机复杂度最关键的地方就是操作系统。操作系统是软件系统的运行环境，操作系统的复杂度直接决定了软件系统的复杂度。

操作系统和性能最相关的就是进程和线程。多进程多线程可以让性能大大提升，其本质就是就是让多个 CPU 能够同时执行。支持这种架构的方案有3种：SMP（Symmetric Multi-Processor，对称多处理器结构）、NUMA（Non-Uniform Memory Access，非一致存储访问结构）、MPP（Massive Parallel Processing，海量并行处理结构）。其中 SMP 是我们最常见的，目前流行的多核处理器就是 SMP 方案。

操作系统发展到现在，如果我们要完成一个高性能的软件系统，需要考虑如多进程、多线程、进程间通信、多线程并发等技术点，而且这些技术并不是最新的就是最好的，也不是非此即彼的选择。在做架构设计的时候，需要花费很大的精力来结合业务进行分析、判断、选择、组合，这个过程同样很复杂。举一个最简单的例子：Nginx 可以用多进程也可以用多线程，JBoss 采用的是多线程；Redis 采用的是单进程，Memcache 采用的是多线程，这些系统都实现了高性能，但内部实现差异却很大。

集群复杂度

支付宝和微信这种规模的业务系统，后台系统的机器数量都是万台级别的。采用机器集群的方式来达到高性能。通过大量机器来提升性能，并不仅仅是增加机器这么简单，让多台机器配合起来达到高性能的目的，是一个复杂的任务。

业务简单的时候，可以直接通过增加机器来提高性能，例如，业务简单的时候 1 台机器扩展到 10 台机器，性能能够提升 8 倍（需要扣除机器群带来的部分性能损耗，因此无法达到理论上的 10 倍那么高），但如果业务越来越复杂，1 台机器扩展到 10 台，性能可能只能提升 5 倍。造成这种现象的主要原因是业务越来越复杂，单台机器处理的性能会越来越低。为了能够继续提升性能，我们就需要做业务拆分。

以微信为例：

通过这种任务分解的方式，能够把原来大一统但复杂的业务系统，拆分成小而简单但需要多个系统配合的业务系统。从业务的角度来看，任务分解既不会减少功能，也不会减少代码量（事实上代码量可能还会增加，因为从代码内部调用改为通过服务器之间的接口调用），那为何通过任务分解就能够提升性能呢？

主要有几方面的因素：

简单的系统更加容易做到高性能，系统的功能越简单，影响性能的点就越少，就更加容易进行有针对性的优化。而系统很复杂的情况下，首先是比较难以找到关键性能点，因为需要考虑和验证的点太多；其次是即使花费很大力气找到了，修改起来也不容易，因为可能将 A 关键性能点提升了，但却无意中将 B 点的性能降低了，整个系统的性能不但没有提升，还有可能会下降。
可以针对单个任务进行扩展，当各个逻辑任务分解到独立的子系统后，整个系统的性能瓶颈更加容易发现，而且发现后只需要针对有瓶颈的子系统进行性能优化或者提升，不需要改动整个系统，风险会小很多。以微信的后台架构为例，如果用户数增长太快，注册登录子系统性能出现瓶颈的时候，只需要优化登录注册子系统的性能（可以是代码优化，也可以简单粗暴地加机器），消息逻辑、LBS 逻辑等其他子系统完全不需要改动。

虽然系统拆分可能在某种程度上能提升业务处理性能，但提升性能也是有限的，不可能系统不拆分的时候业务处理耗时为 50ms，系统拆分后业务处理耗时只要 1ms，因为最终决定业务处理性能的还是业务逻辑本身，业务逻辑本身没有发生大的变化下，理论上的性能是有一个上限的，系统拆分能够让性能逼近这个极限，但无法突破这个极限。因此，系统拆分带来的性能收益是有一个度的，并不是拆分越细越好，而对于架构设计来说，如何把握这个粒度就非常关键了。

高可用

系统的高可用方案五花八门，但万变不离其宗，本质上都是通过“冗余”来实现高可用。通俗点来讲，就是一台机器不够就两台，两台不够就四台；一个机房可能断电，那就部署两个机房；一条通道可能故障，那就用两条，两条不够那就用三条（移动、电信、联通一起上）。高可用的“冗余”解决方案，单纯从形式上来看，和高性能是一样的，都是通过增加更多机器来达到目的，但其实本质上是有根本区别的：高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。

高可用通过集群的方式来达到高可用的目的，同样面临集群的复杂性，集群的方式里面，都会有一个决策者角色，用于判断当前集群所有机器的状态，剔除故障的机器，保证请求不会打到有问题的机器上面，这个角色至关重要，所以如果决策者出了问题，整个机器将处于混乱状态。

目前流行的ZooKeeper集群采用的是leader选举的方式，但这种方式同样不是完美的。ZooKeeper选举时可能产生脑裂问题，虽然可以通过投票节点数必须超过系统总节点数一半，来解决这个问题，但同时降低了系统整体的可用性。

ZooKeeper脑裂问题：

从图中可以看到，正常状态的时候，节点 5 作为主节点，其他节点作为备节点；当连接发生故障时，节点 1、节点 2、节点 3 形成了一个子集群，节点 4、节点 5 形成了另外一个子集群，这两个子集群的连接已经中断，无法进行信息交换。按照民主决策的规则和算法，两个子集群分别选出了节点 2 和节点 5 作为主节点，此时整个系统就出现了两个主节点。这个状态违背了系统设计的初衷，两个主节点会各自做出自己的决策，整个系统的状态就混乱了。

为了解决脑裂问题，民主式决策的系统一般都采用“投票节点数必须超过系统总节点数一半”规则来处理。如图中那种情况，节点 4 和节点 5 形成的子集群总节点数只有 2 个，没有达到总节点数 5 个的一半，因此这个子集群不会进行选举。这种方式虽然解决了脑裂问题，但同时降低了系统整体的可用性，即如果系统不是因为脑裂问题导致投票节点数过少，而真的是因为节点故障（例如，节点 1、节点 2、节点 3 真的发生了故障），此时系统也不会选出主节点，整个系统就相当于宕机了，尽管此时还有节点 4 和节点 5 是正常的。

无论采取什么样的方案，都不可能做到任何场景下都没有问题，但完全不做高可用方案又会产生更大的问题，如何选取适合系统的高可用方案，也是一个复杂的分析、判断和选择的过程。