LNMP生產(chǎn)服務(wù)器技術(shù)改進(jìn)

曾 棕 根

(寧波職業(yè)技術(shù)學(xué)院電子信息工程學(xué)院 浙江 寧波 315800)

0 引 言

LNMP架構(gòu)免費(fèi)開源、功能強(qiáng)大，是當(dāng)前最流行的Web服務(wù)器架構(gòu)，與大數(shù)據(jù)和人工智能服務(wù)器存在密切的關(guān)系。由于LNMP架構(gòu)技術(shù)牽涉面廣、安裝與配置非常復(fù)雜且可借鑒的高端經(jīng)驗(yàn)少，按照默認(rèn)配置無(wú)法發(fā)揮該架構(gòu)穩(wěn)定、安全和高效的特征。LNMP服務(wù)器出現(xiàn)安全漏洞、在訪問(wèn)高峰期網(wǎng)頁(yè)卡死甚至數(shù)據(jù)庫(kù)崩潰成為常態(tài)，因此對(duì)LNMP生產(chǎn)服務(wù)器進(jìn)行技術(shù)改進(jìn)成為當(dāng)前亟待解決的問(wèn)題。

歷經(jīng)七年對(duì)LNMP生產(chǎn)服務(wù)器的管理與深入研究，解決了LNMP架構(gòu)安裝、運(yùn)行中遇到的各種問(wèn)題，對(duì)該架構(gòu)進(jìn)行了全方位的技術(shù)改進(jìn)，使得該架構(gòu)安全、快速、抗擁塞。本文系統(tǒng)地論述了該架構(gòu)在上述三方面所做的深度技術(shù)改進(jìn)。

1 LNMP架構(gòu)的組成

LNMP架構(gòu)是指由Linux內(nèi)核的操作系統(tǒng)、Nginx服務(wù)器、MariaDB數(shù)據(jù)庫(kù)服務(wù)器和PHP腳本服務(wù)器組成的PHP動(dòng)態(tài)網(wǎng)站運(yùn)行架構(gòu)，組成該架構(gòu)的四個(gè)軟件都是免費(fèi)開源的[1]。生產(chǎn)環(huán)境下，推薦使用的Linux操作系統(tǒng)是CentOS-7 (1908)，其穩(wěn)定、快速、安全；Nginx是一款高性能低開銷的Web服務(wù)器，目前最新的穩(wěn)定版本是1.16.2[2]；MariaDB是MySQL數(shù)據(jù)庫(kù)的一個(gè)分支，由開源社區(qū)維護(hù)，代碼更新速度最為快速，目前最新穩(wěn)定版本為10.3.11； PHP網(wǎng)頁(yè)服務(wù)器則是用來(lái)編譯和運(yùn)行PHP腳本，目前最新版本為7.2.24。圖1為L(zhǎng)NMP架構(gòu)數(shù)據(jù)流動(dòng)示意圖。

圖1 LNMP架構(gòu)數(shù)據(jù)流動(dòng)示意圖

用戶總是在瀏覽器中發(fā)出PHP網(wǎng)頁(yè)查看請(qǐng)求，Nginx收到用戶的PHP程序調(diào)用請(qǐng)求后，將此請(qǐng)求發(fā)送給PHP-FPM服務(wù)器，PHP-FPM服務(wù)器則調(diào)用PHP進(jìn)程去編譯和運(yùn)行PHP程序，PHP程序則通過(guò)SQL指令從MariaDB數(shù)據(jù)庫(kù)中去存取所需信息，MariaDB將SQL指令運(yùn)行后以二維表的形式將結(jié)果返回給PHP進(jìn)程，PHP進(jìn)程則將記錄以HTML語(yǔ)法進(jìn)行包裝，PHP-FPM服務(wù)器會(huì)將此HTML文本傳送給Nginx服務(wù)器，Nginx服務(wù)器則將此HTML文本返回給客戶端瀏覽器，客戶端瀏覽器則解釋此HTML文本中的HTML標(biāo)簽，用戶即可從瀏覽器中看到此PHP程序的運(yùn)行結(jié)果。

由圖1可見，數(shù)據(jù)的流動(dòng)是以單一、固定的路徑傳輸?shù)?，?shù)據(jù)總是從客戶端瀏覽器中發(fā)出，經(jīng)過(guò)Nginx、PHP-FPM、MariaDB三項(xiàng)服務(wù)，最后按原路返回，構(gòu)成一個(gè)閉環(huán)。因此，要提高LNMP架構(gòu)的安全性和性能，就必須對(duì)LNMP架構(gòu)每一項(xiàng)服務(wù)進(jìn)行技術(shù)改進(jìn)。

2 安全性改進(jìn)

確保在互聯(lián)網(wǎng)環(huán)境下的訪問(wèn)安全是服務(wù)器建設(shè)中最重要的問(wèn)題。LNMP架構(gòu)服務(wù)器安全措施包括磁盤規(guī)劃、以編譯方式安裝最新源代碼、開放有限端口、限定登錄賬戶、規(guī)劃文件讀取權(quán)限和使用HTTPS訪問(wèn)協(xié)議等。

2.1 磁盤規(guī)劃

服務(wù)器上應(yīng)該使用多個(gè)物理磁盤，構(gòu)建某種磁盤陣列，某個(gè)磁盤損壞時(shí)可以直接用新磁盤替換，從而不影響服務(wù)器的運(yùn)行。例如RAID 5，服務(wù)器上有3個(gè)以上硬盤即可做此模式，一份數(shù)據(jù)分成3份寫，如果一個(gè)硬盤壞了，其他數(shù)據(jù)不會(huì)受損失，抽出壞的硬盤再插入新的硬盤即可[3]。

在安裝CentOS操作系統(tǒng)時(shí)，應(yīng)該將系統(tǒng)所需的不同的目錄分別安裝在不同的物理磁盤分區(qū)上，以避免某一個(gè)目錄出現(xiàn)錯(cuò)誤時(shí)殃及其他目錄或整個(gè)磁盤。表1列出了不同分區(qū)和所需的磁盤空間，其中/boot引導(dǎo)分區(qū)用來(lái)存儲(chǔ)Linux內(nèi)核，/根分區(qū)用來(lái)存儲(chǔ)CentOS操作系統(tǒng)所需的其他文件，而服務(wù)器中所安裝的其他軟件如Nginx、MariaDB、PHP及其需要保存的數(shù)據(jù)則放在/opt分區(qū)內(nèi)。還可以進(jìn)一步細(xì)化，將/根分區(qū)中的用戶目錄和臨時(shí)目錄等放于不同的分區(qū)中。這樣確保了運(yùn)行中出現(xiàn)的問(wèn)題限定在某一個(gè)分區(qū)內(nèi)，能最大限度地減少損失。

