### 服務發現
在配置上游群集時,Envoy需要知道解析這些群集的成員。這被稱為服務發現。
#### 支持的服務發現類型
##### 靜態
靜態是最簡單的服務發現類型。通過靜態配置明確每個上游主機的網絡名稱(IP地址/端口,unix域套接字等)。
##### 嚴格(Strict)DNS
當使用DNS服務發現時,Envoy將持續并異步地解析指定的DNS目標。DNS結果中的每個返回的IP地址將被視為上游群集中的顯式主機。 這意味著如果查詢返回三個IP地址,Envoy將假定集群有三個主機,并且三個主機都應該負載平衡。如果主機從結果中刪除,則Envoy認為它不再存在,并將從任何現有的連接池中攝取流量。請注意,Envoy絕不會在轉發路徑中同步解析DNS。以最終一致性為代價,永遠不會擔心長時間運行的DNS查詢會受到阻塞。
##### 邏輯(Logical)DNS
邏輯DNS使用類似的異步機制來解析嚴格DNS。但是,并不是嚴格考慮DNS查詢的結果,而是假設它們構成整個上游集群,而邏輯DNS集群僅使用在需要啟動新連接時返回的第一個IP地址。因此,單個邏輯連接池可以包含到各種不同上游主機的物理連接。連接永遠不會流失。此服務發現類型適用于必須通過DNS訪問的大型Web服務。這種服務通常使用循環法的DNS來返回許多不同的IP地址。通常會為每個查詢返回不同的結果。如果在這種情況下使用嚴格的DNS,Envoy會認為集群的成員在每個解決時間間隔期間都會發生變化,這會導致連接池,連接循環等消失。相反,使用邏輯DNS,連接將保持活動狀態,直到它們循環。在與大型Web服務交互時,這是所有可能的世界中最好的:異步/最終一致的DNS解析,長期連接,以及轉發路徑中的零阻塞。
##### 服務發現服務(SDS)
Envoy通過[REST API](../../v1APIreference/Clustermanager/Servicediscoveryservice.md)向服務發現服務,獲取集群的成員。Lyft通過Python提供了一個發現服務的[參考實現](https://github.com/lyft/discovery)。該實現是使用AWS DynamoDB作為后端存儲,但該API非常簡單,可以輕松地在各種不同的后備存儲之上實現。對于每個SDS群集,Envoy將定期從發現服務中獲取群集成員。SDS做為首選的服務發現機制,原因如下:
- Envoy能夠對每個上游主機都有更加詳細的信息(相比通過DNS解析),并能做出更智能的負載均衡決策。
- 在每個主機發現的API響應中,通過攜帶附加的屬性,如負載均衡權重,灰度狀態,區域等。這些附加屬性在負載均衡,統計信息收集等過程中由Envoy網絡全局使用。
通常,主動健康檢查與最終一致的服務發現服務結合起來使用,以進行負載平衡和路由決策。這將在下一節進一步討論。
##### 最終一致的服務發現
許多現有的RPC系統將服務發現視為完全一致的過程。為此,他們使用支持完全一致的leader選舉存儲,如Zookeeper,etcd,Consul等。我們的經驗是,在大規模操作這些存儲會很痛苦。
Envoy從一開始就設計了服務發現不需要完全一致的想法。相反,Envoy假定主機以一種最終一致的方式來自網格。在部署服務間Envoy網格時,我們推薦使用最終一致的服務發現,結合主動健康檢查(Envoy主動健康檢查上游集群成員狀態)來確定集群運行狀況。這種范例有許多好處:
- 有的健康決定是完全分配的。 因此,網絡分區被正常處理(應用程序是否正常處理分區是另一回事)。
- 為上游群集配置運行狀況檢查時,Envoy使用2x2矩陣來確定是否路由到主機:
<table>
<tr>
<th> 服務發現狀態 </th>
<th> 健康檢查正常 </th>
<th> 健康檢查失敗 </th>
</tr>
<tr>
<th>存在</th>
<th>路由</th>
<th>停止路由</th>
</tr>
<tr>
<th>不存在</th>
<th>路由</th>
<th>停止路由/刪除</th>
</tr>
</table>
- **主機被發現/健康檢查確定**<br />
特使將路由到目標主機。
- **主機無法被發現/健康檢查確定**<br />
Envoy將路由到目標主機。這是非常重要的,因為設計假定發現服務可以隨時失敗。如果主機即使在發現數據缺失之后仍繼續通過健康檢查,Envoy仍將路由。 雖然在這種情況下添加新主機是不可能的,但現有的主機仍然可以正常運行。 當發現服務再次正常運行時,數據將最終重新收斂。
- **主機被發現/健康檢查失敗**<br />
Envoy不會路由到目標主機。假設健康檢查數據比發現數據更準確。
- **主機無法被發現/健康檢查失敗**<br />
Envoy不會路由并將刪除目標主機。這是Envoy將清除主機數據的唯一狀態。
### 返回
- [架構介紹](../Architectureoverview.md)
- [簡介](../../Introduction.md)
- [首頁目錄](../../README.md)
- 首頁
- 簡介
- Envoy是什么
- 架構介紹
- 術語
- 線程模型
- 監聽器
- L3/L4網絡過濾器
- HTTP連接管理
- HTTP過濾器
- HTTP路由
- gRPC
- WebSocket支持
- 集群管理
- 服務發現
- 健康檢查
- 連接池
- 負載均衡
- 異常檢測
- 熔斷
- 全局限速
- TLS
- 統計
- 運行時配置
- 跟蹤
- TCP代理
- 訪問日志
- MongoDB
- DynamoDB
- Redis
- 熱重啟
- 動態配置
- 初始化
- 逐出
- 腳本
- 部署
- 業界對比
- 獲得幫助
- 歷史版本
- 編譯安裝
- 編譯
- 參考配置
- 演示沙箱
- 前端代理
- Zipkin跟蹤
- Jaeger跟蹤
- gRPC橋接
- 構建Envoy Docker鏡像
- 工具
- 配置參考
- V1 API 概述
- V2 API 概述
- 監聽器
- 網絡過濾器
- TLS客戶端身份認證
- Echo
- Mongo代理
- 速率限制
- Redis代理
- TCP代理
- HTTP連接管理器
- 路由匹配
- 流量轉移/分流
- HTTP頭部操作
- HTTP頭部清理
- 統計
- 運行時設置
- 路由發現服務
- HTTP過濾器
- 緩存
- CORS過濾器
- 故障注入
- DynamoDB
- gRPC HTTP/1.1 橋接
- gRPC-JSON 轉碼過濾器
- gRPC-Web 過濾器
- 健康檢查
- 速率限制
- 路由
- Lua
- 集群管理
- 統計
- 運行時設置
- 集群發現服務
- 健康檢查
- 熔斷
- 訪問日志
- 限速服務
- 運行時配置
- 路由表檢查工具
- 運維管理
- 命令行選項
- 熱重啟
- 管理接口
- 統計概述
- 運行時配置
- 文件系統
- 自定義擴展示例
- V1 API參考
- 監聽器
- 網絡過濾器
- TLS客戶端身份認證
- Echo
- HTTP連接管理
- Mongo代理
- 速率限制
- Redis代理
- TCP代理
- HTTP路由配置
- 虛擬主機
- 路由
- 虛擬集群
- 速率限制配置
- 路由發現服務
- HTTP過濾器
- 緩存
- CORS過濾器
- DynamoDB
- 故障注入
- gRPC HTTP/1.1 橋接
- gRPC-JSON 轉碼過濾器
- gRPC-Web 過濾器
- 健康檢查
- Lua
- 速率限制
- 路由
- 集群管理
- 集群
- 健康檢查
- 熔斷
- TLS上下文
- 異常值檢測
- HASH環負載均衡配置
- 異常檢測
- 集群發現服務
- 服務發現服務
- 訪問日志
- 管理接口
- 限速服務
- 運行時配置
- 跟蹤
- V2 API參考
- 啟動引導
- 監聽&監聽發現
- 集群&集群發現
- 服務發現
- 健康檢查
- HTTP路由管理&發現
- TLS配置
- 通用的類型
- 網絡地址
- 協議選項
- 發現API
- 限速組件
- 過濾器
- 網絡過濾器
- TLS客戶端身份認證
- HTTP連接管理
- Mongo代理
- 速率限制
- Redis代理
- TCP代理
- HTTP過濾器
- 緩存
- 故障注入
- 健康檢查
- Lua
- 速率限制
- 路由
- gRPC-JSON轉碼器
- 常見訪問日志類型
- 常見故障注入類型
- FAQ
- Envoy有多快?
- 我在哪里獲得二進制文件?
- 我如何設置SNI?
- 如何設置區域感知路由?
- 我如何設置Zipkin跟蹤?