Java架构师系统架构设计资源估算

---

想学习架构师构建流程请跳转：Java架构师系统架构设计

1 认识资源估算

首先，我们需要明确资源估算的概念。资源估算，顾名思义，是指为确保软件系统顺利运行并满足用户设定的目标，我们需要估计所需的各类资源。这些资源包括但不限于服务器资源、存储资源以及网络带宽等。简单来说，资源估算的目的是计算为确保软件系统正常运行所需的外部资源数量。

通常，资源估算需要针对几种不同的情况进行估算。首先，我们需要估算正常运行情况下的资源需求。这意味着，我们需要了解用户的预期，包括预期的用户数量、数据量以及性能指标。例如，系统上线后，我们需要确保系统在正常运行时能达到用户提出的基本要求。

其次，我们需要估算高峰使用情况下的资源需求。这意味着我们需要预估系统可能面临的最大负载情况，比如每天的某个高峰时段，如九点到十点。在这种情况下，我们需要确保系统能够应对这种高峰使用情况，而不会出现性能下降或崩溃等问题。因此，我们需要估算为支持高峰使用情况所需的额外资源。

综上所述，资源估算的主要目的是确保软件系统能够正常运行并满足用户设定的目标，无论是正常运行情况还是高峰使用情况。因此，资源估算对于成功交付一个稳定、高效的软件系统至关重要。

1.1 预估未来发展

在进行资源估算时，我们需要根据用户提供的信息，特别是他们对于未来业务发展的规划。用户可能会预计未来三年或五年后，他们的业务将达到多大的规模，我们的软件系统需要支持相应的规模。因此，一般来说，我们需要估算未来一到三年的情况。例如，我们在设计和构建系统时，需要基于未来一到三年的发展情况来进行规划和资源分配。

然而，我们也要注意，长时间的预估并没有太大意义，因为业务变化可能非常快。因此，在进行资源预估时，我们通常将时间范围设定在三年左右就足够了。当然，如果业务是可控且稳步增长的，我们可以考虑预估未来五年的资源需求情况。这就是资源估算的基本概念。

1.2 资源估算的意义

资源估算在软件部署方案中扮演着至关重要的角色。在进行资源估算的过程中，我们需要对软件系统进行全面的分析和评估，了解其所需的服务器、带宽、CPU和内存等资源，以及需要部署哪些服务和组件。这将直接影响到我们的部署方案设计，包括服务器的数量、类型和配置等。

此外，资源估算对于软件架构设计也有着重大影响。架构设计需要满足用户的高性能、高可用性、高安全性、高并发等需求，而资源估算正是为了找出满足这些需求所需的系统资源。如果实际资源与架构设计所需的资源不符，我们可能需要调整架构设计或业务处理算法以适应有限的资源环境，确保系统能够在给定的资源条件下达成用户的目标。例如，如果估算结果显示某个表的数据增长迅速，我们可能需要考虑对其进行分库分表，并调整业务实现以支持这一变化。

2 资源估算方法

2.1 确定系统目标

确定系统目标是资源估算的第一步，这个步骤主要是明确未来系统所需要的资源。为了估算未来系统所需要的资源，我们首先得确定一些系统目标，包括：

1. 每日使用系统的人数：这个人数是用来估算系统负载的重要指标，也是估算服务器资源需求的重要依据。
2. 访问页面的数量（PV）：了解用户访问页面的数量可以帮助我们估算系统的负载量，以及系统的数据流量。
3. 数据量的大小：估算用户访问带来的数据量，可以帮助我们了解未来系统存储的需求，以及数据传输的需求。
4. 网络访问次数：了解用户访问系统的次数，可以帮助我们估算系统的网络负载，以及服务器的负载。

以上这些目标是我们进行资源估算时需要考虑的一些主要因素，当然还有其他一些因素也需要考虑，比如系统要求能够支撑的在线人数、并发数、响应时间等等。这些因素都是我们进行资源估算时需要考虑的系统目标。

2.2 并发用户数

