1.3　如何根據(jù)服務(wù)器應(yīng)用選購(gòu)服務(wù)器

無(wú)論物理服務(wù)器是選用IDC托管還是AWS EC2云主機(jī)（以下為了簡(jiǎn)略說(shuō)明，將它們統(tǒng)稱為服務(wù)器），我們都要面臨一個(gè)問(wèn)題，那就是選擇服務(wù)器的硬件配置，選購(gòu)硬件配置時(shí)要根據(jù)服務(wù)器的應(yīng)用需求而定。因?yàn)橹煌ㄟ^(guò)一臺(tái)服務(wù)器是無(wú)法滿足所有的需求，并解決所有的問(wèn)題的。在設(shè)計(jì)網(wǎng)站的系統(tǒng)架構(gòu)之前，應(yīng)該從以下方面考慮如何選購(gòu)服務(wù)器：

·服務(wù)器要運(yùn)行什么應(yīng)用。

·需要支持多少用戶訪問(wèn)。

·需要多大空間來(lái)存儲(chǔ)數(shù)據(jù)。

·業(yè)務(wù)有多重要。

·服務(wù)器網(wǎng)卡方面的考慮。

·安全方面的考慮。

·機(jī)架安排是否合理化。

·服務(wù)器的價(jià)格是否超出了預(yù)算。

1.服務(wù)器運(yùn)行什么應(yīng)用

這是選購(gòu)服務(wù)器時(shí)首先需要考慮的問(wèn)題，通常是根據(jù)服務(wù)器的應(yīng)用類型（也就是用途），來(lái)決定服務(wù)器的性能、容量和可靠性需求。下面將按照負(fù)載均衡、緩存服務(wù)器、前端服務(wù)器、應(yīng)用程序服務(wù)器、數(shù)據(jù)服務(wù)器和Hadoop分布式計(jì)算的常見基礎(chǔ)架構(gòu)來(lái)討論。

·負(fù)載均衡端：除了網(wǎng)卡性能以外，其他方面對(duì)服務(wù)器的要求比較低，如果選用的是LVS負(fù)載均衡方案，那么它會(huì)直接將所有的連接要求都轉(zhuǎn)給后端的Web應(yīng)用服務(wù)器，因此建議選用萬(wàn)兆網(wǎng)卡。如果選用的是HAProxy負(fù)載均衡器，由于它的運(yùn)行機(jī)制跟LVS不一樣，流量必須雙向經(jīng)過(guò)HAProxy機(jī)器本身，因此對(duì)CPU的運(yùn)行能力會(huì)有要求，也建議選用萬(wàn)兆網(wǎng)卡。如果選用的是AWS EC2機(jī)器，則推薦使用m3.xlarge實(shí)例類型（m3類型提供計(jì)算、內(nèi)存和網(wǎng)絡(luò)資源的平衡，因此是很多應(yīng)用程序的良好選擇）。另外，AWS官方也推出了負(fù)載均衡服務(wù)產(chǎn)品，即Elastic Load Balancing，它具有DNS故障轉(zhuǎn)移和Auto Scalling的功能。

·緩存服務(wù)器：主要是Varnish和redis，對(duì)CPU及其他方面的性能要求一般，但在內(nèi)存方面的要求會(huì)盡量多些。筆者曾為了保證預(yù)算，在雙核（r3.large）機(jī)器上運(yùn)行了4個(gè)redis實(shí)例，AWS官方也建議將此內(nèi)存優(yōu)化型實(shí)例應(yīng)用于高性能數(shù)據(jù)庫(kù)、分布式內(nèi)存緩存、內(nèi)存中分析、基因組裝配和分析，以及SAP、Microsoft SharePoint和其他企業(yè)級(jí)應(yīng)用程序的較大部署。

