谈谈系统复杂度中的高可用与高性能

架构狂人

发布于 2023-08-16 13:42:30

4960

文章被收录于专栏：架构狂人架构狂人

今天，我们聊聊系统复杂度的高可用与高性能。

参考维基百科，先来看看高可用的定义。

系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。

这个定义的关键在于“ 无中断”，但恰好难点也在“无中断”上面，因为无论是单个硬件还是单个软件，都不可能做到无中断，硬件会出故障，软件会有bug；硬件会逐渐老化，软件会越来越复杂和庞大……

除了硬件和软件本质上无法做到“无中断”，外部环境导致的不可用更加不可避免、不受控制。例如，断电、水灾、地震，这些事故或者灾难也会导致系统不可用，而且影响程度更加严重，更加难以预测和规避。

高可用性是指系统在没有中断的情况下能够持续执行其功能的能力，是进行系统设计时的重要准则之一。然而，要实现无中断是非常困难的，因为单个硬件或软件都有可能出现故障或错误，且硬件随着时间的推移会逐渐老化，软件也会变得越来越复杂和庞大。此外，外部环境因素如断电、水灾、地震等灾难也可能导致系统不可用，而且其影响程度更加严重，更难以预测和规避。

因此，实现高可用性的方案是通过增加冗余性来提高系统的可用性。简单来说，就是增加更多的机器或部署多个机房来解决单点故障问题。这样做的目的是为了增强系统的冗余性，从而实现高可用性。需要注意的是，实现高性能和高可用性都需要增加机器，但它们的目的不同，前者是为了“扩展”处理性能，而后者是为了“冗余”处理单元。

虽然通过冗余增强了系统的可用性，但同时也带来了复杂性。因此，在实际应用中需要根据不同的场景逐一分析，采取不同的高可用方案。

计算高可用

在这里，“计算”指的是业务逻辑处理。与计算相关的高可用性的复杂性在于，无论在哪台机器上执行计算，只要算法和输入数据相同，计算结果就应该是相同的。因此，将计算从一台机器转移到另一台机器，对业务逻辑没有任何影响。

以最简单的单机变双机架构为例，我们可以看到以下几个方面的复杂性：先来看一个单机变双机的简单架构示意图。

你可能会发现，这个双机的架构图和上期“高性能”讲到的双机架构图是一样的，因此复杂度也是类似的，具体表现为：

需要增加任务分配器，选择合适的任务分配器也是一个复杂的过程，需要考虑各种因素，例如性能、成本、可维护性和可用性等等。
任务分配器与真正的业务服务器之间需要进行连接和交互。因此，需要选择合适的连接方式，并且对连接进行管理。例如，建立连接、检测连接、处理连接中断等等。
任务分配器需要增加分配算法。常见的双机算法有主备、主主，主备方案又可以细分为冷备、温备、热备等等。

上面这个示意图只是简单的双机架构，我们再看一个复杂一点的高可用集群架构。

上面这个示意图只是一个简单的双机架构，而复杂度会随着集群的规模和结构的变化而增加。例如，上图展示了一个更为复杂的高可用集群架构。这种情况下，分配算法的选择更加复杂，可以是1主3备、2主2备、3主1备、4主0备等等。具体应该采用哪种方式，需要根据实际业务需求进行分析和判断，不存在一种算法一定比其他算法更优。例如，ZooKeeper采用的是1主多备，而Memcached则采用全主0备。

存储高可用

对于需要存储数据的系统来说，整个系统的高可用设计的关键点和难点在于“存储高可用”。与计算相比，存储有一个本质的不同点：将数据从一台机器搬到另一台机器需要经过线路传输。线路传输的速度是毫秒级别，同一机房内部可以做到几毫秒，但分布在不同地方的机房，传输耗时需要几十甚至上百毫秒。例如，从广州机房到北京机房，稳定情况下ping延时大约是50ms，不稳定情况下可能达到1秒甚至更长。