在资源估算中，并发用户数是评估系统性能的重要指标之一。一般来说，一比十是一个合理的比例，即如果有十个人使用系统，那么就有一个并发用户。当然，这个比例并不是绝对的，具体情况还要根据使用系统的实际情况来定。

除了并发用户数之外，还需要考虑其他因素，比如每日使用系统的人数、访问页面的数量、数据量的大小、网络访问次数等等。这些因素都是进行资源估算时需要考虑的因素，它们可以帮助我们估算未来系统所需要的资源。

在进行资源估算时，需要注意的是，这些估算值只是大致的估计，具体情况还需要根据系统的实际运行情况进行调整。因此，我们需要在系统上线后进行实际测量和调整，以保障系统的稳定性和性能。

2.3 指标数据

继续讨论资源估算的问题。在前面的课程中，我们讲到了资源估算的重要性，以及如何确定系统目标。今天，我们将继续探讨如何根据系统目标推算所需的资源。

在进行资源估算时，首先要明确一点：估算的目标是在正常情况和高峰期下的系统目标数据，以及未来一定时间内的这些数据。在进行估算时，我们通常需要考虑以下因素：每日使用系统的人数、访问页面的数量（PV）、数据量的大小以及网络访问次数等。

这些数据是我们进行资源估算的主要依据。通过这些数据，我们可以估算服务器的负载、网络带宽、存储需求等资源需求。需要注意的是，这些估算值只是大致的估计，具体情况还需要根据系统的实际运行情况进行调整。

在进行资源估算时，我们需要考虑不同资源估算的方法。例如，我们需要估算服务器的数量、CPU 核心数、内存大小、存储容量以及网络带宽等。这些估算的方法需要针对具体的系统目标和架构设计来确定。

我们以估算服务器的数量为例，来说明如何根据系统目标推算所需的资源。假设我们的系统目标是一百万并发用户数量和两秒的响应时间。我们可以通过以下步骤来推算所需的服务器数量：

确定每个服务器可以处理的并发用户数量。这需要考虑服务器的性能、操作系统和应用程序等因素。一般来说，每个服务器可以处理几千到几万个并发用户。
根据并发用户数量和每个服务器的处理能力，计算所需的服务器数量。例如，如果我们要求能够处理一百万并发用户，每个服务器可以处理5000个并发用户，那么需要的服务器数量就是2000个。
考虑到未来扩展的需要，我们需要增加一些服务器的储备。一般建议将服务器数量的20% 作为储备，以确保系统的可伸缩性。
需要注意的是，服务器数量并不是唯一的资源需求。我们还需要考虑其他资源的需求，例如CPU 核心数、内存大小、存储容量以及网络带宽等。这些资源的估算方法与服务器数量的估算方法类似，需要根据系统目标、应用程序的性能要求以及架构设计来确定。

最后，我们需要注意一点：资源估算并不是一次性的任务。在实际应用中，我们需要不断地对系统进行性能测试和调整，以确保系统的性能和稳定性。因此，在资源估算的过程中，我们需要不断地积累经验和数据，以便更好地进行估算和优化。

3 资源估算的经验法则

首先是“DID”经验法则，它包括以下三个方面：

D1：设计（Design）
在进行架构设计时，我们要考虑的是按照基准容量的二十倍进行设计。基准容量通常根据现有用户的行为和需求来确定。如果当前没有相关的业务运行，我们可以参考类似业务或行业的数据预估一个基准容量。

I2：实施（Implement）
在实施阶段，我们将按照基准容量的三倍来进行开发和实施。这意味着，虽然我们在设计时考虑了二十倍的容量，但在实际开发和实施时，我们只需满足三倍的容量需求。

D3：部署（Deploy）
部署阶段，我们将按照基准容量的1.5倍来部署系统。也就是说，在我们完成开发并将系统部署到生产环境后，我们将按照1.5倍的基准容量来运行系统。

这个经验法则告诉我们，在设计和实施阶段，我们应该分别考虑和处理未来可能出现的二十倍和三倍于基准容量的需求。而在部署阶段，我们只需按照1.5倍的基准容量来运行，这样既能避免资源的浪费，又能保证系统在未来一段时间内能够应对可能出现的增长需求。也就是说，我们的系统具有良好的伸缩性，通过增加资源和服务的手段，我们可以使系统最终支撑到二十倍的容量。

