nginx搭建http代理伺服器

『壹』 如何用 Nginx 配置透明 HTTP 和 HTTPS 代理

Nginx ("engine x") 是一個高性能的 HTTP 和 反向代理 伺服器，也是一個 IMAP/POP3/SMTP 代理伺服器。
Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru
站點開發的，，因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。
1、首先需要配置站點的WoSign SSl證書

打開Nginx安裝目錄下conf目錄中的nginx.conf文件 找到
# HTTPS server
#
#server {
# listen 443;
# server_name localhost;
# ssl on;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_timeout 5m;
# ssl_protocols SSLv2 SSLv3 TLSv1;
# ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
將其修改為 :
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate sslkey/public.cer; （證書公鑰）
ssl_certificate_key sslkey/private.key; （證書私鑰）
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;
location / {
root html;
index index.html index.htm;
}
}
保存退出，並重啟Nginx。
通過https方式訪問您的站點，測試站點證書的安裝配置。

3、配置強身份認證
1、 修改nginx.conf文件
如果要求客戶採用客戶證書認證方式，可以在原來的配置下增加如下參數：
server {
......
......
......
ssl_verify_client on 要求SSL客戶證書認證。
ssl_client_certificate trust.cer 簽發客戶證書的CA證書，用來驗證客戶證書。
ssl_verify_depth 3 SSL客戶證書認證鏈長度。
}
4、重啟站點使用您的客戶端證書進行登陸測試

『貳』 nginx+FastCGI+C/C++的搭建http伺服器的問題

建議：
1、使用短連接，nginx+fastcgi不太適合長連接應用
2、如果使用長連接，請設置並調整nginx.conf中fastcgi相關的參數，比如buffer之類

『叄』 我想搭建一個http代理伺服器，供公網客戶使用

我使用的是Squid+Stunnel的方案，提供帶有認證的HTTPS代理服務。一方面可以防止因為明文傳輸被發現而攔截，另一方面可以防止其他人惡意使用來攻擊其他站點。具體搭建過程可以參考我的博客：使用Squid搭建HTTPS代理伺服器。
雖然用Nginx搭代理很方便，但是Nginx不能代理HTTPS的站點，而目前很多常用的站點以及一些CDN，比如Google、Twitter、Youtube、gstatic、cloudflare，都已經全站HTTPS了，所以有很多網站是訪問不了的。

『肆』 請教問題nginx反向代理proxy

