Istio实战进阶：这些技巧你可能不知道

最近一年多我们团队一直在生产环境使用Istio作为服务网格管理我们的微服务从最开始的1.0版本到现在的1.1版本踩了不少坑也积累了很多实战经验和技巧。

很多技巧在官方文档里没有详细说，或者藏在某个角落不容易被发现，但是在实际使用中非常有用能帮我们解决很多问题提升效率和稳定性今天想把这些实战进阶技巧整理出来分享给大家希望能帮正在使用，或者准备使用Istio的朋友少走弯路更好地用好Istio这个强大的服务网格工具。

一、Sidecar注入和管理的技巧

Istio的核心机制之一就是Sidecar注入通过给每个服务Pod注入一个EnvoySidecar代理来实现服务间的流量管理安全和可观测性Sidecar注入看起来简单，但是实际使用中有很多技巧和坑这里分享几个实用的技巧。

技巧1：精细化控制Sidecar注入范围不要全局注入：

很多人刚用Istio的时候，喜欢给整个命名空间，或者整个集群开启自动注入觉得这样方便所有服务都自动注入Sidecar不用一个个配置，但是实际上，全局注入会带来很多问题，比如有些服务不适合注入Sidecar（比如基础设施服务JobCronJob等）注入后可能会出问题，或者影响性能，而且全局注入会导致Sidecar数量过多增加资源消耗和管理复杂度也会增加Istio控制面的压力。

更好的做法是精细化控制Sidecar注入的范围只给真正需要服务网格能力的服务注入Sidecar具体来说，可以通过命名空间标签和Pod注解结合的方式来控制，比如默认不开启命名空间自动注入只在需要的命名空间开启，然后在命名空间内通过Pod的sidecar.istio.io/inject: "false"注解来排除不需要注入的服务，或者反过来默认命名空间不注入只给需要的Pod加sidecar.istio.io/inject: "true"注解来开启注入这样能精确控制哪些服务注入Sidecar哪些不注入避免不必要的注入减少资源消耗和潜在问题。

我们团队的做法是按业务域划分命名空间只给业务服务所在的命名空间开启自动注入基础设施服务（比如数据库缓存消息队列等）所在的命名空间不开启注入，然后在业务命名空间内对于一些特殊的服务（比如定时任务一次性Job等）通过Pod注解排除注入这样既保证了业务服务都有Sidecar能享受服务网格的能力又避免了给不需要的服务注入带来的问题效果很好。

技巧2：合理配置Sidecar的资源限制和请求：

Sidecar（Envoy）是要消耗资源的CPU和内存都要占一定的量，如果不配置资源限制和请求可能会导致Sidecar占用过多资源影响业务容器，或者在资源紧张的时候Sidecar被OOMKill或者CPU限流导致服务不可用，所以一定要合理配置Sidecar的资源限制和请求。

Istio默认的Sidecar资源配置可能不适合所有场景需要根据自己的业务情况调整一般来说，可以通过全局配置（istio-config里的defaultResources）来设置默认的Sidecar资源配置，然后对于一些特殊的服务（比如流量特别大的服务，或者资源紧张的服务）通过Pod注解（sidecar.istio.io/proxyCPUsidecar.istio.io/proxyMemorysidecar.istio.io/proxyCPULimitsidecar.istio.io/proxyMemoryLimit等）来单独调整该服务Sidecar的资源配置做到差异化配置既保证Sidecar有足够的资源运行稳定又不浪费过多资源。

我们团队的经验是一般的服务Sidecar配置requests: cpu 100m, memory 128Milimits: cpu 500m, memory 256Mi就够了对于流量特别大的核心服务可以适当调大，比如limits: cpu 1000m, memory 512Mi对于资源紧张的测试环境可以适当调小，但是不要太小，不然Sidecar会被OOMKill或者CPU限流导致问题，另外一定要配置requests不只配置limits不然调度的时候，可能会把Pod调度到资源不够的节点上导致问题也要注意Sidecar的资源是算在Pod总资源里的配置的时候，要把业务容器和Sidecar的资源加起来考虑不要超过节点的资源上限。

技巧3：使用Sidecar资源配置减少控制面压力：

