近日，小編在技術論壇和交流群中，看到一些關於Service Mesh的提問，但很多人都沒找到解決辦法，連技術大神都表示難解！

• 當istio-porxy故障時，有什麼辦法可以直連？
• 如果Sidecar程序出故障時，服務怎麼辦？
• 是否有退路？能否fallback到直連模式？

無疑這些是困擾開發者的難題，Istio的設計是通過讓Sidecar接管流量從而實現的服務治理能力，業務流量會先被Sidecar先行劫持，再抵達業務。因此在Istio落地過程中，是否能無損fallback，通常決定了核心業務能否接入Service Mesh。

為解決上述問題，行雲創新SolarMesh在v1.7.1版本中加入一個重大功能，即在solarctl上為叢集提供直連模式，降低Sidecar自身故障導致的損失，為核心業務接入Service Mesh提供了重要保障。

SolarMesh直連模式的使用方法

當開發者已經部署過bookinfo示例專案，並且為bookinfo示例專案的服務接入了sidecar：

• 訪問事先部署好的示例專案bookinfo頁面，多重新整理幾次，會發現在沒有任何策略干預的情況下，頁面中Book Reviews一欄呈現三種狀態: 紅星、黑星和無星，它們的出現概率約為1:1:1。

• 進入SolarMesh的流量檢視介面，檢視流量拓撲圖。

• 此時reviews 服務有3個版本對應著3種狀態，先在DestinationRule上配置 reviews的版本。

• 在VirtualService建立一份http策略，配置故障注入，將故障碼500注入到reviews服務上。

• 再次訪問示例專案bookinfo的頁面，故障已經產生，reviews服務開始報錯。

• 再次進入SolarMesh的流量檢視介面時，由於請求已經被系統強制返回500錯誤，所以不會抵達真正的服務，看到的是productpage訪問reviews.demo.svc.cluster.local這個host，並且流量線是紅色的。

• 確定是sidecar攔截流量，可使用直連模式來保障業務的連續，用solarctl的命令讓demo這個namespace下所有的pod都切換成直連模式。

• 切換成功後，pod沒有重啟，並且業務恢復了正常，流量檢視上也監測不到任何流量，流量已經繞過sidecar直接抵達業務服務。

• 取消直連模式。

• 重新整理示例專案bookinfo的頁面，故障又會產生，sidecar重新開始起作用。

• 流量檢視可重新識別出它們的流量。

SolarMeshv1.7.1版本的直連模式讓Sidecar在出現故障的極端情況下也能保障業務的連續性，提高企業的研發效率。