目前主流的微服务治理框架主要是Spring Cloud。而Istio作为新一代微服务框架，越来越受到关注。Istio被引入的主要原因是传统微服务存在以下问题。
- 多语言技术栈不统一：C++、Java、PHP、Go。Spring Cloud无法提出非Java语言的微服务治理。
- 服务治理周期长：微服务治理框架与业务耦合，上线周期长，策略调整周期长。
- 产品能力弱：Spring Cloud缺乏平台化和产品化的能力，可视化能力弱。
那么如何选择Spring Cloud与Istio，这里有个简单的对比。
如果企业的开源语言主要是Java、更新升级不频繁、无过多高级治理功能需求、业务规模不是非常大，使用Spring Cloud是比较合适的。那么引入Istio的成本如何？
Spring Cloud和Istio实现的企业微服务治理进行对比。
从开放性以及先进性角度来说，建议将服务网格Istio作为首选微服务应用框架。Istio运维方面的建议包括版本选择、备用环境、评估范围、配置生效、功能健壮性参考、入口流量选择。当然，这些建议都是基于当前的使用情况。随着Istio使用越来越广泛，相信最佳实践将会越来越丰富。
- 版本选择
Istio是一个迭代很快的开源项目。频繁的版本迭代会给企业带来一些困扰：是坚持使用目前已经测试过的版本，还是使用社区的最新版本？出于安全性和稳定性的考虑，红帽Istio往往比社区要晚两个小版本左右。因此建议使用红帽Istio的最新版本。目前看，社区的最新版本的Istio的稳定性往往不尽如人意。
- 备用环境
针对相同的应用，在环境中部署一套不被Istio管理的环境。这样做的好处是，每当进行Istio升级或者部分参数调整时都可以提前进行主从切换，让流量切换到没有被Istio管理的环境中，将Istio升级调整验证完毕后再将流量切换回来。
- 评估范围
由于Istio对微服务的管理是非代码侵入式的。因此通常情况下，业务服务需要进行微服务治理，需要被Istio纳管。而对于没有微服务治理要求的非业务容器，不必强行纳管在Istio中。当非业务容器需要承载业务时，被Istio纳管也不需要修改源代码，重新注入Sidecar部署即可。
- 配置生效
如果系统中已经有相关对象的配置，我们需要使用oc replace -f指定配置文件来替换之前配置的对象。Istio中有的配置策略能够较快生效，有的配置需要一段时间才能生效，如限流、熔断等。新创建策略（oc create -f）的生效速度要高于替换性策略（oc replace -f）。
因此在不影响业务的前提下，可以在应用新策略之前，先删除旧策略。此外，Istio的配置生效，大多是针对微服务所在的项目，但也有一些配置是针对Istio系统。因此，在配置应用时，要注意指定对应的项目。
- 功能健壮性参考
健壮性较强的功能有基于目标端的蓝绿、灰度发布，基于源端的蓝绿、灰度发布，灰度上线，服务推广，延迟和重试，错误注入，mTLS，黑白名单。健壮性有待提升的功能有限流和熔断。
- 入口流量方式
在Istio体系中的应用不使用Router也可以正常访问微服务。但是PaaS上运行的应用未必都是Istio体系下的，其他非微服务或者非Istio体系下的服务还是要通过Router访问。此外，Istio本身的监控系统和Kiali的界面都是通过Router访问的。
相比Spring Cloud，Istio较好地实现了微服务的路由管理。但在实际生产中，仅有微服务的路由管理是不够的，还需要诸如不同微服务之间的业务系统集成管理、微服务的API管理、微服务中的规则流程管理等。