·應(yīng)用服務(wù)器：由于它承擔(dān)了計(jì)算和功能實(shí)現(xiàn)的重任，因此需要為基于Web架構(gòu)的應(yīng)用程序服務(wù)器（Application Server）選擇足夠快的服務(wù)器，另外應(yīng)用程序服務(wù)器可能需要用到大量的內(nèi)存，尤其是基于Windows基礎(chǔ)架構(gòu)的Ruby、Python、Java服務(wù)器，這一類服務(wù)器至少需要使用單路至強(qiáng)的配置；筆者公司線上的核心業(yè)務(wù)機(jī)器選用的AWS c3.xlarge類型。至于可靠性問(wèn)題，如果你的架構(gòu)中只有一臺(tái)應(yīng)用服務(wù)器，那這臺(tái)服務(wù)器肯定要足夠可靠才行，RAID是絕對(duì)不能被忽視的選項(xiàng)。但如果有多臺(tái)應(yīng)用服務(wù)器，并設(shè)計(jì)了負(fù)載均衡機(jī)制，具有冗余功能，那就不必過(guò)于擔(dān)心了。

注意

c3.xlarge EC2主機(jī)屬于計(jì)算優(yōu)化型（Compute Optimized），也就是CPU加強(qiáng)型。這種類型的CPU/內(nèi)存比例比較大，適合于計(jì)算密集型業(yè)務(wù)，它包含c1和c3系列。其實(shí)例除了較舊的兩個(gè)c1系列（c1.medium和c1.xlarge）是采用普通磁盤作為實(shí)例存儲(chǔ)以外，其他的（也就是c3系列的）全部都以SSD作為實(shí)例存儲(chǔ)，其中最高檔次的c3.8xlarge（32核心108個(gè)計(jì)算單元）的網(wǎng)絡(luò)性能明確標(biāo)注為10G bit/s，c3系列被認(rèn)為是最具性價(jià)比的類型。

·特殊應(yīng)用：除了用于Web架構(gòu)中的應(yīng)用程序之外，如果服務(wù)器還要處理流媒體視頻編碼、服務(wù)器虛擬化、媒體服務(wù)器，或者作為游戲服務(wù)器（邏輯、地圖、聊天）運(yùn)行，那么對(duì)CPU和內(nèi)存的需求同樣會(huì)比較高，至少要考慮四核以上的服務(wù)器。

·公共服務(wù)：這里指的是郵件服務(wù)器、文件服務(wù)器、DNS服務(wù)器、域控服務(wù)器等。通常會(huì)部署兩臺(tái)DNS服務(wù)器以互相備份，域控主服務(wù)器也會(huì)擁有一臺(tái)備份服務(wù)器（專用的或非專用的），所以對(duì)于可靠性，無(wú)須過(guò)于苛刻。至于郵件服務(wù)器，至少需要具備足夠的硬件可靠性和容量大小，這主要是對(duì)郵件數(shù)據(jù)負(fù)責(zé)，因?yàn)楹芏嘤脩魶]有保存和歸檔郵件數(shù)據(jù)的習(xí)慣，待其重裝系統(tǒng)后，就會(huì)習(xí)慣性地到服務(wù)器上重新下載相應(yīng)的數(shù)據(jù)。至于性能問(wèn)題，則應(yīng)評(píng)估用戶數(shù)量后再做決定。另外，考慮到它的重要性，建議盡量選擇穩(wěn)定的服務(wù)器系統(tǒng)，比如Linux或BSD系列。

·數(shù)據(jù)庫(kù)服務(wù)器：數(shù)據(jù)庫(kù)對(duì)服務(wù)器的要求也是最高、最重要的。無(wú)論你使用的是MySQL、SQL Server還是Oracle，一般情況下，都需要有足夠快的CPU、足夠大的內(nèi)存、足夠穩(wěn)定可靠的硬件。可直接采用DELL PowerEdge R710或HP 580G5，CPU和內(nèi)存方面也要盡可能最大化，如果預(yù)算充分，建議用固態(tài)硬盤做RAID 10，因?yàn)閿?shù)據(jù)庫(kù)服務(wù)器對(duì)硬盤的I/O要求是最高的。

