儲存nginx.conf檔案，輸入cd ..，回到/usr/local/nginx/sbin目錄下輸入./nginx啟動nginx服務。輸入ps –ef |grep nginx檢視執行的程序。

執行nginx：./nginx

重啟nginx：./nginx -s reload

停止nginx：./nginx -s stop

輸入netstat –ntlp | grep nginx檢視nginx的通訊埠。

輸入wget htt:\\10.190.130.78:8007就測試到配置是否成功。

2.6.在Firewall啟動狀態下執行Nginx

在Firewall啟動的情況下，其他客戶端無法訪問到htt:\\10.190.130.78:8007。

在Firewall中新增8007埠，firewall-cmd –permanent–add-port=8007/tcp，然後在輸入firewall-cmd –reload，過載成功過後， 在輸入firewall-cmd –list-all，可顯示新增的8007埠。

輸入netstat -ntlp | grep nginx檢視nginx的佔用埠

3.設定自定義開機系統服務

CentOS 7 使用systemd替換了SysV。Systemd目的是要取代Unix時代以來一直在使用的init系統，相容SysV和LSB的啟動指令碼，而且夠在程序啟動過程中

更有效地引導載入服務。

systemd的特性有：

支援並行化任務

同時採用socket式與D-Bus匯流排式啟用服務；

按需啟動守護程序（daemon）；

利用 Linux 的 cgroups 監視程序；

支援快照和系統恢復；

維護掛載點和自動掛載點；

各服務間基於依賴關係進行精密控制。

檢視和控制systemd的主要命令是systemctl。該命令可用於檢視系統狀態和管理系統及服務。詳見man 1 systemctl。

輸入vim /usr/lib/systemd/system/nginx.service進入檔案編輯。

將以下內容拷貝到nginx.service檔案中，然後儲存。

[Unit]

Description=nginx servicedaemon

After=network.target

[Service]

Type=forking

PIDFile=/usr/local/nginx/logs/nginx.pid  #nginx安裝路徑下的nginx.pid檔案

ExecStart=/usr/local/nginx/sbin/nginx

ExecReload=/usr/local/nginx/sbin/nginx-s reload

ExecStop=/usr/local/nginx/sbin/nginx-s stop

PrivateTep=true

[Install]

WantedBy=multi-user.target

儲存檔案後，啟動nginx伺服器會出現錯誤。必須要輸入systemctl daemon-reload，過載後臺服務。

輸入systemctl daemon-reload，過載後臺服務。可以使用systemctl命令對nginx進行操作

如果需要更詳細的配置，請參考：

使用單元

一個單元配置檔案可以描述如下內容之一：系統服務（.service）、掛載點（.mount）、sockets（.sockets）、系統裝置（.device）、交換分割槽（.swap）、檔案路徑（.path）、啟動目標（.target）、由 systemd 管理的計時器（.timer）。詳情參閱 man 5 systemd.unit。

使用 systemctl 控制單元時，通常需要使用單元檔案的全名，包括副檔名（例如 sshd.service）。但是有些單元可以在systemctl中使用簡寫方式。

如果無副檔名，systemctl 預設把副檔名當作 .service。例如 netcfg 和 netcfg.service 是等價的。

掛載點會自動轉化為相應的 .mount 單元。例如 /home 等價於 home.mount。

裝置會自動轉化為相應的 .device 單元，所以 /dev/sda2 等價於 dev-sda2.device。

注: 有一些單元的名稱包含一個 @ 標記， (e.g. [email protected]): 這意味著它是模板單元[email protected] 的一個例項。 string 被稱作例項識別符號, 在 systemctl 呼叫模板單元時，會將其當作一個引數傳給模板單元，模板單元會使用這個傳入的引數代替模板中的 %I 指示符。在例項化之前，systemd 會先檢查 [email protected] 檔案是否存在（如果存在，應該就是直接使用這個檔案，而不是模板例項化了）。大多數情況下，包換 @ 標記都意味著這個檔案是模板。如果一個模板單元沒有例項化就呼叫，該呼叫會返回失敗，因為模板單元中的 %I 指示符沒有被替換。

例如：systemctl start <單元>

編寫單元檔案

systemd單元檔案的語法來源於 XDG桌面入口配置檔案.desktop檔案，最初的源頭則是MicrosoftWindows的.ini檔案。單元檔案可以從兩個地方載入，優先順序從低到高分別是：

/usr/lib/systemd/system/: 軟體包安裝的單元

/etc/systemd/system/: 系統管理員安裝的單元

注意: 當systemd執行在使用者模式下時，使用的載入路徑是完全不同的。

處理依賴關係

