朱革　余浩源　王先全　周錫祥

摘要：隨著互聯(lián)網(wǎng)的迅速發(fā)展普及以及手機(jī)App的快速壯大，服務(wù)器需要承受的用戶訪問(wèn)量變得越來(lái)越大，加上現(xiàn)在用戶對(duì)上網(wǎng)體驗(yàn)的重視，這些都對(duì)當(dāng)前服務(wù)器設(shè)計(jì)提出了新的挑戰(zhàn)。單一服務(wù)器架構(gòu)已經(jīng)不適合用來(lái)承受高并發(fā)請(qǐng)求，前幾年流行的SSM框架能通過(guò)集群提高性能，但單體應(yīng)用不適合做大型系統(tǒng)，且僅通過(guò)服務(wù)器集群帶來(lái)的性能提升也會(huì)遇到瓶頸，故需要新的架構(gòu)來(lái)滿足當(dāng)前的需求。從集群、分布式、數(shù)據(jù)庫(kù)幾個(gè)方面入手對(duì)服務(wù)器設(shè)計(jì)進(jìn)行分析，提出適合高并發(fā)環(huán)境的服務(wù)器架構(gòu)。

關(guān)鍵詞：高并發(fā);集群;分布式;架構(gòu)

中圖分類號(hào)：TP311? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2021）12-0069-04

Abstract： With the rapid development and popularization of the Internet and the rapid growth of mobile phone apps. The server has to bear more and more user visits， and now users attach importance to the Internet experience， which all pose new challenges to the current server architecture. The single server architecture is no longer suitable for handling high concurrent requests， The popular SSM frameworks of the past few years can improve performance through clustering， but monolithic applications are not suitable for large system， and the performance improvement only through server clusters will also encounter bottlenecks， therefore， a new architecture is needed to meet the current needs. Analyze server design from the aspects of cluster， distributed， and database， and proposes a server architecture suitable for high-concurrency environments.

Key words： high concurrency; cluster; distributed; framework

1 背景

互聯(lián)網(wǎng)發(fā)展初期對(duì)服務(wù)器的要求不高，通常在一臺(tái)服務(wù)器上搭建服務(wù)就能夠滿足需求，隨著上網(wǎng)人數(shù)的增多以及網(wǎng)速的提高，服務(wù)器需要承受的壓力也越來(lái)越大。比如淘寶在雙十一凌晨0點(diǎn)的時(shí)候所承受的訪問(wèn)量巨大，12306鐵路購(gòu)票網(wǎng)站曾經(jīng)就出現(xiàn)過(guò)由于服務(wù)器壓力過(guò)大系統(tǒng)崩潰的情況，解決服務(wù)器在高并發(fā)情況下的性能低下問(wèn)題是必要的。增強(qiáng)服務(wù)器的并發(fā)能力除了提升硬件性能，參數(shù)調(diào)優(yōu)等方式外，還能通過(guò)優(yōu)化服務(wù)器的架構(gòu)來(lái)提高系統(tǒng)的性能，增強(qiáng)系統(tǒng)的容災(zāi)性與穩(wěn)定性。本文從集群、分布式、數(shù)據(jù)庫(kù)等方面來(lái)對(duì)服務(wù)器架構(gòu)設(shè)計(jì)進(jìn)行分析，為高性能服務(wù)器的設(shè)計(jì)提供一種可行的方案。

2 架構(gòu)優(yōu)化的必要性

對(duì)服務(wù)器性能進(jìn)行提升有多種方式，進(jìn)行硬件的升級(jí)是最為簡(jiǎn)單的方式，但這種方式成本高且不能從根本上解決問(wèn)題[1]。對(duì)單體應(yīng)用進(jìn)行集群部署能有效地提高系統(tǒng)的并發(fā)能力與穩(wěn)定性，但單體應(yīng)用存在著不易迭代及部署效率低等問(wèn)題，并發(fā)到了一定程度僅靠集群并不能完全解決性能問(wèn)題，此時(shí)就需要從其他部分進(jìn)優(yōu)化，單靠某一個(gè)技術(shù)無(wú)法滿足需求，所以需要對(duì)服務(wù)器架構(gòu)進(jìn)行設(shè)計(jì)。

