在确定要进行Service Mesh引入时，就要考虑Service Mesh落地的具体路径。首先是业务当前所处阶段是否已经支持容器化和Kubernetes。如果业务当前已经运行在Kubernetes上，因Istio对Kubernetes有着很好的支持，Service Mesh迁移就会非常顺畅；如果业务当前没有运行在Kubernetes容器上，因Service Mesh领域当前最强大的Istio对Kubernetes有一定的依赖，所以可能就无法直接使用Istio，即使定制修改Istio，解除对Kubernetes的依赖，也需要很大的代价。这时通常有如下两条路径可以选择。
一、非Kubernetes环境下，先接入Sidecar
如果业务当前没有办法快速容器化，同时又有引入Service Mesh的迫切需求，可以先接入Sidecar，满足业务当前的痛点需求。至于接入Sidecar之后的演进方向，需要看业务的未来规划中是否有Kubernetes容器化的计划，如果有，建议先进行容器化改造后，再由Sidecar的方式演进到Istio。
Istio在非Kubernetes环境下没有很好的支持，对Istio进行定制修改以支持非Kubernetes环境有很大的工作量，除非有非常强烈的需求和非常强大的技术储备，一般不建议这么做，特别是对于一些中小公司来说。如果一定要在非Kubernetes环境下实施Service Mesh，可以在数据平面使用Envoy，控制平面根据XDS协议自己研发，这样也非常灵活，方便控制。
二、先进行Kubernetes容器化改造，再接入Istio
对于有Kubernetes容器化需求的团队，可以在Kubernetes容器化完成之后，再进行Istio接入，Istio在很多方面利用了Kubernetes强大的基础设施能力，所以只有在Kubernetes下Istio才能最大限度地发挥作用，并且减少运维上的复杂度。
对于Istio来说，当前性能确实是阻塞Service Mesh大规模实施的关键因素，引入Istio的目的是解决痛点需求，Istio最有价值的部分是Envoy和Pilot，它们一起完成请求路由转发的配置管理，以及实际的转发。
Mixer架构设计上看起来很美好，但业务实际上并不会过多使用Mixer组件，对扩展性和灵活性也并没有那么高的要求，因此出于性能考量，可以把Mixer相关的功能放到Envoy，只实现最精简、最必要的检查和遥测统计逻辑。
Istio security则需要根据业务的具体情况灵活选取。比如我司业务放在自建机房的私有云中，对于Istio面向的微服务内部的东西向通信来说，在内网环境下不需要考虑过多的安全问题，所以可以直接把安全部分裁掉；当然，如果是在公有云中部署Service Mesh服务，则需要对安全部分更多关注。
从解决痛点需求和综合考虑性能，可以先聚焦Istio提供的核心价值，将当前不需要太多关注的部分裁掉。此外，出于对扩展性的考虑，Istio架构的整体性能会受一定的影响，如果你的业务只运行在特定的平台上，比如Kubernetes，可以根据具体平台对Istio进行相应的定制和优化。