一、反向代理：Web伺服器的「經紀人」
1.1 反向代理初印象
反向代理（Reverse Proxy）方式是指以代理伺服器來接受internet上的連接請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連接的客戶端，此時代理伺服器對外就表現為一個伺服器。
Nginx搭建反向代理伺服器過程詳解
從上圖可以看出：反向代理伺服器位於網站機房，代理網站Web伺服器接收Http請求，對請求進行轉發。
1.2 反向代理的作用
①保護網站安全：任何來自Internet的請求都必須先經過代理伺服器；
Nginx搭建反向代理伺服器過程詳解
②通過配置緩存功能加速Web請求：可以緩存真實Web伺服器上的某些靜態資源，減輕真實Web伺服器的負載壓力；
Nginx搭建反向代理伺服器過程詳解
③實現負載均衡：充當負載均衡伺服器均衡地分發請求，平衡集群中各個伺服器的負載壓力；
Nginx搭建反向代理伺服器過程詳解
二、初識Nginx：簡單卻不平凡
2.1 Nginx是神馬？
Nginx搭建反向代理伺服器過程詳解
Nginx是一款輕量級的網頁伺服器、反向代理器以及電子郵件代理伺服器。其將源代碼以類BSD許可證的形式發布，因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。
Source：Nginx（發音同engine x），它是由俄羅斯程序員Igor Sysoev所開發的。起初是供俄國大型的門戶網站及搜索引擎Rambler（俄語：Рамблер）使用。此軟體BSD-like協議下發行，可以在UNIX、GNU/Linux、BSD、Mac OS X、Solaris，以及Microsoft Windows等操作系統中運行。
說到Web伺服器，Apache伺服器和IIS伺服器是兩大巨頭；但是運行速度更快、更靈活的對手：Nginx 正在迎頭趕上。
2.2 Nginx的應用現狀
Nginx 已經在俄羅斯最大的門戶網站── Rambler Media（www.rambler.ru）上運行了3年時間，同時俄羅斯超過20%的虛擬主機平台採用Nginx作為反向代理伺服器。
Nginx搭建反向代理伺服器過程詳解Nginx搭建反向代理伺服器過程詳解Nginx搭建反向代理伺服器過程詳解Nginx搭建反向代理伺服器過程詳解Nginx搭建反向代理伺服器過程詳解
在國內，已經有 淘寶、新浪博客、新浪播客、網易新聞、六間房、56.com、Discuz!、水木社區、豆瓣、YUPOO、海內、迅雷在線 等多家網站使用 Nginx 作為Web伺服器或反向代理伺服器。
2.3 Nginx的核心特點
（1）跨平台：Nginx 可以在大多數 Unix like OS編譯運行，而且也有Windows的移植版本；
（2）配置異常簡單：非常容易上手。配置風格跟程序開發一樣，神一般的配置；
（3）非阻塞、高並發連接：數據復制時，磁碟I/O的第一階段是非阻塞的。官方測試能夠支撐5萬並發連接，在實際生產環境中跑到2～3萬並發連接數。（這得益於Nginx使用了最新的epoll模型）；
PS：對於一個Web伺服器來說，首先看一個請求的基本過程：建立連接—接收數據—發送數據，在系統底層看來 ：上述過程（建立連接—接收數據—發送數據）在系統底層就是讀寫事件。
①如果採用阻塞調用的方式，當讀寫事件沒有準備好時，必然不能夠進行讀寫事件，那麼久只好等待，等事件准備好了，才能進行讀寫事件，那麼請求就會被耽擱 。
②既然沒有準備好阻塞調用不行，那麼採用非阻塞調用方式。非阻塞就是：事件馬上返回，告訴你事件還沒准備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件准備好了為止，在這期間，你就可以先去做其它事情，然後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的。
（4）事件驅動：通信機制採用epoll模型，支持更大的並發連接。
①非阻塞通過不斷檢查事件的狀態來判斷是否進行讀寫操作，這樣帶來的開銷很大，因此就有了非同步非阻塞的事件處理機制。這種機制讓你可以同時監控多個事件，調用他們是阻塞的，但可以設置超時時間，在超時時間之內，如果有事件准備好了，就返回。這種機制解決了上面阻塞調用與非阻塞調用的兩個問題。
②以epoll模型為例：當事件沒有準備好時，就放入epoll(隊列)裡面。如果有事件准備好了，那麼就去處 理；如果事件返回的是EAGAIN，那麼繼續將其放入epoll裡面。從而，只要有事件准備好了，我們就去處理它，只有當所有事件都沒有準備好時，才在 epoll裡面等著。這樣，我們就可以並發處理大量的並發了，當然，這里的並發請求，是指未處理完的請求，線程只有一個，所以同時能處理的請求當然只有一 個了，只是在請求間進行不斷地切換而已，切換也是因為非同步事件未准備好，而主動讓出的。這里的切換是沒有任何代價，你可以理解為循環處理多個准備好的事 件，事實上就是這樣的。
③與多線程方式相比，這種事件處理方式是有很大的優勢的，不需要創建線程，每個請求佔用的內存也很少，沒有上下文切換， 事件處理非常的輕量級，並發數再多也不會導致無謂的資源浪費（上下文切換）。對於IIS伺服器，每個請求會獨佔一個工作線程，當並發數上到幾千時，就同時 有幾千的線程在處理請求了。這對操作系統來說，是個不小的挑戰：因為線程帶來的內存佔用非常大，線程的上下文切換帶來的cpu開銷很大，自然性能就上不 去，從而導致在高並發場景下性能下降嚴重。
總結：通過非同步非阻塞的事件處理機制，Nginx實現由進程循環處理多個准備好的事件，從而實現高並發和輕量級。
（5）Master/Worker結構：一個master進程，生成一個或多個worker進程。
Nginx搭建反向代理伺服器過程詳解
PS：Master-Worker設計模式核心思想是將原來串列的邏輯並行化， 並將邏輯拆分成很多獨立模塊並行執行。其中主要包含兩個主要組件Master和Worker，Master主要將邏輯進行拆分，拆分為互相獨立的部分，同 時維護了Worker隊列，將每個獨立部分下發到多個Worker並行執行，Worker主要進行實際邏輯計算，並將結果返回給Master。
問：nginx採用這種進程模型有什麼好處？
答：採用獨立的進程，可以讓互相之間不會影響，一個進程退出後，其它進程還在工作，服務不會中斷，Master 進程則很快重新啟動新的Worker進程。當然，Worker進程的異常退出，肯定是程序有bug了，異常退出，會導致當前Worker上的所有請求失 敗，不過不會影響到所有請求，所以降低了風險。
（6）內存消耗小：處理大並發的請求內存消耗非常小。在3萬並發連接下，開啟的10個Nginx 進程才消耗150M內存（15M*10=150M）。
（7）內置的健康檢查功能：如果 Nginx 代理的後端的某台 Web 伺服器宕機了，不會影響前端訪問。
（8）節省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。
（9）穩定性高：用於反向代理，宕機的概率微乎其微。
三、構建實戰：Nginx+IIS構築Web伺服器集群的負載均衡
這里我們主要在Windows環境下，通過將同一個Web網站部署到不同伺服器的IIS上，再通過一個統一的Nginx反響代理伺服器對外提供統一訪問接入，實現一個最簡化的反向代理和負載均衡服務。但是，受限於實驗條件， 我們這里主要在一台計算機上進行反向代理、IIS集群的模擬，具體的實驗環境如下圖所示：我們將nginx服務和web網站都部署在一台計算機 上，nginx監聽http80埠，而web網站分別以不同的埠號（這里是8050及8060）部署在同一個IIS伺服器上，用戶訪問 localhost時，nginx作為反向代理將請求均衡地轉發給兩個IIS中不同埠的Web應用程序進行處理。雖然實驗環境很簡單而且有限，但是對於 一個簡單的負載均衡效果而言，本文是可以達到並且展示的。
Nginx搭建反向代理伺服器過程詳解
3.1 准備一個ASP.NET網站部署到IIS伺服器集群中
（1）在VS中新建一個ASP.NET Web應用程序，但是為了在一台計算機上展示效果，我們將這個Web程序復制一份，並修改兩個Web程序的Default.aspx，讓其的首頁顯示不同 的一點信息。這里Web1展示的是「The First Web：」，而Web2展示的則是「The Second Web」。
Nginx搭建反向代理伺服器過程詳解
（2）調試運行，看看兩個網站的效果如何？
①Web1的展示效果：
Nginx搭建反向代理伺服器過程詳解
②Web2的展示效果：
Nginx搭建反向代理伺服器過程詳解
③部署到IIS中，分配不同的埠號：這里我選擇了Web1:8050，Web2:8060
Nginx搭建反向代理伺服器過程詳解
（3）總結：在真實環境中，構建Web應用伺服器集群的實現是將同一個Web應用程序部署到Web伺服器集群中的多個Web伺服器上。
3.2 下載Nginx並部署到伺服器中作為自啟動的Windows服務
（1）到Nginx官網下載Nginx的Windows版本：http://nginx.org/en/download.html（這里我們使用nginx/Windows-1.4.7版本進行實驗，本文底部有下載地址）
（2）解壓到磁碟任意目錄，例如這里我解壓到了：D:\Servers\nginx-1.4.7
（3）啟動、停止和重新載入服務：通過cmd以守護進程方式啟動nginx.exe：start nginx.exe，停止服務：nginx -s stop，重新載入配置：nginx -s reload；
Nginx搭建反向代理伺服器過程詳解
（4）每次以cmd方式啟動Nginx服務不符合實際要求，於是我們想到將其注冊為Windows服務，並設置為自動啟動模式。這里，我們使用一個 不錯的小程序：「Windows Service Wrapper」，將nginx.exe注冊為Windows服務，具體的步湊如下：
①下載最新版的 Windows Service Wrapper 程序，比如我下載的名稱是 「winsw-1.8-bin.exe」（本文底部有下載地址），然後把它命名成你想要的名字（比如: 「nginx-service.exe」，當然，你也可以不改名）
②將重命名後的 nginx-service.exe 復制到 nginx 的安裝目錄（比如，我這里是 「D:\Servers\nginx-1.4.7″）
③在同一個目錄下創建一個Windows Service Wrapper 的XML配置文件，名稱必須與第一步重命名時使用的名稱一致（比如我這里是 「nginx-service.xml」, 如果，你沒有重命名，則應該是 「winsw-1.8-bin.xml」），這個XML的內容如下：
<?xml version="1.0" encoding="UTF-8" ?>
<service>
<id>nginx</id>
<name>Nginx Service</name>
<description>High Performance Nginx Service</description>
<executable>D:\Servers\nginx-1.4.7\nginx.exe</executable>
<logpath>D:\Servers\nginx-1.4.7\</logpath>
<logmode>roll</logmode>
<depend></depend>
<startargument>-p D:\Servers\nginx-1.4.7</startargument>
<stopargument>-p D:\Servers\nginx-1.4.7 -s stop</stopargument>
</service>
④在命令行下執行以下命令，以便將其注冊成Windows服務：nginx-service.exe install
Nginx搭建反向代理伺服器過程詳解
⑤接下來就可以在Windows服務列表看到Nginx服務了，這里我們可以將其設置為自動啟動了：
Nginx搭建反向代理伺服器過程詳解
（5）總結：在Windows環境中，要對外提供的Windows服務一般都要將其啟動類型設置為自動。
3.3 修改Nginx核心配置文件nginx.conf
（1）進程數與每個進程的最大連接數：
?nginx進程數，建議設置為等於CPU總核心數
?單個進程最大連接數，那麼該伺服器的最大連接數=連接數*進程數
Nginx搭建反向代理伺服器過程詳解
（2）Nginx的基本配置：
?監聽埠一般都為http埠：80;
?域名可以有多個，用空格隔開：例如 server_name www.ha97.com ha97.com;
Nginx搭建反向代理伺服器過程詳解
（3）負載均衡列表基本配置：
?location / {}：對aspx後綴的進行負載均衡請求，假如我們要對所有的aspx後綴的文件進行負載均衡時，可以這樣寫：location ~ .*\.aspx$ {}
?proxy_pass：請求轉向自定義的伺服器列表，這里我們將請求都轉向標識為http://cuitccol.com的負載均衡伺服器列表；
Nginx搭建反向代理伺服器過程詳解
?在負載均衡伺服器列表的配置中，weight是權重，可以根據機器配置定義權重（如果某台伺服器的硬體配置十分好，可以處理更多的請求，那麼可以 為其設置一個比較高的weight；而有一台的伺服器的硬體配置比較差，那麼可以將前一台的weight配置為weight=2，後一台差的配置為 weight=1）。weigth參數表示權值，權值越高被分配到的幾率越大；
Nginx搭建反向代理伺服器過程詳解
（4）總結：最基本的Nginx配置差不多就是上面這些內容，當然僅僅是最基礎的配置。（詳細的配置內容請下載底部的nginx-1.4.7詳細查看）
3.4 添加Nginx對於靜態文件的緩存配置
為了提高響應速度，減輕真實伺服器的負載，對於靜態資源我們可以在反向代理伺服器中進行緩存，這也是反向代理伺服器的一個重要的作用。
（1）緩存靜態資源之圖片文件
root /nginx-1.4.7/staticresources/image：對於配置中提到的jpg/png等文件均定為到/nginx-1.4.7/staticresources/image文件夾中進行尋找匹配並將文件返回；
expires 7d：過期時效為7天，靜態文件不怎麼更新，過期時效可以設大一點，如果頻繁更新，則可以設置得小一點；
TIPS：下面的樣式、腳本緩存配置同這里一樣，只是定位的文件夾不一樣而已，不再贅述。
Nginx搭建反向代理伺服器過程詳解
（2）緩存靜態資源之樣式文件
Nginx搭建反向代理伺服器過程詳解
（3）緩存靜態資源之腳本文件
Nginx搭建反向代理伺服器過程詳解
（4）在nginx服務文件夾中創建靜態資源文件夾，並要緩存的靜態文件拷貝進去：這里我主要將Web程序中用到的image、css以及js文件拷貝了進去；
Nginx搭建反向代理伺服器過程詳解
（5）總結：通過配置靜態文件的緩存設置，對於這些靜態文件的請求可以直接從反向代理伺服器中直接返回，而無需再將這些靜態資源請求轉發到具體的Web伺服器進行處理了，可以提高響應速度，減輕真實Web伺服器的負載壓力。
3.5 簡單測試Nginx反向代理實現負載均衡效果
（1）第一次訪問http://localhost/Default.aspx時從127.0.0.1:8050處理響應返回結果
（2）第二次訪問http://localhost/Default.aspx時從127.0.0.1:8060處理響應返回結果
（3）多次訪問http://localhost/Default.aspx時的截屏：
Nginx搭建反向代理伺服器過程詳解
學習小結
在本文中，藉助了Nginx這個神器簡單地在Windows環境下搭建了一個反向代理服務，並模擬了一個IIS伺服器集群的負載均衡效果。從這個 DEMO中，我們可以簡單地感受到反向代理為我們所做的事情，並體會負載均衡是怎麼一回事。但是，在目前大多數的應用中，都會將Nginx部署在 Linux伺服器中，並且會做一些針對負載均衡的優化配置，這里我們所做的僅僅就是一個小小的使用而已（just修改一下配置文件）。不過，萬丈高樓平地 起，前期的小小體會，也會幫助我們向後期的深入學習奠定一點點的基礎。
突然在QQ空間里看到了朋友送的禮物，猛然發現今天居然是我的陽歷生日，好吧，我祝我自己生日快樂，希望自己在未來的日子中能夠做更多的實踐，分享更多的內容。當然，如果你覺得本文還可以，那也麻煩點個贊，不要吝嗇你的滑鼠左鍵喲。

