## 部署 Envoy可用于各種不同的場景，但是在跨基礎架構中進行所有主機網格部署時，它是最有用的。本節介紹三種推薦的部署方式，其復雜程度越來越高。 ### 服務間  上圖顯示了最簡單的Envoy部署方式，使用Envoy作為通信總線，承擔面向服務架構（SOA）內部所有的流量。在這種情況下，Envoy公開了幾個用于本地來源流量的監聽器，以及用于處理服務的流量。 #### 服務間出口監聽器 這是應用程序與基礎結構中的其他服務交互的端口。例如，http://localhost:9001 HTTP和gRPC請求使用HTTP/1.1主機頭或HTTP/2：根據頭來指導請求發往哪個遠程群集。Envoy根據詳細的配置處理服務發現，負載平衡，速率限制等。服務只需要了解本地的Envoy，不需要關心網絡拓撲結構，無論是在開發還是在生產中運行。 此監聽器支持HTTP/1.1或HTTP/2，具體取決于應用程序的功能。 #### 服務間入口監聽器 這是遠程Envoy想要與當地Envoy交談時使用的端口。例如，http://localhost:9211 傳入的請求被路由到配置的端口上的本地服務。可能會涉及多個應用程序端口，具體取決于應用程序或負載平衡需求（例如，如果服務同時需要HTTP端口和gRPC端口）。本地Envoy根據需要進行緩沖，斷路等。 我們的默認配置對所有Envoy通信都使用HTTP/2，而不管應用程序在離開本地Envoy時是否使用HTTP/1.1或HTTP/2。HTTP/2支持長連接和顯式重置通知，能夠提供更好的性能。 #### 可選的外部服務出口監聽器 通常，本地服務要與之通話的每個外部服務都使用明確的出口端口。這樣做是因為一些外部服務SDK不輕易理解主機報文頭，以支持標準的HTTP反向代理能力。例如，http://localhost:9250 可能被分配給發往DynamoDB的連接。我們建議為所有外部服務保持一致并使用本地端口路由，而不是為某些外部服務使用主機路由，為其他服務使用專用本地端口路由。 #### 集成發現服務 建議的配置使用外部發現服務進行所有群集發現。這為Envoy提供了在執行負載平衡，統計收集等時可能使用的詳細的服務發現信息。 #### 配置模板 源代碼發行版包含一個配置示例，與Lyft在生產環境中運行的版本非常相似。瀏覽此處獲取[更多](../Buildingandinstallation/Referenceconfigurations.md)信息。 ### 服務間+前端代理  上圖顯示了服務部署，Envoy作為HTTP L7前端反向代理的群集。反向代理提供以下功能： - 對外提供TLS安全，對內屏蔽TLS - 支持HTTP/1.1和HTTP/2 - 完整的HTTP L7路由支持 - 提供標準入站端口，來訪問Envoy集群服務，并使用發現服務進行主機查找。因此，前面的Envoy和任何其他的Envoy一樣工作，除了他們沒有與另一個服務進程搭配在一起。這意味著可以以相同的方式運行，并發出相同的統計數據。 #### 配置模板 源代碼發行包含一個與Lyft在生產中運行的版本非常相似的示例前端代理配置。瀏覽此處獲取[更多](../Buildingandinstallation/Referenceconfigurations.md)信息。 ### 服務間、前端代理和雙重代理  上圖顯示了作為雙重代理，運行了另一個Envoy做為前端代理。雙重代理背后的想法是，盡可能地將TLS和客戶端連接終止到用戶（TLS握手的更短的往返時間，更快的TCP CWND擴展，更少的數據包丟失機會等），會更高效。在雙重代理中終止的連接，然后被復用到在主數據中心中運行的HTTP/2長連接。 在上圖中，在區域1中，運行的前端Envoy代理通過固定證書與在區域2中運行的前端Envoy代理進行身份驗證。這允許在區域2中運行的前端Envoy實例，信任之前不能信任的入站轉發請求（例如`x-forwarded-for`的HTTP頭）。 #### 配置模板 源碼分發包含一個與Lyft在生產中運行的版本非常相似的示例雙重代理配置。瀏覽此處獲取[更多](../Buildingandinstallation/Referenceconfigurations.md)信息。 ## 返回 - [簡介](../Introduction.md) - [首頁目錄](../README.md)