这就是“DID”经验法则，它为我们进行资源估算和系统设计提供了重要的指导。希望大家能够运用这个法则，更好地估算和设计自己的系统。

4 资源估算的常见参考数据

我们探讨了资源估算的不同方法和简单的示例，以帮助大家理解如何进行资源估算。在估算过程中，我们需要依赖许多数据来支持我们的估算。这里，我将介绍一些常见的参考数据。

在考虑参考数据之前，我们要强调一点：资源估算所需的这些数据最好是在系统实际运行的环境中进行实际测量。这并不意味着要在系统开发完成后才进行实测和资源估算，而是指在相同的条件下进行测量。例如，如果你的系统未来将部署到某个云环境中，最好现在就在相同的云环境中使用类似的服务器进行测试，以了解实际情况。通过这种方式，我们可以更准确地估算所需的资源。这一点非常重要，请大家务必注意。

4.1 带宽估算

供应商提供的带宽通常以比特（bit）为单位进行计算，因此需要将其除以八才能得到我们通常使用的字节（Byte）大小。例如，如果供应商提供的是10兆比特（Mbit）的带宽，实际上按照我们理解的字节大小，它只有1.25兆字节（MByte）。这一点需要注意，因为这可能会对您的计算产生影响。

第二个需要注意的参考数据是网络延迟时间。网络延迟通常在30到100毫秒之间，我们在测试时可能会发现它大约为50毫秒。但请注意，这些数值可能会因您的实际环境而有所不同。如果您没有进行实际的测试，您可以使用这些经验值来进行估算。但是这样可能会导致较大的偏差。

了解网络延迟时间的原因是，在进行性能评估时，我们需要将网络延迟时间考虑在内。

第三个需要注意的参考数据是网络传输速度。一般来说，网络传输一兆的数据大约需要1到10毫秒的时间。我们在测试时可能会发现它大约为2到5毫秒。这个数值指的是没有进行特殊的压缩或解压的数据传输时间，是正常的数据传输时间。

4.2 nginx估算

官方宣称每秒能支持十万以上的并发请求，但实际测试结果大多在五到八万之间，硬件较差的服务器可能只能达到五六万。因此，并发请求的数量受到硬件的影响较大，尤其是CPU和内存的性能。在硬件环境较好的情况下，可能能够测试到七八万并发请求，但要达到十万以上比较困难。

4.3 tomcat估算

因为Tomcat 9目前仍然被广泛使用，所以我们用它来说明一些经验测试数据。一般来说，Tomcat 9的最大连接数通常在2000到3000之间，最大的线程数则在300到500之间。在内存配置方面，一般建议为2到4个G，但这些数值也会受到硬件限制和应用需求的影响。因此，针对不同的应用场景，我们需要进行实际的测试和测算，以获得更准确的数据。

4.4 操作系统估算

对于进程中的线程数量存在一定的限制。在Windows操作系统中，每个进程的线程数通常不允许超过2000个；而在Linux操作系统中，每个进程的线程数不允许超过1000个。这些限制因素大家也需要了解，在进行资源估算时不要超过这些数值。

4.5 redis估算

单个默认最大连接数是1万个。从远程Redis读取一个数据大致需要0.5ms，尽管时间较短，但仍存在时间成本。对于并发处理能力来说，一般可达到5万以上。如果每次传输的数据比较小，所需时间可能达到8~10ms。至于在你的服务器上Redis能够达到什么样的性能，还需要大家自行进行测试。

4.6 mysql估算

单个最大连接数一般设置在4000到8000之间，每秒读写大概在几千到几十万条不等。这种差异较大的原因主要受到硬件、已有数据量的大小、单条数据大小是否批处理、批处理的大小以及是否有索引和MySQL优化等多种因素的影响。如果没有使用批处理，那么每秒的读写可能在几千左右；而如果采用批处理方式，可能达到几万条。因此，为了得到更准确的结果，建议大家在实际环境中进行测试，以获取用于资源估算的基准数据，这样进行的资源估算才会相对准确。