3 設(shè)計(jì)方案

在實(shí)際的使用中，影響服務(wù)器性能的因素有很多，架構(gòu)的不同會(huì)使服務(wù)器的性能有很大的差距。本節(jié)主要從集群、分布式的使用以及數(shù)據(jù)庫(kù)方面進(jìn)行分析。

3.1 使用服務(wù)器集群

客戶端發(fā)送多個(gè)請(qǐng)求到單個(gè)服務(wù)器，服務(wù)器對(duì)請(qǐng)求進(jìn)行處理并且連接數(shù)據(jù)庫(kù)，處理完畢后再將結(jié)果返回到客戶端。這種架構(gòu)的成本低，代碼編寫也較為簡(jiǎn)單，是比較適合早期并發(fā)較少的情況的。但隨著現(xiàn)在請(qǐng)求并發(fā)變得越來(lái)越大，如果想要繼續(xù)采取單一服務(wù)器來(lái)處理請(qǐng)求，就得提升服務(wù)器的性能，隨著摩爾定律[2]逐漸失效，硬件性能的提升已經(jīng)跟不上需求的提升，就算不考慮成本將硬件的配置提升到最好仍然不能滿足需求，那通過(guò)提升硬件配置這條縱向解決問(wèn)題的道路就走不通。服務(wù)器集群[3]這種通過(guò)橫向增加服務(wù)器數(shù)量的方式就正好能夠解決這個(gè)問(wèn)題。

3.1.1 服務(wù)器集群的作用

服務(wù)器集群就是將多個(gè)做同種服務(wù)的服務(wù)器集中起來(lái)，利用多個(gè)計(jì)算機(jī)來(lái)進(jìn)行并行的計(jì)算以提高性能，每個(gè)服務(wù)器是一個(gè)節(jié)點(diǎn)，所有節(jié)點(diǎn)構(gòu)成了集群[4]。當(dāng)單個(gè)服務(wù)器處理高并發(fā)請(qǐng)求遇到瓶頸的時(shí)候使用集群可以提升系統(tǒng)的處理能力，當(dāng)集群的性能不夠時(shí)也可以適當(dāng)增加節(jié)點(diǎn)數(shù)量。對(duì)客戶端而言，訪問(wèn)服務(wù)器的集群就和訪問(wèn)一個(gè)服務(wù)器是一樣的，客戶端不用專門為此做配置。

3.1.2 用負(fù)載均衡服務(wù)器搭建服務(wù)器集群

服務(wù)器集群是由多個(gè)服務(wù)器組成，但是用戶的請(qǐng)求到底由哪個(gè)服務(wù)器來(lái)進(jìn)行處理，需要一個(gè)調(diào)度者來(lái)進(jìn)行調(diào)度，這個(gè)調(diào)度者就是負(fù)載均衡服務(wù)器。用戶的請(qǐng)求先發(fā)送給負(fù)載均衡服務(wù)器，然后服務(wù)器再根據(jù)相應(yīng)的設(shè)置以及當(dāng)時(shí)負(fù)載的情況，來(lái)選出一個(gè)合適的節(jié)點(diǎn)對(duì)請(qǐng)求進(jìn)行處理。

本文選用Nginx作為負(fù)載均衡服務(wù)器，它可以通過(guò)反向代理來(lái)實(shí)現(xiàn)軟件負(fù)載均衡，反向代理時(shí)客戶端不需要做任何配置[5]。如圖1所示客戶端對(duì)代理是無(wú)感知的，請(qǐng)求發(fā)送到了反向代理服務(wù)器，由反向代理服務(wù)器去選擇目標(biāo)服務(wù)器，從目標(biāo)服務(wù)器獲取返回的數(shù)據(jù)后再返回給客戶端，客戶端訪問(wèn)的實(shí)際是代理服務(wù)器的地址，而不是直接訪問(wèn)的被隱藏了的真實(shí)服務(wù)器地址。

使用Nginx作為負(fù)載均衡服務(wù)器首先需要對(duì)其配置文件nginx.conf進(jìn)行修改，在http塊中添加：

upstream myserver {

server 192.168.0.1：8080;

server 192.168.0.2：8080;

server 192.168.0.3：8080;

}