如果LNMP服務(wù)器配有專用的大容量磁盤陣列服務(wù)器時(shí)，可以使用網(wǎng)線將二者的網(wǎng)卡直連，兩塊直連網(wǎng)卡使用192.168.0.x地址組建成一個(gè)局域網(wǎng)，在LNMP服務(wù)器中采用mount命令將磁盤陣列服務(wù)器掛載到CentOS操作系統(tǒng)的一個(gè)目錄中，如mount 192.168.0.100:/vol1/mnt/array，最后將CentOS操作系統(tǒng)中LNMP架構(gòu)的用戶數(shù)據(jù)或者備份數(shù)據(jù)直接寫在/mnt/array即磁盤陣列設(shè)備上，這樣就確保了LNMP架構(gòu)在物理層面上的安全性。

2.2 編譯安裝最新源碼

LNMP架構(gòu)中Nginx、MariaDB和PHP都是開源軟件，官方一直在做功能、性能或安全性上的改進(jìn)，因此不宜采用LNMP一鍵安裝包或RPM安裝包，而應(yīng)去官網(wǎng)下載最新的適用于Linux操作系統(tǒng)的源代碼包，直接在CentOS操作系統(tǒng)上現(xiàn)場(chǎng)配置、編譯和安裝。這樣可以確保得到最新的穩(wěn)定版本，而且可以生成最適合服務(wù)器CPU運(yùn)行的二進(jìn)制代碼。同時(shí)，管理員也清楚每個(gè)軟件都安裝到哪個(gè)文件夾中，便于日后的升級(jí)和維護(hù)。

CentOS操作系統(tǒng)安裝好后，應(yīng)該立即使用yum-y update命令對(duì)操作系統(tǒng)進(jìn)行一次全面更新，而且要定期使用這個(gè)命令更新系統(tǒng)。系統(tǒng)更新后，采用rpm-q kernel查看是否升級(jí)了內(nèi)核，若升級(jí)，則需重啟操作系統(tǒng)，重啟后會(huì)自動(dòng)運(yùn)行最新內(nèi)核。這時(shí)，使用uname-a查看正在運(yùn)行的內(nèi)核，并用rpm-e將舊版本的內(nèi)核刪除，否則分配給內(nèi)核的200 MB磁盤空間會(huì)不夠用，下次將無(wú)法升級(jí)新版內(nèi)核。

還要立即升級(jí)CentOS操作系統(tǒng)中的gcc、cmake和libzip，這三個(gè)軟件都是編譯其他軟件(如Nginx、MariaDB和PHP)所必須的。

