Istio是一個開源的服務網格，可為分布式微服務架構提供所需的基礎運行和管理要素。隨著各組織越來越多地采用云平臺，開發者必須使用微服務設計架構以實現可移植性，而運維人員必須管理包含混合云部署和多云部署的大型分布式應用。Istio采用一種一致的方式來保護、連接和監控微服務，降低了管理微服務部署的復雜性。

從架構設計上來看，Istio服務網格在邏輯上分為控制平面和數據平面兩部分。其中，控制平面Pilot負責管理和配置代理來路由流量，并配置Mixer以實施策略和收集遙測數據；數據平面由一組以Sidecar方式部署的智能代理（Envoy）組成，這些代理可以調節和控制微服務及Mixer之間所有的網絡通信。

Istio架構

作為代理，Envoy非常適合服務網格的場景，但要發揮Envoy的最大價值，就需要使它很好地與底層基礎設施或組件緊密配合。Envoy構成了服務網格的數據平面，Istio提供的支撐組件則是創建了控制平面。

Pilot與Envoy數據平面

一方面，我們在Envoy中看到，可以使用靜態配置文件或使用一組發現服務來配置一組服務代理，以便在運行時發現監聽器、端點和集群。Istio在Pilot中實現了這些Envoy代理的xDS API。

另一方面，Envoy的服務發現依賴于某種服務注冊表來發現服務端點。Istio Pilot實現了這個API，但也將Envoy從任何特定的服務注冊實現中抽象出來。當Istio部署在Kubernetes上時，Kubernetes的服務注冊表是Istio用于服務發現的。其他注冊表也可以像HashiCorp的Consul那樣使用。Envoy數據平面完全不受這些實施細節的影響。

Mixer架構

此外，Envoy代理可以發出很多指標和遙測數據，這些遙測數據發送到何處，取決于Envoy的配置。Istio提供遙測接收器Mixer作為其控制平面的一部分，Envoy代理可以將這些數據發送到Mixer。Envoy還將分布式跟蹤數據發送到開放式跟蹤引擎（遵循Open Tracing API）。Istio可以支持兼容的開放式跟蹤引擎并配置Envoy將其跟蹤數據發送到該位置。

剖析Istio控制平面

Istio的控制平面和Envoy的數據平面共同構成了一個引人注目的服務網格實現。兩者都擁有蓬勃發展和充滿活力的社區，并且面向下一代服務架構。Istio是獨立于平臺的，可運行于各種環境中，包括跨云、內部部署、Kubernetes、Mesos等。你可以在Kubernetes 上部署Istio或在具有Consul的Nomad上部署。Istio目前支持在Kubernetes上部署的服務、使用Consul注冊的服務以及在虛擬機上部署的服務。

其中，控制平面部分包括了Pilot、Mixer、Citadel和Galley四個組件。

Pilot

Istio的Pilot組件用于管理流量，可以控制服務之間的流量流動和API調用，通過Pilot可以更好地了解流量，以便在問題出現之前發現問題。這使得調用更加可靠、網絡更加強健，即使遇到不利條件也能讓應用穩如磐石。借助Istio的Pilot，你能夠配置熔斷器、超時和重試等服務級屬性，并設置常見的連續部署任務，如金絲雀發布、A/B測試和基于百分比拆分流量的分階段發布。Pilot為Envoy代理提供服務發現功能，為智能路由和彈性能力（如超時、重試、熔斷器等）提供流量管理功能。Pilot將控制流量行為的高級路由規則轉換為特定于Envoy代理的配置，并在運行時將它們傳播到Envoy。此外，Istio提供了強大的開箱即用故障恢復功能，包括超時、支持超時預算和變量抖動的重試機制、發往上游服務的并發連接和請求數限制、對負載均衡池中的每個成員進行的定期主動運行狀況檢查，以及被動運行狀況檢查。

Pilot將平臺特定的服務發現機制抽象化并將其合成為標準格式，符合數據平面API的任何Sidecar都可以使用這種標準格式。這種松散耦合使得Istio能夠在多種環境下運行（例如Kubernetes、Consul、Nomad），同時可保持用于流量管理的操作界面相同。

Mixer