虽然对人类来说，毫秒几乎没有什么感觉，但对于高可用系统来说，这是本质的不同之处。这意味着在某个时间点上，整个系统中的数据肯定是不一致的。按照“数据 + 逻辑 = 业务”这个公式来看，数据不一致即使逻辑一致，最终的业务表现也会不同。以银行储蓄业务为例，假设用户的数据存在北京机房，用户存入1万块钱，然后查询时被路由到了上海机房，而北京机房的数据没有同步到上海机房。用户会发现他的余额并没有增加1万块。想象一下，此时用户肯定会感到不安，会怀疑自己的钱被盗了，赶紧打客服电话投诉，甚至可能打110报警。即使最终发现只是因为传输延迟导致的问题，从用户的角度来看，这个过程的体验肯定很不好。

除了物理传输速度限制，传输线路本身也可能出现可用性问题。传输线路可能会中断、拥塞、异常（如错包、丢包），并且线路故障的恢复时间通常较长，可能持续几分钟甚至几小时。例如，2015年支付宝因为光缆被挖断，业务受到了超过4个小时的影响；2016年中美海底光缆中断3小时等。线路中断意味着存储无法同步，这段时间内整个系统的数据将不一致。

综合考虑，在正常情况下的传输延迟和异常情况下的传输中断都会导致系统在某个时间点或时间段内的数据不一致，从而影响业务。然而，如果完全不做冗余，整个系统的高可用性就无法保证。因此，存储高可用的难点不在于如何备份数据，而在于如何减少或规避数据不一致对业务造成的影响。

在分布式系统领域，有一个著名的CAP定理，从理论上证明了存储高可用的复杂度。也就是说，存储高可用不可能同时满足“一致性、可用性、分区容错性”，最多只能满足其中两个。因此，在架构设计时，需要根据实际业务需求进行取舍。

高可用状态决策

无论是计算高可用还是存储高可用，其基础都是“状态决策”，即系统需要能够判断当前的状态是正常还是异常，如果出现异常就需要采取行动来保证高可用。如果状态决策本身存在错误或偏差，那么后续的任何行动和处理都将失去意义和价值。然而，在具体实践中，存在一个本质的矛盾：通过冗余实现的高可用系统，状态决策本质上不可能做到完全正确。以下是对几种常见的决策方式的详细分析：

1.独裁式

独裁式决策指的是存在一个独立的决策主体，我们称之为“决策者”，其负责收集信息并做出决策。所有冗余的个体，我们称之为“上报者”，将状态信息发送给决策者。

独裁式的决策方式不会出现决策混乱的问题，因为只有一个决策者，但问题也正是在于只有一个决策者。当决策者本身故障时，整个系统就无法实现准确的状态决策。如果决策者本身又做一套状态决策，那就陷入一个递归的死循环了。

2.协商式

协商式决策指的是两个独立的个体通过交流信息，然后根据规则进行决策， 最常用的协商式决策就是主备决策。

这个架构的基本协商规则可以设计成：

2台服务器启动时都是备机。
2台服务器建立连接。
2台服务器交换状态信息。
某1台服务器做出决策，成为主机；另一台服务器继续保持备机身份。

协商式决策的架构不复杂，规则也不复杂，其难点在于，如果两者的信息交换出现问题（比如主备连接中断），此时状态决策应该怎么做。

如果备机在连接中断的情况下认为主机故障，那么备机需要升级为主机，但实际上此时主机并没有故障，那么系统就出现了两个主机，这与设计初衷（1主1备）是不符合的。

如果备机在连接中断的情况下不认为主机故障，则此时如果主机真的发生故障，那么系统就没有主机了，这同样与设计初衷（1主1备）是不符合的。

如果为了规避连接中断对状态决策带来的影响，可以增加更多的连接。例如，双连接、三连接。这样虽然能够降低连接中断对状态带来的影响（注意：只能降低，不能彻底解决），但同时又引入了这几条连接之间信息取舍的问题，即如果不同连接传递的信息不同，应该以哪个连接为准？实际上这也是一个无解的答案，无论以哪个连接为准，在特定场景下都可能存在问题。