通過(guò)g++ --version命令，可以看到CentOS中g(shù)++的版本為g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)，由于該版本太老，因此須到官網(wǎng)(https://gcc.gnu.org/)上下載gcc-9.2.0.tar.gz源代碼編譯安裝。安裝完成后，必須要把/usr/lib64/中的libstdc++.so.6鏈接到新版本的/usr/local/lib64/libstdc++.so.6.0.27文件，否則g++編譯器將無(wú)法使用gcc-9.2.0。

從cmake官方網(wǎng)站(https://cmake.org/download/)上下載最新的cmake-3.15.1.tar.gz源代碼包，編譯安裝完成后，調(diào)用cmake-version時(shí)，會(huì)出現(xiàn)“段錯(cuò)誤 (core dumped)”而無(wú)法使用，執(zhí)行hash -r命令可以解決此錯(cuò)誤。

libzip是編譯PHP所必須的支持包，CentOS默認(rèn)沒有安裝libzip，要去官網(wǎng)(https://libzip.org/)下載最新版本的libzip-1.5.2.tar.gz源代碼包，編譯安裝后，運(yùn)行l(wèi)ibzip時(shí)會(huì)出現(xiàn)找不到 zipconf.h的錯(cuò)誤，還需復(fù)制/usr/local/lib/libzip/include/zipconf.h到/usr/local/include/zipconf.h位置。

Nginx、MariaDB和PHP都需要從官網(wǎng)上下載最新源代碼，然后在本機(jī)上現(xiàn)場(chǎng)編譯安裝，Nginx安裝在/opt中，而MariaDB和PHP安裝在/usr/local/文件夾中。要定期關(guān)注這三個(gè)軟件的更新情況，并要隨官方的修訂及時(shí)更新它們，以確保最近發(fā)現(xiàn)的漏洞能被及時(shí)修復(fù)。

特別地，以前PHP使用Oracle官方發(fā)布的MySQL驅(qū)動(dòng)libmysql與MariaDB服務(wù)進(jìn)行通信，為了避免版權(quán)問(wèn)題和程序的非可控性，PHP已自行開發(fā)了mysqlnd本地驅(qū)動(dòng)替代libmysql，所以不再需要先安裝MariaDB再安裝PHP了，傳統(tǒng)的安裝PHP的方式中，在編譯PHP時(shí)，需要指定以下幾項(xiàng)：

--with-mysql=/usr/local/mysql

--with-mysqli=/usr/local/mysql/bin/mysql_config

--with-pdo-mysql=/usr/local/mysql

現(xiàn)在使用mysqlnd驅(qū)動(dòng)，編譯PHP時(shí)，上述本條配置應(yīng)該改為：

--with-mysql=mysqlnd

--with-mysqli=mysqlnd

--with-pdo-mysql=mysqlnd

安裝完成后，如果在phpinfo輸出的mysqli項(xiàng)中發(fā)現(xiàn)Client API library version為mysqlnd 5.0.12-dev-20150407,說(shuō)明mysqlnd驅(qū)動(dòng)mysqlnd 5.0.12-dev-20150407已經(jīng)安裝成功，PHP腳本可以使用pdo_mysql和mysqli這兩種API Extensions通過(guò)mysqlnd驅(qū)動(dòng)與MariaDB數(shù)據(jù)庫(kù)服務(wù)器通信。

CentOS操作系統(tǒng)中各種軟件都采用OpenSSL函數(shù)庫(kù)進(jìn)行加密，但OpenSSL在2014年4月8日曝光了一個(gè)名為heartbleed的漏洞。利用該漏洞，約30%以https開頭網(wǎng)址的用戶登錄賬號(hào)密碼通過(guò)網(wǎng)絡(luò)被竊取[4]。所以必須從OpenSSL官網(wǎng)(https://www.openssl.org)下載，將OpenSSL 1.0.2k-fips 26 Jan 2017升級(jí)為OpenSSL 1.1.1d 10 Sep 2019。同時(shí)，使用Open-SSL加密函數(shù)庫(kù)的Nginx、PHP和OpenSSH都必須采用新安裝的OpenSSL加密函數(shù)庫(kù)重新編譯安裝，以確保網(wǎng)站訪問(wèn)安全和服務(wù)器SSH遠(yuǎn)程訪問(wèn)安全。

2.3 服務(wù)器訪問(wèn)限制

LNMP服務(wù)器編譯安裝好后，為確保服務(wù)器在互聯(lián)網(wǎng)上的訪問(wèn)安全，必須在開放有限端口、限定登錄賬戶、規(guī)劃文件讀取權(quán)限等方面作出限制。

通常情況下，服務(wù)器只開放80號(hào)Web服務(wù)端口、22號(hào)SSH遠(yuǎn)程訪問(wèn)端口和443號(hào)https訪問(wèn)端口，同時(shí)關(guān)閉不需要的服務(wù)，這樣可以減少暴露在互聯(lián)網(wǎng)中的漏洞。同時(shí)，刪除firewalld.service防火墻，安裝iptables-services防火墻，這樣易于使用。

同時(shí)，在CentOS操作系統(tǒng)中，要禁止在ssh中使用root直接登錄，要求用戶先用普通賬號(hào)登錄CentOS操作系統(tǒng)，再通過(guò)su命令輸入root賬號(hào)密碼才可以登錄root賬號(hào)，這樣可以防止針對(duì)root賬號(hào)的遠(yuǎn)程暴力破解。因此，首先要在CentOS中創(chuàng)建一個(gè)普通賬號(hào)，再在/etc/ssh/sshd_config中設(shè)置PermitRootLogin no即可。

在PHP-FPM服務(wù)器的配置文件php-fpm.conf中，設(shè)置user=www和group=www，使得只有www組的www用戶才可能訪問(wèn)PHP-FPM服務(wù)。

MariaDB數(shù)據(jù)庫(kù)服務(wù)必須指定允許來(lái)自某臺(tái)客戶機(jī)的某個(gè)賬號(hào)來(lái)連接自己。在MySQL數(shù)據(jù)庫(kù)的user表中，只留下Host為localhost和127.0.0.1和User為root的這兩條記錄，以此只允許來(lái)自當(dāng)前服務(wù)器的root賬號(hào)連接MariaDB數(shù)據(jù)庫(kù)服務(wù)，從而確保了MariaDB數(shù)據(jù)庫(kù)服務(wù)的安全。

對(duì)CentOS操作系統(tǒng)中每個(gè)文件和文件夾，都可以通過(guò)chgrp命令設(shè)置其隸屬于哪個(gè)組，通過(guò)chown命令來(lái)設(shè)置它隸屬于哪個(gè)用戶，并通過(guò)chmod命令來(lái)設(shè)置所有者、所屬組其他用戶和其他組對(duì)它的操作權(quán)限。操作權(quán)限用4、2、1數(shù)字來(lái)代表，4表示讀取權(quán)限，2表示寫入權(quán)限，1表示執(zhí)行權(quán)限[5]。如775這三個(gè)數(shù)字代表?yè)碛姓?、組用戶、其他用戶的權(quán)限分別為7=4+2+1、7=4+2+1、5=4+1，第一個(gè)數(shù)字7表示所有者具有讀取、寫入和執(zhí)行權(quán)限，第二個(gè)數(shù)字7表示與所有者同組的用戶具有讀取、寫入和執(zhí)行權(quán)限，第三個(gè)數(shù)字5表示其他用戶具有讀取和執(zhí)行權(quán)限。對(duì)訪問(wèn)用戶、訪問(wèn)組和其他組的操作權(quán)限限定，使得CentOS操作系統(tǒng)中的文件訪問(wèn)得到有效地保護(hù)。

2.4 使用HTTPS訪問(wèn)協(xié)議

Nginx默認(rèn)采用HTTP協(xié)議與客戶端瀏覽器通信，該協(xié)議采用明文方式傳輸網(wǎng)頁(yè)和用戶賬號(hào)密碼，容易受到網(wǎng)絡(luò)中間人的竊密，所以極不安全。Nginx服務(wù)器必須采用HTTPS安全傳輸協(xié)議與用戶端瀏覽器通信。用戶在首次訪問(wèn)Nginx服務(wù)器時(shí)，Nginx服務(wù)器會(huì)將使用私鑰加密的包含對(duì)應(yīng)公鑰的數(shù)字證書CA發(fā)送到客戶端瀏覽器中，以后用戶發(fā)送訪問(wèn)請(qǐng)求給Nginx服務(wù)器時(shí)，先用瀏覽器中的數(shù)字證書中的公鑰對(duì)信息進(jìn)行加密，再發(fā)送給Nginx服務(wù)器；Nginx服務(wù)器在接收到用戶的訪問(wèn)信息后，用服務(wù)器上的對(duì)應(yīng)的私鑰解開信息；在完成用戶提交的請(qǐng)求后，將相應(yīng)網(wǎng)頁(yè)用服務(wù)器中對(duì)應(yīng)的私鑰加密后，再發(fā)送給客戶端瀏覽器；客戶端瀏覽器接收到信息后，會(huì)用瀏覽器中該Nginx服務(wù)器對(duì)應(yīng)的數(shù)字證書中的公鑰解密，完成雙向加密通信。

將私鑰和包含對(duì)應(yīng)公鑰的數(shù)字證書拷貝到Nginx服務(wù)器上后，只需在Nginx的配置文件中編寫如下配置即可：

server {

listen 443 ssl;

server_name localhost;

ssl_certificate /etc/pki/tls/certs/server.cer;

ssl_certificate_key /etc/pki/tls/private/server.key;

重啟Nginx服務(wù)器后，客戶端瀏覽器就可以采用https://方式來(lái)訪問(wèn)網(wǎng)站了，這樣確保了通信安全。

3 處理速度改進(jìn)

對(duì)軟件的運(yùn)行方式進(jìn)行優(yōu)化，才可以充分發(fā)揮服務(wù)器硬件性能，使得服務(wù)器處理Web請(qǐng)求的速度大大加快，從而避免服務(wù)器橫向擴(kuò)展，一方面降低了服務(wù)器購(gòu)置成本，另一方面降低了軟件管理上的復(fù)雜度?？梢詮娜缦聨讉€(gè)方面進(jìn)行技術(shù)改進(jìn)來(lái)加快LNMP服務(wù)器的處理速度：用內(nèi)存代替磁盤、使用PHP緩存、多進(jìn)程并行處理、優(yōu)化InnoDB存儲(chǔ)引擎性能和壓縮后再傳輸。

3.1 用內(nèi)存代替磁盤

內(nèi)存的存取速度遠(yuǎn)高于磁盤的存取速度，因此把網(wǎng)站的程序文件和數(shù)據(jù)庫(kù)直接放在內(nèi)存中，將會(huì)大大提高網(wǎng)站的訪問(wèn)速度。目前最大容量?jī)?nèi)存是單條128 GB，一塊CPU可以插8條內(nèi)存，也就是1 TB。如果是雙路CPU，最大內(nèi)存可達(dá)8 TB。網(wǎng)站代碼磁盤占用量一般在1 GB以內(nèi)，MariaDB數(shù)據(jù)庫(kù)的數(shù)據(jù)文件一般在20 GB以內(nèi)，因此一臺(tái)64 GB的服務(wù)器就可以將網(wǎng)站和數(shù)據(jù)庫(kù)全部放入內(nèi)存直接存取。

將磁盤文件放入內(nèi)存的方法，就是使用TMPFS文件系統(tǒng)。TMPFS，即臨時(shí)文件系統(tǒng)，是最好的基于RAM的文件系統(tǒng)，是由Linux內(nèi)核的VM子系統(tǒng)管理的。TMPFS初始容量默認(rèn)是物理內(nèi)存大小的一半[6]。指定的TMPFS內(nèi)存空間并不會(huì)被鎖定獨(dú)占，只有掛載存儲(chǔ)文件后才會(huì)占用相應(yīng)大小的空間。

使用TMPFS文件系統(tǒng)最大的風(fēng)險(xiǎn)是意外掉電后該文件系統(tǒng)中的文件會(huì)全部消失。為了防止服務(wù)器意外掉電，確保數(shù)據(jù)安全，一方面定期自動(dòng)備份數(shù)據(jù)庫(kù)，另一方面，確保服務(wù)器上的雙電源都有效。使用通信型UPS不間斷電源通過(guò)聯(lián)機(jī)USB線實(shí)時(shí)監(jiān)測(cè)市電，一旦發(fā)現(xiàn)斷電，立即會(huì)切換到電源供電，并自動(dòng)將內(nèi)存中的文件保存到磁盤中，再自動(dòng)關(guān)閉CentOS服務(wù)器，最后自動(dòng)關(guān)閉UPS。整個(gè)處理過(guò)程只需5分鐘，所以UPS只需600 W的功率，如LADIS H1000 600 W型UPS。

3.2 使用PHP緩存

使用PHP緩存，可以大大減少同一網(wǎng)頁(yè)再次被訪問(wèn)時(shí)PHP的編譯時(shí)間開銷，從而大大加快網(wǎng)頁(yè)訪問(wèn)速度。

PHP是解釋型語(yǔ)言而非編譯型語(yǔ)言，每次調(diào)用PHP文件時(shí)，翻譯器先將PHP文件翻譯成易于執(zhí)行的中間代碼(即opcode字節(jié)碼)后再執(zhí)行，執(zhí)行完后所占用的內(nèi)存馬上被釋放，基本上所有數(shù)據(jù)包括opcode字節(jié)碼在此時(shí)都被銷毀。opcode字節(jié)碼并非目標(biāo)機(jī)器代碼，不能直接在硬件上運(yùn)行。該P(yáng)HP文件第二次被調(diào)用時(shí)，同樣還是會(huì)被重新轉(zhuǎn)換為字節(jié)碼，但很多時(shí)候文件內(nèi)容幾乎是一樣的，比如靜態(tài)HTML文件生成字節(jié)碼后其內(nèi)容很久都不會(huì)改變，這樣就非常浪費(fèi)時(shí)間。

為了避免上述問(wèn)題，PHP開發(fā)了Opcache組件。該組件的前身是Optimizer+，它是PHP的官方公司Zend開發(fā)的一款閉源但可以免費(fèi)使用的PHP優(yōu)化加速組件，2013年3月中旬Optimizer+改名為Opcache，在PHP源代碼中已經(jīng)包含了該組件。啟用PHP的Opcache組件后，PHP會(huì)緩存PHP字節(jié)碼，使得再次調(diào)用相同的PHP文件時(shí)，無(wú)須編譯，直接從Opcache緩存中獲取字節(jié)碼去運(yùn)行；同時(shí)，Opcache還應(yīng)用了一些代碼優(yōu)化模式，使得代碼執(zhí)行更快，從而加速PHP的執(zhí)行，使CPU消耗少了許多，PHP網(wǎng)頁(yè)的響應(yīng)時(shí)間也大幅縮短。圖2是PHP程序使用Opcache緩存后的生命周期示意圖。

可以看到，傳統(tǒng)的PHP的整個(gè)運(yùn)行過(guò)程為：Request請(qǐng)求(Nginx等)→Zend引擎讀取.php文件→掃描其詞典和表達(dá)式→解析文件→創(chuàng)建要執(zhí)行的計(jì)算機(jī)代碼(稱為Opcode) →執(zhí)行Opcode→ Response返回。使用了Opcache組件后，如果PHP網(wǎng)頁(yè)沒有變化，就直接從Opcache緩存中讀取中間代碼，再去執(zhí)行，避免了CPU的重復(fù)計(jì)算。

3.3 多進(jìn)程并行處理

為了充分利用CPU多核特征，Nginx和PHP都設(shè)計(jì)為多進(jìn)程的工作方式，以提高處理效率。從圖3所示的LNMP架構(gòu)示意圖中可以看出，客戶端瀏覽器與Nginx管理進(jìn)程交互后，Nginx監(jiān)控進(jìn)程就會(huì)把具體的工作任務(wù)分配給一個(gè)空閑的Nginx工作進(jìn)程，對(duì)于用戶的PHP網(wǎng)頁(yè)請(qǐng)求，Nginx工作進(jìn)程會(huì)把PHP的編譯和運(yùn)行工作交給PHP-FPM管理進(jìn)程，PHP-FPM則把具體的工作任務(wù)分配給一個(gè)空閑的PHP FastCGI工作進(jìn)程，PHP FastCGI會(huì)把要訪問(wèn)的PHP網(wǎng)頁(yè)編譯并運(yùn)行，并存取MariaDB數(shù)據(jù)庫(kù)，最后把結(jié)果組織成HTML超文本，回傳給用戶端瀏覽器。

圖3 LNMP架構(gòu)示意圖

因此，為Nginx和PHP-FPM設(shè)置合適的工作進(jìn)程數(shù)量和工作方式，可以加快LNMP整體架構(gòu)的處理速度。Nginx通過(guò)worker_processes指令本配置開啟多少個(gè)工作進(jìn)程，其數(shù)量一般為CPU的邏輯核心數(shù)量(即CPU超線程總量)。例如，雙CPU共16個(gè)物理核心，每個(gè)物理核心上有2個(gè)超線程，那么worker_processes應(yīng)該設(shè)置為32。

PHP-FPM進(jìn)程池(pm)有static(靜態(tài))、dynamic(動(dòng)態(tài))和ondemand(按需)三種PHP FastCGI工作進(jìn)程啟動(dòng)方式。

如果將pm設(shè)置為static，那么PHP FastCGI工作進(jìn)程始終保持pm.max_children個(gè)數(shù)目。

如果將pm設(shè)置為dynamic，那么PHP-FPM管理進(jìn)程首先啟動(dòng)pm.start_servers個(gè)工作進(jìn)程，遇到訪問(wèn)高峰時(shí)，會(huì)自動(dòng)增加工作進(jìn)程數(shù)量，確保任何時(shí)候都有pm.min_spare_servers個(gè)空閑進(jìn)程存在。訪問(wèn)高峰過(guò)后，如果空閑進(jìn)程多于pm.max_spare_servers個(gè)時(shí)，多余的空閑進(jìn)程會(huì)被殺掉；而同時(shí)能存活的最大工作進(jìn)程總量為pm.max_children個(gè)。

如果將pm設(shè)置為ondemand，那么剛開始時(shí)php-fpm管理進(jìn)程不會(huì)創(chuàng)建任何工作進(jìn)程，當(dāng)有請(qǐng)求時(shí)才會(huì)創(chuàng)建；當(dāng)進(jìn)程在pm.process_idle_timeout秒后還處于空閑狀態(tài)就會(huì)被殺掉，默認(rèn)時(shí)長(zhǎng)為10秒。因此，在完全空閑時(shí)，只有一個(gè)PHP-FPM管理進(jìn)程存在。在此模式下，能同時(shí)存活的工作進(jìn)程最大數(shù)量為pm.max_children個(gè)。

要根據(jù)具體情況來(lái)選擇這三種PHP-FPM的進(jìn)程管理方式。如果內(nèi)存足夠大，可以選用static方式，按一個(gè)PHP進(jìn)程占用30 MB內(nèi)存的標(biāo)準(zhǔn)來(lái)確定PHP進(jìn)程設(shè)置數(shù)量，由于不用在使用時(shí)臨時(shí)創(chuàng)建PHP進(jìn)程，因此這種方式效率最高，作為首選方式。如果服務(wù)器內(nèi)存不寬裕，則可以選用dynamic方式，動(dòng)態(tài)應(yīng)付訪問(wèn)高峰，能兼顧內(nèi)存與效率。ondemand方式把節(jié)約內(nèi)存放在首位，其缺點(diǎn)是遇到訪問(wèn)高峰或者如果pm.process_idle_timeout的值太短的話，服務(wù)器會(huì)頻繁創(chuàng)建進(jìn)程，用戶會(huì)感受到明顯的網(wǎng)絡(luò)延遲。

3.4 優(yōu)化InnoDB存儲(chǔ)引擎性能

MariaDB的存儲(chǔ)引擎采用插件式工作方式，而InnoDB存儲(chǔ)引擎作為事務(wù)型數(shù)據(jù)庫(kù)的首選引擎，支持事務(wù)安全表(ACID)，能與MariaDB數(shù)據(jù)庫(kù)系統(tǒng)完美結(jié)合。MariaDB系統(tǒng)接收的用戶SQL請(qǐng)求和傳輸?shù)臄?shù)據(jù)最后都要通過(guò)InnoDB存儲(chǔ)引擎與磁盤設(shè)備交互。LNMP架構(gòu)中用戶請(qǐng)求數(shù)據(jù)鏈最后都要經(jīng)過(guò)InnoDB存儲(chǔ)引擎，因此InnoDB數(shù)據(jù)庫(kù)的存取性能決定了LNMP架構(gòu)的性能。MariaDB中的InnoDB實(shí)際上是XtraDB，它是InnoDB的增強(qiáng)版，但MariaDB的配置文件中仍然標(biāo)記為InnoDB。InnoDB存儲(chǔ)引擎采用緩沖池來(lái)緩存數(shù)據(jù)，最后按設(shè)定的時(shí)間間隔將數(shù)據(jù)寫到磁盤中去持久化。

