问题描述
在容器（Docker）和编排（Kubernetes）方面，行业似乎已经选择了事实上的标准，但在实现服务网格的选项方面似乎并非如此。在选择可用的服务网格选项时，是否有一些好的标准可供参考？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在选择服务网格时，一个很好的标准是选择业界已经广泛采用的解决方案。目前，Istio 是服务网格的事实标准，由 Google 和 IBM 共同推出。
以下是一些关于 Istio 的资源：
– Welcome to the service mesh era: Introducing a new Istio blog post series
– IBM, Google Cloud and the open community launch Istio 1.0 to bring microservices to the enterprise
方案2
在选择服务网格时，还可以考虑所使用的技术栈是否已经有类似的解决方案。例如，如果你是一个使用 Java 的团队，正在开发微服务应用程序，那么你可能已经在使用 Spring Boot 和 Spring Cloud。在这种情况下，Spring Cloud 已经提供了一些组件，可以提供与服务网格相同的好处，但是以更传统的方式实现（通过在应用程序中嵌入库）。
以下是一个示例架构，演示了如何将一个 Java Spring Cloud 航空订票微服务演示应用程序迁移到 OpenShift Kubernetes 上：
– Spring Boot Microservices on Red Hat OpenShift Container Platform
根据你的情况，可以考虑以下三种选择：
1. 如果你正在编写 Spring Boot 微服务，可以继续使用 Spring Cloud。开发人员可以在他们的本地计算机上运行所有内容，并负责在 Kubernetes 上使其正常工作。
2. 部署 Linkerd，因为它是一个成熟的 CNCF 项目，所以是最成熟的选择。
3. 部署 Istio，它最近发布了 v1.0 版本，但可能会快速成熟。
如果有时间，最好尝试这三种选择，以找到最适合你的需求的解决方案。
评论：选择“聪明的客户端和愚蠢的管道”是一个经验法则，而像 Istio 这样的服务网格技术似乎违背了这个原则。这意味着，如果你部署了“魔法管道”并出现错误，你的开发团队会期望你每次都解决问题。如果你提供了“愚蠢的管道”（原始的 Kubernetes）并允许他们在应用程序中安装执行“聪明客户端逻辑”的库，他们将负责解决问题。