5 并发人数估算

5.1 请求量

在进行具体的并发人数估算之前，我们需要统一两个重要的认识。第一个认识是，大家要理解资源估算需要进行全链路计算。

那么，什么是全链路计算呢？在这里稍微给大家介绍一下。全链路计算指的是从请求或数据进入系统开始，在系统里面流转并进行处理，最后返回结果的整个链条中所涉及到的所有方面都要进行计算。换句话说，全链路计算需要考虑整个系统处理请求的每一个环节，包括但不限于入口、处理逻辑、存储、网络等等。因此，在资源估算中，我们需要对每个环节进行分析和计算，以确保系统的整体性能和稳定性。

在进行全链路计算时，我们需要关注每个环节的性能瓶颈和瓶颈出现的位置，并且针对瓶颈进行优化和调整。例如，如果数据库成为了瓶颈，我们可能需要增加数据库的读写能力；如果网络成为了瓶颈，我们可能需要优化网络结构或者采用更高效的通信协议。

5.2 数据量

在进行并发人数估算之前，我们需要先了解全链路计算的概念。全链路计算指的是从请求或数据进入系统开始，在系统里面流转并进行处理，最后返回结果的整个链条中所涉及到的所有方面都要进行计算。
在进行资源估算的时候，我们需要估算需要多少资源才能应对这么大量的请求和数据，以及现有的资源能否扛住这些请求和数据。因此，我们需要考虑每个环节的性能瓶颈和瓶颈出现的位置，并且针对瓶颈进行优化和调整。
在进行全链路计算时，需要考虑以下方面：

1. 请求量：需要考虑每秒进入系统的请求数量，以及这些请求对系统的影响。
2. 数据量：需要考虑每秒进入系统的数据量，以及这些数据对系统的影响。
3. 硬件资源：需要考虑硬件资源的数量和性能，例如CPU、内存、磁盘、网络等。
4. 软件优化：需要考虑软件优化对系统性能的影响，例如缓存、压缩、索引、MySQL优化等。
   在进行并发人数估算时，需要考虑以下因素：
5. 硬件资源：需要考虑服务器的硬件配置，例如CPU、内存、磁盘、网络等。
6. 软件优化：需要考虑软件优化对系统性能的影响，例如缓存、压缩、索引、MySQL优化等。
7. 网络环境：需要考虑网络环境对系统性能的影响，例如网络延迟、带宽等。
8. 数据结构：需要考虑数据结构对系统性能的影响，例如数据大小、数据类型等。
9. 请求类型：需要考虑请求类型对系统性能的影响，例如HTTP请求类型、请求大小等。

本地网卡有瓶颈以后我们的系统会部署到云端，那到了云端我还需要担心这个问题吗？大家注意一下，在云端你不需要去担心，因为在云端这个服务器上，他们用的网卡可能是高性能的网卡，或者说是光纤网卡，它们的速度都会非常的快。甚至一些大型的网络设备，它们的每秒交互的数据量可以达到几百G甚至上T。所以说呢，如果我们把系统部署到云端，那我们不用去考虑这个局网内的带宽限制问题。

比如说你使用的二十台阿里云的服务器，那么这二十台你在阿里云里面呢，可以去组建自己的一个专有的小局域网。那这个小局域网内的网卡的流量呢，我们可以认为它是足够的，不用担心这个问题。这就是第一的一个全链路计算。

资源估算会多次进行，也就是说不是一次就能够估算到位的。现在做资源估算，是因为我们现在什么都没有，你用什么技术啊？做成什么样啊？咱啥都不知道。我们现在做这个资源估算的目的就是为了接下来的技术选型，还有做整体的技术架构去使用的。所以说我们现在的这个估算是比较笼统的，不够准确的。

6 lvs和nginx的计算

那这是咱们前面资源估算呢记录下来的一些数据啊，大家可以看一下，我们已经算到数据量了，也就是说呢读写量我们已经算完了。接下来呢咱们就应该去开始计算这个服务数了，30万每秒读请求和3万写请求。