設(shè)置InnoDB的緩存池的大小innodb_buffer_pool_size為所有內(nèi)存的80%以上。當(dāng)然，需要除去CentOS操作系統(tǒng)、PHP進(jìn)程和Nginx進(jìn)程的內(nèi)存開銷，余下的都設(shè)置為InnoDB的緩存。在64 GB的內(nèi)存下，一般16 GB InnoDB緩存就足夠使用了，其中操作系統(tǒng)、TMPFS文件系統(tǒng)、Nginx進(jìn)程和PHP進(jìn)程分配16 GB內(nèi)存，其余32 GB全部分配給MariaDB的線程。

innodb_log_files_in_group日志文件分為3組就足夠了[7]。此外，為了避免在日志文件覆蓋時(shí)產(chǎn)生不必要的緩沖池刷新活動(dòng)，每個(gè)日志文件的大小應(yīng)該正好占緩存大小的25%。這樣，innodb_log_file_size正好設(shè)置為innodb_buffer_pool_size的1/12。

假如InnoDB緩沖的大小為16 GB時(shí)，每個(gè)innodb_log_file_size就是1 365 MB了。

InnoDB內(nèi)核中允許的線程數(shù)量依賴服務(wù)器硬件性能，設(shè)置太高會(huì)導(dǎo)致線程抖動(dòng)。一般將innodb_thread_concurrency設(shè)置為16即可。