·Hadoop分布式計(jì)算：這里建議選用密集存儲(chǔ)實(shí)例——D2實(shí)例，它擁有高頻率Intel Xeon E5-2676v3（Haswell）處理器、高達(dá)48TB的本地存儲(chǔ)、具備高磁盤吞吐量，并支持Amazon EC2增強(qiáng)型聯(lián)網(wǎng)。它適合于大規(guī)模并行處理數(shù)據(jù)倉(cāng)庫(kù)、MapReduce和Hadoop分布式計(jì)算、分布式文件系統(tǒng)、網(wǎng)絡(luò)文件系統(tǒng)、日志或數(shù)據(jù)處理等應(yīng)用。

更多關(guān)于AWS EC2的實(shí)例類型請(qǐng)參考：https://aws.amazon.com/cn/ec2/instance-types/。

2.服務(wù)器需要支持多少用戶訪問(wèn)

服務(wù)器就是用來(lái)給用戶提供某種服務(wù)的，所以使用這些服務(wù)的用戶同樣是我們必須考慮的因素，可以從下面幾個(gè)具體的方面進(jìn)行評(píng)估：

·有多少注冊(cè)用戶。

·正常情況下有多少用戶會(huì)同時(shí)在線訪問(wèn)。

·每天同時(shí)在線訪問(wèn)的最高峰值大概是多少。

一般在項(xiàng)目實(shí)施之前，客戶方面會(huì)針對(duì)這些問(wèn)題給出一個(gè)大致的結(jié)果，但設(shè)計(jì)要盡量更充分和具體，同時(shí)，還要對(duì)未來(lái)的用戶增長(zhǎng)做一個(gè)盡可能準(zhǔn)確的預(yù)測(cè)和規(guī)劃，因?yàn)榉?wù)器可能會(huì)支持越來(lái)越多的用戶，所以在進(jìn)行網(wǎng)站或系統(tǒng)架構(gòu)設(shè)計(jì)時(shí)要讓機(jī)器能夠靈活地?cái)U(kuò)展。

3.需要多大空間來(lái)存儲(chǔ)數(shù)據(jù)

關(guān)于這個(gè)問(wèn)題需要從兩個(gè)方面來(lái)考慮，一方面是有哪些類別的數(shù)據(jù)，包括：操作系統(tǒng)本身占用的空間，安裝應(yīng)用程序所需要的空間，應(yīng)用程序所產(chǎn)生的數(shù)據(jù)、數(shù)據(jù)庫(kù)、日志文件、郵件數(shù)據(jù)等，如果網(wǎng)站是Web 2.0的，還要計(jì)算每個(gè)用戶的存儲(chǔ)空間；另一方面是從時(shí)間軸上來(lái)考慮，這些數(shù)據(jù)每天都在增長(zhǎng)，至少要為未來(lái)兩三年的數(shù)據(jù)增長(zhǎng)做個(gè)準(zhǔn)確的預(yù)算，這就需要軟件開發(fā)人員和業(yè)務(wù)人員一起來(lái)提供充分的信息了。最后將計(jì)算出來(lái)的結(jié)果乘上1.5左右的系數(shù)，以方便維護(hù)的時(shí)候做各種數(shù)據(jù)的備份和文件轉(zhuǎn)移操作。

4.我的業(yè)務(wù)有多重要

這需要根據(jù)自身的業(yè)務(wù)領(lǐng)域來(lái)考慮，下面舉幾個(gè)簡(jiǎn)單的例子，幫助大家了解這些服務(wù)器對(duì)可靠性、數(shù)據(jù)完整性等方面的要求：