Istio的Mixer組件提供策略控制和遙測收集功能，將Istio的其余部分與各個后端基礎設施后端的實現細節隔離開來。Mixer是一個獨立于平臺的組件，負責在服務網格上執行訪問控制和使用策略，并從Envoy代理和其他服務收集遙測數據。代理提取請求級屬性，發送到Mixer進行評估。

Mixer中包括一個靈活的插件模型，使其能夠接入到各種主機環境和后端基礎設施，從這些細節中抽象出Envoy代理和Istio管理的服務。利用Mixer，你可以精細控制網格和后端基礎設施后端之間的所有交互。

與必須節省內存的Sidecar代理不同，Mixer獨立運行，因此它可以使用相當大的緩存和輸出緩沖區，充當Sidecar的高度可伸縮且高度可用的二級緩存。

Mixer旨在為每個實例提供高可用性。它的本地緩存和緩沖區可以減少延遲時間，還有助于屏蔽后端基礎設施后端故障，即使后端沒有響應也是如此。

Citadel

Istio Citadel安全功能提供強大的身份驗證功能、強大的策略、透明的TLS加密以及用于保護服務和數據的身份驗證、授權和審計（AAA）工具，Envoy可以終止或向網格中的服務發起TLS流量。為此，Citadel需要支持創建、簽署和輪換證書。Istio Citadel提供特定于應用程序的證書，可用于建立雙向TLS以保護服務之間的流量。

Istio Citadel架構

借助Istio Citadel，確保只能從經過嚴格身份驗證和授權的客戶端訪問包含敏感數據的服務。Citadel通過內置身份和憑證管理提供了強大的服務間和最終用戶身份驗證。可用于升級服務網格中未加密的流量，并為運維人員提供基于服務標識而不是網絡控制的強制執行策略的能力。Istio的配置策略在服務器端配置平臺身份驗證，但不在客戶端強制實施該策略，同時允許你指定服務的身份驗證要求。Istio的密鑰管理系統可自動生成、分發、輪換與撤銷密鑰和證書。

Istio RBAC為Istio網格中的服務提供命名空間級別、服務級別和方法級別的訪問權限控制，包括易于使用的基于角色的語義、服務到服務和最終用戶到服務的授權，并在角色和角色綁定方面提供靈活的自定義屬性支持。

Istio可以增強微服務及其通信（包括服務到服務和最終用戶到服務的通信）的安全性，且不需要更改服務代碼。它為每個服務提供基于角色的強大身份機制，以實現跨集群、跨云端的交互操作。

Galley

Galley用于驗證用戶編寫的Istio API配置。隨著時間的推移，Galley將接管Istio獲取配置、處理和分配組件的頂級責任。它負責將其他的Istio組件與從底層平臺（例如Kubernetes）獲取用戶配置的細節中隔離開來。

總而言之，通過Pilot，Istio可在部署規模逐步擴大的過程中幫助你簡化流量管理。通過Mixer，借助強健且易于使用的監控功能，能夠快速有效地檢測和修復問題。通過Citadel，減輕安全負擔，讓開發者可以專注于其他關鍵任務。

Istio的架構設計中有幾個關鍵目標，這些目標對于系統應對大規模流量和高性能的服務處理至關重要。

• 最大化透明度：要采用Istio，應該讓運維和開發人員只需付出很少的代價就可以從中獲得實際價值。為此，Istio將自身自動注入到服務間所有的網絡路徑中。Istio使用Envoy代理來捕獲流量，并且在可能的情況下自動對網絡層進行編程，以便通過這些代理路由流量，而無需對已部署的應用程序代碼進行太多的更改，甚至不需要任何更改。在Kubernetes中，Envoy代理被注入到pod中，通過iptables規則來捕獲流量。一旦注入Envoy代理到pod中并且修改路由規則，Istio就能夠調節所有流量。這個原則也適用于性能。當將Istio用于部署時，運維人員可以發現，為提供這些功能而增加的資源開銷是很小的。所有組件和API在設計時都必須考慮性能和規模。