InnoDB存儲(chǔ)引擎中用來(lái)同步操作系統(tǒng)I/O的寫線程innodb_write_io_threads和讀線程innodb_read_io_threads在UNIX/Linux操作系統(tǒng)上都設(shè)置為8個(gè)。

innodb_flush_log_at_trx_commit的值可以設(shè)置為0、1或2。設(shè)置為2時(shí)，每個(gè)交易在提交時(shí)都會(huì)寫日志到文件緩存中，且大約每秒將日志文件緩存刷新到磁盤中去持久化，這樣使得InnoDB的日志存盤時(shí)間開銷達(dá)到最少，又兼具數(shù)據(jù)安全。

3.5 壓縮后再傳輸

經(jīng)過(guò)前面的LNMP服務(wù)器性能優(yōu)化后，處理PHP頁(yè)面的速度得到了加快，訪問(wèn)LNMP架構(gòu)的性能瓶頸就落在網(wǎng)頁(yè)從Nginx服務(wù)器傳輸?shù)接脩魹g覽器的網(wǎng)絡(luò)帶寬上了。HTTP協(xié)議使用gzip壓縮網(wǎng)頁(yè)內(nèi)容，能極大減少傳輸內(nèi)容的大小，從而使網(wǎng)頁(yè)訪問(wèn)速度得到大幅提升。