·如果服務(wù)器是用來(lái)運(yùn)行一個(gè)WordPress博客的，那么，一臺(tái)酷睿處理器的服務(wù)器、1GB的內(nèi)存，外加一塊160GB的硬盤就足夠了（如果是AWS EC2主機(jī)，可以考慮t2.micro實(shí)例類型）。就算服務(wù)器出現(xiàn)了一點(diǎn)硬件故障，導(dǎo)致幾個(gè)小時(shí)甚至一兩天不能提供訪問(wèn)，生活也會(huì)照常繼續(xù)。

·如果服務(wù)器是用作測(cè)試平臺(tái)的，那么就不會(huì)如生產(chǎn)環(huán)境那樣對(duì)可靠性有極高的要求，所需要的可能只是做好例行的數(shù)據(jù)備份即可，若服務(wù)器宕機(jī)，只要能在當(dāng)天把問(wèn)題解決掉就可以了。

·如果是一家電子商務(wù)公司的服務(wù)器，運(yùn)行著電子商務(wù)網(wǎng)站平臺(tái)，當(dāng)硬件發(fā)生故障而導(dǎo)致宕機(jī)時(shí)，你需要對(duì)以下“危言聳聽”的后果做好心理準(zhǔn)備：投訴電話被打爆、顧客大量流失、顧客要求退款、市場(chǎng)推廣費(fèi)用打水漂、員工無(wú)事可干、公司運(yùn)營(yíng)陷入癱瘓狀態(tài)、數(shù)據(jù)丟失。事實(shí)上，電子商務(wù)網(wǎng)站一般是需要365×24小時(shí)不間斷運(yùn)行和監(jiān)控的，而且要有專人輪流值守，并且要有足夠的備份設(shè)備，每天還要有專人負(fù)責(zé)檢查。

·如果是大型廣告類或門戶類網(wǎng)站，那么建議選擇CDN系統(tǒng)。由于它具有提高網(wǎng)站響應(yīng)速度、負(fù)載均衡、有效抵御DDoS攻擊等特點(diǎn)，相對(duì)而言，每個(gè)節(jié)點(diǎn)都會(huì)有大量的冗余。

這里其實(shí)只是簡(jiǎn)單地討論下業(yè)務(wù)對(duì)服務(wù)器硬件可靠性的要求。要全面解決這個(gè)問(wèn)題，不能只考慮單個(gè)服務(wù)器的硬件，還需要結(jié)合系統(tǒng)架構(gòu)的規(guī)劃設(shè)計(jì)。

在回答了以上問(wèn)題后，接下來(lái)就可以決定下面這些具體的選項(xiàng)了。

（1）選擇什么CPU

回憶一下上面關(guān)于“服務(wù)器運(yùn)行什么應(yīng)用”和“需要支持多少用戶訪問(wèn)”兩個(gè)方面的考慮，這將幫助我們選擇合適的CPU。毫無(wú)疑問(wèn)，CPU的主頻越高，其性能也就越高；兩個(gè)CPU要比一個(gè)CPU來(lái)得更好；至強(qiáng)（Xeon）肯定比酷睿（Core）的性能更強(qiáng)。但究竟怎樣的CPU才是最合適的呢？下面提供了一些常見情況下的建議：

·如果業(yè)務(wù)剛剛起步，預(yù)算不是很充足，建議選擇一款經(jīng)典的酷睿服務(wù)器，這可以幫你節(jié)約大量的成本。而且，以后還可以根據(jù)業(yè)務(wù)發(fā)展的情況，隨時(shí)升級(jí)到更高配置的服務(wù)器。

·如果需要在一臺(tái)服務(wù)器上同時(shí)運(yùn)行多種應(yīng)用服務(wù)，例如基于LNMP架構(gòu)的Web網(wǎng)站，那么一個(gè)單核至強(qiáng)（例如X3330）或新一代的酷睿I5（雙核四線程）將是最佳的選擇。雖然從技術(shù)的角度來(lái)說(shuō)，這并不是一個(gè)好主意，但至少能節(jié)約一大筆成本。