综合分析，协商式状态决策在某些场景总是存在一些问题的。

3.民主式

民主式决策指的是多个独立的个体通过投票的方式来进行状态决策。例如，ZooKeeper集群在选举leader时就是采用这种方式。

民主式决策和协商式决策比较类似，其基础都是独立的个体之间交换信息，每个个体做出自己的决策，然后按照“ 多数取胜”的规则来确定最终的状态。不同点在于民主式决策比协商式决策要复杂得多，ZooKeeper的选举算法ZAB，绝大部分人都看得云里雾里，更不用说用代码来实现这套算法了。

除了算法复杂，民主式决策还有一个固有的缺陷：脑裂。这个词来源于医学，指人体左右大脑半球的连接被切断后，左右脑因为无法交换信息，导致各自做出决策，然后身体受到两个大脑分别控制，会做出各种奇怪的动作。例如：当一个脑裂患者更衣时，他有时会一只手将裤子拉起，另一只手却将裤子往下脱。脑裂的根本原因是，原来统一的集群因为连接中断，造成了两个独立分隔的子集群，每个子集群单独进行选举，于是选出了2个主机，相当于人体有两个大脑了。

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

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

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

高性能

紧接着是另外一个话题，系统的高性能。

对性能的不懈追求一直是人类科技持续发展的核心动力。例如计算机，从电子管计算机到晶体管计算机，再到集成电路计算机，运算性能从每秒几次提高到每秒几亿次。然而，随着性能的提升，相应的方法和系统复杂度也逐渐增加。现代计算机CPU集成了数亿颗晶体管，其逻辑复杂度和制造难度与最初的晶体管计算机相比，已经有了天壤之别。

软件系统也呈现出类似的现象。近几十年来，软件系统性能得到了飞速发展，从最初的计算机仅能进行简单科学计算，到如今Google能支撑每秒几万次的搜索。与此同时，软件系统规模从单台计算机扩展到上万台计算机；从最初的单用户单任务的字符界面DOS操作系统，发展到现在的多用户多任务的Windows 10图形操作系统。

当然，技术进步带来的性能提升，并不一定伴随着复杂度的增长。例如，硬件存储从纸带、磁带、磁盘发展到SSD，并未明显增加系统复杂度。这是因为新技术逐步淘汰旧技术，我们可以直接使用新技术，而无需担心系统复杂度的提升。只有那些不是用来取代旧技术，而是开拓全新领域的技术，才会给软件系统带来复杂性，因为软件系统在设计时需要在这些技术之间进行判断、选择或组合。就像汽车的发明不能取代火车，飞机的出现也不能完全替代火车，所以在我们出行时，需要权衡选择汽车、火车还是飞机，这个选择过程相对复杂，涉及价格、时间、速度、舒适度等诸多因素。

软件系统中性能提升带来的复杂度主要体现在两个方面：一方面是单台计算机内部为实现高性能所产生的复杂度；另一方面是多台计算机集群为实现高性能所引发的复杂度。

单机复杂度

计算机内部复杂度的关键在于操作系统。计算机性能的发展基本上是由硬件，尤其是CPU性能的发展所驱动的。著名的“摩尔定律”预测CPU处理能力每18个月翻一番；而充分发挥硬件性能的关键便是操作系统。因此，操作系统也是随着硬件的发展而发展的，作为软件系统的运行环境，操作系统的复杂度直接决定了软件系统的复杂度。

操作系统与性能最相关的便是进程和线程。最早的计算机实际上是没有操作系统的，仅具有输入、计算和输出功能。用户输入一个指令后，计算机完成操作。然而，大部分时间计算机都在等待用户输入指令，这种处理性能显然是低效的，因为人的输入速度远不及计算机的运算速度。

为解决手工操作带来的低效，批处理操作系统应运而生。简单来说，批处理是先将要执行的指令预先编写好（写到纸带、磁带、磁盘等），形成一个指令清单，即我们常说的“任务”。将任务交给计算机执行，批处理操作系统负责读取“任务”中的指令清单并进行处理。这样，计算机执行过程中无需等待人工操作，从而大大提高性能。

