近日，小编在技术论坛和交流群中，看到一些关于Service Mesh的提问，但很多人都没找到解决办法，连技术大神都表示难解！

当istio-porxy故障时，有什么办法可以直连？

如果Sidecar进程出故障时，服务怎么办？

是否有退路？能否fallback到直连模式？

无疑这些是困扰开发者的难题，Istio的设计是通过让Sidecar接管流量从而实现的服务治理能力，业务流量会先被Sidecar先行劫持，再抵达业务。因此在Istio落地过程中，是否能无损fallback，通常决定了核心业务能否接入Service Mesh。

为解决上述问题，行云创新SolarMesh在v1.7.1版本中加入一个重大功能，即在solarctl上为集群提供直连模式，降低Sidecar自身故障导致的损失，为核心业务接入Service Mesh提供了重要保障。

SolarMesh直连模式的使用方法

$ solarctl iptables -h

clean iptables istio-proxy.

Usage:
  solarctl iptables [flags]

Flags:
      --all                list the requested object(s) across all pod.
      --clean              if clean true clean iptables
  -c, --context string     The name of the kubeconfig context to use
  -h, --help               help for iptables
  -n, --namespace string   Namespace in current context is ignored even if specified with --namespace. (default "default")
  -p, --pod string         pod name

当开发者已经部署过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在出现故障的极端情况下也能保障业务的连续性，提高企业的研发效率。