使用systemd時，可通過正確編寫單元配置檔案來解決其依賴關係。典型的情況是，單元A要求單元B在A啟動之前執行。在此情況下，向單元A配置檔案中的 [Unit] 段新增 Requires=B 和 After=B 即可。若此依賴關係是可選的，可新增 Wants=B 和 After=B。請注意 Wants= 和 Requires= 並不意味著 After=，即如果 After= 選項沒有制定，這兩個單元將被並行啟動。

依賴關係通常被用在服務（service）而不是目標（target）上。例如， network.target 一般會被某個配置網路介面的服務引入，所以，將自定義的單元排在該服務之後即可，因為 network.target 已經啟動。

服務型別

編寫自定義的 service 檔案時，可以選擇幾種不同的服務啟動方式。啟動方式可通過配置檔案 [Service] 段中的 Type= 引數進行設定。

Type=simple（預設值）：systemd認為該服務將立即啟動。服務程序不會fork。如果該服務要啟動其他服務，不要使用此型別啟動，除非該服務是socket啟用型。

Type=forking：systemd認為當該服務程序fork，且父程序退出後服務啟動成功。對於常規的守護程序（daemon），除非你確定此啟動方式無法滿足需求，使用此型別啟動即可。使用此啟動型別應同時指定 PIDFile=，以便systemd能夠跟蹤服務的主程序。

Type=oneshot：這一選項適用於只執行一項任務、隨後立即退出的服務。可能需要同時設定 RemainAfterExit=yes 使得 systemd 在服務程序退出之後仍然認為服務處於啟用狀態。

Type=notify：與 Type=simple 相同，但約定服務會在就緒後向 systemd 傳送一個訊號。這一通知的實現由 libsystemd-daemon.so 提供。

Type=dbus：若以此方式啟動，當指定的 BusName出現在DBus系統總線上時，systemd認為服務就緒。

Type=idle: systemd會等待所有任務(Jobs)處理完成後，才開始執行idle型別的單元。除此之外，其他行為和Type=simple 類似。

type的更多解釋可以參考systemd.service(5)。

3.1.設定開機服務

輸入systemctl start nginx啟動nginx服務，在輸入systemctl enable nginx 設定nginx服務為開機啟動服務，最後，輸入systemctl status nginx檢視nginx的執行狀態。

3.2.停止開機服務

輸入systemctl disable nginx停止開機啟動nginx服務，輸入systemctlstop nginx停止nginx服務，輸入systemctl status nginx檢視nginx的執行狀態。

4.負載均衡策略

在nginx中支援的負載均衡策略如下：

輪詢加權策略（Round-Robin）：在輪詢模策略中，要求應用伺服器是分散式的

最少連線策略（Least-Connected）：下一個請求是分配給最少的活動連線數伺服器。

IP雜湊策略（IP-Hash）：一個雜湊函式用來決定那個伺服器被選擇作為下一個請求處理的伺服器（基於客戶端的IP地址）。

4.1.輪詢策略

http {

   upstream myapp1 {           #伺服器組，組名：myapp1

       server srv1.example.com;  #web應用伺服器1

       server srv2.example.com;  #web應用伺服器2

       server srv3.example.com;  #web應用伺服器3

    }

   server {

       listen 80;

       location / {

           proxy_pass http://myapp1;          #客戶端訪問的URL

       }

    }

}

以上是最簡單的Nginx負載均衡配置。在upstream myapp1中有3個應用伺服器例項，當負載均衡中沒有指定配置負載策略時，預設是使用輪詢權重策略。所有請求都是代理給伺服器組myapp1，Nginx應用http負載均衡到分散式請求中。

在Nginx反向代理負載均衡的擴充套件包括：http，https，FastCGI，uwsgi，SCGI和快取。

配置負載均衡

配置https負載均衡代替http，只使用“https”作為協議就可以了。

當設定負載均衡為FastCGI，uwsgi，SCGI，或快取，指令分別使用fastcgi_pass，uwsgi_pass，scgi_pass，和memcached_pass。

如果可以把加權輪詢演算法分為先深搜尋和先廣搜尋，那麼nginx採用的是先深搜尋演算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其他機器低，才開始將請求分給下一個高權重的機器；第二，當所有後端機器都down掉時，nginx會立即將所有機器的標誌位清成初始狀態，以避免造成所有的機器都處在timeout的狀態，從而導致整個前端被夯住。

4.2.最少連線策略

upstream myapp1 {                     #伺服器組，組名：myapp1

       least_conn;                  #least_conn;最少連線策略

       server srv1.example.com;       #web應用伺服器1

       server srv2.example.com;       #web應用伺服器2

       server srv3.example.com;       #web應用伺服器3

}

最少連線允許控制載入應用例項，更多適合在一些花費比較長時間去完成請求的一個場景中。

用最少連線負載均衡，Nginx會盡量不要求過載繁忙的應用伺服器去執行請求，分配新的請求給一個不太忙碌的伺服器代替執行。