尽管批处理程序大大提升了处理性能，但它存在一个明显的缺点：计算机一次只能执行一个任务。如果某个任务需要从I/O设备（例如磁带）读取大量数据，在I/O操作过程中，CPU实际上是空闲的，而这段空闲时间本可以用于其他计算。

为进一步提升性能，人们发明了“进程”，将一个任务对应到一个进程，每个任务都有自己独立的内存空间，进程间互不相关，由操作系统进行调度。当时的CPU尚无多核和多线程概念，为实现多进程并行运行，采用了分时方式，即将CPU时间划分成许多片段，每个片段仅执行某个进程中的指令。尽管从操作系统和CPU角度看仍为串行处理，但由于CPU处理速度极快，用户感觉上是多进程并行处理。

多进程要求每个任务都有独立的内存空间，进程间互不相关，但从用户角度看，若两个任务在运行过程中能够通信，则任务设计会更加灵活高效。为解决这个问题，各种进程间通信方式应运而生，包括管道、消息队列、信号量、共享存储等。

多进程使多任务能够并行处理，但仍存在缺陷，单个进程内部仅能串行处理。实际上，许多进程内部的子任务并不要求严格按时间顺序执行，也需要并行处理。例如，一个餐馆管理进程，排位、点菜、买单、服务员调度等子任务必须并行处理，否则可能出现因某客人买单时间较长（如信用卡刷不出来）而导致其他客人无法点菜的情况。为解决这一问题，人们发明了线程，线程是进程内部的子任务，但这些子任务共享同一份进程数据。为保证数据的正确性，又发明了互斥锁机制。有了多线程后，操作系统调度的最小单位变成了线程，而进程则成为操作系统分配资源的最小单位。

尽管多进程多线程让多任务并行处理的性能大大提升，但本质上仍为分时系统，无法实现时间上真正的并行。解决这一问题的方法是让多个CPU同时执行计算任务，从而实现真正意义上的多任务并行。目前这样的解决方案有三种：SMP（对称多处理器结构）、NUMA（非一致存储访问结构）和MPP（海量并行处理结构）。其中，SMP是我们最常见的，当前流行的多核处理器即采用SMP方案。

如今的操作系统发展已经相当成熟，若要完成一个高性能的软件系统，需要考虑多进程、多线程、进程间通信、多线程并发等技术点。然而，这些技术并非最新的就是最好的，也不是非此即彼的选择。在进行架构设计时，需要投入大量精力来结合业务进行分析、判断、选择和组合，这一过程同样颇为复杂。举一个简单的例子：Nginx可以采用多进程或多线程，JBoss则采用多线程；Redis采用单进程，而Memcache则采用多线程，尽管这些系统都实现了高性能，但其内部实现却大相径庭。

集群的复杂度

尽管计算机硬件性能迅速发展，但与业务发展速度相比，仍显得力不从心，特别是进入互联网时代后，业务发展速度远超硬件发展速度。例如：

2016年“双11”支付宝每秒峰值达到12万笔支付。
2017年春节微信红包收发红包每秒达到76万个。

要支持如支付和红包等复杂业务，单机性能无论如何都无法支撑。因此，必须采用机器集群的方式来实现高性能。例如，支付宝和微信这类规模的业务系统，后台系统的机器数量均达到了万台级别。

通过大量机器提升性能，并非仅仅是增加机器那么简单。让多台机器协同完成高性能任务是一项复杂的任务。以下针对常见的几种方式进行简要分析：

1.任务分配

任务分配意味着每台机器都能处理完整的业务任务，将不同任务分配给不同机器执行。为实现有效的任务分配，负载均衡技术应运而生。负载均衡可以通过硬件或软件实现，其目标是将任务平均分配到各个机器上，确保系统资源得到充分利用，从而提高整体性能。

2.数据分片