表示使用默認(rèn)的負(fù)載均衡策略輪詢將請(qǐng)求分配給三個(gè)服務(wù)。然后將http塊里的server部分修改為：

server{

listen 80;

server_name localhost;

location /{

proxy_pass http：//myserver ;

}

......

其中l(wèi)isten為監(jiān)聽(tīng)的端口，server_name為監(jiān)聽(tīng)的地址，proxy_pass則為請(qǐng)求的轉(zhuǎn)向，值為前面upstream定義的服務(wù)器列表。除輪詢外常見(jiàn)的負(fù)載均衡策略還有Weight、ip_hash、fair、least_conn等。

3.2 采用分布式架構(gòu)

前面講了通過(guò)服務(wù)器集群來(lái)提高性能，當(dāng)訪問(wèn)量越來(lái)越大，單一應(yīng)用增加服務(wù)器數(shù)量所帶來(lái)的性能提升變得越來(lái)越小，這時(shí)候就需要用到分布式架構(gòu)了，從圖2中可以看出一般服務(wù)器集群中的單體架構(gòu)和分布式系統(tǒng)間的區(qū)別。

分布式與集群相比，分布式是一種工作方式而集群則是一種物理形態(tài)。將同一個(gè)業(yè)務(wù)放到不同的機(jī)器上以提高性能與可用性就能稱為集群，而分布式則是將不同的業(yè)務(wù)或者一個(gè)業(yè)務(wù)拆分成多個(gè)子業(yè)務(wù)部署到不同的服務(wù)器上通過(guò)交換信息的方式來(lái)進(jìn)行協(xié)作[6]。分布式是通過(guò)縮短單個(gè)任務(wù)的執(zhí)行時(shí)間來(lái)提升工作效率，集群則是通過(guò)提高相同時(shí)間并行執(zhí)行的任務(wù)數(shù)量來(lái)提高效率的，所以當(dāng)增加集群服務(wù)器數(shù)量提升的性能有限時(shí)可通過(guò)分布式來(lái)提升性能。

3.2.1 微服務(wù)的概念

簡(jiǎn)單地來(lái)說(shuō)微服務(wù)[7]就是很小的服務(wù)，甚至功能可以單一到只做一件事，一個(gè)操作。單體應(yīng)用將它的所有功能放在一個(gè)進(jìn)程里執(zhí)行，能夠在多個(gè)服務(wù)器里復(fù)制這單體應(yīng)用實(shí)現(xiàn)擴(kuò)展。而微服務(wù)則將它的每個(gè)功能元素放在不同的服務(wù)中，通過(guò)跨服務(wù)器的分發(fā)這些服務(wù)進(jìn)行擴(kuò)展，對(duì)需要進(jìn)行復(fù)制的功能元素進(jìn)行復(fù)制也可以實(shí)現(xiàn)性能提升。

分布式也屬于微服務(wù)，兩者的概念比較相似但是也有一些差別。分布式是一種讓分散的機(jī)器相互協(xié)助完成業(yè)務(wù)的手段，微服務(wù)相比一般的分布式則對(duì)服務(wù)進(jìn)行更細(xì)粒度的切分，使得整個(gè)系統(tǒng)更加易于迭代且并行度更高。

3.2.2 分布式服務(wù)中應(yīng)解決的問(wèn)題

在微服務(wù)架構(gòu)中隨著功能模塊的增多，代碼和配置文件變得越來(lái)越冗雜，為解決這個(gè)問(wèn)題可使用Spring Boot來(lái)快速構(gòu)建微服務(wù)應(yīng)用，它能幫助開(kāi)發(fā)者解決開(kāi)發(fā)中大部分的配置問(wèn)題，大部分配置都可以用java類加上注解來(lái)代替。Spring Boot能簡(jiǎn)化Spring的開(kāi)發(fā)，它為Spring整合了許多第三方技術(shù)，去繁從簡(jiǎn)約定大于配置，十分適合微服務(wù)開(kāi)發(fā)[8]。它的特點(diǎn)有：

1）能快速創(chuàng)建獨(dú)立運(yùn)行的Spring項(xiàng)目以及集成了主流的框架。

2）擁有內(nèi)嵌的Servlet容器，方便運(yùn)行。

3）簡(jiǎn)化了Maven配置。

4）無(wú)代碼生成，不需要配置XML文件。

5）有大量的自動(dòng)配置，簡(jiǎn)化開(kāi)發(fā)，當(dāng)然也能修改默認(rèn)值。

微服務(wù)雖然帶來(lái)了許多好處，同時(shí)也使得運(yùn)維變得更加復(fù)雜，監(jiān)控更加困難，分布式的復(fù)雜性也提高了。比較明顯的幾個(gè)問(wèn)題是：

①服務(wù)間的調(diào)用問(wèn)題。各個(gè)服務(wù)間實(shí)現(xiàn)調(diào)用需要知道服務(wù)所在的地址，服務(wù)不會(huì)放在固定的機(jī)器上，故不能將要調(diào)用的目標(biāo)服務(wù)地址寫死在配置文件里。

②配置問(wèn)題。微服務(wù)要將單體服務(wù)中的業(yè)務(wù)拆分成多個(gè)粒度較小的子服務(wù)，這樣就會(huì)導(dǎo)致系統(tǒng)中出現(xiàn)大量的服務(wù)，如果仍然為每個(gè)服務(wù)都提供單獨(dú)的配置文件則會(huì)出現(xiàn)配置信息冗余。

③系統(tǒng)的穩(wěn)定性問(wèn)題。由于微服務(wù)間的調(diào)用是鏈性的，如果在整個(gè)調(diào)用鏈中某個(gè)服務(wù)出現(xiàn)了問(wèn)題則整個(gè)系統(tǒng)則會(huì)雪崩式癱瘓。

3.2.3 分布式服務(wù)設(shè)計(jì)

分布式服務(wù)中存在的問(wèn)題使其構(gòu)建變得復(fù)雜，可以使用Spring Cloud[9]來(lái)解決這些問(wèn)題，它提供很多工具用來(lái)進(jìn)行分布式系統(tǒng)的構(gòu)建，比如：服務(wù)發(fā)現(xiàn)，配置管理，熔斷，微代理，智能路由，控制總線，全局鎖，一次性token，決策競(jìng)選，分布式session，集群狀態(tài)等。

Spring Cloud Alibaba[10]是阿里巴巴推出的解決方案，使用其中的Nacos、Sentinel、Seata組件來(lái)解決前面所提到的問(wèn)題。

服務(wù)間調(diào)用的地址問(wèn)題可以使用Nacos中的服務(wù)注冊(cè)發(fā)現(xiàn)來(lái)解決，在服務(wù)的配置中添加如下代碼：

spring：

application：

name： provider

cloud：

nacos：

discovery：

server-addr： localhost：8848

該配置指定了Nacos的地址以及該服務(wù)的服務(wù)名。

將服務(wù)提供者注冊(cè)進(jìn)Nacos后，服務(wù)消費(fèi)者可以用restTemplate或OpenFeign等來(lái)請(qǐng)求調(diào)用該服務(wù)中的功能。其原理是在服務(wù)器啟動(dòng)的時(shí)候會(huì)將服務(wù)器的服務(wù)地址通信地址等用別名注冊(cè)進(jìn)注冊(cè)中心，而另一邊服務(wù)的消費(fèi)者則以該別名在注冊(cè)中心中獲取到服務(wù)的真實(shí)通信地址。

配置問(wèn)題同樣也可以使用Nacos來(lái)解決，使用其配置管理功能來(lái)充當(dāng)配置中心。需要注意的是在使用配置中心管理配置時(shí)，springboot的配置文件需要使用bootstrap.yml，這是因?yàn)樵陧?xiàng)目初始化時(shí)需要保證配置先從配置中心拉取，拉取配置后項(xiàng)目才能正常啟動(dòng)，application.yml是用戶級(jí)的資源配置項(xiàng)，而bootstrap.yml是系統(tǒng)級(jí)的，優(yōu)先級(jí)更高。

