关于后端:为什么大部分人做不了架构师

腾小云导读

成为架构师，是许多程序员的职业幻想。然而其中只有多数有着丰富编码积攒、超强自驱力和独到思维的程序员能力最终成为架构师。其实，日常工作中小到某个性能的开发，大到整个业务零碎的设计，都能够看到架构设计的影子。《从 0 开始学架构》一书是颇受程序员欢送的架构设计入门教程。接下来本文作者将提取该书籍之精华，联合本身教训分享架构设计常见办法以及高可用、高性能、可扩散架构模式的实现思路，将架构设计思维“为我所用”、晋升日常研效。心愿对你有帮忙~

目录

1 基本概念与设计办法

2 高性能架构模式

2.1 存储高性能

2.2 计算高性能

3 高可用架构模式

3.1 实践办法

3.2 存储高可用

3.3 计算高可用

4 可扩大架构模式

5 总结

之前本栏目《腾讯专家 10 年积淀：后海量时代的架构设计》、《工作十年，在腾讯积淀的高可用零碎架构设计教训》两篇文章中，两位腾讯的开发者联合本身经验，分享了架构设计的实践经验。而本期，本栏目特邀腾讯云对《从 0 开始学架构》一书提取精华，并联合亲身经验做分享。

01、基本概念与设计办法

在解说架构思维之前，咱们先对立介绍一下基本概念的含意，防止每个人对系统、框架、架构这些名词的了解不统一导致的误会。上面是《从 0 开始学架构》作者对每个名词的定义。其作用域仅限本文领域，不必纠结其在其余上下文中的意义。

由以上定义可见，所谓架构，是为了解决软件系统的某个复杂度带来的具体问题，将模块和组件以某种形式有机组合，基于某个具体的框架实现后的一种落地计划。

而探讨架构时，往往只探讨到零碎与子系统这个顶层的架构。

可见，要进行架构选型，首先应该晓得本人要解决的业务和零碎简单点在哪里，是作为秒杀零碎有霎时高并发，还是作为金融科技零碎有极高的数据一致性和可用性要求等。

一般来说，零碎的复杂度起源有以下几个方面：

• 高性能

如果业务的拜访频率或实时性要求较高，则会对系统提出高性能的要求。

如果是单机零碎，须要利用多过程、多线程技术。

如果是集群零碎，则还波及工作拆分、调配与调度，多机器状态治理，机器间通信，当单机性能达到瓶颈后，即便持续加机器也无奈持续晋升性能，还是要针对单个子工作进行性能晋升。

• 高可用

如果业务的可用性要求较高，也会带来高可用方面的复杂度。高可用又分为计算高可用和存储高可用。

针对计算高可用，能够采纳主备（冷备、温备、热备）、多主的形式来冗余计算能力，但会减少老本、可维护性方面的复杂度。

针对存储高可用，同样是减少机器来冗余，但这也会带来多机器导致的数据不统一问题，如遇到提早、中断、故障等状况。难点在于怎么缩小数据不统一对业务的影响。

既然次要解决思路是减少机器来做冗余，那么就波及到了状态决策的问题。即如果判断以后主机的状态是失常还是异样，以及异样了要如何采取行动（比方切换哪台做主机）。

对主机状态的判断，多采纳机器信息采集或申请响应状况剖析等伎俩，但又会产生采集信息这一条通信链路自身是否失常的问题，下文会具体展开讨论。事实上，状态决策实质上不可能做到完全正确。

而对于决策形式，有以下几种形式：

• 可扩展性

家喻户晓在互联网行业只有变动才是永远不变的，而开发一个零碎根本都不是欲速不达的，那应该如何为零碎的将来可能性进行设计来放弃可扩展性呢？

这里首先要明确的一个观点就是，在做零碎设计时，既不可能齐全不思考可扩展性，也不可能每个设计点都思考可扩展性，前者很显著，后者则是为了防止本末倒置，为了扩大而扩大，实际上可能会为不存在的预测破费过多的精力。

那么怎么思考零碎的将来可能性从而做出相应的可扩展性设计呢？这里作者给出了一个办法：只预测两年内可能的变动，不要试图预测五年乃至十年的变动。因为对于变动快的行业来说，预测两年曾经足够远了，再多就可能打算赶不上变动。而对变动慢的行业，则预测的意义更是不大。

要应答变动，次要是将变与不变分隔开来。

这里能够针对业务，提炼变动层和稳固层，通过变动层将变动隔离。比方通过一个 DAO 服务来对接各种变动的存储载体，然而下层稳固的逻辑不必通晓以后采纳何种存储，只需依照固定的接口拜访 DAO 即可获取数据。

也能够将一些实现细节剥离开来，提炼出形象层，仅在实现层去封装变动。比方面对经营上常常变动的业务规定，能够提炼出一个规定引擎来实现外围的形象逻辑，而具体的规定实现则能够按需减少。