『伍』 如何利用Nginx架設Http代理伺服器

配置如下:
server {
listen 8888;
client_body_timeout 60000;
client_max_body_size 1024m;
send_timeout 60000;
client_header_buffer_size 16k;
large_client_header_buffers 4 64k;

proxy_headers_hash_bucket_size 1024;
proxy_headers_hash_max_size 4096;
proxy_read_timeout 60000;
proxy_send_timeout 60000;

location / {
resolver 8.8.8.8;
proxy_pass http://$http_host$request_uri;
}
}

resolver 8.8.8.8; 代表使用Google DNS來解析域名 client_body_timeout , large_client_header_buffers 等設置,確保大的請求不會返回400錯誤.

但,這個代理伺服器只支持Http請求, Https會報400錯誤.

『陸』 如何用Nginx快速搭建一個安全的微服務架構

教你如何用Nginx搭建一個安全的、快速的微服務架構
今天我們要談論微服務以及如何使用Nginx構建一個快速的、安全的網路系統。最後，我們將向您展示一個使用Fabric模式如何非常快速和輕松地構建一個微服務的demo。
在我們探討Fabric模式之前，我想談一談微服務並且從Nginx的角度來看這意味著什麼。
0：56 - 大轉變

微服務已經引起了應用程序架構的重大轉變。