• 可擴展性：隨著運維人員和開發人員越來越依賴Istio提供的功能，系統必然和他們的需求一起成長。在我們繼續添加新功能的同時，最需要的是能夠擴展策略系統，集成其他策略和控制來源，并將網格行為信號傳播到其他系統進行分析。策略運行時支持標準擴展機制以便插入到其他服務中。此外，它允許擴展詞匯表，以允許基于網格生成的新信號來強制執行策略。

• 可移植性：使用Istio的生態系統在很多方面都有所不同。Istio必須能夠以最少的代價運行在任何云或本地環境中。將基于Istio的服務移植到新環境應該是輕而易舉的，而使用Istio將一個服務同時部署到多個環境中也是可行的，例如可以在混合云上部署以實現冗余災備。

• 策略一致性：策略應用于服務之間的API調用，可以很好地控制網格行為。但對于無需在API級別表達的資源來說，對資源應用策略也同樣重要。例如，將配額應用到機器學習訓練任務消耗的CPU數量上，比將配額應用到啟動這個工作的調用上更為有用。因此，Istio將策略系統維護為具有自己的API的獨特服務，而不是將其放到代理中，這允許服務根據需要直接與其集成。

剖析Istio數據平面

當介紹服務網格的概念時，提到了服務代理的概念以及如何使用代理構建一個服務網格，以調節和控制微服務之間的所有網絡通信。Istio使用Envoy代理作為默認的開箱即用服務代理，這些Envoy代理與參與服務網格的所有應用程序實例一起運行，但不在同一個容器進程中，形成了服務網格的數據平面。只要應用程序想要與其他服務通信，就會通過服務代理Envoy進行。由此可見，Envoy代理是數據平面和整個服務網格架構中的關鍵組成部分。

Envoy代理

Envoy最初是由Lyft開發的，用于解決構建分布式系統時出現的一些復雜的網絡問題。它于2016年9月作為開源項目提供，一年后加入了云原生計算基金會（CNCF）。Envoy是用C++語言實現的，具有很高的性能，更重要的是，它在高負載運行時也非常穩定和可靠。網絡對應用程序來說應該是透明的，當網絡和應用程序出現問題時，應該很容易確定問題的根源。正是基于這樣的一種設計理念，將Envoy設計為一個面向服務架構的七層代理和通信總線。

為了更好地理解Envoy，我們需要先搞清楚相關的幾個基本術語：

• 進程外（Out of Process）架構：Envoy是一個獨立進程，Envoy之間形成一個透明的通信網格，每個應用程序發送消息到本地主機或從本地主機接收消息，但無需關心網絡拓撲。

• 單進程多線程模型：Envoy使用了單進程多線程的架構模型。一個主線程管理各種瑣碎的任務，而一些工作子線程則負責執行監聽、過濾和轉發功能。

• 下游（Downstream）：連接到Envoy并發送請求、接收響應的主機叫下游主機，也就是說下游主機代表的是發送請求的主機。

• 上游（Upstream）：與下游相對，接收請求的主機叫上游主機。

• 監聽器（Listener）：監聽器是命名網絡地址，包括端口、unix domain socket等，可以被下游主機連接。Envoy暴露一個或者多個監聽器給下游主機連接。每個監聽器都獨立配置一些網絡級別（即三層或四層）的過濾器。當監聽器接收到新連接時，配置好的本地過濾器將被實例化，并開始處理后續事件。一般來說監聽器架構用于執行絕大多數不同的代理任務，例如限速、TLS客戶端認證、HTTP連接管理、MongoDB sniff?ing、原始TCP代理等。

• 集群（Cluster）：集群是指Envoy連接的一組邏輯相同的上游主機。

• xDS協議：在Envoy中xDS協議代表的是多個發現服務協議，包括集群發現服務（CDS，Cluster Discovery Service）、監聽器發現服務（LDS，Listener Discovery Service）、路由發現服務（RDS，Route Discovery Service）、端點發現服務（EDS，Endpoint Discovery Service），以及密鑰發現服務（SDS，Secret Discovery Service）。

Envoy代理

Envoy代理有許多功能可用于服務間通信，例如，暴露一個或者多個監聽器給下游主機連接，通過端口暴露給外部的應用程序；通過定義路由規則處理監聽器中傳輸的流量，并將該流量定向到目標集群，等等。后續章節會進一步分析這幾個發現服務在Istio中的角色和作用。

