這篇文章主要介紹了自動化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聲明的消息就可以了。