當我第一次開始構建應用程序時，他們都是差不多的。幻燈片中所展示的單體架構也象徵了應用程序的構造方式。
目前存在著某種類型的虛擬機（VM），對我來說，就是通常的Java。在虛擬機中應用的功能組件以對象的形式存在，這些對象是在內存中相互通訊的，它們將來來回回處理並進行方法調用。偶爾，你會採用諸如通知等機制來接觸到其他系統以便獲取數據或傳遞信息。

有了微服務之後，應用程序如何構建的範式是完全不同的了。你的功能組件會從在同一個主機的內存中通過虛擬機相互通訊轉變到部署在容器中，並且使用Restful API調用通過HTTP來相互連接。
這是非常強大的，因為它賦予了你功能隔離。它為您提供了更細粒度的可伸縮性，並且你可以獲得更好地處理故障的彈性。很多情況下這是簡單的事實，你只需要使用HTTP進行跨網路調用。
現在，這種方法也有一些缺點。
一件軼事


我有一個暗黑的秘密，我是一個微軟的員工並且從事.Net開發已經很多年了。當我在那兒的時候，我搭建了一個他們的名為Showcase的視頻發布平台。
Showcase是一個用來將微軟內部發布的所有視頻發布到網上的工具。人們可以觀看這些視頻並進行學習，比如Microsoft Word的使用提示和技巧。這是一個非常受歡迎的平台，我們有很多人使用它，並且其中很多人都會在我們發布的視頻上發表評論。
Showcase從一開始就是一個.Net單體應用，隨著它日益受歡迎，我們決定應該將它更換為SOA架構。轉換是相對容易的。Visual Studio提供了本質上的翻轉開關的能力，也就是將你的DLL調用轉變為Restful API調用。隨著一些小的重構，我們能夠讓我們的代碼運行得相當好。我們也為這些評論和應用內的社區功能使用智能社區服務。
緊密的迴路問題