最少連線負載均衡在Nginx中被啟用時，least_conn指令被用來作為伺服器群組配置的一個部分。

4.3.IP雜湊策略

配置IP雜湊負載均衡，只需要新增ip_hash指令指向伺服器(uptream) 組配置：

upstream myapp1 {

   ip_hash;

   server srv1.example.com;

   server srv2.example.com;

   server srv3.example.com;

}

每個客戶端請求都有可能傳送到不同的伺服器，不能保證同一個客戶端總是指向同一個伺服器。如果一個客戶端必須要跟伺服器的會話關聯在一起的時候，可以使用IP雜湊負載均衡快取策略。

通過獲取客戶端額IP地址，經過雜湊函式的計算得到一個值，利用該值對伺服器的列表大小進行取模運算，得到的值就是處理客戶端請求的伺服器序號。採用IP雜湊負載均衡策略，的優點是，同一個客戶端的IP地址，每次傳送的請求都是指向同一臺伺服器進行處理。這種方式確保來自同一個客戶端請求總是指向同一個伺服器除非這個服務是無效的。

舉例子說明：

例如一個系統的會話儲存使用者資訊，每次將請求傳送到伺服器，伺服器都會從會話中獲取資料。但在負載均衡環境中，每次客戶端的每次請求都可能由不同的伺服器處理，所以可能出現無法獲取的到客戶端的會話資料（由於會話資料是儲存在伺服器的記憶體中）。

4.4.權重策略

使用伺服器權重策略，它也有可能影響到Nginx負載均衡演算法。

在上面的例子中，伺服器權重沒有配置，意味著所有指定的伺服器都被視為同等資格的一個特定負載均衡策略。尤其是輪詢策略，它也意味著差不多平等地分配請求給伺服器，並且快速平均地處理請求。

當權重引數被指定在一個伺服器時，權重作為負載均衡決策的部分。

upstream myapp1 {

       server srv1.example.com weight=3;

       server srv2.example.com;

       server srv3.example.com;

}

在這個配置中，每5個請求都分配給應用伺服器例項如下：

3個請求將分配到serv1中，1個請求分配給srv2中，而另外1個請求則分配個srv3中。

在最近的Nginx版本中，它同樣可以與最少連線和IP雜湊策略一樣去使用權重策略。

4.5.總結

輪詢策略：

優點：如果希望每個伺服器都能平均處理客戶端請求可使用輪詢策略。

缺點：不支援會話管理，另外，假設有5個客戶端請求，有2臺伺服器處理請求，某一臺伺服器處理請求時消耗資源比較大，每次都接到消耗資源比較大的請求，那麼該伺服器處理能力就會下降。

IP雜湊策略：

缺點：使用該策略，伺服器可能不會平均處理每個請求。假設有5個客戶端請求，那麼通過計算出雜湊值後，可能都是由一臺伺服器處理。其它的伺服器可能沒有請求需要處理。

優點：支援會話管理，如果系統中使用會話處理資料，該策略比較適合。

最少連線策略：

優點：系統把新連線分配給當前連線數目最少的伺服器。該演算法在各個伺服器運算能力基本相似的環境中非常有效。此負載均衡策略適合請求處理時間長短不一造成伺服器過載的情況。

缺點：雖然某個伺服器的連線數較少，但處理請求時間較長，這時候再接受請求處理，可能影響到時間效率的問題。

權重策略：

優點：如果伺服器的硬體等級差別比較大，那麼配置高的伺服器可分配較高權重，以便處理更多的請求。而配置低的伺服器可接受少量請求。

缺點：如果伺服器的硬體等級一樣不太適合使用該策略。

5.健康檢查

在Nginx反向代理中實現主動或被動健康檢查，如果指定的響應伺服器出現錯誤，Nginx將標記該伺服器為失敗，將盡量去避免為後續的請求選擇該伺服器。

設定發生在超時失敗期間連續不成功的伺服器通訊的max_fails指令。預設max_fails設定是1，當設定為0次時，這臺伺服器的檢查檢查不啟用。Fail_timeout引數定義伺服器多長時間將被標記為失敗。在伺服器fail_timeout期間，Nginx不會馬上將該伺服器標記為失敗的伺服器，而是模擬想客戶端請求去偵查伺服器，如果偵查成功，該伺服器標記為線上伺服器。

關於健康檢查的的外掛需要花錢購買，更多的資訊請參考：

6.附錄

6.1.systemctl命令指南

Systemctl是一個systemd工具，主要負責控制systemd系統和服務管理器。

Systemd是一個系統管理守護程序、工具和庫的集合，用於取代System V初始程序。Systemd的功能是用於集中管理和配置類UNIX系統。

在Linux生態系統中，Systemd被部署到了大多數的標準Linux發行版中，只有為數不多的幾個發行版尚未部署。Systemd通常是所有其它守護程序的父程序，