gzip是GNUzip的縮寫，它是一個(gè)GNU自由軟件的文件壓縮程序，由Jean-loup Gailly和Mark Adler一起開發(fā)。其工作原理是：在一個(gè)文本文件中找出類似的字符串，并臨時(shí)替換它們，使整個(gè)文件變小。這種形式的壓縮對(duì)Web來(lái)說(shuō)非常適合， 因?yàn)镠TML和CSS文件通常包含大量的重復(fù)的字符串，例如空格、標(biāo)簽。檢測(cè)表明，Nginx啟用gzip壓縮后，網(wǎng)頁(yè)字節(jié)數(shù)縮小為原先的20%，其壓縮率高達(dá)80%，有效減少了網(wǎng)絡(luò)帶寬開銷，大幅提高了網(wǎng)頁(yè)的瀏覽速度。

gzip的壓縮過(guò)程如下：

(1) 瀏覽器發(fā)送HTTP Request給Web服務(wù)器,Request中有Accept-Encoding: gzip、deflate字符串，它告訴服務(wù)器，當(dāng)前的瀏覽器支持gzip壓縮。

(2) Web服務(wù)器接到Request后， 生成原始的Response,其中有原始的Content-Type和Content-Length。

(3) Web服務(wù)器通過(guò)gzip，來(lái)對(duì)Response進(jìn)行編碼， 編碼后header中有Content-Type和Content-Length(壓縮后的大小)，并且增加了Content-Encoding:gzip字符串,然后把Response發(fā)送給瀏覽器。

(4) 瀏覽器接到Response后，根據(jù)Content-Encoding:gzip字符串來(lái)對(duì)Response進(jìn)行解碼，獲取到原始Response后，顯示出網(wǎng)頁(yè)。

Nginx服務(wù)器是通過(guò)ngx_http_gzip_module、ngx_http_gzip_static_module、ngx_http_gunzip_module三個(gè)模塊對(duì)指令進(jìn)行解析處理。其中：ngx_http_gzip_module模塊對(duì)Response進(jìn)行壓縮；ngx_http_gzip_static_module負(fù)責(zé)搜索和發(fā)送經(jīng)過(guò)gzip處理的數(shù)據(jù)；ngx_http_gunzip_module用于對(duì)后端服務(wù)器或者預(yù)壓縮數(shù)據(jù)解壓，為了防止瀏覽器不能解壓，用此模塊解壓。

Nginx服務(wù)器中，gzip的壓縮級(jí)別gzip_comp_level可以設(shè)置為1～9級(jí)，級(jí)別越高，壓縮率更高，但服務(wù)器的CPU開銷也越大，訪問(wèn)高峰時(shí)，會(huì)影響LNMP架構(gòu)的整體性能。同時(shí)，由于壓縮級(jí)別越高，壓縮比提高并不是非常明顯，所以需要權(quán)衡壓縮比與CPU開銷增長(zhǎng)之間的關(guān)系，當(dāng)gzip_comp_level設(shè)置為6時(shí)，性價(jià)比最好。

Nginx通過(guò)在nginx.conf配置文件中添加gzip on指令來(lái)啟用gzip壓縮功能。為了避免對(duì)于訪問(wèn)同一個(gè)文件時(shí)被重復(fù)壓縮，可以開啟靜態(tài)壓縮模塊ngx_http_gzip_static_module， 在使用gzip_static on 指令后，Nginx會(huì)直接讀取之前已經(jīng)壓縮好的文件(文件名為*.gz)，而不是現(xiàn)場(chǎng)動(dòng)態(tài)壓縮，這樣再次加快了網(wǎng)頁(yè)訪問(wèn)速度。

4 抗擁塞改進(jìn)

上文對(duì)LNMP架構(gòu)各個(gè)環(huán)節(jié)的優(yōu)化最大可能地縮短了服務(wù)器處理延遲和線路處理延遲，使服務(wù)器能在0.5秒左右完成單個(gè)用戶的HTTP請(qǐng)求處理的全部環(huán)節(jié)，用戶獲得了極快的網(wǎng)頁(yè)響應(yīng)體驗(yàn)。

但當(dāng)LNMP架構(gòu)遇到瞬間大量的HTTP請(qǐng)求時(shí)，服務(wù)器就會(huì)出現(xiàn)響應(yīng)緩慢、卡死甚至數(shù)據(jù)庫(kù)服務(wù)器崩潰的典型現(xiàn)象。因此，對(duì)服務(wù)器進(jìn)行抗擁塞改進(jìn)成為整個(gè)LNMP架構(gòu)服務(wù)器技術(shù)改進(jìn)的重中之重。