如果是面对一个旧零碎的保护，接到了新的重复性需要，而旧零碎并不反对较好的可扩展性，这时是否须要破费工夫精力去重构呢？作者也提出了《重构》一书中提到的准则：事不过三，三则重构。

简而言之，不要一开始就思考简单的做法去满足可扩展性，而是等到第三次遇到相似的实现时再来重构，重构的时候采取上述说的隔离或者封装的计划。

这一准则对新零碎开发也是实用的。总而言之就是，不要为难以预测的将来去适度设计，为明确的将来保留适量的可扩展性即可。

• 低成本

下面说的高性能、高可用都须要减少机器，带来的是老本的减少，而很多时候研发的估算是无限的。换句话说，低成本往往并不是架构设计的首要指标，而是设计架构时的束缚限度。

那如何在无限的老本下满足复杂性要求呢？往往只有“翻新”能力达到低成本的指标。举几个例子：

上述案例都是为了在不显著减少老本的前提下，实现零碎的指标。

这里还要阐明的是，发明新技术的复杂度自身就是很高的，因而个别中小公司根本都是靠引入现有的成熟新技术来达到低成本的指标；而大公司才更有可能本人去发明新的技术来达到低成本的指标，因为大公司才有足够的资源、技术和工夫去发明新技术。

• 平安

平安是一个研发人员很相熟的指标，从整体来说，平安蕴含两方面：性能平安和架构平安。

性能平安是为了“防小偷”，即防止零碎因安全漏洞而被窃取数据，如 SQL 注入。常见的安全漏洞曾经有很多框架反对，所以更倡议利用现有框架的平安能力，来防止反复开发，也防止因本身思考不够全面而脱漏。在此基础上，仍需继续攻防来欠缺本身的平安。

架构平安是为了“防匪徒”，即防止零碎被暴力攻打导致系统故障，比方 DDOS 攻打。这里一方面只能通过防火墙集运营商或云服务商的大带宽和流量荡涤的能力进行防备，另一方面也须要做好攻打发现与干涉、复原的能力。

• 规模

架构师在宣讲时往往会先说本人任职和设计过的大型公司的架构，这是因为当零碎的规模达到肯定水平后，复杂度会产生质的变动，即所谓质变引起量变。

这个量，体现在访问量、性能数量及数据量上。

访问量映射到对高性能的要求。性能数量须要视具体业务会带来不同的复杂度。而数据量带来的收集、加工、存储、剖析方面的挑战，现有的计划根本都是基于 Google 的三篇大数据论文的实践：

通过下面的剖析能够看到，复杂度起源很多，想要一一应答，仿佛会失去一个简单无比的架构，但对于架构设计来说，其实刚开始设计时越简略越好，只有能解决问题，就能够从简略开始再缓缓去演变，对应的是上面三条准则：

即便是 QQ、淘宝这种现在曾经非常复杂的零碎，刚开始时也只是一个简略的零碎，甚至淘宝都是间接买来的零碎，随着业务倒退也只是先加服务器、引入一些组件解决性能问题，直到达到瓶颈才去重构重写，从新在新的复杂度要求下设计新的架构。

明确了设计准则后，当面对一个具体的业务，咱们能够依照如下步骤进行架构设计：

02、高性能架构模式

2.1 存储高性能

互联网业务大多是数据密集型的业务，其对性能的压力也经常来自于海量用户对数据的高频读写压力上。因而解决高性能问题，首先要解决数据读写的存储高性能问题。

• 读写拆散

在大多数业务中，用户查问和批改数据的频率是不同的，甚至是差异很大的，大部分状况下都是读多写少的，因而能够将对数据的读和写操作离开看待，对压力更大的读操作提供额定的机器分担压力，这就是读写拆散。

读写拆散的根本实现是搭建数据库的主从集群，依据须要提供一主一从或一主多从。

留神是主从不是主备，从和备的差异在于从机是要干活的。

通常在读多写少的状况下，主机负责读写操作，从机只负责读操作，负责帮主机分担读操作的压力。而数据会通过复制机制（如全同步、半同步、异步）同步到从机，每台服务器都有所有业务数据。

既然有数据的同步，就肯定存在复制提早导致的从机数据不统一问题，针对这个问题有几种常见的解法，如：

除了数据同步的问题之外，只有波及主从机同时反对业务拜访的，就肯定须要制订申请调配的机制。下面说的几个问题解法也波及了一些分配机制的细节。具体到分配机制的实现来说，有两种思路：

• 分库分表

除了高频拜访的压力，当数据量大了当前，也会带来数据库存储方面的压力。此时就须要思考分库分表的问题。分库分表既能够缓解拜访的压力，也能够扩散存储的压力。

先说分库，所谓分库，就是指业务依照性能、模块、畛域等不同，将数据扩散存储到不同的数据库实例中。