Istio的控制面（Pilot）需要把集群里所有服务的信息（服务发现配置等）都同步给每个Sidecar这样每个Sidecar都知道所有服务的信息能路由到任何服务，但是当集群里服务数量多了之后，这会导致两个问题一是控制面Pilot的压力很大要给成百上千个Sidecar同步大量的配置CPU和内存消耗都很高二是每个Sidecar都要存储所有服务的配置内存消耗也会很高，而且配置同步的时间也会变长影响配置生效的速度。

为了解决这个问题Istio提供了Sidecar资源（注意这个Sidecar是Istio的一种CRD资源不是指Sidecar代理本身）可以用来配置每个命名空间，或者每个工作负载的Sidecar需要知道哪些服务的信息不需要知道所有服务的信息这样就能大大减少控制面和Sidecar的压力提升性能和稳定性。

比如我们可以给某个命名空间配置一个Sidecar资源指定该命名空间的服务只需要知道同命名空间的服务和几个指定的其他命名空间的服务（比如基础设施服务所在的命名空间）不需要知道所有，命名空间的服务这样该命名空间的Sidecar就只会同步这些服务的配置不会同步所有服务的配置大大减少配置量降低控制面和Sidecar的压力。

示例配置大概是这样：

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: my-namespace
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"
    - "infrastructure/*"