数据分片是指将数据切分成多个部分，每个部分分配到一个或多个机器上。这种方式可以实现数据的水平扩展，提高数据处理能力。例如，数据库分片技术可以将一个大型数据库分割成多个小型数据库，每个小型数据库承担部分数据处理任务。

3.数据副本

为提高数据可靠性和可用性，可在多台机器上创建数据的副本。当一台机器出现故障时，其他具有数据副本的机器可以立即接管服务，确保业务不间断。数据副本技术在分布式存储系统中尤为重要，如分布式文件系统、分布式数据库等。

4.任务并行

任务并行是指将一个大任务分解成多个小任务，并在多台机器上同时执行。这种方式可以显著减少任务执行时间，提高处理能力。例如，MapReduce是一种著名的任务并行计算模型，可以将大数据处理任务分解成多个小任务，在集群中并行执行，最后将结果汇总输出。

总之，集群技术为应对业务需求提供了强大的支持，但实现高性能集群需要考虑任务分配、数据分片、数据副本、任务并行等多种技术，并根据具体业务需求进行合理选择和组合。随着云计算的普及，集群技术将更加成熟，未来亦可期待更多创新和发展。

我从最简单的一台服务器变两台服务器开始，来讲任务分配带来的复杂性，整体架构示意图如下。

从图中可以看到，1台服务器演变为2台服务器后，架构上明显要复杂多了，主要体现在：

需要增加一个任务分配器，这个分配器可能是硬件网络设备（例如，F5、交换机等），可能是软件网络设备（例如，LVS），也可能是负载均衡软件（例如，Nginx、HAProxy），还可能是自己开发的系统。选择合适的任务分配器也是一件复杂的事情，需要综合考虑性能、成本、可维护性、可用性等各方面的因素。
任务分配器和真正的业务服务器之间有连接和交互（即图中任务分配器到业务服务器的连接线），需要选择合适的连接方式，并且对连接进行管理。例如，连接建立、连接检测、连接中断后如何处理等。
任务分配器需要增加分配算法。例如，是采用轮询算法，还是按权重分配，又或者按照负载进行分配。如果按照服务器的负载进行分配，则业务服务器还要能够上报自己的状态给任务分配器。

这一大段描述，即使你可能还看不懂，但也应该感受到其中的复杂度了，更何况还要真正去实践和实现。

上面这个架构只是最简单地增加1台业务机器，我们假设单台业务服务器每秒能够处理5000次业务请求，那么这个架构理论上能够支撑10000次请求，实际上的性能一般按照8折计算，大约是8000次左右。

如果我们的性能要求继续提高，假设要求每秒提升到10万次，上面这个架构会出现什么问题呢？是不是将业务服务器增加到25台就可以了呢？显然不是，因为随着性能的增加，任务分配器本身又会成为性能瓶颈，当业务请求达到每秒10万次的时候，单台任务分配器也不够用了，任务分配器本身也需要扩展为多台机器，这时的架构又会演变成这个样子。

这个架构比2台业务服务器的架构要复杂，主要体现在：

任务分配器从1台变成了多台（对应图中的任务分配器1到任务分配器M），这个变化带来的复杂度就是需要将不同的用户分配到不同的任务分配器上（即图中的虚线“用户分配”部分），常见的方法包括DNS轮询、智能DNS、CDN（Content Delivery Network，内容分发网络）、GSLB设备（Global Server Load Balance，全局负载均衡）等。
任务分配器和业务服务器的连接从简单的“1对多”（1台任务分配器连接多台业务服务器）变成了“多对多”（多台任务分配器连接多台业务服务器）的网状结构。
机器数量从3台扩展到30台（一般任务分配器数量比业务服务器要少，这里我们假设业务服务器为25台，任务分配器为5台），状态管理、故障处理复杂度也大大增加。

上面这两个例子都是以业务处理为例，实际上“任务”涵盖的范围很广， 可以指完整的业务处理，也可以单指某个具体的任务。例如，“存储”“运算”“缓存”等都可以作为一项任务，因此存储系统、运算系统、缓存系统都可以按照任务分配的方式来搭建架构。此外，“任务分配器”也并不一定只能是物理上存在的机器或者一个独立运行的程序，也可以是嵌入在其他程序中的算法，例如Memcache的集群架构。

