Service Mesh 迁移原则

Service Mesh 迁移过程中需要注意的一些原则，以及如何根据实际使用情况。

1、业务透明

为了减少 Service Mesh 迁移对业务的影响，减少业务的迁移阻力，迁移刚开始一段时间，必须保证迁移过程中，业务完全透明且不需要有任何变更和修改。方案上，为了保证迁移对业务的完全透明，在数据平面通信上需要采用支持透明拦截的方式，对业务请求流量透明拦截。

2、渐进式迁移

为了减少 Service Mesh 迁移过程中的风险，必须采用渐进式迁移原则，每次只迁移一个服务，迁移后观察足够长的时间，没有问题后再进行接下来的迁移。同时为了保证在迁移过程中出现问题时，可以随时回退到迁移之前的状态，需要针对每个迁移动作增加一键回滚开关。如果遇到线上问题，可以立即通过开关关闭迁移特性，回归到迁移之前的状态。

3、迁移前后网络打通

如果 Service Mesh 迁移前后使用不同的网络方案，迁移过程中就会出现已迁移部分和未迁移部分之间的网络无法直接访问的场景。为了应对这种情况，迁移过程中需要将未迁移服务和已迁移服务之间的通信从内网访问修改为外网访问，外网访问和内网访问方案上差异很大，需要通过修改路由配置的方式来支持，对路由配置的频繁修改，无形中会增加迁移出错的概率。

为了保证迁移过程平稳进行，建议 Service Mesh 迁移前后采用相同的网络地址空间，保证服务迁移前后均可以正常访问，这样迁移过程中网络访问层面对业务透明，业务不需要感知，访问方式也不需要有任何变化。

4、Istio 性能

Service Mesh 的实践方面，性能是一个永远不能回避的问题，如果当前性能不能满足业务的要求，就不具备在生产环境下使用的条件。对于 Istio 来说，当前性能确实是阻塞 Service Mesh 大规模实施的关键因素，引入 Istio 的目的是解决痛点需求，Istio 最有价值的部分是 Envoy 和 Pilot，它们一起完成请求路由转发的配置管理，以及实际的转发。

Mixer 架构设计上看起来很美好，但业务实际上并不会过多使用 Mixer 组件，对扩展性和灵活性也并没有那么高的要求，因此出于性能考量，可以把 Mixer 相关的功能放到 Envoy，只实现最精简、最必要的检查和遥测统计逻辑。

Istio security 则需要根据业务的具体情况灵活选取。比如我司业务放在自建机房的私有云中，对于 Istio 面向的微服务内部的东西向通信来说，在内网环境下不需要考虑过多的安全问题，所以可以直接把安全部分裁掉；当然，如果是在公有云中部署 Service Mesh 服务，则需要对安全部分更多关注。从解决痛点需求和综合考虑性能，可以先聚焦 Istio 提供的核心价值，将当前不需要太多关注的部分裁掉。

此外，出于对扩展性的考虑，Istio 架构的整体性能会受一定的影响，如果你的业务只运行在特定的平台上，比如 Kubernetes，可以根据具体平台对 Istio 进行相应的定制和优化。