微服务治理框架对比

目前主流的微服务治理框架主要是 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 使用越来越广泛，相信最佳实践将会越来越丰富。

1. 版本选择

Istio 是一个迭代很快的开源项目。频繁的版本迭代会给企业带来一些困扰：是坚持使用目前已经测试过的版本，还是使用社区的最新版本？出于安全性和稳定性的考虑，红帽 Istio 往往比社区要晚两个小版本左右。因此建议使用红帽 Istio 的最新版本。目前看，社区的最新版本的 Istio 的稳定性往往不尽如人意。

2. 备用环境

针对相同的应用，在环境中部署一套不被 Istio 管理的环境。这样做的好处是，每当进行 Istio 升级或者部分参数调整时都可以提前进行主从切换，让流量切换到没有被 Istio 管理的环境中，将 Istio 升级调整验证完毕后再将流量切换回来。

3. 评估范围

由于 Istio 对微服务的管理是非代码侵入式的。因此通常情况下，业务服务需要进行微服务治理，需要被 Istio 纳管。而对于没有微服务治理要求的非业务容器，不必强行纳管在 Istio 中。当非业务容器需要承载业务时，被 Istio 纳管也不需要修改源代码，重新注入 Sidecar 部署即可。

4. 配置生效

如果系统中已经有相关对象的配置，我们需要使用 oc replace -f 指定配置文件来替换之前配置的对象。Istio 中有的配置策略能够较快生效，有的配置需要一段时间才能生效，如限流、熔断等。新创建策略（oc create -f）的生效速度要高于替换性策略（oc replace -f）。

因此在不影响业务的前提下，可以在应用新策略之前，先删除旧策略。此外，Istio 的配置生效，大多是针对微服务所在的项目，但也有一些配置是针对 Istio 系统。因此，在配置应用时，要注意指定对应的项目。

5. 功能健壮性参考

健壮性较强的功能有基于目标端的蓝绿、灰度发布，基于源端的蓝绿、灰度发布，灰度上线，服务推广，延迟和重试，错误注入，mTLS，黑白名单。健壮性有待提升的功能有限流和熔断。

6. 入口流量方式

在 Istio 体系中的应用不使用 Router 也可以正常访问微服务。但是 PaaS 上运行的应用未必都是 Istio 体系下的，其他非微服务或者非 Istio 体系下的服务还是要通过 Router 访问。此外，Istio 本身的监控系统和 Kiali 的界面都是通过 Router 访问的。

相比 Spring Cloud，Istio 较好地实现了微服务的路由管理。但在实际生产中，仅有微服务的路由管理是不够的，还需要诸如不同微服务之间的业务系统集成管理、微服务的 API 管理、微服务中的规则流程管理等。