1.3 考慮可行的解決方案

把項目需求的所有疑點都澄清后，就可以開始構建詳細而具體的需求說明了；這份說明要把早前收集到的相關信息都涵蓋進來。假如我們剛才提出的問題都得到了客戶的答復，那么就可以像下面這樣編寫更為詳細的需求說明：

客戶要求為公司的財務應用程序創建新的Web服務器，該服務器每秒至少要支持10000次訪問，這些訪問來自大約2000名用戶，該服務器所提供的數據會由另外3個應用程序使用。這套解決方案要采用至少4個節點來打造高度可用的服務，以便在維護與停機時段依然能夠運作。我們首次實現該項目時，共有20000美元預算可以動用，由于客戶要求降低預付成本，因此打算利用OSS來實現。這套解決方案會部署在客戶已有的虛擬機環境中，該環境由客戶公司內部的Linux團隊提供支持，其更新工作由客戶公司自己的更新管理方案負責處理。大約每兩個月會增加一批新用戶，客戶公司的采購流程已經考慮到了這一點，因此，可以相當迅速地添置新資源，而不會讓資源緊缺的局面持續太久。用戶數量增加之后，主要問題就在于計算資源必須跟上。

大家可以看到，這份需求說明要比早前那封郵件更加詳細。于是，我們可以從這些需求出發進行項目設計。現在可以確定該項目要部署在客戶已有的虛擬基礎設施上，而且我們已經獲準使用OSS來建設這個項目。該項目必須具備高可用性，由于它的更新工作由客戶現有的更新與版本控制設施負責，因此，我們需要做的可能僅是給解決方案安設一些監控代理（monitoring agent）。

圖1-3簡單地概括了我們可能會采用的設計方案，并沒有展示出太多的細節：

從圖1-3可以看到，我們的方案要通過一個Web服務器集群向客戶端以及使用本方案的應用程序提供高度可用的服務，并確保負載均衡。

由于方案中的很多地方用客戶方已有的基礎設施，因此，POC的可選之處并不多，整套方案的實現過程將會相當直接。雖說如此，依然有一些變數能夠引出幾種不同的選項，我們可以把這些選項交給客戶去選擇。例如，Web服務器就可以有3種做法，一種是純用Apache實現，另一種是純用NGINX實現，還有一種是用Apache托管網站，并通過NGINX實現負載均衡。

POC

我們已經完整地陳述了項目需求，并把可以做出選擇的地方呈現給了客戶，接下來對其中的某一套具體做法進行概念驗證。

POC（概念驗證）是對某個想法或做法進行演示的過程，該過程旨在驗證某項特定的功能。對于本書來說指的是一套具體的解決方案。此外，POC還能讓我們全面了解受測方案在某種情境中的行為，針對特定的負載情況或用途，對其展開深入測試或微調。

無論對什么樣的方案做POC，我們都可以同時看到該方案的好處與壞處；然而對于客戶及架構師來說，關注的重點是受測方案中的各種理念能否在實際的環境下運作。在接受POC的諸多方案中，哪一個能夠成為最終方案，很大程度上受到架構師的影響。不過，在對這些所施加的限制以及帶來的好處進行權衡時，客戶通常更了解它們對公司業務的影響。

現在假設用Apache服務器來托管應用程序的相關文件，并用一臺NGINX服務器實現負載均衡，以提升Apache服務器的性能，并確保它們高度可用。為了驗證該方案，我們可以先用少量的資源，打造一個微縮版的樣品。也就是說，我們不用像最終方案要求的采用4個節點，而是只需要部署2個節點，就可以演示該方案的負載均衡效果，同時還可以讓其中一個節點下線，以判斷此方案是否具備高度的可用性。

圖1-4描述了微縮版設計方案。

這個樣品不需要像正式的設計方案那樣，在集群中把4個節點全都安設好，因為我們現在要測試的并不是整個解決方案，而是它的一個微縮版樣品。在測試這個樣品的性能與負載情況時，不一定要讓訪問該產品的用戶數像訪問正式產品時那樣多。我們可以根據這一小批用戶的訪問情況來估算該方案實際上線后的負載。估算出的結果雖然無法與方案實際實現出來后的結果完全相符，但可以由該數據推算方案上線后的性能。

例如，在測試這個樣品的性能時，我們不必像測試實際方案時那樣讓2000名用戶去加載這個應用程序，而是只安排四分之一的用戶去訪問，同時分配給該樣品的資源，也可以是實際方案的一半。這樣既可以大幅減少測試所需的資源數量，又能分析方案實際實現出來后的性能。

在信息收集環節中，應該把針對不同的備選方案所做的POC全都記錄在一份文檔里面，如果客戶將來想要打造類似的解決方案，可以參照這份文檔。