·如果服務(wù)器要運(yùn)行MySQL或Oracle數(shù)據(jù)庫(kù)，而且目前有幾百個(gè)用戶同時(shí)在線，未來(lái)還會(huì)不斷增長(zhǎng)，那么至少應(yīng)該選擇安裝一個(gè)雙四核服務(wù)器。

·如果需要的是Web應(yīng)用服務(wù)器，雙四核基本就可以滿足要求了。

（2）需要多大的內(nèi)存

同樣，“服務(wù)器運(yùn)行什么應(yīng)用”和“需要支持多少用戶訪問(wèn)”兩方面的考慮也將有助于我們選擇合適的內(nèi)存容量。相比于CPU，筆者認(rèn)為內(nèi)存（RAM）才是影響性能的最關(guān)鍵因素。因?yàn)樵诤芏嗾谶\(yùn)行的服務(wù)器中，CPU的利用率一般都在10%~30%之間，甚至更低。但由于內(nèi)存容量不夠而導(dǎo)致服務(wù)器運(yùn)行緩慢的案例比比皆是，如果服務(wù)器不能分配足夠的內(nèi)存給應(yīng)用程序，那么應(yīng)用程序就需要通過(guò)硬盤接口緩慢地交換讀寫數(shù)據(jù)了，這將導(dǎo)致網(wǎng)站慢得令人無(wú)法接受。內(nèi)存的大小主要取決于服務(wù)器的用戶數(shù)量，當(dāng)然也和應(yīng)用軟件對(duì)內(nèi)存的最低需求和內(nèi)存管理機(jī)制有關(guān)，所以，最好由程序員或軟件開發(fā)商給出最佳的內(nèi)存配置建議。下面同樣給出了一些常見應(yīng)用環(huán)境下的內(nèi)存配置建議：

·無(wú)論是Apache還是Nginx服務(wù)器，一般情況下Web前端服務(wù)器都不需要配置特別高的內(nèi)存，尤其是在集群架構(gòu)中，4GB的內(nèi)存就已經(jīng)足夠了。如果用戶數(shù)量持續(xù)增加，我們才會(huì)考慮使用8GB或更大的內(nèi)存。單Apache Web機(jī)器，在配置了16GB的內(nèi)存后，可以抗6000個(gè)并發(fā)鏈接數(shù)。

·對(duì)于運(yùn)行Tomcat、Resin、WebLogic的應(yīng)用服務(wù)器，8GB內(nèi)存應(yīng)該是基準(zhǔn)配置，更準(zhǔn)確的數(shù)字需要根據(jù)用戶數(shù)量和技術(shù)架構(gòu)來(lái)確定。

·數(shù)據(jù)庫(kù)服務(wù)器的內(nèi)存由數(shù)據(jù)庫(kù)實(shí)例的數(shù)量、表大小、索引、用戶數(shù)量等來(lái)決定，一般建議配置16GB以上的內(nèi)存，筆者公司在許多項(xiàng)目方案中使用了24GB到48GB的內(nèi)存。

·諸如Postfix和Exchange這樣的郵件服務(wù)器對(duì)內(nèi)存的要求并不高，1GB~2GB就可以滿足了。

·還有一些特殊的服務(wù)器，需要為之配置盡可能大的內(nèi)存容量，比如配置有Varnish和Memcached的緩存服務(wù)器等。

·若是只有一臺(tái)文件服務(wù)器，1GB的內(nèi)存可能就足夠了。

事實(shí)上，由于內(nèi)存技術(shù)在不斷進(jìn)化，價(jià)格也在不斷降低，因此才得以近乎奢侈地討論4GB、8GB、16GB這些曾經(jīng)不可想象的內(nèi)存容量。然而，除了花錢購(gòu)買內(nèi)存來(lái)滿足應(yīng)用程序的“貪婪”之外，系統(tǒng)優(yōu)化和數(shù)據(jù)庫(kù)優(yōu)化仍然是我們需要重視的問(wèn)題。

