面向服務的體系結構中的網關服務

Question

我非常喜歡實現我自己的單入口點「網關」的想法，它有兩件事。

首先，它記錄SOA服務器處理了多少個請求，並將下一個請求循環到最可用的服務器。對負載均衡邏輯的完全控制很有吸引力。其次，這個「門戶」將是我所有服務的單一聯絡人，包括安全。如果客戶端發送了一個用戶名 - 密碼組合，它將它們傳遞給安全服務，該服務在成功認證時授予令牌。如果客戶端發送令牌，則網關運行該令牌的安全服務，如果它是猶太潔食，則將請求傳遞給其中一個業務服務。隱藏或封裝除網關以外的所有服務似乎都是可取的。

我的問題是：有沒有任何理由爲什麼這不是「正確的做事方式」？當我已經有一個框架可以完成我上面所描述的內容時，我是否可以重新發明輪子？我的堆棧是.NET和WCF。

Answer 1

好問題，但我必須同意sweetfa的評論，在99％的情況下，現成的負載平衡器將是最佳選擇。選項更詳盡的清單：

1. 硬件負載均衡器/網關（如IBM XML網關） - 非常可擴展性和昂貴
2. 服務總線軟件（如Oracle服務總線）會做的安全性和負載平衡好 - 非常可配置和昂貴。可擴展性不如硬件解決方案
3. 開源負載均衡器軟件（例如Apache HTTPD代理模塊）將有大量用戶幫助您通過論壇進行設置。許多解決方案具有很好的可擴展性和強大功能，但配置方式比選項1和2要複雜得多
4. 基於服務註冊表（UDDI v3）的負載均衡，當服務使用者在每次調用時查找提供者URI 。註冊表將通過返回不同的URI來負載平衡請求。如果您需要一些高級自適應負載平衡算法或者您需要非標準安全層，此解決方案將不會充當安全網關，並且消費者可能會將其全部忽略。
5. 構建您自己的解決方案。讓我們忘記非標準的安全性，這很少是一個好主意，但是自適應負載平衡是可取的。選項1-3將基於響應時間進行循環或加權循環或自適應循環，並且它們將檢測到無響應的實例。選項1和3提供了另一個難以實現的功能，即HTTP會話粘性，但對於SOAP或REST服務不是必需的。