引入Istio主要是因为传统微服务存在以下问题。多语言技术栈不统一：C++、Java、PHP、Go。SpringCloud无法提出非Java语言的微服务治理。服务治理周期长：微服务治理框架与业务耦合，上线周期长，策略调整周期长。产品能力弱：SpringCloud缺乏平台和产品能力，可视化能力弱。那么，是不是意味着企业一定要用Istio呢？没有。表2-2是SpringCloud和Istio的简单对比。▼表2-2SpringCloud与Istio的对比与选择即企业开源语言以Java为主，更新升级不频繁，高级治理功能需求不多，业务规模大不是很大，还是用SpringCloud比较合适。企业如果要引入Istio，引入成本有多高？具体有3种情况，如表2-3所示。▼表2-3企业引入Istio的成本接下来，我们对比SpringCloud和Istio在OpenShift上实现的企业微服务治理，如表2-4所示。▼表2-4SpringCloud与Istio的实现对比从开放性和先进性的角度，推荐使用服务网格Istio作为首选的微服务应用框架。接下来介绍Istio在实践中的使用建议。Istio运维建议包括版本选择、备份环境、评估范围、配置验证、功能健壮性参考、入口流量选择等。当然，这些建议只是基于我们目前在测试过程中得到的数据。随着Istio的应用越来越广泛，相信最佳实践会越来越丰富。1.版本选择Istio是一个开源项目，迭代很快。截至2021年5月，社区中最新的Istio版本为1.9。频繁的版本迭代会给企业带来一些困扰：是坚持目前已经测试过的版本，还是使用社区的最新版本？正如我们前面提到的，RedHat有自己的Istio企业版，它是通过Operator实现的。部署和管理。出于安全和稳定性的考虑，RedHatIstio通常比社区晚两个小版本。因此建议使用最新版本的RedHatIstio。目前，社区中Istio最新版本的稳定性往往不尽如人意。2.备份环境在OpenShift环境中为同一个应用部署一个非Istio管理的环境。比如文中的三层微服务，可以独立启动一组不受Istio管理的应用，使用OpenShift原有的接入方式。这样做的好处是每当Istio升级或者调整一些参数的时候，可以提前进行主从切换，这样就可以将流量切换到一个不受Istio管理的环境，实现流量的切换Istio升级调整验证完成后返回。3.评估范围因为Istio对微服务的管理是非代码侵入的。因此，一般情况下，业务服务需要通过微服务来管理，由Istio来管理。对于没有微服务治理需求的非业务容器，没有必要强行在Istio中进行管理。当非服务容器需要承载服务时，不需要修改源码就可以交由Istio管理，只需要在OpenShift上重新注入Sidecar部署即可。4、配置生效如果系统中已经存在相关对象的配置，我们需要使用ocreplace-f指定配置文件来替换之前配置的对象。Istio中有些配置策略可以快速生效，有些配置需要一段时间才能生效，比如限流、熔断等。新创建策略(occreate-f)比替换策略(ocreplace-f)生效得更快。因此，在不影响业务的前提下，您可以先删除旧策略，再应用新策略。另外，Istio配置生效，主要针对微服务所在的项目，但也有一些针对Istio系统的配置。因此，在配置应用时，要注意指定对应的项目。在OpenShift中，VirtualService和DestinationRules都对项目生效，所以需要在配置应用时指定项目。5.功能健壮性参考从笔者大量的测试结果来看，比较健壮的功能有基于目标的蓝绿，灰度发布，基于源的蓝绿，灰度发布，灰度上线，服务提升、延迟和重试、错误注入、mTLS、黑白名单。限流和断路器功能需要提高鲁棒性。因此，整体来看，虽然Istio的功能越来越完善，但仍然有待完善。6.Ingress流量模式选择创建Ingress网关时，OpenShiftRouter上会自动创建对应的路由。Ingress网关可以暴露比Router更多的端口。因此，我们可以根据自己的需要选择访问应用程序的路径。Istio系统中的应用程序可以在不使用Router的情况下正常访问微服务。但是并不是所有运行在PaaS上的应用都在Istio体系下，其他非微服务或者非Istio体系下的服务仍然需要通过Router来访问。另外，Istio自带的监控系统和Kiali的接口都是通过Router来访问的。与SpringCloud相比，Istio更好的实现了微服务的路由管理。但在实际生产中，仅靠微服务的路由管理是不够的，还需要不同微服务之间的业务系统集成管理、微服务的API管理、微服务中的规则流程管理等。本文节选自《金融级IT架构与运维：云原生、分布式与安全》，经发布者授权发布。（书号：978-7-111-69829-6）