看起來我們是SOA可行的，在我們的首次測試中，一切都工作正常，直到我們將系統切換到我們的Staging環境並開始使用生產環境數據時，我們就會看到一些嚴重的問題。這些問題在在頁面上有很多評論。
這是一個非常受歡迎的平台，其中的一些頁面已經有多達2000條評論了。當我們深入這些問題時，我們意識到這些頁面需要花費一分鍾進行渲染的原因是因為智能社區服務首先需要填充用戶名，然後對每一個用戶名都需要發起一個對於用戶資料庫的網路調用來獲得用戶詳細信息並且填充在渲染頁面上。這是非常低效的，需要一到兩分鍾來渲染頁面，而在內存中進行通常只需要5到6秒鍾。
緩解


當我們經歷了發現和解決問題的過程後，我們最終通過一些措施來調整優化系統，比如對所有的請求進行分組。我們緩存了一些數據，最終我們優化了網路來真正的提高性能。
所以，這與微服務有什麼關系呢？對的，藉助於微服務，你基本上是採用SOA架構的，並且會將其放入超光速引擎中。在SOA架構中所有的對象都是包含在單個虛擬機中並且在其內部管理，在內存中相互通訊，而現在微服務中是使用HTTP進行數據交換的。
當這樣做沒有問題時，你會獲得很好的性能和線性可伸縮性。
Nginx能夠很好地與微服務工作


Nginx是一個你可以用來過渡到微服務的最佳工具之一。
關於Nginx和微服務的一些歷史。我們從一開始就參與了微服務運動，還是第一個從Docker Hub下載應用的，我們的客戶以及那些擁有一些世界上最大的微服務安裝量的最終用戶廣泛地在他們的基礎設施使用Nginx。
原因是Nginx很小、很快並且很可靠。
Nginx微服務參考架構


我們還致力於在Nginx內部使用微服務工作已經有一段時間了。這是一個我們已經搭建的程式化的Nginx微服務參考架構，目前正在AWS上運行。
我們擁有6個核心的微服務，它們都運行在Docker容器里。我們決定建立一個多語種的應用，所以每個容器都可以運行不同的語言，我們目前使用了Ruby、Python、php、Java和Node.js。
我們搭建了這個使用十二要素應用的系統，稍加修改，就會使其更好地為微服務工作從而可以替代Roku平台。稍後，我們將向您展示一個實際上運行在demo里的應用。
MRA的價值


為什麼我們要建立這樣一個參考的微服務架構呢？
我們建立這個參考架構是因為我們需要給我們的客戶提供構建微服務的藍圖，我們也想在微服務上下文中測試Nginx和Nginx Plus的功能，弄清楚如何才能更好地利用它的優勢。最後，我們要確保我們對於微服務生態系統以及其可以給我們提供什麼有一個深入的理解。
網路問題


讓我們回到我們討論的大轉變。
從將運行在內存里並且被虛擬機管理的你的應用的所有功能組件遷移到通過網路進行工作並且相互通訊的方式，你會本質上引入一系列為了應用有效工作需要你解決的問題。
第一你需要服務發現，第二，你需要在架構中為所有不同的實例進行負載均衡，然後還有第三個，你需要操心性能和安全。
無論是好是壞，這些問題密不可分，你必須做權衡，有希望的是我們有一個可以解決所有這些問題的解決方案。
讓我們更深入地看待每一個問題。
服務發現