在了解了Envoy的術語之后，你可能想盡快知道Envoy到底起到了什么作用？

首先，Envoy是一種代理，在網絡體系架構中扮演著中介的角色，可以為網絡中的流量管理添加額外的功能，包括提供安全性、隱私保護或策略等。在服務間調用的場景中，代理可以為客戶端隱藏服務后端的拓撲細節，簡化交互的復雜性，并保護后端服務不會過載。例如，后端服務實際上是運行的一組相同實例，每個實例能夠處理一定量的負載。

其次，Envoy中的集群（Cluster）本質上是指Envoy連接到的邏輯上相同的一組上游主機。那么客戶端如何知道在與后端服務交互時要使用哪個實例或IP地址？Envoy作為代理起到了路由選擇的作用，通過服務發現（SDS，Service Discovery Service），Envoy代理發現集群中的所有成員，然后通過主動健康檢查來確定集群成員的健康狀態，并根據健康狀態，通過負載均衡策略決定將請求路由到哪個集群成員。而在Envoy代理處理跨服務實例的負載均衡過程中，客戶端不需要知道實際部署的任何細節。

Envoy的啟動配置

Envoy目前提供了兩個版本的API，即v1和v2，從Envoy 1.5.0起就有v2 API了，為了能夠讓用戶順利地向v2版本API遷移，Envoy啟動的時候設置了一個參數--v2-conf?ig-only。通過這個參數，可以明確指定Envoy使用v2 API的協議。幸運的是，v2 API是v1的一個超集，兼容v1的API。在當前的Istio 1.0之后的版本中，明確指定了其支持v2的API。通過查看使用Envoy作為Sidecar代理的容器啟動命令，可以看到如下類似的啟動參數，其中指定了參數--v2-conf?ig-only：

$ /usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster ratings --service-node sidecar~172.33.14.2~ratings-v1-8558d4458d-ld8x9.default~default.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only

其中，參數-c表示的是基于版本v2的引導配置文件的路徑，格式為JSON，也支持其他格式，如YAML、Proto3等。它會首先作為版本v2的引導配置文件進行解析，若解析失敗，會根據[--v2-conf?ig-only]選項決定是否作為版本v1的JSON配置文件進行解析。其他參數解釋如下，以便讀者及時理解Envoy代理啟動時的配置信息：

• restart-epoch表示熱重啟周期，對于第一次啟動默認為0，每次熱重啟后都應該增加它。

• service-cluster定義Envoy運行的本地服務集群名稱。

• service-node定義Envoy運行的本地服務節點名稱。

• drain-time-s表示熱重啟期間Envoy將耗盡連接的時間（秒），默認為600秒（10分鐘）。通常耗盡時間應小于通過--parent-shutdown-time-s選項設置的父進程關閉時間。

• parent-shutdown-time-s表示Envoy在熱重啟時關閉父進程之前等待的時間（秒）。

• max-obj-name-len描述的是集群cluster、路由配置route_conf?ig以及監聽器listener中名稱字段的最大長度，以字節為單位。此選項通常用于自動生成集群名稱的場景，通常會超過60個字符的內部限制。默認為60。

Envoy的啟動配置文件分為兩種方式：靜態配置和動態配置。具體表現為：

• 靜態配置是將所有信息都放在配置文件中，啟動的時候直接加載。

• 動態配置需要提供一個Envoy的服務端，用于動態生成Envoy需要的服務發現接口，也就是通常說的xDS，通過發現服務來動態調整配置信息，Istio實現了v2的xDS API。

Envoy靜態與動態配置

Envoy是由JSON或YAML格式的配置文件驅動的智能代理，對于已經熟悉Envoy或Envoy配置的用戶來說，相信應該已經知道了Envoy的配置也有不同的版本。初始版本v1是Envoy啟動時配置Envoy的原始方式。此版本已被棄用，以支持Envoy配置的v2版本。Envoy的參考文檔（https://www.envoyproxy.io/docs）還提供了明確區分v1和v2的文檔。本書中將只關注v2配置，因為它是最新的版本，也是Istio使用的版本。