比方本来是一个 MySQL 数据库实例，在库中依照不同业务建了多张表，大体能够归类为 A、B 两个畛域的数据。当初新建一个库，将原库中 A 畛域的数据迁徙到新的库中存储，还是按需建表，而 B 畛域的数据持续留在原库中。

分库一方面能够缓解拜访和存储的压力，另一方面也能够减少抗危险能力，当一个库出问题后，另一个库中的数据并不会受到影响，而且还能离开管理权限。

但分库也会带来一些问题：本来同一个库中的不同表能够不便地进行联表查问，分库后则会变得很简单。因为数据在不同的库中，当要操作两个库中的数据时，无奈应用事务操作，一致性也变得更难以保障。而且当减少备库来保障可用性的时候，老本是成倍增加的。

基于以上问题，初创的业务并不倡议在一开始就做这种拆分，会减少很多开发时的老本和复杂度，拖慢业务的节奏。

再说分表。所谓分表，就是将本来存储在一张表里的数据，依照不同的维度，拆分成多张表来存储。

依照诉求与业务的个性不同，能够采纳垂直分表或程度分表的形式。

垂直分表相当于垂直地给原表切了一刀，把不同的字段拆分到不同的子表中，这样拆分后，本来拜访一张表能够获取的所有字段，当初则须要拜访不同的表获取。

垂直分表适宜将表中某些不罕用又占了大量空间的列（字段）拆分进来，能够晋升拜访常用字段的性能。

但相应的，当真的须要的字段处于不同表中时，或者要新增记录存储所有字段数据时，要操作的表变多了。

程度分表相当于横着给原表切了一刀，那么原表中的记录会被扩散存储到不同的子表中，然而每张子表的字段都是全副字段。

程度分表适宜表的量级很大以至影响拜访性能的场景，何时该拆分并没有相对的指标，个别记录数超过千万时就须要警惕了。

不同于垂直分表仍然能拜访到所有记录，程度分表后无奈再在一张表中拜访所有数据了，因而很多查问操作会受到影响，比方 join 操作就须要屡次查问后合并后果，count 操作也须要计算多表的后果后相加，如果常常用到 count 的总数，能够额定保护一个总数表去更新，但也会带来数据一致性的问题。

值得特地提出的是范畴查问，本来的一张表能够通过范畴查问到的数据，分表后也须要屡次查问后合并数据，如果是业务常常用到的范畴查问，那倡议罗唆就依照这种形式来分表，这也是分表的路由形式之一：范畴路由。

所谓路由形式是指：分表后当新插入记录时，如何判断该往哪张表插入。罕用的插入方式有以下三种：

无论是垂直分表还是程度分表，单表切分为多表后，新的表即便在同一个数据库服务器中，也可能带来可观的性能晋升，如果性能可能满足业务要求，能够不拆分到多台数据库服务器，毕竟分库也会引入很多复杂性的问题；如果单表拆分为多表后，单台服务器仍然无奈满足性能要求，那就不得不再次进行业务分库的设计了。

• NoSQL 数据库

下面发分库分表探讨的都是关系型数据库的优化计划，但关系型数据库也有其无奈躲避的毛病，比方无奈间接存储某种结构化的数据、扩大表构造时会锁表影响线上性能、大数据场景下 I/O 较高、全文搜寻的性能比拟弱等。

基于这些毛病，也有很多新的数据库框架被发明进去，解决其某方面的问题。

比方以 Redis 为代表的的 KV 存储，能够解决无奈存储结构化数据的问题；以 MongoDB 为代表的的文档数据库能够解决扩大表构造被强 Schema 束缚的问题；以 HBase 为代表的的列式数据库能够解决大数据场景下的 I/O 问题；以 ES 为代表的的全文搜索引擎能够解决全文检索效率的问题等。

这些数据库统称为 NoSQL 数据库，但 NoSQL 并不是全都不能写 SQL，而是 Not Only SQL 的意思。

NoSQL 数据库除了聚焦于解决某方面的问题以外也会有其本身的毛病，比方 Redis 没有反对残缺的 ACID 事务、列式存储在更新一条记录的多字段时性能较差等。因而并不是说应用了 NoSQL 就能一劳永逸，更多的是按需取用，解决业务面临的问题。

对于 NoSQL 的更多理解，举荐大家能够看看《NoSQL 精粹》这本书。

• 缓存

如果 NoSQL 也解决不了业务的高性能诉求，那么或者你须要加点 缓存。

缓存最间接的概念就是把罕用的数据存在内存中，当业务申请来查问的时候间接从内存中拿进去，不必从新去数据库中按条件查问，也就省去了大量的磁盘 IO 工夫。

一般来说缓存都是通过 Key-Value 的形式存储在内存中，依据存储的地位，分为单机缓存和集中式缓存。单机缓存就是存在本身服务器所在的机器上，那么势必会有不同机器数据可能不统一，或者反复缓存的问题，要解决能够应用查问内容做路由来保障同一记录始终到同一台机器上查问缓存。集中式缓存则是所有服务器都去一个中央查缓存，会减少一些调用工夫。