讓我們來談談服務發現。在單體應用中，APP引擎會管理所有的對象關系，你永遠不必擔心一個對象與另一個對象的相對位置，你只需要簡單的調用一個方法，虛擬機會連接到對象實例，然後在調用完畢後銷毀。
然後有了微服務，你需要考慮那些服務的位置。不幸的是，這不是一個普遍的標准流程。您正在使用的各種服務注冊中心，無論是Zookeeper、Consul、etcd或者其它的，都會以不同的方式進行工作。在這個過程中，你需要注冊你的服務，還需要能夠讀取這些服務在哪裡並且可以被連接。
負載均衡


第二個問題是關於負載均衡的。當您擁有多個服務實例時，您希望能夠輕松地連接到它們，將您的請求在它們中高效地分發，並以最快的方式執行，所以不同實例之間的負載均衡是非常重要的問題。
不幸的是，最簡單形式的負載均衡是非常低效的。當你開始使用不同的更加復雜的方案做負載均衡時，它也變得更加復雜並且不易於管理。理想情況下，您希望您的開發人員能夠基於他們的應用程序的需求決定何種負載均衡方案。例如，如果你連接到一個有狀態的應用程序，你需要擁有持久化，這樣可以確保你的Session信息會被保留。
安全和快速通訊


也許微服務最令人生畏的領域是性能和安全。
當在內存中運行時，一切都很快。現在，運行在網路上就會慢了一個數量級。
被安全地包含在一個系統中的信息，通常是二進制格式的，現在會被用文本格式在網路上傳輸。現在是比較容易在網路上布置嗅探器並能夠監聽你的應用正在被移動的所有數據。
如果要在傳輸層加密數據，那麼會在連接速率和CPU使用率方面引入顯著的開銷。SSL/TLS在其全面實施階段需要九個步驟來初始化一個請求。當你的系統每天需要處理成千上萬、幾萬、數十萬或數百萬的請求時，這就成為性能的一個重要障礙了。
一個解決方案


我們已經在Nginx開發的一些解決方案，我們認為，會解決所有的這些問題，它賦予你健壯的服務發現、非常棒的用戶可配置負載均衡以及安全和快速加密。
網路架構


讓我們來談談你可以安裝和配置你的網路架構的各種方法。
我們提出了三種網路模型，它們本身並不相互排斥，但我們認為它們屬於多種格式的。這三種模式是Proxy模式、Router Mesh模式和Fabric模式——這是最復雜的，並在許多方面在其頭部進行負載均衡。
Proxy模式


Proxy模式完全聚焦於你的微服務應用的入站流量，並且事實上忽略內部通訊。
你會獲得Nginx提供的所有的HTTP流量管理方面的福利。你可以有SSL/TLS終止、流量整形和安全，並且藉助於最新版本的Nginx Plus和ModSecurity，你可以獲得WAF能力。
你也可以緩存，你可以將Nginx提供給你的單體應用的所有東西添加到你的微服務系統里，並且藉助於Nginx Plus，你可以實現服務發現。當你的API實例上下浮動時，Nginx Plus可以在負載均衡工具里動態地添加和減去它們。
Router Mesh模式


Router Mesh模式類似於Proxy模式，在其中我們有一個前端代理服務來管理接入流量，但它也在服務之間添加了集中式的負載均衡。
每個服務連接到集中式的Router Mesh，它管理不同服務之間的連接分發。Router Mesh模式還允許你在熔斷器模式中搭建，以便可以對你的應用添加彈性並允許你採取措施來監控和拉回你的失效的服務實例。
不幸的是，因為該模式增加了一個額外的環節，如果你不得不進行SSL/TLS加密，它事實上加劇了性能問題。這就是引入Fabric模式的原因。
Fabric模式


Fabric模式是將其頭部的所有東西翻轉的模式。
就像之前的另外兩個模式一樣，在前面會有一個代理伺服器來管理流入流量，但與Router Mesh模式不同的地方就是你用運行在每個容器里的Nginx Plus來替代了集中式的Router。
這個Nginx Plus實例對於所有的HTTP流量作為反向和正向代理，使用這個系統，你可以獲得服務發現、健壯的負載均衡和最重要的高性能加密網路。
我們將探討這是如何發生的，以及我們如何處理這項工作。讓我們先來看看一個服務如何連接和分發他們的請求結構的正常流程。
正常的流程


在這個圖中，你可以看到投資管理器需要跟用戶管理器通訊來獲取信息。投資管理器創建了一個HTTP客戶端，該客戶端針對服務注冊中心發起了一個DNS請求並獲得返回的一個IP地址，接著初始化了一個到用戶管理器的SSL/TLS連接，該連接需要通過九階段的協商或者是」握手」過程。一旦數據傳輸完畢，虛擬機會關閉連接並進行HTTP客戶端的垃圾回收。
整個過程就是這樣。這是相當簡單和易於理解的。當你把它分解成這些步驟時，您可以看到該模式是如何真正完成請求和響應過程的。
在Fabric模式中，我們已經改變了這一點。
Fabric模式的細節


