自動化Nginx服務器的反向代理的配置方法

 　　這篇文章主要介紹了自動化Nginx服務器的反向代理的配置方法,反向代理是Nginx服務器的招牌功能,需要的朋友可以參考下

　　如果可以減少過多的外部隔離的API和簡化部署的細節 這會是非常好的。

　　在以前的文章中，我解釋了"一些使用反向代理的好處"。在我目前的項目裡，我們已經構建分布式面向服務的架構，也顯式提供了一個HTTP API，我們使用反向代理將請求路由通過API路由給單個組件。我們選擇了Nginx Web這個優秀的服務器作為我們的反向代理，它快速、可靠且易於配置。我們通過它將多個HTTP的API服務聚合到一個URL空間。舉例來說，當你鍵入：

　　http://api.example.com/product/pinstripe_suit

　　它將被路由到:

　　http://10.0.1.101:8001/product/pinstripe_suit

　　但當你訪問:

　　http://api.example.com/customer/103474783

　　它將被路由到:

　　http://10.0.1.104:8003/customer/103474783

　　對使用者來言，他們覺得是在使用同一個URL空間(http://api.example.com/blah/blah)，但在後端不同的頂級分類的URL被路由到不同的後端服務器。 /prodect/...路由到 10.0.1.101:8001， /customer/…則路由到10.0.1.104:8003。 我們也希望這是自動配置。比如說我想創建一個新的組件來記錄的庫存水平。相比於擴展現有的組件，我更希望能夠寫另一個獨立的可執行文件或提供服務的HTTP端點，然後自動部署成為我的雲計算基礎架構中的主機之一，並使Nginx的自動將http ://api.example.com/sock/whatever 路由我新組件。 我們也想進行 後端服務的負載平衡，我們也想部署我們的股票 新API的多個服務實例間的Nginx自動輪詢。

　　我們稱每個頂級分類(/stock、/produck、/customer)為一個聲明。 A組件上線時通過RabbitMQ發布了一個'AddApiClaim'。此消息有3個字段：'聲明'，'IP地址'，'端口地址'。我們有一個'ProxyAutomation'的特殊組件，這個組件接收這些消息並按要求重寫Nginx配置項。它使用SSH和SCP登錄到nginx服務器，傳輸各種配置文件，並指示Nginx的重新加載配置。我們使用the excellent SSH.NET庫來進行自動化。

　　Nginx的配置是一個非常好的事情是支持通配符。看一看我們的頂級配置文件：

　　代碼如下:

　　...

　　http {

　　include /etc/nginx/mime.types;

　　default_type application/octet-stream;

　　log_format main '$remote_addr - $remote_user [$time_local] "$request" '

　　'$status $body_bytes_sent "$http_referer" '

　　'"$http_user_agent" "$http_x_forwarded_for"';

　　access_log /var/log/nginx/access.log main;

　　sendfile on;

　　keepalive_timeout 65;

　　include /etc/nginx/conf.d/*.conf;

　　}

　　如16行所描述, 將conf.d目錄的所有.conf引用到此處.

　　在conf.d文件夾內，有一個文件包含了所有api.example.com的請求配置:

　　代碼如下:

　　include /etc/nginx/conf.d/api.example.com.conf.d/upstream.*.conf;

　　server {

　　listen 80;

　　server_name api.example.com;

　　include /etc/nginx/conf.d/api.example.com.conf.d/location.*.conf;

　　location / {

　　root /usr/share/nginx/api.example.com;

　　index index.html index.htm;

　　}

　　}

　　這段配置讓 Nginx 偵聽來自 80 端口的 api.example.com 的請求。

　　這裡包括兩部分。第一個部分是第一行，我將在以後討論。第7行表述了將子目錄"api.example.com.conf.d"中的location.*.conf引用到配置中來。我們代理服務器的自動化組件添加新的組件(AKA API claims)通過引入新的location.*.conf。舉個例子，我們的股票組件可能創建一個location.stock.conf配置文件，像這樣：

　　代碼如下:

　　location /stock/ {

　　proxy_pass http://stock;

　　}

　　這只是簡單的告訴Nginx將所有api.example.com/stock/…的代理請求轉發到'stock'中定義的後端服務器，這些定義存放在'upstream.*.conf'中。代理自動化組件也引入了一個名為upstream.stock.conf文件，它看起來像這樣：

　　 代碼如下:

　　upstream stock {

　　server 10.0.0.23:8001;

　　server 10.0.0.23:8002;

　　}

　　這些配置告訴Nginx將所有到api.example.com/stock/的請求輪詢到給定的地址，在這個例子中兩個實例在同一台機器(10.0.0.23)上，一個在8001端口，一個在8002端口。

　　正如股票組件的部署一樣，添加新條目可以同樣增加到upstream.stock.conf中。同樣，當組件卸載時，只要刪除對應條目就可以了，當所有組件移除時，將整個文件已就刪除。

　　這種基礎架構可以讓我們聚合組件的基礎設備。我們可以 通過簡單地添加新的組件實例來擴展應用程序。作為組件開發人員也不需要做任何代理配置，只需要確保組件發送了添加或刪除API聲明的消息就可以了。