bootstrap.yml中相關(guān)配置代碼寫法：

spring：

application：

name： config

cloud：

nacos：

discovery：

server-addr： localhost：8848

config：

server-addr： localhost：8848

file-extension： yaml

group： DEV_GROUP

namespace： 077e4037-3b40-4d4a-801e-c8d

4012a815f

使用Sentinel從流量切入，在流量控制、熔斷降級(jí)等維度來(lái)維持服務(wù)的穩(wěn)定性。流量控制是監(jiān)控應(yīng)用流量的QPS或并發(fā)線程數(shù)來(lái)避免瞬時(shí)高流量沖垮服務(wù)器。熔斷就好比保險(xiǎn)絲，當(dāng)請(qǐng)求滿足設(shè)定的異常條件就會(huì)熔斷掉服務(wù)，而不是一直等待到此服務(wù)超時(shí)。降級(jí)則是對(duì)服務(wù)進(jìn)行有策略的降級(jí)，可以理解為保證核心業(yè)務(wù)正常運(yùn)行的兜底方法。

啟動(dòng)好Sentinel與服務(wù)并且進(jìn)行過(guò)一次請(qǐng)求后登錄Sentinel控制臺(tái)就可以看到相關(guān)服務(wù)并且對(duì)其進(jìn)行控制。圖3為新增流控規(guī)則的面板，可以看到閾值類型有QPS和線程數(shù)兩種，QPS是指當(dāng)調(diào)用該api的QPS達(dá)到閾值的時(shí)候，進(jìn)行限流。線程數(shù)則是當(dāng)調(diào)用該api的線程數(shù)達(dá)到閾值的時(shí)候，進(jìn)行限流。

