Service Mesh 落地路径

在确定要进行 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 进行相应的定制和优化。