6.1 LVS估算

计算LVS时，如果你选择的是自建负载均衡服务，那么我们就不需要关注LVS本身了。反之，如果你选择的是云服务提供商的负载均衡，我们就需要计算所需的LVS数量。每个LVS处理请求的能力是极其强大的，所以我们只需要根据请求的数量来决定LVS的数量。一个LVS支撑百万级的流量都可以做得到。

那么它的后面呢是nginx，nginx可支撑不了三十万每秒。咱们前面也说过了，nginx呢它号称是每秒十万以上，但实际上啊咱们也就是做个五六万的样子。

6.2 Nginx估算

Nginx作为反向代理服务器，能够处理的请求量也是有限的。一般来说，一个Nginx实例可以处理每秒数万的请求，这是基于它本身的性能和网络带宽的限制。

在考虑实际应用场景时，我们还要考虑后端处理的速度。也就是说，Nginx将请求发送给后端处理，如果后端处理不及时，Nginx也无法及时响应前端请求。所以我们要根据前端请求量、后端处理能力以及网络带宽等多个因素来决定Nginx的数量。

进行估算时，我们可以根据一个Nginx实例能够处理的请求量来计算所需的Nginx数量。但需要注意的是，为了确保高可用性，我们通常不会只使用一个Nginx实例，而是使用多个实例来避免单点故障。

7 tomcat的数量估算

在先前我们已经对LVS和Nginx进行了估算，现在我们将进入更复杂的计算，特别是关于Tomcat数量的决定。为了方便我们的计算，我们需要先设定一些硬件环境标准。让我们以一个8核、32GB内存 500GB机械硬盘的配置为例来进行讨论。这个配置其实相对较低，可以作为服务器的一个基础标准。我们将以此为基础来进行接下来的计算。

7.1 读的方面计算

好的，接下来我们来讨论读请求的处理。现在的读请求量是三十万每秒。我们要思考一下，需要多少个Tomcat才能支撑这个读请求量。当然，这里暂时不涉及具体的应用，我们仅考虑Tomcat作为外部容器，应用就部署在其中。

为了进行计算，我们需要先做一些假设。首先，假设一个Tomcat处理一个读请求的时间大致在几毫秒到几十毫秒之间。这里我们取一个中位数，比如四十毫秒来计算。另外，我们还要确定Tomcat内部的线程数。假设每个Tomcat拥有三百个线程。

为什么要假设这个线程数呢？因为Tomcat在处理请求时，会为每个请求生成一个线程进行处理。如果线程数不足，Tomcat将无法处理请求。因此，我们在这里需要假定一个线程数量，以便进行计算。我们就按照三百个线程来计算。

此时，一个Tomcat每秒能处理的请求数就可以计算出来了。具体计算方法是：三百个线程乘以一千再除以四十。这就是理论上一个Tomcat每秒能处理的请求数。然后，按照之前提到的70%原则，我们再乘以0.7。经过计算，大约每个Tomcat每秒能够处理五千个请求。

根据总的读请求量三十万除以五千，我们大约需要六十个Tomcat。这里需要强调的是，这只是理论计算结果，实际应用中还需要考虑其他因素，如集群、冗余和高可用等情况。

因此，我们在考虑这些因素的情况下，预计需要大约六十个Tomcat来支撑当前的读请求量。

7.2 写的方面计算

好的，接下来我们再计算一下写请求的处理。在写的方面，请求量约为三万每秒。

同样地，我们需要假设一个Tomcat处理一个写请求的时间，这个时间肯定比四十毫秒要长。我们假设处理一个写请求的时间为一百毫秒（这个时间可能因为处理复杂的业务逻辑而稍长）。

我们还是假定每个Tomcat有三百个线程。那么，每个Tomcat每秒能处理的请求数就是这三百个线程乘以一千再除以一百，然后乘以0.7，得出的结果大约是两千个。