新增降級(jí)規(guī)則的面板為圖4，降級(jí)策略有RT、異常比例以及異常數(shù)。RT為平均響應(yīng)時(shí)間，滿足平均響應(yīng)時(shí)間超出閾值且在時(shí)間窗口內(nèi)通過(guò)的請(qǐng)求數(shù)大于一定值兩個(gè)條件時(shí)觸發(fā)降級(jí)。異常比例和異常數(shù)則分別是發(fā)生異常的比例和異常的個(gè)數(shù)超過(guò)閾值時(shí)觸發(fā)降級(jí)。

3.3 數(shù)據(jù)庫(kù)優(yōu)化方案

在高并發(fā)的環(huán)境下，對(duì)數(shù)據(jù)庫(kù)的操作頻繁，如果只對(duì)單實(shí)例數(shù)據(jù)庫(kù)進(jìn)行簡(jiǎn)單的操作無(wú)法支撐系統(tǒng)的正常運(yùn)行，所以需要對(duì)數(shù)據(jù)庫(kù)的使用進(jìn)行設(shè)計(jì)。

3.3.1 索引優(yōu)化分析

數(shù)據(jù)庫(kù)執(zhí)行查詢語(yǔ)句時(shí)會(huì)根據(jù)條件進(jìn)行全表掃描，正確的使用索引可以提高查詢的效率[11]。索引的本質(zhì)是數(shù)據(jù)結(jié)構(gòu)，它能夠幫助數(shù)據(jù)庫(kù)高效的獲取數(shù)據(jù)，但其本身也會(huì)占用磁盤空間。使用索引時(shí)每次對(duì)表進(jìn)行更新操作時(shí)需要更新索引，故會(huì)降低表的更新速度。當(dāng)表的數(shù)據(jù)特別多時(shí)，索引能帶來(lái)的性能提升會(huì)降低，這就需要合理的設(shè)計(jì)索引，以免影響性能的提升甚至帶來(lái)負(fù)面效果[12]。

索引在使用中也需要注意避免索引失效，在mysql中可以使用explain關(guān)鍵字來(lái)看mysql如何處理sql語(yǔ)句，其使用方法是Explain + SQL語(yǔ)句：

EXPLAIN SELECT * FROM t1，t2，t3 WHERE t1.id=t2.id AND t2.id=t3.id

圖5為執(zhí)行Explain的結(jié)果，可以看到內(nèi)容并不是一般查詢語(yǔ)句的格式。其中各個(gè)字段都有其含義：

1）id：查詢序列號(hào)，表示查詢中執(zhí)行的順序，值相同則從上往下執(zhí)行，值不同則id越大的越先執(zhí)行。