（3）需要怎樣的硬盤存儲(chǔ)系統(tǒng)

硬盤存儲(chǔ)系統(tǒng)的選擇和配置是整個(gè)服務(wù)器系統(tǒng)里最復(fù)雜的一部分，需要考慮硬盤的數(shù)量、容量、接口類型、轉(zhuǎn)速、緩存大小，以及是否需要RAID卡、RAID卡的型號(hào)和RAID級(jí)別等問(wèn)題。甚至在一些高可靠性高性能的應(yīng)用環(huán)境中，還需要考慮使用怎樣的外部存儲(chǔ)系統(tǒng)（SAN、NAS或DAS）。下面將服務(wù)器的硬盤RAID卡的特點(diǎn)歸納一下：

·如果是用作緩存服務(wù)器，比如Varnish或redis，則可以考慮用RAID 0。

·如果是跑Nginx+FastCGI或Nginx等應(yīng)用，則可以考慮用RAID 1。

·如果是內(nèi)網(wǎng)開發(fā)服務(wù)器或存放重要代碼的服務(wù)器，則可以考慮用RAID 5。

·如果是跑MySQL或Oracle等數(shù)據(jù)庫(kù)應(yīng)用，則可以考慮用固態(tài)硬盤做RAID 5或RAID 10。

5.網(wǎng)卡性能方面的考慮

如果基礎(chǔ)架構(gòu)是多服務(wù)器環(huán)境，而且服務(wù)器之間有大量的數(shù)據(jù)交換，那么建議為每臺(tái)服務(wù)器配置兩個(gè)或更多的網(wǎng)卡，一個(gè)用來(lái)對(duì)外提供服務(wù)，另一個(gè)用來(lái)做內(nèi)部數(shù)據(jù)交換。由于現(xiàn)在項(xiàng)目外端都置于防火墻內(nèi)，所以許多時(shí)候單網(wǎng)卡就足夠了；而比如LVS＋Keepalived這種只用公網(wǎng)地址的Linux集群架構(gòu)，有時(shí)可能只需要一塊網(wǎng)卡即可。建議大家選用萬(wàn)兆網(wǎng)卡。另外，建議交換機(jī)至少也要選擇千兆網(wǎng)卡級(jí)別的。

如果采用的是AWS EC2云主機(jī)環(huán)境，單純以EC2作為L(zhǎng)VS或HAProxy意義不大。如果經(jīng)常使用AWS EC2機(jī)器，應(yīng)該會(huì)注意到AWS將機(jī)器的網(wǎng)卡性能分成了3個(gè)級(jí)別，即Low、Moderate、High，那么這3個(gè)級(jí)別分別是什么情況呢？雖然AWS沒有帶寬限制，但是由于多虛擬機(jī)共享HOST物理機(jī)的網(wǎng)絡(luò)性能和I/O性能，單個(gè)虛擬機(jī)的網(wǎng)絡(luò)性能也不是特別好度量，不過(guò)大概情況是這樣的：Low級(jí)別的是20M bit/s，Moderate級(jí)別的是40M bit/s，High級(jí)別的能達(dá)到80M bit/s~100M bit/s。從上面的分析情況可以得知，單臺(tái)AWS EC2主機(jī)作為網(wǎng)站的負(fù)載均衡入口，容易成為網(wǎng)站的瓶頸。這個(gè)時(shí)候可以考慮使用AWS提供的Elastic Load Balancing產(chǎn)品，它可以在云中的多個(gè)Amazon EC2實(shí)例間自動(dòng)分配應(yīng)用程序的訪問(wèn)流量（大家注意到?jīng)]，相當(dāng)于它將網(wǎng)站的流量分擔(dān)到了多臺(tái)機(jī)器上）。它可以實(shí)現(xiàn)更高水平的應(yīng)用程序容錯(cuò)性能，從而無(wú)縫地提供分配應(yīng)用程序流量所需的負(fù)載均衡容量。除了提供負(fù)載均衡常見的功能之外，它還具有Auto Scalling功能，關(guān)于Auto Scalling的詳細(xì)介紹，可參見AWS官方文檔。