我们取整为两千个请求每秒。那么三万每秒的写请求量需要多少个Tomcat来处理呢？答案大约是十五个Tomcat。同样地，这里我们还没有考虑集群、故障备用等其他因素。

因此，为了处理三十万的读请求和三万的写请求，我们大约需要七十五个Tomcat服务。如果还要考虑冗余和其他故障处理等因素，我们应该申请八十到八十五个Tomcat服务，并至少预留十个以备不时之需。

所以，总的Tomcat服务数应该是申请八十到八十五个。

8 数据库的估算

当然，除了数据库之外，还有很多其他的第三方框架和资源我们在应用中会使用到。

例如，Redis、Kafka、ElasticSearch等等。

不过，由于我们目前还没有确定具体的技术体系，这里我们就以数据库估算为例进行示范。

当然，等到我们确定了技术体系之后，在后续进行部署设计的时候，我们再去估算其他的外部资源。

8.1 mysql估算

在电商行业中，数据库通常以MySQL为主，因此我们以它为例进行计算。对于MySQL的计算，主要有以下几个方面：

首先，我们需要考虑数据量。这个数据量主要是指数据条数，也就是表中记录的数量。

其次，我们需要考虑存储量。上面的数据量主要是指数据的大小。

除了这两个方面，还有很多其他的因素需要考虑，比如读写的速度和连接数等等。但是今天我们先暂时不讨论这些因素。

大家可能会发现，这个存储量我们好像已经算过了。确实，我们在前面计算读写量的时候，已经计算过了数据量。大家看一下，我们在前面计算读写速度时，已经计算过了存储量。

8.1.1 数据量计算

根据估算，假设每天产生一千万单，每单产生十条新增数据，那么每天大约产生一亿的新增数据。如果单表不超过一千万，那么半年就要保留一千万的数据量，需要大约六万的数据条数来平摊每天的数据量。因此，每天产生的数据量不能超过六万条。
如果按照一千万的数据量来计算，需要大约一千七百个单表才能放下这些数据。可以将这些单表分散到十个数据库中，每个数据库放十个表。如果要进一步减少数据库的数量，可以将一个库中的表数增加到十个，将一百七十个数据库减少到十七个。每个数据库集群的数据容量大约为十五亿条，对于一个MySQL集群来说是可以接受的。因此，最终的设计是三十六个数据库集群，每个集群的数据容量为五亿条。

8.1.1 读写速度计算

如何评估数据库的读写速度。其中，特别关注了随机写入和事务处理的影响。根据经验，对于MySQL来说，这种随机写入没有批处理的情况下，通常最好的机器配置也只能达到1-2万条每秒。然后，通过计算，我们知道我们的写入需求是每秒3万单，每单产生10条新增数据，所以总共的需求是30万条每秒。显然，这是一个非常高的写入负载，单个数据库无法承受。

因此，我们需要进行分库分表。通过计算，如果我们每个数据库集群可以承受2万条每秒，那么我们需要的数据库集群数量就是30万/2万=15个。如果我们选择每秒1万的写入速度，那么需要的数据库集群数量就是30万/1万=30个。

在考虑读写速度时，我们应该更关注写入速度，因为读操作通常会通过缓存等技术来提高性能。因此，我们取15或30作为数据库集群的数量可以满足我们的需求。

9 总结

首先，确定系统的目标可以帮助我们明确系统的规模和复杂性，以及需要满足的性能指标，例如响应时间、吞吐量、可扩展性等。这些目标会影响到我们在后续步骤中所需要的技术和资源。

接着，根据系统的目标来推算需要的资源，这包括服务器、存储、网络等方面的资源。在推算过程中，我们需要使用一些经过服务端测试得到的基本性能指标，例如每秒事务数、每秒查询数等，这些指标可以帮助我们评估系统所需的资源数量。

同时，在进行资源估算时，还需要考虑到需要部署的数量。这些数据会影响到我们后续的架构设计，例如需要设计多少个节点、每个节点的负载情况等。

总之，系统架构设计和资源估算是一个相互关联的过程，需要综合考虑系统的目标和所需的资源，以设计出高效、可靠、可扩展的系统架构。