缓存能够晋升性能是很好了解的，但缓存同样有着它的问题须要应答或躲避。数据时效性是最容易想到的问题，但也能够靠同时更新缓存的策略来保障数据的时效性，除此之外还有其余几个常见的问题。

如果某条数据不存在，缓存中势必查不到对应的 KEY，从而就会申请数据库确认是否有新减少这条数据，如果始终没有这条数据，而客户端又重复频繁地查问这条数据，就会变相地对数据库造成很大的压力，换句话说，缓存失去了爱护作用，申请穿透到了数据库，这称为 缓存穿透。

应答缓存穿透，最好的伎俩就是把“空值”这一状况也缓存下来，当客户端下次再查问时，发现缓存中阐明了该数据是空值，则不会再问询数据库。但也要留神如果真的有对应数据写入了数据库，该当能及时革除”空值“缓存。

为了保障缓存的数据及时更新，经常都会依据业务个性设置一个缓存过期工夫，在缓存过期后，到再次生成期间，如果呈现大量的查问，会导致申请都传递到数据库，而且会多次重复生成缓存，甚至可能拖垮整个零碎，这就叫 缓存雪崩，和缓存穿透的区别在于，穿透是面对空值的状况，而雪崩是因为缓存从新生成的间隔期大量申请产生的连锁效应。

既然是缓存更新时反复生成所导致的问题，那么一种解法就是在缓存从新生成前给这个 KEY 加锁，加锁期间呈现的申请都期待或返回默认值，而不去都尝试从新生成缓存。

另一种办法是罗唆不要由客户端申请来触发缓存更新，而是由后盾脚本对立更新，同样能够躲避反复申请导致的反复生成。然而这就失去了只缓存热点数据的能力，如果缓存因空间问题被革除了，也会因为后盾没及时更新导致查不到缓存数据，这就会要求更简单的后盾更新策略，比方被动查问缓存有效性、缓存被删后告诉后盾被动更新等。

虽说在无限的内存空间内最好缓存热点数据，但如果数据过热，比方微博的超级热搜，也会导致缓存服务器压力过大而解体，称之为 缓存热点 问题。

能够复制多份缓存正本，来扩散缓存服务器的单机压力，毕竟堆机器是最简略无效。此处也要留神，多个缓存正本不要设置雷同的缓存过期工夫，否则多处缓存同时过期，并同时更新，也容易引起缓存雪崩，应该设置一个工夫范畴内的随机值来更新缓存。

2.2 计算高性能

讲完存储高性能，再讲 计算高性能，计算性能的优化能够先从单机性能优化开始，多过程、多线程、IO 多路复用、异步 IO 等都存在很多能够优化的中央，但根本零碎或框架曾经提供了根本的优化能力，只需应用即可。

• 负载平衡

如果单机的性能优化曾经到了瓶颈，无奈应答业务的增长，就会开始减少服务器，构建集群。对于计算来说，每一台服务器接到同样的输出，都应该返回同样的输入，当服务器从单台变成多台之后，就会面临申请来了要由哪一台服务器解决的问题，咱们当然心愿由以后比拟闲暇的服务器去解决新的申请，这里对申请工作的解决调配问题，就叫 负载平衡。

负载平衡的策略，从分类上来说，能够分为三类：

一般来说，DNS 负载平衡用于实现天文级别的负载平衡；硬件负载平衡用于实现集群级别的负载平衡；软件负载平衡用于实现机器级别的负载平衡。

所以部署起来能够依照这三层去部署，第一层通过 DNS 将申请散发到北京、上海、深圳的机房；第二层通过硬件负载平衡将申请散发到当地三个集群中的一个；第三层通过软件策略将申请散发到具体的某台服务器去响应业务。

就负载平衡算法来说，多是咱们很相熟的算法，如轮询、加权轮询、负载最低优先、性能最优优先、Hash 调配等，各有特点，按需采纳即可。

03、高可用架构模式

3.1 实践形式

• CAP 与 BASE

在说高可用之前，先来说说 CAP 实践，即：

在一个分布式系统（指相互连贯并共享数据的节点的汇合）中，当波及读写操作时，只能保障一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被就义。

大家可能都晓得 CAP 定理是什么，但大家可能不晓得，CAP 定理的作者（Seth Gilbert & Nancy Lynch）其实并没有具体解释 CAP 三个单词的具体含意，目前大家相熟的解释其实是另一个人（Robert Greiner）给出的。而且他还给出了两版有所差别的解释。

书中第二版解释算是对第一版解释的增强，他要增强的点次要是：

在分布式系统下，P（分区容忍）是必须抉择的，否则当分区后零碎无奈履行职责时，为了保障 C（一致性），就要回绝写入数据，也就是不可用了。

在此基础上，其实咱们能抉择的只有 C+P 或者 A+P，依据业务个性来抉择要优先保障一致性还是可用性。