但並非總是如此。使用Systemctl管理Linux服務

6.1.1.Systemd初體驗和Systemctl基礎

6.1.1.1.1.檢查systemd安裝版本

1. 首先檢查你的系統中是否安裝有systemd並確定當前安裝的版本

# systemd –version

6.1.1.1.2.檢查systemd和systemctl的二進位制檔案和庫檔案的安裝位置

# whereis system

# whereis systemctl

6.1.1.1.3檢查systemd是否執行

# ps -eaf | grep system

6.1.1.4.分析systemd啟動程序

# systemd-analyze

6.1.1.5.分析啟動時各個程序花費的時間

#systemd-analyze blame

6.1.1.6.分析啟動時的關鍵鏈

# systemd-analyze critical-chain

重要：Systemctl接受服務（.service），掛載點（.mount），套介面（.socket）和裝置（.device）作為單元。

Systemctl是一個systemd工具，主要負責控制systemd系統和服務管理器。

Systemd是一個系統管理守護程序、工具和庫的集合，用於取代System V初始程序。Systemd的功能是用於集中管理和配置類UNIX系統。

在Linux生態系統中，Systemd被部署到了大多數的標準Linux發行版中，只有為數不多的幾個發行版尚未部署。Systemd通常是所有其它守護程序的父程序，

但並非總是如此。

使用Systemctl管理Linux服務

本文旨在闡明在執行systemd的系統上“如何控制系統和服務”。

Systemd初體驗和Systemctl基礎

1. 首先檢查你的系統中是否安裝有systemd並確定當前安裝的版本

# systemd--version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP-APPARMOR

上例中很清楚地表明，我們安裝了215版本的systemd。

2. 檢查systemd和systemctl的二進位制檔案和庫檔案的安裝位置

# whereissystemd
systemd:/usr/lib/systemd /etc/systemd /usr/share/systemd/usr/share/man/man1/systemd.1.gz
# whereis systemctl
systemctl:/usr/bin/systemctl /usr/share/man/man1/systemctl.1.gz

3. 檢查systemd是否執行

# ps -eaf | grep[s]ystemd
root 10016:27?00:00:00/usr/lib/systemd/systemd --switched-root --system--deserialize 23
root 4441016:27?00:00:00/usr/lib/systemd/systemd-journald
root 4691016:27?00:00:00/usr/lib/systemd/systemd-udevd
root 5551016:27?00:00:00/usr/lib/systemd/systemd-logind
dbus 5561016:27?00:00:00/bin/dbus-daemon --system --address=systemd:--nofork--nopidfile --systemd-activation

注意：systemd是作為父程序（PID=1）執行的。在上面帶（-e）引數的ps命令輸出中，選擇所有程序，（-a）選擇除會話前導外的所有程序，並使用（-f）引數輸出完整格式列表（即 -eaf）。

也請注意上例中後隨的方括號和例子中剩餘部分。方括號表示式是grep的字元類表示式的一部分。

4. 分析systemd啟動程序

#systemd-analyze
Startup finished in487ms(kernel)+2.776s(initrd)+20.229s(userspace)=23.493s

5. 分析啟動時各個程序花費的時間

#systemd-analyze blame
8.565s mariadb.service
7.991s webmin.service
6.095s postfix.service
4.311s httpd.service
3.926s firewalld.service
3.780s kdump.service
3.238s tuned.service
1.712s network.service
1.394s lvm2-monitor.service
1.126s systemd-logind.service
....

6. 分析啟動時的關鍵鏈

#systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@"character.
The time the unit takes to start is printed after the "+" character.
multi-user.target @20.222s
└─mariadb.service @11.657s+8.565s
└─network.target @11.168s
└─network.service @9.456s+1.712s
└─NetworkManager.service @8.858s+596ms
└─firewalld.service @4.931s+3.926s
└─basic.target @4.916s
└─sockets.target @4.916s
└─dbus.socket @4.916s
└─sysinit.target @4.905s
└─systemd-update-utmp.service @4.864s+39ms
└─auditd.service @4.563s+301ms
└─systemd-tmpfiles-setup.service @4.485s+69ms
└─rhel-import-state.service @4.342s+142ms
└─local-fs.target @4.324s
└─boot.mount @4.286s+31ms
└─[email protected]\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d19608096
└─dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\[email protected]

重要：Systemctl接受服務（.service），掛載點（.mount），套介面（.socket）和裝置（.device）作為單元。

6.1.1.7.列出所有可用單元

# systemctl list-unit-files

6.1.1.8.列出所有執行中單元

# systemctl list-units

6.1.1.9.列出所有失敗單元

# systemctl –failed

6.1.1.10.檢查某個單元是否啟用

# systemctl is-enabled nginx.service 

6.1.1.11.檢查某個單元或服務是否執行

# systemctl status nginx.service