摘要：接下來我們要配置這個的端口，這樣他們才能運行時端口號不沖突。問題指明不同的端口號訪問也太蠢了吧的確很蠢，所以我們要慢慢過渡學習。接下來我們學習用來進行反向代理。阿里云的部分有一些配置的具體過程。

雖然說是在linux上，但是windows上也是同樣的道理，只不過我們服務器都是選用linux罷了。

原先，自己有多個項目需要部署在linux上時，我的做法（新手的做法）是：在linux上只有一個tomcat服務器，我們把多個項目如project-1.war、project-2.war、project-3.war（一般都是.war包的形式）都傳輸到這個tomcat的webapps/目錄下；在啟動tomcat后，tomcat自動解壓war包成文件夾，然后我們通過地址+項目名的方法來訪問項目。

比如：192.168.1.1:8080/project-1/index.jsp，192.168.1.1:8080/project-2/index.jsp等形式。

缺點： 作為新手來說，這只是一個過渡的時期。我們發現，如果我們有時候想要重啟服務器或關閉服務器（修改配置、項目之類的），所有的項目就都暫時無法訪問了。而且tomcat每次啟動都要重新加載所有的項目。簡而言之，十分地不方便。

我們可以運行多個tomcat，每一個tomcat都使用不同的端口號，這樣我們就能隨心所欲地部署我們的web項目了。當然，這里可能有多種搭配。如：單tomcat單項目，單tomcat多項目，多tomcat單項目，多tomcat多項目等。重要的是：使用多個tomcat可以讓我們借助不同端口號來獨立分隔不同的項目，個人覺得比較條理清楚

下面講解一下如何部署多個tomcat來運行同一個項目。假設我們的工作目錄是/opt/，我們下載傳輸tomcat-xxx.zip到該目錄下，解壓unzip tomcat-xxx.zip后，重命名mv tomcat-1，這個就是我們的第一個tomcat服務器了。然后我們再復制一個cp -a tomcat-1 tomcat-2，這樣就得到了第2個tomcat服務器。

接下來我們要配置這2個tomcat的端口，這樣他們才能運行時端口號不沖突。下面的內容參考自網絡，大家分享的都是差不多的。

1、打開配置文件，配置環境變量：vim /etc/profile

2、在文件的最后幾行加入配置信息：

# tomcat-1 config
CATALINA_1_BASE=/opt/tomcat-1
CATALINA_1_HOME=/opt/tomcat-1
TOMCAT_1_HOME=/opt/tomcat-1
export CATALINA_1_BASE CATALINA_1_HOME TOMCAT_1_HOME

# tomcat-2 config
CATALINA_2_BASE=/opt/tomcat-2
CATALINA_2_HOME=/opt/tomcat-2
TOMCAT_2_HOME=/opt/tomcat-2
export CATALINA_2_BASE CATALINA_2_HOME TOMCAT_2_HOME

這里就是配置了我們自己的tomcat所在路徑

然后，我們要刷新文件使其生效：source /etc/profile。

3、對tomcat進行相應的配置

我們先來到第一個tomcat下cd /opt/tomcat-1/，然后編輯第一個需要配置的文件：vim /bin/catalina.sh：

我們找到下面的內容：# OS specific support. $var _must_ be set to either true or false.

然后在下面增加如下代碼：

export CATALINA_BASE=$CATALINA_1_BASE
export CATALINA_HOME=$CATALINA_1_HOME

接著，我們編輯第二個需要配置的文件vim /conf/server.xml：找到下面3條信息

我們需要修改這3個端口號的值，以防止多個tomcat之間端口沖突。比如改成下面的端口號。

4、這樣，第1個tomcat就已經配置好了。我們這時候可以把項目project-1.war傳輸到/opt/tomcat-1/webapps/目錄下，然后運行這個tomcat/bin/startup.sh。接著我們訪問192.168.1.1:9080/project-1/index.jsp就能看到項目了。

5、小插曲：

可能會出現無法執行startup.sh文件的情況，提示沒有權限，我們需要賦予執行權限cd /opt/tomcat-1/bin/，chmod u+x *.sh即可。