在抉择保障策略时，有几个须要留神的点：

随同 CAP 的一个退而求其次，也更事实的谋求，是 BASE 实践，即根本可用，保障外围业务的可用性；软状态，容许零碎存在数据不统一的中间状态；最终一致性，一段时间后零碎应该达到统一。

• FMEA 分析法

要保障高可用，咱们该怎么下手呢？俗话说知己知彼能力对症下药，因而做高可用的前提是理解零碎存在怎么的危险，并且还要辨认出危险的优先级，先治理更可能产生的、影响更大的危险。说得简略，到底怎么做？业界其实曾经提供了排查零碎危险的根本方法论，即 FMEA（Failure mode and effects analysis）——故障模式与影响剖析。

FMEA 的基本思路是，面对初始的架构设计图，思考假如其中某个部件产生故障，对系统会造成什么影响，进而判断架构是否须要优化。

具体来说，须要画一张表，依照如下步骤一一列出：

基于下面这套方法论，咱们能够无效地对系统的危险进行梳理，找出须要优先解决的危险点，从而进步零碎的可用性。

除了 FMEA，其实还有一种利用更宽泛的危险剖析和治理的实践，即 BCP——业务连续性打算，它是一套基于业务法则的规章流程，保障业务或组织在面对突发状况时其要害业务性能能够继续不中断。

相比 FMEA，BCP 除了评估危险及重要水平，还要求具体地形容应答计划、残余危险、灾备复原计划，并要求进行相应故障的培训和演习安顿，尽最大致力保障业务连续性。

晓得危险在哪、优先治理何种危险之后，就能够着手优化架构。和高性能架构模式一样，高可用架构也能够从存储和计算两个方面来剖析。

3.2 存储高可用

存储高可用 的实质都是通过将数据复制到多个存储设备，通过数据冗余的形式来进步可用性。

• 双机架构

让咱们先从简略的减少一台机器开始，即 双机架构。

当机器变成两台后，依据两台机器负责的角色不同，就会分成不同的策略，比方主备、主从、主主。

主备复制 的架构是指一台机器作为客户端拜访的主机，另一台机器纯正作为冗余备份用，当主机没有故障时，备机不会被客户端拜访到，仅仅须要从主机同步数据。这种策略很简略，能够应答主机故障状况下的业务可用性问题，但在平时无奈分担主机的读写压力，有点节约。

主从复制 的架构和主备复制的差异在于，从机除了复制备份数据，还须要干活，即还须要承当一部分的客户端申请（个别是分担读操作）。当主机故障时，从机的读操作不会受到影响，但须要减少读操作的申请散发策略，且和主备不同，因为从机间接提供数据读，如果主从复制提早大，数据不统一会对业务造成更显著的影响。

对于主备和主从两种策略，如果主机故障，都须要让另一台机器变成主机，能力持续残缺地提供服务，如果全靠人工干预来切换，会比拟滞后和易错，最好是可能主动实现切换，这就波及 双机切换 的策略。

在思考双机切换时，要思考什么？首先是须要感知机器的状态，是两台机器直连传递相互的状态，还是都传递给第三方来仲裁？所谓状态要蕴含哪些内容能力定义一台主机是故障呢？是发现一次问题就切换还是多察看一会再切换？切换后如果主机复原了是切换回来还是主动变备机呢？需不需要人工二次确认一下？

这些问题可能都得依据业务的个性来得出答案，此处仅给出三种常见的双机切换模式：

最初一种双机架构是 主主复制，和后面两种只有一主的策略不同，这次两台都是主机，客户端的申请能够达到任何一台主机，不存在切换主机的问题。但这对数据的设计就有了严格的要求，如果存在惟一 ID、严格的库存数量等数据，就无奈实用，这种策略适宜那些偏临时性、可失落、可笼罩的数据场景。

• 数据集群

采纳双机架构的前提是一台主机可能存储所有的业务数据并解决所有的业务申请，但机器的存储和解决能力是有下限的，在大数据场景下就须要多台服务器来形成 数据集群。

如果是因为解决能力达到瓶颈，此时能够减少从机帮主机分担压力，即一主多从，称为 数据集中集群。这种集群形式须要任务分配算法将申请扩散到不同机器下来，次要的问题在于数据须要复制到多台从机，数据的一致性保障会比一主一从更为简单。且当主机故障时，多台从机协商新主机的策略也会变得复杂。这里有开源的 zookeeper ZAB 算法能够间接参考。

如果是因为存储量级达到瓶颈，此时能够将数据扩散存储到不同服务器，每台服务器负责存储一部分数据，同时也备份一部分数据，称为 数据扩散集群。数据扩散集群同样须要做负载平衡，在数据分区的调配上，hadoop 采纳独立服务器负责数据分区的调配，ES 集群通过选举一台服务器来做数据分区的调配。除了负载平衡，还须要反对扩缩容，此外因为数据是扩散存储的，当局部服务器故障时，要可能将故障服务器的数据在其余服务器上复原，并把本来调配到故障服务器的数据调配到其余失常的服务器上，即分区容错性。