6.服務(wù)器安全方面的考慮

由于目前國(guó)內(nèi)的DDoS攻擊還是比較普遍的，因此建議給每個(gè)項(xiàng)目方案和自己的電子商務(wù)網(wǎng)站配備硬件防火墻，比如Juniper、Cisco等硬件防火墻。當(dāng)然了，這個(gè)問(wèn)題也是網(wǎng)站后期運(yùn)營(yíng)維護(hù)需要考慮的，這里只是想讓大家有個(gè)概念性的認(rèn)識(shí)。此外，建議租賃CDN服務(wù)，這樣萬(wàn)一不幸遭遇惡意的DDoS流量攻擊，CDN還能幫助抵擋部分惡意流量，核心機(jī)房的業(yè)務(wù)不至于在很短的時(shí)間內(nèi)就會(huì)崩潰。

7.根據(jù)機(jī)架數(shù)合理安排服務(wù)器的數(shù)量

這個(gè)問(wèn)題應(yīng)該在項(xiàng)目實(shí)施前就處理好了的，選擇服務(wù)器時(shí)應(yīng)該明確服務(wù)器的規(guī)格，即到底是1U、2U還是4U的，到底有多少臺(tái)服務(wù)器和交換機(jī)，應(yīng)該如何安排，畢竟機(jī)柜只有42U的容量。在小項(xiàng)目中這個(gè)問(wèn)題可能無(wú)關(guān)緊要，但在大型項(xiàng)目的實(shí)施過(guò)程中，這個(gè)問(wèn)題就很突出了。我們應(yīng)該根據(jù)現(xiàn)有或額定的機(jī)架數(shù)目確定到底應(yīng)該選擇多少臺(tái)服務(wù)器和交換機(jī)。

8.成本考慮：服務(wù)器的價(jià)格問(wèn)題

無(wú)論是在公司采購(gòu)時(shí)，還是在項(xiàng)目實(shí)施過(guò)程中，成本都是非常重要的問(wèn)題。筆者的方案經(jīng)常被退回，理由就是超出預(yù)算。尤其對(duì)于一些小項(xiàng)目，預(yù)算更吃緊。之前筆者經(jīng)常面對(duì)的客戶需求是為證券類資訊網(wǎng)站設(shè)計(jì)方案，只要求周一至周日的上午九點(diǎn)至下午三點(diǎn)網(wǎng)站不出問(wèn)題即可，并不需要做復(fù)雜的負(fù)載均衡高可用。所以面對(duì)這種需求，筆者會(huì)將單Nginx或HAProxy設(shè)計(jì)成負(fù)載均衡，后面接兩臺(tái)Web應(yīng)用服務(wù)器作為簡(jiǎn)單集群架構(gòu)。如果是做中大型電子商務(wù)網(wǎng)站，那么在服務(wù)器成本上的控制就尤其重要了。事實(shí)上，我們經(jīng)常面對(duì)的問(wèn)題是，客戶給出的成本預(yù)算有限，而實(shí)際應(yīng)用又需要比較多的服務(wù)器，這時(shí)候，就不得不另外設(shè)計(jì)一套最小化成本預(yù)算方案來(lái)折中處理。

以上8個(gè)方面是我們?cè)诓少?gòu)服務(wù)器時(shí)應(yīng)該要注意的因素，在選擇服務(wù)器的組件時(shí)要有所偏重，然后根據(jù)系統(tǒng)或網(wǎng)站架構(gòu)來(lái)決定服務(wù)器的數(shù)量，盡量做到服務(wù)器資源利用的最大化。在控制方案成本的同時(shí)，要做到最優(yōu)的性價(jià)比。