2）select_type：查詢的類型。

3）table：此行數(shù)據(jù)與哪張表相關(guān)。

4）type：表示訪問(wèn)的類型，較為重要的一個(gè)指標(biāo)，能顯示出數(shù)據(jù)庫(kù)引擎查找表的方式。

5）possible_keys：可能應(yīng)用在這張表上的索引。

6）key：實(shí)際使用的索引。

7）key_len：索引中使用的字節(jié)數(shù)，檢查是否充分利用上了索引。

8）ref：索引被使用的列。

9）rows：顯示mysql認(rèn)為執(zhí)行查詢時(shí)需檢查的行數(shù)。

3.3.2 讀寫分離

一個(gè)系統(tǒng)對(duì)數(shù)據(jù)庫(kù)的讀寫需求通常不同，讓單一數(shù)據(jù)庫(kù)處理讀和寫操作可能會(huì)使其承受的壓力過(guò)大。可以使用主從復(fù)制來(lái)實(shí)現(xiàn)讀寫分離，讓主服務(wù)器只執(zhí)行寫操作，從服務(wù)器執(zhí)行讀操作，以此分散服務(wù)器的壓力[13]。

如圖6所示，主從復(fù)制的原理是從數(shù)據(jù)庫(kù)slave通過(guò)讀取主數(shù)據(jù)庫(kù)master的binlog然后執(zhí)行一遍master執(zhí)行過(guò)的操作從而達(dá)到主從同步的效果?？梢詫⑵渲械倪^(guò)程分為三個(gè)部分：1）master將每個(gè)會(huì)改變數(shù)據(jù)的操作串行的記錄進(jìn)二進(jìn)制日志binlog中，將這些記錄稱為二進(jìn)制日志事件。2）slave從master拷貝二進(jìn)制日志事件到它的中繼日志中。3）slave按照順序執(zhí)行中繼日志中的事件，將master的改變應(yīng)用到自己的數(shù)據(jù)庫(kù)中。

3.3.3 分表存儲(chǔ)

在數(shù)據(jù)量特別大的情況下，數(shù)據(jù)庫(kù)的讀取性能會(huì)有較大的降低，為了解決這個(gè)問(wèn)題可以將一張表的數(shù)據(jù)拆分到多張表上存儲(chǔ)[14]。

切分有垂直切分與水平切分，根據(jù)業(yè)務(wù)對(duì)表進(jìn)行分類然后分布到不同的數(shù)據(jù)庫(kù)上，這屬于對(duì)數(shù)據(jù)的垂直切分。切分時(shí)可按照模塊進(jìn)行分類，有時(shí)也可以根據(jù)數(shù)據(jù)量的大小來(lái)切分。垂直切分并不會(huì)縮表，所以依然存在著單庫(kù)的瓶頸，這時(shí)就需要用到水平切分。水平切分是根據(jù)某個(gè)字段的一些規(guī)則將原本放在一個(gè)表里的數(shù)據(jù)放在不同的數(shù)據(jù)庫(kù)里，就相當(dāng)于對(duì)表按照數(shù)據(jù)行來(lái)進(jìn)行切分。

隨著數(shù)據(jù)量的增大，先對(duì)表進(jìn)行水平切分，此時(shí)利用多塊硬盤來(lái)提升IO性能與存儲(chǔ)空間，成本比較低。數(shù)據(jù)庫(kù)到了需要垂直切分的階段，此時(shí)修改數(shù)據(jù)庫(kù)結(jié)構(gòu)的主要原因已經(jīng)不是數(shù)據(jù)量而是整個(gè)業(yè)務(wù)系統(tǒng)不能承受壓力了。若過(guò)早對(duì)數(shù)據(jù)庫(kù)進(jìn)行垂直切分需要重新構(gòu)建業(yè)務(wù)系統(tǒng)，工作量大，而水平切分不需要對(duì)業(yè)務(wù)做大量修改，所以在實(shí)際應(yīng)用時(shí)建議先考慮水平切分，然后再做垂直切分。

4 結(jié)束語(yǔ)