實(shí)踐表明，遇到訪問(wèn)高峰時(shí)，服務(wù)器出現(xiàn)擁塞的原因在于：(1) MariaDB數(shù)據(jù)庫(kù)默認(rèn)采用了實(shí)驗(yàn)室模式的線程模型，使得訪問(wèn)高峰時(shí)響應(yīng)緩慢；(2) PHP工作進(jìn)程數(shù)過(guò)多，導(dǎo)致MariaDB連接數(shù)同步變大，造成數(shù)據(jù)庫(kù)服務(wù)崩潰。

4.1 MariaDB采用線程池模型

PHP與MariaDB建立連接后，MariaDB通過(guò)工作線程來(lái)處理來(lái)自PHP的請(qǐng)求。由于MariaDB數(shù)據(jù)庫(kù)默認(rèn)的線程模型是one-thread-per-connection，即會(huì)為每個(gè)PHP-MariaDB連接創(chuàng)建一個(gè)獨(dú)立的線程，處理PHP請(qǐng)求的任務(wù)完成后，該線程的生命周期就結(jié)束了。遇訪問(wèn)高峰時(shí)，MariaDB創(chuàng)建的線程數(shù)量激增，導(dǎo)致操作系統(tǒng)頻繁的上下文切換和對(duì)系統(tǒng)資源的競(jìng)爭(zhēng)，造成訪問(wèn)阻塞，LNMP架構(gòu)吞吐量急劇下降，直到無(wú)法正常提供HTTP服務(wù)。

Oracle公司的MySQL 5.5商用版采用線程池插件(Thread Pool Plugin)有效地解決了這個(gè)問(wèn)題。由開源社區(qū)維護(hù)的MariaDB從5.5版本開始內(nèi)建了線程池(Thread Pool)，先將連接分配到不同的組的隊(duì)列里，以語(yǔ)句(statement)為最小單位，排隊(duì)處理用戶的SQL請(qǐng)求，不光減少了同時(shí)運(yùn)行的線程的數(shù)量，還減少了上下文切換的次數(shù)；尤其是通過(guò)優(yōu)先隊(duì)列和普通隊(duì)列運(yùn)行機(jī)制，保證了最短時(shí)間內(nèi)完成對(duì)一個(gè)事物(transaction)的處理，減少了并行處理事務(wù)的機(jī)率，最大可能地防止了對(duì)熱點(diǎn)資源的競(jìng)爭(zhēng)產(chǎn)生死鎖；同時(shí)，線程的復(fù)用降低了創(chuàng)建和銷毀線程的CPU開銷，使得在訪問(wèn)高峰時(shí)MariaDB數(shù)據(jù)庫(kù)能保持恒定的最高的吞吐量，有效解決了阻塞問(wèn)題[8]。

為了適應(yīng)不同的運(yùn)行場(chǎng)景，MariaDB線程池提供了以下8個(gè)可調(diào)節(jié)參數(shù)：

thread_handling=pool-of-threads

thread_pool_size=32

thread_pool_priority=auto

thread_pool_prio_kickup_timer=1 000

thread_pool_stall_limit=60 ms

thread_pool_oversubscribe=10

thread_pool_max_threads=65 536

thread_pool_idle_timeout=500

通常只需要在MariaDB的配置文件my.cnf中設(shè)置thread_handling=pool-of-threads線程池就能很好地運(yùn)行了，其余7個(gè)參數(shù)MariaDB默認(rèn)會(huì)直接復(fù)制CentOS操作系統(tǒng)的線程池運(yùn)行參數(shù)。

線程池通過(guò)使用分組的方法來(lái)限制和平衡并發(fā)，隔離了用戶連接和SQL請(qǐng)求語(yǔ)句，高優(yōu)先級(jí)隊(duì)列使一個(gè)完整的事務(wù)能盡快完成，減少了并行事務(wù)的數(shù)量，最大可能降低事務(wù)對(duì)熱點(diǎn)資源的搶占，同時(shí)使用Timer定時(shí)線程防止線程組運(yùn)行停滯，實(shí)現(xiàn)了高并發(fā)下平穩(wěn)的高吞吐量，防止LNMP架構(gòu)訪問(wèn)高峰時(shí)的阻塞現(xiàn)象。

Thread pool取得了良好的應(yīng)用效果，根據(jù)Oracle MySQL官方的性能測(cè)試：在并發(fā)達(dá)到128個(gè)連接以后，沒有線程池的MySQL性能會(huì)迅速降低。使用線程池以后，性能不會(huì)出現(xiàn)波動(dòng)，會(huì)一直保持在較好的狀態(tài)運(yùn)行。在讀寫模式下，128個(gè)連接以后，有線程池的MySQL比沒有線程池的MySQL性能高出60倍。在只讀模式下，512個(gè)連接以后，有線程池的MySQL比沒有線程池的MySQL性能高出18倍。

4.2 固定PHP進(jìn)程數(shù)量

在LNMP架構(gòu)中，來(lái)自客戶端的請(qǐng)求通過(guò)Nginx傳達(dá)到PHP-FPM服務(wù)器中，PHP-FPM服務(wù)器將這些用戶請(qǐng)求排隊(duì)發(fā)送給PHP工作進(jìn)程去處理，每個(gè)PHP工作進(jìn)程都會(huì)與MariaDB建立一個(gè)連接，MariaDB則通過(guò)某種線程模型去處理來(lái)自PHP連接的SQL請(qǐng)求。通過(guò)觀察發(fā)現(xiàn)，PHP工作進(jìn)程的數(shù)量與MariaDB所創(chuàng)建的連接connection數(shù)量是相等。也就是說(shuō)，如果PHP進(jìn)程模型采用的是dynamic(動(dòng)態(tài))方式的話，同時(shí)有1 000個(gè)用戶來(lái)連接LNMP服務(wù)器，那么PHP-FPM服務(wù)器將創(chuàng)建1 024個(gè)PHP工作進(jìn)程，此時(shí)，MariaDB數(shù)據(jù)庫(kù)服務(wù)器也將創(chuàng)建1 024個(gè)connection連接，并同時(shí)將這1 000個(gè)連接交給自己的工作線程去處理。在如此大的連接處理的壓力下，MariaDB的工作線程，無(wú)論是one-thread-per-connection每個(gè)連接一個(gè)線程的模式還是pool-of-threads進(jìn)程池處理模式，都會(huì)無(wú)力運(yùn)轉(zhuǎn)。因此，固定PHP進(jìn)程數(shù)量，成為解決問(wèn)題的關(guān)鍵。