2.任务分解

通过任务分配的方式，我们能够突破单台机器处理性能的瓶颈，通过增加更多的机器来满足业务的性能需求，但如果业务本身也越来越复杂，单纯只通过任务分配的方式来扩展性能，收益会越来越低。例如，业务简单的时候1台机器扩展到10台机器，性能能够提升8倍（需要扣除机器群带来的部分性能损耗，因此无法达到理论上的10倍那么高），但如果业务越来越复杂，1台机器扩展到10台，性能可能只能提升5倍。造成这种现象的主要原因是业务越来越复杂，单台机器处理的性能会越来越低。为了能够继续提升性能，我们需要采取第二种方式：任务分解。

继续以上面“任务分配”中的架构为例，“业务服务器”如果越来越复杂，我们可以将其拆分为更多的组成部分，我以微信的后台架构为例。

通过上面的架构示意图可以看出，微信后台架构从逻辑上将各个子业务进行了拆分，包括：接入、注册登录、消息、LBS、摇一摇、漂流瓶、其他业务（聊天、视频、朋友圈等）。

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

主要有几方面的因素：

简单的系统更加容易做到高性能

系统的功能越简单，影响性能的点就越少，就更加容易进行有针对性的优化。而系统很复杂的情况下，首先是比较难以找到关键性能点，因为需要考虑和验证的点太多；其次是即使花费很大力气找到了，修改起来也不容易，因为可能将A关键性能点提升了，但却无意中将B点的性能降低了，整个系统的性能不但没有提升，还有可能会下降。

可以针对单个任务进行扩展

当各个逻辑任务分解到独立的子系统后，整个系统的性能瓶颈更加容易发现，而且发现后只需要针对有瓶颈的子系统进行性能优化或者提升，不需要改动整个系统，风险会小很多。以微信的后台架构为例，如果用户数增长太快，注册登录子系统性能出现瓶颈的时候，只需要优化登录注册子系统的性能（可以是代码优化，也可以简单粗暴地加机器），消息逻辑、LBS逻辑等其他子系统完全不需要改动。

既然将一个大一统的系统分解为多个子系统能够提升性能，那是不是划分得越细越好呢？例如，上面的微信后台目前是7个逻辑子系统，如果我们把这7个逻辑子系统再细分，划分为100个逻辑子系统，性能是不是会更高呢？

其实不然，这样做性能不仅不会提升，反而还会下降，最主要的原因是如果系统拆分得太细，为了完成某个业务，系统间的调用次数会呈指数级别上升，而系统间的调用通道目前都是通过网络传输的方式，性能远比系统内的函数调用要低得多。我以一个简单的图示来说明。

从图中可见，当系统拆分为2个子系统时，用户访问需要1次系统间请求和1次响应；当系统拆分为4个子系统时，系统间请求次数从1次增加到3次；若继续拆分为100个子系统，为完成某次用户访问，系统间请求次数将达到99次。

为简化描述，我们抽象出一个最简模型：假设这些系统通过IP网络连接，在理想情况下，一次请求和响应在网络上耗时为1ms，业务处理本身耗时为50ms。我们还假设系统拆分对单个业务请求性能没有影响。因此，当系统拆分为2个子系统时，处理一次用户访问耗时为51ms；而系统拆分为100个子系统时，处理一次用户访问耗时竟然达到了149ms。

尽管在一定程度上，系统拆分有助于提升业务处理性能，但性能提升是有限的。当系统未拆分时，业务处理耗时为50ms，系统拆分后业务处理耗时不可能仅为1ms。因为业务处理性能仍然受限于业务逻辑本身，而在业务逻辑没有发生重大变化的情况下，理论上性能具有一个上限。系统拆分可以让性能接近这一极限，但无法突破它。因此，任务分解所带来的性能收益具有一定的度，任务分解不是越细越好。对于架构设计而言，如何把握这一粒度便显得至关重要。