• 数据分区

数据集群能够在单台乃至多台服务器故障时仍然放弃业务可用，但如果因为天文级劫难导致整个集群都故障了（断网、火灾等），那整个服务就不可用了。面对这种状况，就须要基于不同地理位置做 数据分区。

做不同地理位置的数据分区，首先要依据业务个性制订分区规定，大多还是依照地理位置提供的服务去做数据分区，比方中国区次要存储中国用户的数据。

既然分区是为了防灾，那么一个分区必定不止存储本身的数据，还须要做数据备份。从数据备份的策略来说，次要有三种模式：

3.3 计算高可用

从存储高可用的思路能够看出，高可用次要是通过减少机器冗余来实现备份，对 计算高可用 来说也是如此。通过减少机器，分担服务器的压力，并在单机产生故障的时候将申请调配到其余机器来保障业务可用性。

因而计算高可用的复杂性也次要是在多机器下任务分配的问题，比方当工作降临（比方客户端申请到来）时，如何抉择执行工作的服务器？如果工作执行失败，如何重新分配呢？这里又能够回到前文说过的负载平衡相干的解法上。

计算服务器和存储服务器在多机器状况下的架构是相似的，也分为主备、主从和集群。

主备架构 下，备机仅仅用作冗余，平时不会接管到客户端申请，当主机故障时，备机才会降级为主机提供服务。备机分为冷备和温备。冷备是指备机只筹备好程序包和配置文件，但理论平时并不会启动零碎。温备是指备机的零碎是继续启动的，只是不对外提供服务，从而能够随时切换主机。

主从架构 下，从机也要执行工作，由工作分配器依照事后定义的规定将任务分配给主机和从机。相比起主备，主从能够施展肯定的从机性能，防止老本空费，但工作的调配就变得复杂一些。

集群架构 又分为对称集群和非对称集群。

对称集群 也叫负载平衡集群，其中所有的服务器都是同等对待的，工作会平衡地调配到每台服务器。此时能够采纳随机、轮询、Hash 等简略的分配机制，如果某台服务器故障，不再给它分配任务即可。

非对称集群 下不同的服务器有不同的角色，比方分为 master 和 slave。此时工作分配器须要有肯定的规定将任务分配给不同角色的服务器，还须要有选举策略来在 master 故障时抉择新的 master。这个选举策略的复杂度就丰俭由人了。

• 异地多活

讲存储高可用曾经说过数据分区，计算高可用也有相似的高可用保障思路，演绎来说，它们都能够依据须要做 异地多活，来进步整体的解决能力，并防备地区级的劫难。异地多活中的”异地“，就是指集群部署到不同的地理位置，“活”则强调集群是随时能提供服务的，不同于“备”还须要一个切换过程。

依照规模，异地多活能够分为同城异区、跨城异地和跨国异地。不言而喻，不同模式下可能应答的地区级故障是越来越高的，但同样的，间隔越远，通信老本与提早就越高，对通信通道可用性的挑战也越高。因而跨城异地曾经不适宜对数据一致性要求十分高的业务，而跨国异地往往是用来给不同国家的用户提供不同服务的。

因为异地多活须要破费很高的老本，极大地减少零碎复杂度，因而在设计异地多活架构时，能够不必强求为所有业务都做异地多活，能够优先为外围业务实现异地多活。尽量保障绝大部分用户的异地多活，对于没能保障的用户，通过挂布告、预先弥补、欠缺失败提醒等措施进行安抚、晋升体验。毕竟要做到 100% 可用性是不可能的，只能在能承受的老本下尽量迫近，所以当可用性达到肯定瓶颈后，弥补伎俩的老本或者更低。

在异地部署的状况下，数据肯定会冗余存储，物理上就无奈实现相对的实时同步，且间隔越远对数据一致性的挑战越大，尽管能够靠缩小间隔、搭建高速专用网络等形式来进步一致性，但也只是进步而已，因而大部分状况下，只需思考保障业务能承受范畴下的最终一致性即可。

在同步数据的时候，能够采纳多种形式，比方通过音讯队列同步、利用数据库自带的同步机制同步、通过换机房重试来解决同步提早问题、通过 session id 让同一数据的申请都到同一机房从而不必同步等。

可见，整个异地多活的设计步骤首先是对业务分级，挑选出外围业务做异地多活，而后对须要做异地多活的数据进行特征分析，思考数据量、唯一性、实时性要求、可失落性、可恢复性等，依据数据个性设计数据同步的计划。最初思考各种异常情况下的解决伎俩，比方多通道同步、日志记录复原、用户弥补等，此时能够借用前文所说的 FMEA 等办法进行剖析。

• 接口级故障