所以，PHP應(yīng)該采用static(靜態(tài))工作方式，設(shè)置為64個(gè)固定的靜態(tài)進(jìn)程并行處理就可以了，MariaDB同時(shí)建立的connection連接數(shù)最大就是64，這很好地保護(hù)了后端的MariaDB數(shù)據(jù)庫(kù)服務(wù)器的正常運(yùn)行。

通常，可以根據(jù)先MariaDB最大允許的連接數(shù)量反過(guò)來(lái)確定PHP工作進(jìn)程設(shè)置的最大數(shù)量。例如，MariaDB以每個(gè)連接42.2 MB的最大內(nèi)存用量來(lái)計(jì)算的話，如果分配32 GB的內(nèi)存用量給MariaDB連接使用，那么MariaDB的最大連接數(shù)max_connections可以設(shè)置為776，也就是說(shuō)PHP工作進(jìn)程數(shù)量也可以設(shè)置為776。但考慮到每個(gè)PHP工作進(jìn)程最大30 MB的內(nèi)存開銷和LNMP架構(gòu)整體CPU計(jì)算、內(nèi)存開銷情況，一般PHP設(shè)置為64個(gè)進(jìn)程同時(shí)運(yùn)行就足夠了。以此很好地保護(hù)了MariaDB服務(wù)器，即使遇到訪問(wèn)高峰，MariaDB數(shù)據(jù)庫(kù)服務(wù)器承受的計(jì)算壓力也穩(wěn)定在一個(gè)可承受水平上，不至于被壓垮。

5 LNMP服務(wù)器測(cè)試

5.1 服務(wù)器配置

被檢測(cè)的LNMP服務(wù)器是閃電Moodle服務(wù)器https://mood.nbpt.edu.cn/；服務(wù)器CPU型號(hào)及數(shù)量是Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60 GHz，2塊，共16核心32線程；內(nèi)存型號(hào)及容量是DDR 3，64 GB；硬盤是SCSI硬盤，轉(zhuǎn)速15 000 r/min，共4塊300 GB的硬盤，建了Raid 5磁盤陣列。

5.2 壓縮比測(cè)試

Nginx中網(wǎng)頁(yè)傳輸采用gzip壓縮后，經(jīng)過(guò)http://tool.chinaz.com/Gzips/Default.aspx?q=mood.nbpt.edu.cn網(wǎng)站統(tǒng)計(jì)，壓縮率(估計(jì)值)達(dá)到了73.07%，即減少了73.07%的數(shù)據(jù)傳輸?shù)捏w積。

5.3 安全性檢測(cè)

經(jīng)國(guó)內(nèi)某知名的網(wǎng)絡(luò)安全公司對(duì)該LNMP服務(wù)器進(jìn)行的權(quán)威安全性檢測(cè)，沒有發(fā)現(xiàn)緊急、高危和中危漏洞，通過(guò)了ITSS(信息技術(shù)服務(wù)標(biāo)準(zhǔn))、ITIL v3(信息技術(shù)基礎(chǔ)設(shè)施庫(kù))、ISO/IEC 20000(IT服務(wù)管理國(guó)際標(biāo)準(zhǔn)體系)、ISO/IEC 27000(信息技術(shù)-安全技術(shù)-信息安全管理體系-要求)系列服務(wù)標(biāo)準(zhǔn)下的安全評(píng)測(cè)。使用的檢測(cè)軟件是WebScan(V6.0.1.9),Engine Version是V6.1.79, Policy Version是V6.1.109。

5.4 性能測(cè)試

對(duì)LNMP服務(wù)器整體性能測(cè)試，采用Chrome瀏覽器自帶的Network網(wǎng)頁(yè)加載計(jì)時(shí)工具，從瀏覽器發(fā)出PHP讀取MariaDB數(shù)據(jù)庫(kù)的請(qǐng)求，到瀏覽器收到運(yùn)行結(jié)果，即針對(duì)一個(gè)完整的Request和Response的PHP存讀取數(shù)據(jù)庫(kù)操作計(jì)時(shí)，發(fā)現(xiàn)優(yōu)化前https://mood.nbpt.edu.cn/index.php主頁(yè)中PHP訪問(wèn)MariaDB加載耗時(shí)穩(wěn)定在352 ms左右；而優(yōu)化后，主頁(yè)加載耗時(shí)穩(wěn)定在124 ms左右，處理速度達(dá)到優(yōu)化前的2.8倍，優(yōu)化效果明顯。

5.5 抗擁塞測(cè)試

在整個(gè)LNMP架構(gòu)中，擁塞出現(xiàn)在MariaDB服務(wù)這個(gè)節(jié)點(diǎn)中。因此，采用sysbench OLTP RO對(duì)MariaDB數(shù)據(jù)庫(kù)進(jìn)行了只讀壓力測(cè)試，考察其在高線程時(shí)的吞吐量TPS，即每秒鐘系統(tǒng)能夠處理的交易或事務(wù)的數(shù)量，如圖4所示。

圖4 兩種線程調(diào)度器吞吐量對(duì)比

可以看出，在高達(dá)4 096個(gè)線程并發(fā)讀取的情況下，新的pool-of-threads線程池吞吐量TPS能穩(wěn)定在5 250；而傳統(tǒng)的thread-per-connection調(diào)度器TPS則急速下降到268，幾乎被壓垮。測(cè)試表明，使用線程池設(shè)計(jì)的MariaDB數(shù)據(jù)庫(kù)服務(wù)器具有抗擁塞特征，能應(yīng)付網(wǎng)絡(luò)訪問(wèn)高峰。

6 結(jié) 語(yǔ)

本文詳細(xì)論述了LNMP服務(wù)器在安全性、處理速度和抗擁塞性上的深度技術(shù)改進(jìn)，應(yīng)用在閃電moodle服務(wù)器(網(wǎng)址 https://mood.nbpt.edu.cn/)中，該服務(wù)器得到了多年的應(yīng)用檢驗(yàn)，用戶體驗(yàn)度高，取得了很好的應(yīng)用效果。

本文提出的技術(shù)改進(jìn)對(duì)構(gòu)建于Linux操作系統(tǒng)上的各類系統(tǒng)如Docker等的性能優(yōu)化都具有重要的參考價(jià)值。隨著技術(shù)進(jìn)步，人們對(duì)LNMP服務(wù)器不斷深入研究，LNMP服務(wù)器也必將更加安全、快速和穩(wěn)固。