記得要開放linux對應的端口號，我用的是阿里云，所以就在控制臺進行開發，你也可以使用ufw軟件來進行開放。

第2個tomcat服務器的配置、運行的步驟和上面是一致的，只是選用的端口號不能重復，在配置完之后，我們就有2個tomcat服務器來運行同一個web項目了。
比如說：192.168.1.1:9080/project-1/index.jsp、192.168.1.1:10080/project-1/index.jsp

其實上面這種多tomcat單個項目的方式，我們稱之為tomcat集群。當然，上面的還很粗糙，只是一個小demo。

問題1：指明不同的端口號訪問（9080、10080）也太蠢了吧！

的確很蠢，所以我們要慢慢過渡學習。接下來我們學習用nginx來進行反向代理。

nginx的安裝

在上面的教程安裝完成之后，如何啟動呢？我建議把nginx的目錄加到環境變量中。
在/etc/profile 中加入：
export NGINX_HOME=/usr/local/nginx
export PATH=$PATH:$NGINX_HOME/sbin
這樣，就能直接使用nginx -t等命令了。

在安裝完成后，啟動nginx，訪問我們的地址192.168.1.1就可以看到nginx的歡迎頁面了。

曾經的一個bug： 遇到的情況是，無論如何修改配置都不能使其生效！通過nginx -t可以看到配置文件的路徑：

那一次就是我找錯了配置文件。也可以手動加載配置文件來啟動：nginx -t -c /usr/local/nginx/conf/nginx.conf來先檢查，然后讀取配置文件啟動。

# 檢查配置文件
nginx -t

# 啟動
nginx

# 停止
nginx -s stop

# 重新加載配置文件啟動
nginx -s reload

# 指定配置文件啟動
nginx -c /usr/local/nginx/conf/nginx.conf

# 查看nginx版本
nginx -v

# 摘自網絡
nginx -s stop       快速關閉Nginx，可能不保存相關信息，并迅速終止web服務。
nginx -s quit       平穩關閉Nginx，保存相關信息，有安排的結束web服務。
nginx -s reload     因改變了Nginx相關配置，需要重新加載配置而重載。
nginx -s reopen     重新打開日志文件。
nginx -c filename   為 Nginx 指定一個配置文件，來代替缺省的。
nginx -t            不運行，而僅僅測試配置文件。nginx 將檢查配置文件的語法的正確性，并嘗試打開配置文件中所引用到的文件。
nginx -v            顯示 nginx 的版本。
nginx -V            顯示 nginx 的版本，編譯器版本和配置參數。

# 找到安裝的nginx
whereis nginx

# 進入安裝目錄
cd /usr/local/nginx/

# 編輯nginx配置文件
vim conf/nginx.conf

我們先找到下面這些信息：

server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

上面的配置，意思是：

nginx監聽服務器本地的80端口（建議把localhost改成自己的ip，更清晰），對外部訪問的/進行代理，所以我們訪問192.168.1.1就會看到nginx的歡迎頁面。

之前我們不是覺得加上端口號9080、10080很蠢嗎，現在來改造一下：

# 虛擬主機
server {
        listen       80;
        server_name  yeziqiduo.top;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

        location /tomcat-1/ {
            proxy_pass http://yeziqiduo.top:9080/xmlconfig/;
        }

        location /tomcat-2/ {
            proxy_pass http://yeziqiduo.top:10080/xmlconfig/;
        }

我們把localhost改成了自己的域名（當然你也可以用ip地址），然后添加了2個location的配置，意思是nginx監聽到指定的server_name匹配到的location時，進行請求代理，即：yeziqiduo.top/tomcat-1的請求被代理給了我們設置的http://yeziqiduo.top:9080/xmlconfig/。第2個location的意思是一樣的。

示意圖如下：

瀏覽器監聽請求轉發（重定向）：可以明顯看到先是301的永久重定向，請求被轉發給了下一個url。

這個練手，讓我們明白了可以用nginx來映射請求url和服務器上的真實url。

如果我們使用主域名+項目名的url（yeziqiduo.top/tomcat-1、yeziqiduo.top/tomcat-2），看起來還是太low了啊。我覺得，用二級域名來代表不同的項目豈不是很爽嗎？比如說：book.yeziqiduo.top、movie.yeziqiduo.top，就可以用來分別表示book項目和movie項目。

首先，我們要對我們的域名（yeziqiduo.top）添加2條A類型的解析記錄，讓book.yeziqiduo.top指向我們的ip地址。同理movie也是。

然后，我們再來編輯nginx的配置文件，（/usr/local/nginx/conf/nginx.conf.default是默認文件）我們可以添加多個server段來配置基于域名的虛擬主機。如下：

# 第一個虛擬主機
server {
  listen       80;
  server_name  book.yeziqiduo.top;

  location / {
    proxy_pass  http://yeziqiduo.top/book/;
  }

  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
      root   html;
  }
}