后面探讨的都是较为宏观的服务器、分区级的故障产生时该怎么办，实际上在平时的开发中，还应该防微杜渐，从接口粒度的角度，来防备和应对接口级的故障。应答的外围思路仍然是优先保障外围业务和绝大部分用户可用。

对于 接口级故障，有几个罕用的办法：限流、排队、降级、熔断。其中限流和排队属于事先防备的措施，而降级和熔断属于接口真的故障后的解决伎俩。

限流 的目标在于管制接口的访问量，防止被高频拜访冲垮。

从限流维度来说，能够基于申请限流，即限度某个指标下、某个时间段内的申请数量，阈值的定义须要基于压测和线上状况来逐渐调优。还能够基于资源限流，比方依据连接数、文件句柄、线程数等，这种维度更适宜非凡的业务。

实现限流罕用的有工夫窗算法和桶算法。

工夫窗算法 分为固定工夫窗和滑动工夫窗。

固定工夫窗 通过统计固定工夫周期内的量级来决定限流，但存在一个临界点的问题，如果在两个工夫窗的两头产生超大流量，而在两个工夫窗内都各自没有超出限度，就会呈现无奈被限流拦挡的接口故障。因而 滑动工夫窗 采纳了局部重叠的工夫统计周期来解决临界点问题。

桶算法分为漏桶和令牌桶。

漏桶算法 是将申请放入桶中，处理单元从桶里拿申请去进行解决，如果桶堆满了就抛弃掉新的申请，能够了解为桶上面有个漏斗将申请往处理单元流动，整个桶的容量是无限的。这种模式下流入的速率取决于申请的频率，当桶内有沉积的待处理申请时，流出速率是匀速的。漏桶算法实用于刹时高并发的场景（如秒杀），解决可能慢一点，但能够缓存局部申请不抛弃。

令牌桶算法 是在桶内放令牌，令牌数是无限的，新的申请须要先到桶里拿到令牌能力被解决，拿不到就会被抛弃。和漏桶匀速流出解决不同，令牌桶还能通过管制放令牌的速率来管制接管新申请的频率，对于突发流量，牢靠累计的令牌来解决，然而绝对的处理速度也会突增。令牌桶算法实用于管制第三方服务访问速度的场景，避免压垮上游。

除了限流，还有一种管制处理速度的办法就是 排队。当新申请到来后先退出队列，出队端通过固定速度出队解决申请，防止处理单元压力过大。队列也有长度限度，其机制和漏桶算法差不多。

如果真的事先防备真的被冲破了，接口很可能或曾经产生了故障，还能做什么呢？

一种伎俩是 熔断，即当处理量达到阈值，就被动停掉内部接口的拜访能力，这其实也是一种防范措施，对外的体现尽管是接口拜访故障，但零碎外部得以被爱护，不会引起更大的问题，待存量解决被消化完，或者内部申请削弱，或实现扩容后，再凋谢接口。熔断的设计次要是阈值，须要依照业务特点和统计数据制订。

当接口故障后（无论是被动还是被动断开），最好能提供 降级 策略。降级是丢车保帅，放弃一下非核心业务，保障外围业务可用，或者最低水平能提供故障布告，让用户不要重复尝试申请来减轻问题了。比起手动降级，更好的做法也是主动降级，须要具备检测和发现降级机会的机制。

04、可扩大架构模式

再回顾一遍互联网行业的清规戒律：只有变动才是不变的。在设计架构时，一开始就要抱着业务随时可能变动导致架构也要跟着变动的思维筹备去设计，差异只在于变动的快慢而已。因而在设计架构时肯定是要思考可扩展性的。

在思考怎么才是可扩大的时候，先想一想平时开发中什么状况下会感觉扩展性不好？大都是因为零碎宏大、耦合重大、牵一发而动全身。因而对可扩大架构设计来说，根本的思维就是 拆分。

拆分也有多种指导思想，如果面向业务流程来谈拆分，就是分层架构；如果面向零碎服务来谈拆分，就是 SOA、微服务架构；如果面向零碎性能来拆分，就是微内核架构。

• 分层架构

分层架构 是咱们最相熟的，因为互联网业务下，曾经很少有纯单机的服务，因而至多都是 C/S 架构、B/S 架构，也就是至多也分为了客户端 / 浏览器和后盾服务器这两层。如果进一步拆分，就会将后盾服务基于职责进行自顶向下的划分，比方分为接入层、应用层、逻辑层、畛域层等。

分层的目标当然是为了让各个档次间的服务缩小耦合，不便进行各自领域下的优化，因而须要保障各层级间的差别是足够清晰、边界足够显著的，否则当要减少新性能的时候就会不晓得该放到哪一层。各个层只解决本层逻辑，隔离关注点。

额定需注意的是一旦确定了分层，申请就必须层层传递，不能跳层，这是为了防止架构凌乱，减少保护和扩大的复杂度，比方为了不便间接跨层从接入层调用畛域层查问数据，当须要进行对立的逻辑解决时，就无奈切面解决所有申请了。

• SOA 架构

