如果可以減少過多的外部隔離的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的配置是一個非常好的事情是支持通配符。看一看我們的頂級配置文件：
 

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

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

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

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

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

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

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

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