你會注意到的第一件事是Nginx Plus是運行在每一個服務里的，並且應用程序代碼是在本地與Nginx Plus通信的。因為這些是本地連接，你不需要擔心加密問題。它們可以是從Java或者PHP代碼到Nginx Plus實例的HTTP請求，並且都是在容器內的本地HTTP請求。
你也注意到Nginx Plus會管理到服務注冊中心的連接，我們有一個解析器，通過非同步查詢注冊中心的DNS實例來獲取所有的用戶管理器實例，並且預先建立連接，這樣當Java服務需要從用戶管理器請求一些數據的時候，可以使用預先建立的連接。
持久的SSL/TLS連接


微服務之間的有狀態的、持久化的並且可以加密的連接是真正的益處。
記得在第一個圖中服務實例是如何通過一些流程的吧，比如創建HTTP客戶端、協商SSL/TLS連接、發起請求並關閉的嗎？在這里，Nginx預先建立了微服務之間的連接，並使用Keepalive特性，保持調用之間的持續連接，這樣你就不必為每一個請求處理SSL/TLS協商了。
本質上，我們創建了一個迷你的從服務到服務的VPN連接。在我們最初的測試中，我們發現連接速度增加了77%。
熔斷器Plus


在Fabric模式以及Router Mesh模式中，你也可以從創建和使用熔斷器模式中獲得好處。
本質上，您定義了一個在服務內部的活躍的健康檢查，並設置緩存，以便在服務不可用的情況下保留數據，從而獲得完整的熔斷器功能。
所以，現在我可以確定你認為Fabirc模式聽起來很酷，並且想在實際環境中躍躍欲試。

『柒』 nginx http文件伺服器 怎麼配置

Nginx功能豐富，可作為HTTP伺服器，也可作為反向代理伺服器，郵件伺服器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。並且支持很多第三方的模塊擴展。

『捌』 求助關於centos6.6搭建nginx反向代理伺服器

〉直接作為http server(代替apache，對PHP需要FastCGI處理器支持)；
〉另外一個功能就是作為反向代理伺服器實現負載均衡

以下我們就來舉例說明如何使用 nginx 實現負載均衡。因為nginx在處理並發方面的優勢，現在這個應用非常常見。當然了Apache的 mod_proxy和mod_cache結合使用也可以實現對多台app server的反向代理和負載均衡，但是在並發處理方面apache還是沒有 nginx擅長。

1)環境：

a. 我們本地是Windows系統，然後使用VirutalBox安裝一個虛擬的Linux系統。
在本地的Windows系統上分別安裝nginx(偵聽8080埠)和apache(偵聽80埠)。在虛擬的Linux系統上安裝apache(偵聽80埠)。
這樣我們相當於擁有了1台nginx在前端作為反向代理伺服器；後面有2台apache作為應用程序伺服器(可以看作是小型的server cluster。;-) )；

b. nginx用來作為反向代理伺服器，放置到兩台apache之前，作為用戶訪問的入口；
nginx僅僅處理靜態頁面，動態的頁面(php請求)統統都交付給後台的兩台apache來處理。
也就是說，可以把我們網站的靜態頁面或者文件放置到nginx的目錄下；動態的頁面和資料庫訪問都保留到後台的apache伺服器上。

c. 如下介紹兩種方法實現server cluster的負載均衡。
我們假設前端nginx(為127.0.0.1:80)僅僅包含一個靜態頁面index.html；
後台的兩個apache伺服器(分別為localhost:80和158.37.70.143:80)，一台根目錄放置phpMyAdmin文件夾和test.php(裡面測試代碼為print 「server1「;)，另一台根目錄僅僅放置一個test.php(裡面測試代碼為 print 「server2「;)。

2)針對不同請求 的負載均衡：

a. 在最簡單地構建反向代理的時候 (nginx僅僅處理靜態不處理動態內容，動態內容交給後台的apache server來處理)，我們具體的設置為：在nginx.conf中修改：
復制代碼 代碼如下:

location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}

〉 這樣當客戶端訪問localhost:8080/index.html的時候，前端的nginx會自動進行響應；
〉當用戶訪問localhost:8080/test.php的時候(這個時候nginx目錄下根本就沒有該文件)，但是通過上面的設置 location ~ \.php$(表示正則表達式匹配以.php結尾的文件，詳情參看location是如何定義和匹配的 http://wiki.nginx.org/NginxHttpCoreMole) ，nginx伺服器會自動pass給 158.37.70.143的apache伺服器了。該伺服器下的test.php就會被自動解析，然後將html的結果頁面返回給nginx，然後 nginx進行顯示(如果nginx使用memcached模塊或者squid還可以支持緩存)，輸出結果為列印server2。

如上是最為簡單的使用nginx做為反向代理伺服器的例子；

b. 我們現在對如上例子進行擴展，使其支持如上的兩台伺服器。
我們設置nginx.conf的server模塊部分，將對應部分修改為：
復制代碼 代碼如下:

location ^~ /phpMyAdmin/ {
proxy_pass 127.0.0.1:80 ;
}
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}