SOA 架构 更多呈现在传统企业中，其次要解决的问题是企业中 IT 建设反复且效率低下，各部门自行接入独立的 IT 零碎，彼此之间架构、协定都不同，为了让各个系统的服务可能协调工作，SOA 架构应运而生。

其有三个要害概念：服务、ESB 和松耦合。

服务是指各个业务性能，比方本来各部门本来的零碎提供的服务，可大可小。因为各服务之间无奈间接通信，因而须要 ESB，即企业服务总线进行对接，它将不同服务连贯在一起，屏蔽各个服务的不同接口标准，相似计算机中的总线。松耦合是指各个服务的依赖须要尽量少，否则某个服务降级后整个零碎无奈应用就麻烦了。

这里也能够看出，ESB 作为总线，为了对接各个服务，要解决各种不同的协定，其协定转换消耗了大量的性能，会成为整个零碎的瓶颈。

• 微服务

微服务 是近几年最耳熟能详的架构，其实它和 SOA 有一些相同之处，比方都是将各个服务拆分开来提供能力。然而和 SOA 也有一些实质的区别，微服务是没有 ESB 的，其通信协议是统一的，因而通信管道仅仅做音讯的传递，不理解内容和格局，也就没有 ESB 的问题。而且为了疾速交付、迭代，其服务的粒度会划分地更细，对自动化部署能力也就要求更高，否则部署老本太大，达不到轻量疾速的目标。

当然微服务尽管很火，但也不是解决所有问题的银弹，它也会有一些问题存在。如果服务划分的太细，那么相互之间的依赖关系就会变得特地简单，服务数量、接口量、部署量过多，团队的效率可能大降，如果没有自动化撑持，交付效率会很低。因为调用链太长（多个服务），因而性能也会降落，问题定位会更艰难，如果没有服务治理的能力，治理起来会很凌乱，不晓得每个服务的状况如何。

因而如何拆分服务就成了每个应用微服务架构的团队的重要考量点。这里也提供一些拆分的思路：

微服务架构如果没有欠缺的基础设施保障服务治理，那么也会带来很多问题，升高效率，因而依据团队和业务的规模，能够按以下优先级进行基础设施的反对：

• 微内核架构

最初说说 微内核架构，也叫插件化架构，顾名思义，是面向性能拆分的，通常蕴含外围零碎和插件模块。在微内核架构中，外围零碎须要反对插件的治理和链接，即如何加载插件，何时加载插件，插件如何新增和操作，插件如何和外围引擎通信等。

举一个最常见的微内核架构的例子——规定引擎，在这个架构中，引擎是内核，负责解析规定，并将输出通过规定解决后失去输入。而各种规定则是插件，通常依据各种业务场景进行配置，存储到数据库中。

05、总结

人们通常把某项互联网业务的倒退分为四个期间：初创期、发展期、竞争期和成熟期。

在初创期通常求快，零碎能买就买，能用开源就用开源，能用的就是好的，先要活下来；到了发展期开始堆性能和优化，要求能疾速实现需求，并有余力对一些零碎的问题进行优化，当优化到顶的时候就须要从架构层面来拆分优化了；进入竞争期后，通过发展期的疾速迭代，可能会存在很多反复造轮子和凌乱的交互，此时就须要通过平台化、服务化来解决一些公共的问题；最初达到成熟期后，次要在于补齐短板，优化弱项，保障系统的稳固。

在整个倒退的过程中，同一个性能的前后要求也是不同的，随着用户规模的减少，性能会越来越难保障，可用性问题的影响也会越来越大，因而复杂度就来了。

对于架构师来说，首要的工作是从以后零碎的一大堆纷繁复杂的问题中辨认出真正要通过架构重构来解决的问题，集中力量疾速冲破，但整体来说，要徐徐图之，不要想着用重构来一次性解决所有问题。

对我的项目中的问题做好分类，划分优先级，先易后难，才更容易通过较少的资源占用，较快地失去成绩，进步士气。而后再循序渐进，每个阶段管制在 1~3 个月，稳步推动。

当然，在这个过程中，免不了和上下游团队沟通合作，须要留神的是本人的指标和其余团队的指标可能是不同的，须要对重构的价值进行换位思考，让单方都能够单干共赢，能力借力后退。

还是回到结尾的那句话，架构设计的次要目标是为了解决软件系统复杂度带来的问题。首先找到主要矛盾在哪，做到对症下药，而后再联合常识、教训进行设计，去解决背后的问题。

祝各位开发者都成为一名合格的架构师。以上便是本次分享的全部内容，如果感觉内容有用，欢送转发分享。

-End-

原创作者|Cloudox

你有什么架构设计的教训？你认为架构的要害设计准则是什么？欢送在腾讯云开发者公众号评论区分享。咱们将选取 1 则最有意义的分享，送出腾讯云开发者 - 鼠标垫 1 件（见下图）。7 月 10 日中午 12 点开奖。