Envoy版本v2的配置API建立在gRPC之上，v2 API的一個重要特性是可以在調用API時利用流功能來減少Envoy代理匯聚配置所需的時間。實際上，這也消除了輪詢API的弊端，允許服務器將更新推送到Envoy代理，而不是定期輪詢代理。

Envoy的架構使得使用不同類型的配置管理方法成為可能。部署中采用的方法將取決于實現者的需求。簡單部署可以通過全靜態配置來實現，更復雜的部署可以遞增地添加更復雜的動態配置。主要分為以下幾種情況：

• 全靜態：在全靜態配置中，實現者提供一組監聽器和過濾器鏈、集群和可選的HTTP路由配置。動態主機發現僅能通過基于DNS的服務發現。配置重載必須通過內置的熱重啟機制進行。

• 僅SDS/EDS：在靜態配置之上，Envoy可以通過該機制發現上游集群中的成員。

• SDS/EDS和CDS：Envoy可以通過該機制發現使用的上游集群。

• SDS/EDS、CDS和RDS：RDS可以在運行時發現用于HTTP連接管理器過濾器的整個路由配置。

• SDS/EDS、CDS、RDS和LDS：LDS可以在運行時發現整個監聽器。這包括所有的過濾器堆棧，包括帶有內嵌到RDS的應用的HTTP過濾器。

靜態配置

我們可以使用Envoy的配置文件指定監聽器、路由規則和集群。如下示例提供了一個非常簡單的Envoy配置：

static_resources:listeners:- name: httpbin-demoaddress:socket_address: { address: 0.0.0.0, port_value: 15001 }filter_chains:- filters:- name: envoy.http_connection_managerconfig:stat_prefix: egress_httproute_config:name: httpbin_local_routevirtual_hosts:- name: httpbin_local_servicedomains: ["*"]routes:- match: { prefix: "/" }route:auto_host_rewrite: truecluster: httpbin_servicehttp_filters:- name: envoy.routerclusters:- name: httpbin_serviceconnect_timeout: 5stype: LOGICAL_DNS# Comment out the following line to test on v6 networksdns_lookup_family: V4_ONLYlb_policy: ROUND_ROBINhosts: [{ socket_address: { address: httpbin, port_value: 8000 }}]

在這個簡單的Envoy配置文件中，我們聲明了一個監聽器，它在端口15001上打開一個套接字并為其附加一個過濾器鏈。過濾器http_connection_manager在Envoy配置中使用路由指令（在此示例中看到的簡單路由指令是匹配所有虛擬主機的通配符），并將所有流量路由到httpbin_service集群。配置的最后一部分定義了httpbin_service集群的連接屬性。在此示例中，我們指定端點服務發現的類型為LOGICAL_DNS、與上游httpbin服務通信時的負載均衡算法為ROUND_ROBIN。

這是一個簡單的配置文件，用于創建監聽器傳入的流量，并將所有流量路由到httpbin集群。它還指定要使用的負載均衡算法的設置以及要使用的連接超時配置。

你會注意到很多配置是明確指定的，例如指定了哪些監聽器，路由規則是什么，我們可以路由到哪些集群等。這是完全靜態配置文件的示例。

有關這些參數更多信息的解釋，請參閱Envoy的文檔（http://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#logical-dns）。

在前面的部分中，我們指出Envoy能夠動態配置其各種設置。下面將介紹Envoy的動態配置以及Envoy如何使用xDS API進行動態配置。

動態配置

Envoy可以利用一組API進行配置更新，而無需任何停機或重啟。Envoy只需要一個簡單的引導配置文件，該配置文件將配置指向正確的發現服務API，其余動態配置。Envoy進行動態配置的API通常統稱為xDS服務，具體包括如下：

• 監聽器發現服務（LDS）：一種允許Envoy查詢整個監聽器的機制，通過調用該API可以動態添加、修改或刪除已知監聽器；每個監聽器都必須具有唯一的名稱。如果未提供名稱，Envoy將創建一個UUID。

• 路由發現服務（RDS）：Envoy動態獲取路由配置的機制，路由配置包括HTTP標頭修改、虛擬主機以及每個虛擬主機中包含的單個路由規則。每個HTTP連接管理器都可以通過API獨立地獲取自身的路由配置。RDS配置隸屬于監聽器發現服務LDS的一部分，是LDS的一個子集，用于指定何時應使用靜態和動態配置，以及指定使用哪個路由。