上面第一個部分location ^~ /phpMyAdmin/，表示不使用正則表達式匹配(^~)，而是直接匹配，也就是如果客戶端訪問的 URL是以http://localhost:8080/phpMyAdmin/ 開頭的話(本地的nginx目錄下根本沒有phpMyAdmin目錄)，nginx會自動pass到127.0.0.1:80 的Apache伺服器，該伺服器對phpMyAdmin目錄下的頁面進行解析，然後將結果發送給nginx，後者顯示；
如果客戶端訪問URL是http://localhost/test.php 的話，則會被pass到158.37.70.143:80 的apache進行處理。

因此綜上，我們實現了針對不同請求的負載均衡。
〉如果用戶訪問靜態頁面index.html，最前端的nginx直接進行響應；
〉如果用戶訪問test.php頁面的話，158.37.70.143:80 的Apache進行響應；
〉如果用戶訪問目錄phpMyAdmin下的頁面的話，127.0.0.1:80 的Apache進行響應；

3)訪問同一頁面 的負載均衡：
即用戶訪問http://localhost:8080/test.php 這個同一頁面的時候，我們實現兩台伺服器的負載均衡 (實際情況中，這兩個伺服器上的數據要求同步一致，這里我們分別定義了列印server1和server2是為了進行辨認區別)。

a. 現在我們的情況是在windows下nginx是localhost偵聽8080埠；
兩台apache，一台是127.0.0.1:80(包含test.php頁面但是列印server1)，另一台是虛擬機的158.37.70.143:80(包含test.php頁面但是列印server2)。

b. 因此重新配置nginx.conf為：
〉首先在nginx的配置文件nginx.conf的http模塊中添加，伺服器集群server cluster(我們這里是兩台)的定義：
復制代碼 代碼如下:

upstream myCluster {
server 127.0.0.1:80 ;
server 158.37.70.143:80 ;
}

表示這個server cluster包含2台伺服器
〉然後在server模塊中定義，負載均衡：
復制代碼 代碼如下:

location ~ \.php$ {
proxy_pass http://myCluster ; #這里的名字和上面的cluster的名字相同
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

這樣的話，如果訪問http://localhost:8080/test.php 頁面的話，nginx目錄下根本沒有該文件，但是它會自動將其pass到myCluster定義的服務區機群中，分別由127.0.0.1:80;或者158.37.70.143:80;來做處理。
上面在定義upstream的時候每個server之後沒有定義權重，表示兩者均衡；如果希望某個更多響應的話例如：
復制代碼 代碼如下:

upstream myCluster {
server 127.0.0.1:80 weight=5;
server 158.37.70.143:80 ;
}

這樣表示5/6的幾率訪問第一個server,1/6訪問第二個。另外還可以定義max_fails和fail_timeout等參數。

綜上，我們使用nginx的反向代理伺服器reverse proxy server的功能，將其布置到多台apache server的前端。
nginx僅僅用來處理靜態頁面響應和動態請求的代理pass，後台的apache server作為app server來對前台pass過來的動態頁面進行處理並返回給nginx。

通過以上的架構，我們可以實現nginx和多台apache構成的機群cluster的負載均衡。
兩種均衡：
1)可以在nginx中定義訪問不同的內容，代理到不同的後台server； 如上例子中的訪問phpMyAdmin目錄代理到第一台server上；訪問test.php代理到第二台server上；
2)可以在nginx中定義訪問同一頁面，均衡 (當然如果伺服器性能不同可以定義權重來均衡)地代理到不同的後台server上。 如上的例子訪問test.php頁面，會均衡地代理到server1或者server2上。
實際應用中，server1和server2上分別保留相同的app程序和數據，需要考慮兩者的數據同步。

『玖』 如何用 Nginx 配置透明 HTTP 和 HTTPS 代理

Nginx ("engine x") 是一個高性能的 HTTP 和 反向代理 伺服器，也是一個 IMAP/POP3/SMTP 代理伺服器。 Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru 站點開發的，，因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。
1、首先需要配置站點的WoSign SSl證書

打開Nginx安裝目錄下conf目錄中的nginx.conf文件 找到
# HTTPS server
#
#server {
# listen 443;
# server_name localhost;
# ssl on;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_timeout 5m;
# ssl_protocols SSLv2 SSLv3 TLSv1;
# ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
將其修改為 :
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate sslkey/public.cer; （證書公鑰）
ssl_certificate_key sslkey/private.key; （證書私鑰）
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;
location / {
root html;
index index.html index.htm;
}
}
保存退出，並重啟Nginx。
通過https方式訪問您的站點，測試站點證書的安裝配置。

『拾』 如何用 Nginx 配置透明 HTTP 和 HTTPS 代理

Nginx ("engine x") 是一個高性能的 HTTP 和 反向代理 伺服器，也是一個 IMAP/POP3/SMTP 代理伺服器。 Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru 站點開發的，，因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。
1、首先需要配置站點的WoSign SSl證書

打開Nginx安裝目錄下conf目錄中的nginx.conf文件 找到
# HTTPS server
#
#server {
# listen 443;
# server_name localhost;
# ssl on;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_timeout 5m;
# ssl_protocols SSLv2 SSLv3 TLSv1;
# ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}