# 第二個虛擬主機
server {
  listen       80;
  server_name  movie.yeziqiduo.top;

  location / {
      proxy_pass  http://yeziqiduo.top/movie/;
  }

  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
      root   html;
  }
}

這樣，我們就可以通過2個二級域名的地址來訪問服務器上的2個不同項目了。

這種方式，是我們比較常用的方式，因為2級域名更加直觀。毫無疑問，這種方式把第一種方式給碾壓了。

當一個項目訪問的人數多了之后，可能單個tomcat就支撐不住并發量了。這時候，我們希望有多臺tomcat可以提供服務，理想的情況如下圖：

在前面的2次練手后，我們可以很容易想明白。服務器端我們部署運行多個tomcat來實現單項目的集群。然后借助nginx來對請求進行代理，nginx依據某種策略把這些請求分發給不同的tomcat來處理。

為了方式調試，我們讓tomcat-1和tomcat-2下的book項目有一點不同，就是主頁index的顯示不一樣，這樣才知道是哪個tomcat提供的服務。

我們來編輯配置文件：

# 配置上游服務器集群
upstream book_cluster {
  server  yeziqiduo.top:9080;
  server  yeziqiduo.top:10080;
}

# 虛擬主機
server {
  listen       80;
  server_name  book.yeziqiduo.top;

  location / {
    # 如果服務器出錯,則代理給下一臺服務器
    proxy_next_upstream  http_502 http_504 error timeout invalid_header;
    proxy_pass  http://book_cluster/xmlconfig/;
    proxy_set_header  Host book.yeziqiduo.top;
    proxy_set_header  X-Forwarded-For $remote_addr;
  }

  access_log  logs/book.yeziqiudo.top_access.log;

  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
      root   html;
  }
}

要注意，upstream只能配置地址+端口，不能加上項目路徑。我們將項目路徑配置在proxy_pass字段，緊跟著集群地址后加上/xmlconfig/來指定這個tomcat集群的項目。

我們在瀏覽器多次訪問，刷新，可以看到不同的tomcat提供的服務。

相信看著，應該很激動了。到這里，我們接觸到了比較粗淺的負載均衡。

nginx的upstream目前支持4種方式的分配
1、輪詢（默認）
每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。
2、按權重分配weight
weight和訪問比率成正比，用于后端服務器性能不均的情況。 例如：

upstream bakend {
  server yeziqiduo.top:9080 weight=10;
  server yeziqiduo.top:10080 weight=10;
}

3、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。 例如：

upstream bakend {
  ip_hash;
  server yeziqiduo.top:9080;
  server yeziqiduo.top:10080;
}

4、fair（第三方）
按后端服務器的響應時間來分配請求，響應時間短的優先分配。

upstream backend {
  server yeziqiduo.top:9080;
  server yeziqiduo.top:10080;
    fair;
}

5、url_hash（第三方）
按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效。
例：在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash算法。

upstream backend {
  server yeziqiduo.top:9080;
  server yeziqiduo.top:9080;
  hash $request_uri;
  hash_method crc32;
}