高并發(fā)服務(wù)器的設(shè)計(jì)需要從多方面考慮，若某個(gè)部分出現(xiàn)短板就會(huì)影響整體性能。本文從服務(wù)器集群、分布式、數(shù)據(jù)庫(kù)幾個(gè)方面入手設(shè)計(jì)服務(wù)器架構(gòu)，以提升服務(wù)器的可用性與并發(fā)性能。提高服務(wù)器性能的方式并不唯一，且不同的使用情景需要不同的架構(gòu)，除了文中的方案外，還可從其他部分優(yōu)化，比如使用緩存、動(dòng)靜分離、對(duì)熱點(diǎn)部分進(jìn)行優(yōu)化、對(duì)表的設(shè)計(jì)進(jìn)行優(yōu)化、對(duì)jvm等參數(shù)進(jìn)行調(diào)優(yōu)、使用CDN等等?；ヂ?lián)網(wǎng)正在高速發(fā)展，這使得高并發(fā)的場(chǎng)景變得越來(lái)越多。雖然各自解決高并發(fā)問(wèn)題使用的技術(shù)各不相同，但是遇到的各種問(wèn)題有很多都是類似的，故能夠?qū)e人的解決方案進(jìn)行參考，然后找到自己解決問(wèn)題的思路。希望本文提供的方案能夠有助于大家對(duì)高并發(fā)服務(wù)器搭建知識(shí)的學(xué)習(xí)。

參考文獻(xiàn)：

[1] 王亞楠，吳華瑞，黃鋒.高并發(fā)Web應(yīng)用系統(tǒng)的性能優(yōu)化分析與研究[J].計(jì)算機(jī)工程與設(shè)計(jì)，2014，35（8）5：2976-2981.

[2] 逄健，劉佳.摩爾定律發(fā)展述評(píng)[J].科技管理研究，2015，35（15）：46-50.

[3] 吳海明.基于Linux高可用性負(fù)載均衡集群技術(shù)的研究與應(yīng)用[J].科技創(chuàng)新與應(yīng)用，2018（36）：17-18.

[4] 李海軍.服務(wù)器集群技術(shù)綜述[J].電腦知識(shí)與技術(shù)，2013，9（22）：5018-5020.

[5] 劉金秀，陳怡華，谷長(zhǎng)樂(lè).基于Nginx的高可用Web系統(tǒng)的架構(gòu)研究與設(shè)計(jì)[J].現(xiàn)代信息科技，2019，3（11）：94-97.

[6] 金磐石.分布式架構(gòu)在銀行核心業(yè)務(wù)系統(tǒng)的應(yīng)用[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2017，26（6）：46-52.

[7] 趙然，朱小勇.微服務(wù)架構(gòu)評(píng)述[J].網(wǎng)絡(luò)新媒體技術(shù)，2019，8（1）：58-61，65.

[8] 熊永平.基于SpringBoot框架應(yīng)用開(kāi)發(fā)技術(shù)的分析與研究[J].電腦知識(shí)與技術(shù)，2019，15（36）：76-77.

[9] 周永圣，侯峰裕，孫雯，等.基于SpringCloud微服務(wù)架構(gòu)的進(jìn)銷存管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].工業(yè)控制計(jì)算機(jī)，2018，31（11）：129-130，133.

[10] 方永敢.微服務(wù)架構(gòu)的研究及小區(qū)生活服務(wù)平臺(tái)的實(shí)現(xiàn)[D].成都：電子科技大學(xué)，2020.

[11] 母鳳雯.數(shù)據(jù)庫(kù)索引技術(shù)概述[J].電腦知識(shí)與技術(shù)，2017，13（25）：9-11，13.

[12] 王麗娟，靳繼紅.基于MySQL的查詢優(yōu)化技術(shù)研究[J].電腦知識(shí)與技術(shù)，2017，13（30）：35-36.

[13] 劉建宏.MySQL數(shù)據(jù)庫(kù)優(yōu)化與集群[J].數(shù)字通信世界，2017（7）：47.

[14] 韋美雁，段華斌，周新林.大數(shù)據(jù)環(huán)境下的MySQL優(yōu)化技術(shù)探討[J].現(xiàn)代計(jì)算機(jī)（專業(yè)版），2018（30）：68-72.

【通聯(lián)編輯：謝媛媛】