雖說是在linux上,可是windows上也是一樣的道理,只不過咱們服務器都是選用linux罷了。html
原先,本身有多個項目須要部署在linux上時,個人作法(新手的作法)是:在linux上只有一個tomcat服務器,咱們把多個項目如project-1.war
、project-2.war
、project-3.war
(通常都是.war包的形式)都傳輸到這個tomcat的webapps/
目錄下;在啓動tomcat後,tomcat自動解壓war包成文件夾,而後咱們經過地址+項目名的方法來訪問項目。linux
好比:192.168.1.1:8080/project-1/index.jsp
,192.168.1.1:8080/project-2/index.jsp
等形式。nginx
缺點: 做爲新手來講,這只是一個過渡的時期。咱們發現,若是咱們有時候想要重啓服務器或關閉服務器(修改配置、項目之類的),全部的項目就都暫時沒法訪問了。並且tomcat每次啓動都要從新加載全部的項目。簡而言之,十分地不方便。git
咱們能夠運行多個tomcat,每個tomcat都使用不一樣的端口號,這樣咱們就能爲所欲爲地部署咱們的web項目了。固然,這裏可能有多種搭配。如:單tomcat單項目,單tomcat多項目,多tomcat單項目,多tomcat多項目等。重要的是:使用多個tomcat可讓咱們藉助不一樣端口號來獨立分隔不一樣的項目,我的以爲比較條理清楚github
下面講解一下如何部署多個tomcat來運行同一個項目。假設咱們的工做目錄是/opt/
,咱們下載傳輸tomcat-xxx.zip到該目錄下,解壓unzip tomcat-xxx.zip
後,重命名mv tomcat-1
,這個就是咱們的第一個tomcat服務器了。而後咱們再複製一個cp -a tomcat-1 tomcat-2
,這樣就獲得了第2個tomcat服務器。web
接下來咱們要配置這2個tomcat的端口,這樣他們才能運行時端口號不衝突。下面的內容參考自網絡,你們分享的都是差很少的。算法
一、打開配置文件,配置環境變量:vim /etc/profile
apache
二、在文件的最後幾行加入配置信息:vim
# 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所在路徑windows
而後,咱們要刷新文件使其生效:source /etc/profile
。
三、對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條信息
<Server port="8005" shutdown="SHUTDOWN"> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
咱們須要修改這3個端口號的值,以防止多個tomcat之間端口衝突。好比改爲下面的端口號。
<Server port="9005" shutdown="SHUTDOWN"> <!-- tomcat訪問端口 --> <Connector port="9080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="9009" protocol="AJP/1.3" redirectPort="8443" />
四、這樣,第1個tomcat就已經配置好了。咱們這時候能夠把項目project-1.war
傳輸到/opt/tomcat-1/webapps/
目錄下,而後運行這個tomcat/bin/startup.sh
。接着咱們訪問192.168.1.1:9080/project-1/index.jsp
就能看到項目了。
五、小插曲:
startup.sh
文件的狀況,提示沒有權限,咱們須要賦予執行權限cd /opt/tomcat-1/bin/
,chmod u+x *.sh
便可。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。
的確很蠢,因此咱們要慢慢過渡學習。接下來咱們學習用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種方式的分配
一、輪詢(默認)
每一個請求按時間順序逐一分配到不一樣的後端服務器,若是後端服務器down掉,能自動剔除。
二、按權重分配weight
weight和訪問比率成正比,用於後端服務器性能不均的狀況。 例如:
upstream bakend { server yeziqiduo.top:9080 weight=10; server yeziqiduo.top:10080 weight=10; }
三、ip_hash
每一個請求按訪問ip的hash結果分配,這樣每一個訪客固定訪問一個後端服務器,能夠解決session的問題。 例如:
upstream bakend { ip_hash; server yeziqiduo.top:9080; server yeziqiduo.top:10080; }
四、fair(第三方)
按後端服務器的響應時間來分配請求,響應時間短的優先分配。
upstream backend { server yeziqiduo.top:9080; server yeziqiduo.top:10080; fair; }
五、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能夠查看網站的證書信息,重要的內容有:證書編號,過時時間,全部者信息,全部者公鑰。
一個概念就是數字證書就比如網站的身份證,CA頒發給網站的證書就比如是一張張可信任的身份證。
上面就是CA機構生成證書的過程,能夠看到,證書中包含的內容有3部分:證書編號的數字簽名值,網站的公鑰,網站的信息。
https的鏈接,就是在tcp層和http層之間加了一層ssl層,因此須要先創建ssl鏈接,而後纔開始http鏈接與通訊。下面講解一下,客戶端如何與網站進行通訊鏈接的創建。
當客戶端請求網站時,網站將證書發送給客戶端,客戶端如何判斷髮送的證書內容沒有修改呢?這樣我才能使用該證書的公鑰進行通訊!
這個過程就是證書生成的逆過程。須要指出的是:CA的公鑰哪裏來的呢? 操做系統和瀏覽器會本身維護爲數很少的CA機構列表。因此CA機構的公鑰是在咱們本地的。客戶端使用一樣的哈希方法(這個信息放在網站信息中)計算獲得證書編號,同時使用CA公鑰對數字簽名值進行解密獲得真實的證書編號,2者一對比,相等則說明該證書沒有被篡改,能夠信任而且使用其公鑰。
一、若是證書被人修改,由於它沒有CA的私鑰,因此只能篡改網站公鑰或網站信息這2部分的內容。客戶端計算2個證書編號後就能知道信息是否被篡改。
2.若是證書被CA信任的其餘網站劫持,發送過來的是被信任的網站的證書呢?客戶端還會判斷證書中網站信息裏的域名是否和本身請求的域名一致,這樣就能知道是否被中間人劫持了。
證書驗證經過以後,還要作更重要的事情!
客戶端生成隨機數,並使用網站的公鑰進行加密,發送給網站(中間人沒有私鑰,沒法篡改);網站收到密文後使用私鑰進行解密獲得隨機數,並回復客戶端。這個過程就是在協商後面的http通訊所要使用的對稱加密的密文。協商完成後,雙方後面就開始進行http通訊了,通訊的內容都要使用密文進行對稱加密(中間人不知道對稱加密的密文,沒法篡改),這樣內容的安全性就獲得了保證。
HTTPS要使客戶端與服務器端的通訊過程獲得安全保證,必須使用的對稱加密算法,可是協商對稱加密算法的過程,須要使用非對稱加密算法來保證安全,然而直接使用非對稱加密的過程自己也不安全,會有中間人篡改公鑰的可能性,因此客戶端與服務器不直接使用公鑰,而是使用數字證書籤發機構頒發的證書來保證非對稱加密過程自己的安全。這樣經過這些機制協商出一個對稱加密算法,就此雙方使用該算法進行加密解密。從而解決了客戶端與服務器端之間的通訊安全問題。
先使用非對稱加密方式通訊,驗證網站身份以及取得公鑰。而後雙方協商對稱加密的密文。後面雙方的http通訊就使用密文進行對稱加密。
下面是參考的博文。
https博文列表:
2.圖解 HTTPS:Charles 捕獲 HTTPS 的原理
3.阿里雲技術專家金九:Tengine HTTPS原理解析、實踐與調試
《精通nginx》、《實戰nginx,取代apache的高性能服務器》