1.3 考虑可行的解决方案

把项目需求的所有疑点都澄清后，就可以开始构建详细而具体的需求说明了；这份说明要把早前收集到的相关信息都涵盖进来。假如我们刚才提出的问题都得到了客户的答复，那么就可以像下面这样编写更为详细的需求说明：

客户要求为公司的财务应用程序创建新的Web服务器，该服务器每秒至少要支持10000次访问，这些访问来自大约2000名用户，该服务器所提供的数据会由另外3个应用程序使用。这套解决方案要采用至少4个节点来打造高度可用的服务，以便在维护与停机时段依然能够运作。我们首次实现该项目时，共有20000美元预算可以动用，由于客户要求降低预付成本，因此打算利用OSS来实现。这套解决方案会部署在客户已有的虚拟机环境中，该环境由客户公司内部的Linux团队提供支持，其更新工作由客户公司自己的更新管理方案负责处理。大约每两个月会增加一批新用户，客户公司的采购流程已经考虑到了这一点，因此，可以相当迅速地添置新资源，而不会让资源紧缺的局面持续太久。用户数量增加之后，主要问题就在于计算资源必须跟上。

大家可以看到，这份需求说明要比早前那封邮件更加详细。于是，我们可以从这些需求出发进行项目设计。现在可以确定该项目要部署在客户已有的虚拟基础设施上，而且我们已经获准使用OSS来建设这个项目。该项目必须具备高可用性，由于它的更新工作由客户现有的更新与版本控制设施负责，因此，我们需要做的可能仅是给解决方案安设一些监控代理（monitoring agent）。

图1-3简单地概括了我们可能会采用的设计方案，并没有展示出太多的细节：

图1-3

从图1-3可以看到，我们的方案要通过一个Web服务器集群向客户端以及使用本方案的应用程序提供高度可用的服务，并确保负载均衡。

由于方案中的很多地方用客户方已有的基础设施，因此，POC的可选之处并不多，整套方案的实现过程将会相当直接。虽说如此，依然有一些变数能够引出几种不同的选项，我们可以把这些选项交给客户去选择。例如，Web服务器就可以有3种做法，一种是纯用Apache实现，另一种是纯用NGINX实现，还有一种是用Apache托管网站，并通过NGINX实现负载均衡。

POC

我们已经完整地陈述了项目需求，并把可以做出选择的地方呈现给了客户，接下来对其中的某一套具体做法进行概念验证。

POC（概念验证）是对某个想法或做法进行演示的过程，该过程旨在验证某项特定的功能。对于本书来说指的是一套具体的解决方案。此外，POC还能让我们全面了解受测方案在某种情境中的行为，针对特定的负载情况或用途，对其展开深入测试或微调。

无论对什么样的方案做POC，我们都可以同时看到该方案的好处与坏处；然而对于客户及架构师来说，关注的重点是受测方案中的各种理念能否在实际的环境下运作。在接受POC的诸多方案中，哪一个能够成为最终方案，很大程度上受到架构师的影响。不过，在对这些所施加的限制以及带来的好处进行权衡时，客户通常更了解它们对公司业务的影响。

现在假设用Apache服务器来托管应用程序的相关文件，并用一台NGINX服务器实现负载均衡，以提升Apache服务器的性能，并确保它们高度可用。为了验证该方案，我们可以先用少量的资源，打造一个微缩版的样品。也就是说，我们不用像最终方案要求的采用4个节点，而是只需要部署2个节点，就可以演示该方案的负载均衡效果，同时还可以让其中一个节点下线，以判断此方案是否具备高度的可用性。

图1-4描述了微缩版设计方案。

图1-4

这个样品不需要像正式的设计方案那样，在集群中把4个节点全都安设好，因为我们现在要测试的并不是整个解决方案，而是它的一个微缩版样品。在测试这个样品的性能与负载情况时，不一定要让访问该产品的用户数像访问正式产品时那样多。我们可以根据这一小批用户的访问情况来估算该方案实际上线后的负载。估算出的结果虽然无法与方案实际实现出来后的结果完全相符，但可以由该数据推算方案上线后的性能。

例如，在测试这个样品的性能时，我们不必像测试实际方案时那样让2000名用户去加载这个应用程序，而是只安排四分之一的用户去访问，同时分配给该样品的资源，也可以是实际方案的一半。这样既可以大幅减少测试所需的资源数量，又能分析方案实际实现出来后的性能。

在信息收集环节中，应该把针对不同的备选方案所做的POC全都记录在一份文档里面，如果客户将来想要打造类似的解决方案，可以参照这份文档。