这个配置表示my-namespace命名空间的Sidecar只需要知道自己命名空间（./*）istio-system命名空间和，infrastructure命名空间的服务不需要知道其他命名空间的服务这样就能大大减少配置量。

我们团队在服务数量多了之后，就遇到了Pilot内存占用过高配置同步慢的问题后来通过给每个业务命名空间配置Sidecar资源限制每个命名空间只同步需要的服务配置Pilot的内存占用直接降了一半多配置同步速度也快了很多效果非常明显，所以，如果你的集群服务数量比较多一定要用Sidecar资源来优化控制面和Sidecar的压力这是一个非常有效，但是很多人不知道的技巧。

二、流量管理的技巧

流量管理是Istio最核心的功能之一通过VirtualService和DestinationRule等资源可以实现非常灵活的流量管理，比如灰度发布蓝绿部署流量镜像故障注入负载均衡等，但是实际使用中有很多技巧和坑这里分享几个。

技巧4：灰度发布用权重路由配合标签选择器精细化控制：

灰度发布是Istio最常用的功能之一通过VirtualService的权重路由可以把流量按比例分配到不同版本的服务实现灰度发布，比如把10%的流量导到新版本90%的流量还在旧版本观察没问题再逐步调大新版本的流量比例直到全量这个功能很强大也很常用，但是很多人用的时候，只是简单配置权重没有结合标签选择器做精细化控制导致灰度的粒度不够，或者出问题。

更好的做法是结合DestinationRule的子集（subset）和VirtualService的权重路由以及标签选择器来做精细化的灰度控制具体来说，先在DestinationRule里根据Pod的标签（比如version: v1version: v2）定义不同的子集，然后在VirtualService里给不同的子集分配不同的流量权重这样就能精确控制哪些实例属于哪个版本流量怎么分配，而且还可以结合请求的属性（比如请求头Cookie源IP等）做更精细化的路由，比如只让内部员工，或者特定用户的请求走新版本其他用户还走旧版本这样灰度的风险更小更可控。

比如我们团队做灰度发布的时候，一般分几个阶段第一阶段只让内部测试人员的请求（通过特定的请求头，或者Cookie标识）走新版本内部验证没问题第二阶段给新版本分10%的流量观察错误率和性能指标没问题第三阶段调到30%再观察没问题第四阶段调到50%最后全量每个阶段都观察一段时间确认没问题再进下一阶段出问题随时把流量切回旧版本这样灰度发布的风险非常小几乎不会影响用户，而且通过Istio的流量管理配置非常方便不用改代码不用重新部署随时调整流量比例非常灵活。

技巧5：用流量镜像做新版本验证不影响用户：

除了灰度发布Istio还提供了流量镜像（Traffic Mirroring也叫影子流量Shadow Traffic）的功能可以把实时流量复制一份发送给新版本的服务，但是新版本的响应会被丢弃不会返回给用户用户的请求还是由旧版本处理和响应这样我们就可以用真实的用户流量来验证新版本的服务是否正常有没有错误性能怎么样，但是完全不影响用户，因为用户的请求还是旧版本处理的新版本只是收到一份镜像流量做验证响应被丢弃不影响用户。

这个功能非常有用特别是对于一些重大的版本更新，或者架构重构我们可以先把新版本部署上去，然后配置流量镜像把真实流量复制一份给新版本跑一段时间观察新版本的错误率性能日志等指标确认新版本能正常处理真实流量没有问题，然后再做灰度发布把真实流量逐步切到新版本这样就非常安全，因为在灰度之前，已经用真实流量验证过新版本了出问题的概率大大降低。

流量镜像的配置也很简单在VirtualService里配置mirror字段指定要镜像到哪个子集（新版本）以及镜像流量的比例（mirror_percent或者1.1版本后的mirrorPercentage）就行了示例配置大概是这样：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
        subset: v1
      weight: 100
    mirror:
      host: my-service
      subset: v2
    mirrorPercentage:
      value: 100.0

这个配置表示把100%的流量都镜像一份给v2版本，但是用户的请求还是由v1版本处理和响应v2版本只是收到镜像流量做验证响应被丢弃。

我们团队在几次重大的服务重构和版本更新中都用了流量镜像功能先用真实流量验证新版本跑几天观察指标没问题再灰度发布效果非常好几次重大更新都没有出问题非常平滑，所以，如果你有重大的版本更新，或者架构重构一定要试试流量镜像功能用真实流量验证新版本不影响用户非常安全和方便。

技巧6：用故障注入做混沌工程验证系统韧性：

Istio还提供了故障注入（Fault Injection）的功能可以在路由配置里主动注入延迟，或者错误来模拟服务异常的情况验证系统的容错能力和韧性这其实就是混沌工程的一种实现方式通过主动注入故障来验证系统在故障情况下是否能正常运行有没有单点故障降级机制是否有效等等。

故障注入支持两种类型延迟注入（Delay）和错误注入（Abort）延迟注入是给请求加一个人为的延迟模拟网络延迟，或者服务响应慢的情况错误注入是直接返回指定的错误码（比如500503等）模拟服务出错的情况我们可以给特定的服务，或者特定的请求注入故障也可以指定注入的比例只给一定比例的请求注入故障避免影响太大。

比如我们可以给某个核心服务的下游依赖注入5秒的延迟看看核心服务有没有配置超时和降级会不会，因为下游慢而被拖垮也可以注入50%的503错误看看核心服务有没有重试和熔断机制能不能在下游出错的时候，正常降级不影响用户通过这些故障注入实验我们能发现系统中的容错弱点提前修复提升系统的韧性和可靠性。

故障注入的配置也很简单在VirtualService的http路由里配置fault字段指定延迟，或者错误以及比例就行了示例配置大概是这样：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - fault:
      delay:
        percentage:
          value: 50.0
        fixedDelay: 5s
    route:
    - destination:
        host: my-service
        subset: v1

这个配置表示给50%的请求注入5秒的延迟模拟服务响应慢的情况。

我们团队定期会做混沌工程演练用Istio的故障注入功能给各种服务注入延迟和错误验证系统的容错能力发现了不少问题，比如有些服务没配置超时导致下游慢的时候，线程池被占满服务不可用有些服务没配置熔断导致下游出错的时候，重试风暴把下游彻底打挂等等发现问题后我们都及时修复了现在系统的容错能力和韧性提升了很多，所以建议大家也定期用Istio的故障注入功能做混沌工程演练验证和提升系统的韧性这是一个非常有价值，但是很多人没充分利用的功能。

三、安全和可观测性的技巧

技巧7：用mTLS做服务间通信加密注意迁移策略：

双向TLS（mTLS）是Istio安全功能的核心通过Sidecar自动给服务间的通信加密，并且做身份认证保证服务间通信的安全性防止中间人攻击和未授权访问Istio的mTLS是透明的不需要改业务代码Sidecar自动处理TLS握手和加密解密非常方便。

但是开启mTLS的时候，要注意迁移策略不要一下子全局开启严格mTLS不然可能会导致一些没有注入Sidecar的服务（或者外部服务）无法和开启了mTLS的服务通信，因为它们没有证书也不会做mTLS握手会导致连接失败，所以要循序渐进地迁移到mTLS。

Istio提供了三种mTLS模式PERMISSIVE（宽容模式）STRICT（严格模式）DISABLED（禁用）PERMISSIVE模式下服务，同时接受明文和mTLS的请求这样，即使有些客户端没有Sidecar用明文请求也能正常访问不会断STRICT模式下服务只接受mTLS的请求明文请求会被拒绝安全性更高，但是要求所有客户端都有Sidecar能做mTLS。

迁移的最佳实践是先全局开启PERMISSIVE模式让所有服务都，同时支持明文和mTLS然后观察服务间的通信情况用Istio的可观测性工具（比如Grafana仪表盘，或者istioctl authn tls-check命令）检查哪些服务间的通信已经是mTLS了哪些还是明文等所有服务间的通信都已经是mTLS了（也就是所有客户端都有Sidecar能做mTLS）再逐步把服务的mTLS模式切换到STRICT先从非核心服务开始确认没问题再切核心服务最后全量STRICT这样迁移过程非常平滑不会导致通信中断也能最终达到全量mTLS的安全目标。

我们团队迁移mTLS的时候，就是按这个策略来的先全局PERMISSIVE观察了一周确认所有服务间通信都已经是mTLS了，然后逐个命名空间切换到STRICT每个命名空间切换后观察一段时间没问题再切下一个最后全量STRICT整个过程非常平滑没有出现任何通信中断的问题，所以开启mTLS一定要注意迁移策略不要一下子全局STRICT不然很容易出问题。

技巧8：用Kiali做服务拓扑可视化快速定位问题：

Istio的可观测性功能非常强大集成了PrometheusGrafanaJaegerKiali等工具能提供指标监控分布式追踪服务拓扑等可观测性能力这里特别推荐Kiali这个工具很多人可能没充分利用，但是它非常有用能把服务间的调用关系和流量情况可视化成服务拓扑图非常直观能帮我们快速理解服务间的依赖关系也能快速定位问题。

Kiali的服务拓扑图会显示所有服务的节点以及服务间的调用边边的粗细表示流量大小边的颜色表示错误率（绿色正常黄色警告红色错误率高）还能看到每个服务的请求量错误率延迟等指标鼠标悬停，或者点击节点和边能看到更详细的信息还能跳转到Grafana仪表盘，或者Jaeger追踪详情非常方便。

我们团队平时排查问题的时候，经常先打开Kiali看服务拓扑图看看哪个服务的边是红的（错误率高）或者哪个服务的延迟高流量异常，然后点进去看详细指标和追踪能非常快速地定位问题出在哪个服务哪个调用链上比一个个看Grafana仪表盘，或者查日志效率高很多特别是在服务数量多依赖关系复杂的情况下Kiali的拓扑图能让我们对整个系统的运行状态一目了然快速发现异常和定位问题。

另外Kiali还有很多其他实用功能，比如配置验证（能检查Istio的配置有没有错误，或者冲突）分布式追踪集成（能直接在Kiali里看服务的追踪数据）多版本流量监控（能看到灰度发布的不同版本的流量和指标）等等都非常实用，所以，如果你用Istio一定要好好利用Kiali这个工具它能大大提升你排查问题和管理服务网格的效率。

技巧9：分布式追踪要注意采样率和上下文传播：

Istio通过Sidecar自动集成了分布式追踪能力能自动给服务间的调用生成追踪span不需要改业务代码非常方便，但是实际使用中有两个点要注意采样率和上下文传播，不然追踪效果会打折扣。

第一个是采样率分布式追踪是有性能开销的，而且数据量很大，如果每个请求都采样存储成本会非常高，而且也会对服务性能有一定影响，所以一般会设置采样率只采样一定比例的请求，比如1%或者10%Istio默认的采样率是1%这个对于大部分场景可能够了，但是，如果你的服务请求量不大1%的采样率可能很久都采不到一个请求追踪数据很少不利于排查问题这时候可以适当调大采样率，比如调到10%或者更高，但是也不要太高，不然存储成本和性能开销会比较大要根据自己的请求量和需求合理设置采样率，另外也可以针对不同的服务，或者请求设置不同的采样率核心服务，或者重要请求采样率高一些非核心服务采样率低一些做到差异化配置。

第二个是上下文传播Istio的Sidecar能自动生成和传播追踪上下文（Trace IDSpan ID等）在服务间调用的时候Sidecar会自动把追踪上下文注入到请求头里下游服务的Sidecar会自动提取这些请求头继续传播这样就能把整个调用链的span串起来形成完整的追踪，但是这只适用于服务间的调用对于服务内部的调用（比如服务内部的函数调用线程池异步任务等）Sidecar是无法自动传播追踪上下文的这时候就需要业务代码自己传播追踪上下文，不然追踪就会断掉看不到完整的调用链，另外，如果服务要调用外部服务（没有注入Sidecar的服务）也需要业务代码自己把追踪上下文注入到请求头里，不然追踪也会断，所以在实际使用中要注意这些场景必要的时候，在业务代码里手动传播追踪上下文保证追踪的完整性。

我们团队在使用分布式追踪的过程中就遇到过追踪断掉的问题后来发现是，因为有些异步任务和线程池的场景追踪上下文没有传播过去后来我们在业务代码里加了追踪上下文的传播逻辑（用OpenTracingAPI或者直接操作请求头）问题就解决了追踪完整了排查问题也更方便了，所以使用Istio的分布式追踪一定要注意采样率和上下文传播这两个点才能充分发挥追踪的作用。

四、性能优化和运维的技巧

技巧10：控制面组件高可用和资源优化：

Istio的控制面（istio-system命名空间下的组件，比如PilotGalleyCitadelIngress Gateway等）是整个服务网格的大脑负责配置管理证书签发网关流量等控制面的稳定性非常重要，如果控制面出问题会影响整个服务网格的配置下发和网关流量，所以一定要保证控制面组件的高可用和性能。

首先，控制面的核心组件（PilotIngress Gateway等）一定要部署多个副本做高可用不要只部署一个副本，不然那个副本挂了，或者所在节点出问题控制面就不可用了影响整个服务网格一般Pilot部署2-3个副本Ingress Gateway根据流量情况部署2个以上副本，并且通过反亲和调度到不同的节点上避免单点故障，另外要给控制面组件配置合理的资源请求和限制特别是Pilot它要处理大量的配置同步内存占用可能会比较高要给足够的内存避免被OOMKill也要给足够的CPU避免配置下发慢我们团队之前，就遇到过Pilot内存不够被OOMKill的问题导致配置无法下发新的服务注册了，但是Sidecar收不到配置路由失败后来给Pilot调大了内存，并且配置了Sidecar资源减少配置量问题就解决了。

另外Ingress Gateway作为整个集群的流量入口性能和高可用也非常重要要根据流量情况合理配置副本数和资源，并且最好用Kubernetes的LoadBalancer或者NodePort+外部负载均衡的方式把流量分散到多个Ingress Gateway副本上避免单点瓶颈也要给Ingress Gateway配置合理的超时重试熔断等参数保护后端服务也提升网关的稳定性和性能。

技巧11：Sidecar生命周期和优雅退出配置：

Sidecar是和业务容器一起跑在Pod里的Pod启动的时候Sidecar和业务容器一起启动Pod退出的时候Sidecar和业务容器一起退出，但是这里有一个常见的问题就是Pod退出的时候Sidecar可能会比业务容器先退出导致业务容器，还有正在处理的请求要通过Sidecar转发，但是Sidecar已经退出了请求就失败了特别是在服务滚动更新，或者缩容的时候，这个问题会导致一些请求失败影响用户。

为了解决这个问题需要配置Sidecar的优雅退出让Sidecar在收到退出信号后不要立即退出而是等业务容器把正在处理的请求都处理完了再退出Istio提供了相关的配置和注解可以控制Sidecar的退出行为，比如通过terminationDrainDuration配置Sidecar退出前的排空时间在这段时间里Sidecar会停止接受新的请求，但是会继续处理已经接受的请求等请求处理完，或者时间到了再退出这样就能避免Sidecar先退出导致请求失败的问题。

另外业务容器自己也要配置优雅退出在收到SIGTERM信号后停止接受新的请求处理完已经接受的请求再退出不要立即退出Kubernetes的terminationGracePeriodSeconds参数也要合理设置给业务容器和Sidecar足够的优雅退出时间一般设置30秒，或者更长根据业务情况调整通过业务容器和Sidecar都配置优雅退出配合合理的优雅退出时间就能保证Pod退出的时候，正在处理的请求都能处理完不会导致请求失败实现平滑的滚动更新和缩容。

我们团队之前，就遇到过滚动更新的时候，有少量请求失败的问题后来发现就是Sidecar先退出导致的后来我们配置了Sidecar的优雅退出排空时间，并且调大了terminationGracePeriodSeconds问题就解决了滚动更新的时候，再也没有请求失败了非常平滑，所以使用Istio一定要注意Sidecar的优雅退出配置避免滚动更新和缩容的时候，请求失败。

技巧12：版本升级要注意兼容性循序渐进：

Istio的版本更新比较快经常会有新的版本发布修复bug增加新功能，但是升级Istio版本是一件需要谨慎的事情，因为Istio涉及控制面和数据面（Sidecar）还有各种CRD和配置升级不当可能会导致兼容性问题甚至服务中断，所以升级Istio版本一定要注意兼容性循序渐进不要一下子跨大版本升级也不要在生产环境直接升级要先在测试环境验证没问题再在生产环境灰度升级。

首先，升级前一定要仔细阅读新版本的发布说明（Release Notes）和升级指南（Upgrade Notes）了解新版本有哪些不兼容的变化哪些配置，或者API废弃了需要修改哪些行为变化了需要注意提前做好准备修改不兼容的配置，然后先在测试环境升级验证所有功能都正常性能也没问题再考虑在生产环境升级。

生产环境升级的时候，要循序渐进先升级控制面再逐步升级数据面（Sidecar）不要一下子把所有Sidecar都升级Istio支持控制面和数据面版本不一致（控制面版本比数据面高1-2个小版本是支持的）所以可以先把控制面升级到新版本，然后通过滚动重启Pod的方式逐步升级Sidecar先从非核心服务开始升级观察一段时间没问题再升级核心服务最后全量升级这样，即使新版本有问题也只影响少量服务能及时回滚不会导致大面积故障。

另外升级前一定要做好备份备份Istio的配置（CRDVirtualServiceDestinationRule等）以及控制面的数据万一升级出问题能快速回滚升级过程中也要密切监控服务的运行状态错误率延迟流量等指标发现异常及时回滚，或者处理不要升级完就，不管了要观察一段时间确认稳定了再结束升级。

我们团队升级Istio版本的时候，就是严格按这个流程来的先看发布说明和升级指南修改不兼容配置测试环境升级验证没问题生产环境先升级控制面再逐步滚动升级Sidecar从非核心到核心每个阶段都观察没问题再进下一阶段整个升级过程非常平滑没有出任何问题，所以升级Istio版本一定要谨慎循序渐进做好验证和回滚准备不要操之过急。

五、写在最后

以上就是我们团队在Istio实战中积累的12个进阶技巧涵盖了Sidecar管理流量管理安全可观测性性能优化运维等各个方面这些技巧很多在官方文档里没有详细说，或者不容易被发现，但是在实际使用中非常有用能帮我们解决很多问题提升效率和稳定性希望这些技巧能帮正在使用，或者准备使用Istio的朋友少走弯路更好地用好Istio这个强大的服务网格工具。

Istio作为目前最流行的服务网格实现功能非常强大能帮我们解决微服务架构下的很多问题，比如服务发现负载均衡灰度发布安全认证可观测性等等，而且这些功能都是透明的不需要改业务代码通过Sidecar自动实现非常方便，但是Istio也是一个比较复杂的系统涉及的概念和组件比较多要真正用好它需要一定的学习成本和实战经验希望这篇文章能帮大家更快地掌握Istio的使用技巧少踩坑多受益。

当然这12个技巧只是我们团队实战经验的一部分Istio还有很多其他的功能和技巧值得探索和学习，而且Istio也在快速发展新的功能和特性不断加入我们也在不断学习和实践积累更多的经验以后有机会再和大家分享更多的实战技巧和经验。

最后用一句话结束这篇文章也是我使用Istio最大的心得"服务网格是微服务架构的好帮手能帮我们解决很多痛点，但是要用好它需要深入理解它的原理和机制积累实战经验做好细节优化才能充分发挥它的威力为我们的系统保驾护航。"

愿大家都能用好Istio构建稳定可靠可观测的微服务架构提升系统的稳定性和，研发效率加油！