首先我們需要https的證書，免費提供https證書的網站有freessl、letsencrypt、以及阿里云這3個網站。借助阿里云的單域名ssl證書，可以得到一個.key文件（私鑰）和.pem文件（證書）。阿里云的ssl部分有一些配置的具體過程。在nginx的配置文件中，配置如下。對yeziqiduo.top啟用了ssl即https連接，2個文件需要復制到linux中并指明路徑。

然后我們想要強制http轉成https連接，nginx配置如下：借助return重定向為https。（實現的方式還有其他幾種）

由于阿里云提供的免費ssl證書只支持單域名，所有我們按照自己的需求申請多個證書并一一配置就可以了。

這部分內容，網上的博客分析地比較全面和透徹，看到好的文章多看看理解了才行。

下面自己梳理一下一些關鍵的名詞https的連接、傳輸過程。

首先，我們知道申請得到的ssl文件：一個是私鑰(private key)，另一個是證書(certificate)。我先講一下什么是證書吧！借助Firefox可以查看網站的證書信息，重要的內容有：證書編號，過期時間，所有者信息，所有者公鑰。

1.下面講解一下證書的生成過程：

一個概念就是數字證書就好比網站的身份證，CA頒發給網站的證書就好比是一張張可信任的身份證。

上面就是CA機構生成證書的過程，可以看到，證書中包含的內容有3部分：證書編號的數字簽名值，網站的公鑰，網站的信息。

2.https的連接

https的連接，就是在tcp層和http層之間加了一層ssl層，所以需要先建立ssl連接，然后才開始http連接與通信。下面講解一下，客戶端如何與網站進行通信連接的建立。

當客戶端請求網站時，網站將證書發送給客戶端，客戶端如何判斷發送的證書內容沒有修改呢？這樣我才能使用該證書的公鑰進行通信！

這個過程就是證書生成的逆過程。需要指出的是：CA的公鑰哪里來的呢？ 操作系統和瀏覽器會自己維護為數不多的CA機構列表。所以CA機構的公鑰是在我們本地的。客戶端使用同樣的哈希方法（這個信息放在網站信息中）計算得到證書編號，同時使用CA公鑰對數字簽名值進行解密得到真實的證書編號，2者一對比，相等則說明該證書沒有被篡改，可以信任并且使用其公鑰。

1、如果證書被人修改，因為它沒有CA的私鑰，所以只能篡改網站公鑰或網站信息這2部分的內容?？蛻舳擞嬎?個證書編號后就能知道信息是否被篡改。

2.如果證書被CA信任的其他網站劫持，發送過來的是被信任的網站的證書呢？客戶端還會判斷證書中網站信息里的域名是否和自己請求的域名一致，這樣就能知道是否被中間人劫持了。

證書驗證通過之后，還要做更重要的事情！

客戶端生成隨機數，并使用網站的公鑰進行加密，發送給網站（中間人沒有私鑰，無法篡改）；網站收到密文后使用私鑰進行解密得到隨機數，并回復客戶端。這個過程就是在協商后面的http通信所要使用的對稱加密的密文。協商完成后，雙方后面就開始進行http通信了，通信的內容都要使用密文進行對稱加密（中間人不知道對稱加密的密文，無法篡改），這樣內容的安全性就得到了保證。

HTTPS要使客戶端與服務器端的通信過程得到安全保證，必須使用的對稱加密算法，但是協商對稱加密算法的過程，需要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與服務器不直接使用公鑰，而是使用數字證書簽發機構頒發的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協商出一個對稱加密算法，就此雙方使用該算法進行加密解密。從而解決了客戶端與服務器端之間的通信安全問題。

先使用非對稱加密方式通信，驗證網站身份以及取得公鑰。然后雙方協商對稱加密的密文。后面雙方的http通信就使用密文進行對稱加密。

下面是參考的博文。

https博文列表：

1.也許，這樣理解HTTPS更容易

2.圖解 HTTPS：Charles 捕獲 HTTPS 的原理

3.阿里云技術專家金九：Tengine HTTPS原理解析、實踐與調試

4.HTTPS 原理詳解

5.HTTPS工作原理

6.HTTPS 原理詳解

HTTPS工作原理和TCP握手機制

《精通nginx》、《實戰nginx，取代apache的高性能服務器》