• 集群發現服務（CDS）：一個可選的API，Envoy將調用該API來動態獲取集群管理成員。Envoy還將根據API響應協調集群管理，根據需要添加、修改或刪除已知的集群。在Envoy配置中靜態定義的任何集群都不能通過CDS API進行修改或刪除。

• 端點發現服務（EDS）：一種允許Envoy獲取集群成員的機制，基于gRPC或RESTJSON的API，它是CDS的一個子集；集群成員在Envoy術語中稱為端點（Endpoint）。對于每個集群，Envoy從發現服務獲取端點。EDS是首選的服務發現機制。

• 密鑰發現服務（SDS）：用于分發證書的API；SDS最重要的好處是簡化證書管理。如果沒有此功能，在Kubernetes部署中，必須將證書創建為密鑰并掛載到Envoy代理容器中。如果證書過期，則需要更新密鑰并且需要重新部署代理容器。使用密鑰發現服務SDS，那么SDS服務器會將證書推送到所有Envoy實例。如果證書過期，服務器只需將新證書推送到Envoy實例，Envoy將立即使用新證書而無需重新部署。

• 聚合發現服務（ADS）：上述其他API的所有更改的序列化流；你可以使用此單個API按順序獲取所有更改；ADS并不是一個實際意義上的xDS，它提供了一個匯聚的功能，在需要多個同步xDS訪問的時候，ADS可以在一個流中完成。

配置可以使用上述服務中的一個或其中幾個的組合，不必全部使用它們。需要注意的一點是，Envoy的xDS API是建立在最終一致性的前提下，正確的配置最終會收斂。例如，Envoy最終可能會使用新路由獲取RDS的更新，該路由將流量路由到尚未在CDS中更新的集群。這意味著，路由可能會引入路由錯誤，直到更新CDS。Envoy引入了聚合發現服務ADS來解決這種問題，而Istio實現了聚合發現服務ADS，并使用ADS進行代理配置的更改。

例如，Envoy代理要動態發現監聽器，可以使用如下配置：

dynamic_resources:lds_config:api_config_source:api_type: GRPCgrpc_services:- envoy_grpc:cluster_name: xds_cluster clusters: - name: xds_clusterconnect_timeout: 0.25stype: STATIClb_policy: ROUND_ROBINhttp2_protocol_options: {}hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

通過上面的配置，我們不需要在配置文件中顯式配置每個監聽器。我們告訴Envoy使用LDS API在運行時發現正確的監聽器配置值。但是，我們需要明確配置一個集群，這個集群就是LDS API所在的位置，也就是該示例中定義的集群xds_cluster。

在靜態配置的基礎上，比較直觀地表示出各個發現服務所提供的信息。

xDS服務信息

在靜態配置的基礎上，比較直觀地表示出各個發現服務所提供的信息。

福利時間

本文摘自于《Istio服務網格技術解析與實踐》，該書由阿里云高級技術專家王夕寧撰寫，詳細介紹Istio的基本原理與開發實戰，包含大量精選案例和參考代碼可以下載，可快速入門Istio開發，適合所有對微服務和云原生感興趣的讀者，推薦大家對本書進行深入的閱讀。本次聯合機械工業出版社華章公司為大家帶來10本書作為福利。在文末留言中寫下對Istio的認識，截止4月21日12點前，評論點贊數前10名的讀者將獲以下任意圖書1本。沒中獎的讀者也可以點擊下面鏈接購買，目前京東有活動，滿100減50。

基于Kubernetes的DevOps實戰培訓

基于Kubernetes的DevOps實戰培訓將于2020年5月15日在上海開課，3天時間帶你系統掌握Kubernetes，學習效果不好可以繼續學習。本次培訓包括：容器特性、鏡像、網絡；Kubernetes架構、核心組件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用對象、設計原則；Kubernetes的數據庫、運行時、網絡、插件已經落地經驗；微服務架構、組件、監控方案等，點擊下方圖片或者閱讀原文鏈接查看詳情。

總結

以上是生活随笔為你收集整理的Istio架构剖析 | 文末有福利的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。