服务网格是近年来火热的技术之一，并且格局在不断变化中。可选择的服务网格选项也不少。但总要根据自己的需求来进行选择，本文会提到一些要素，来帮助DevOps团队确定最适合其特定情况的服务网格。
你能没有Envoy吗?
Envoy拥有一个由社区构建的充满活力的生态系统;它是开源的，并且是许多服务网格的基础。其丰富的功能使其难以被超越。
你的用例需要什么?
服务网格适用于微服务。如果要构建整体应用，则可能无法通过服务网格实现投资回报。如果不是所有应用程序都采用Kubernetes，则最好做出与平台无关的选择。
你现有的容器管理工具的依赖关系是什么?
那些已经利用供应商生态系统进行容器编排的公司，比如利用AWS EKS、红帽的OpenShift和consults，你可能会从它们的本地工具中获益，因为这些特性超出了开源的范围。
你从事什么行业?
大多数服务网格并不是针对特定行业类型而构建的。比如Kuma具有划分多个网格的能力，对于受到严格监管的金融平台可能会比较适合。小的电信运营商和ISP可以考虑使用Network Service Mesh服务网格。
你需要多少可见度?
从可观察性到高级指标是服务网格的核心。寻求定制和深度能力的企业可以考虑使用Istio或Consul。
你是否关心开放标准?
使用开放标准可以使技术在将来得到验证，并使其可以通过其他工具进行扩展。企业可能应该采用支持SMI的工具，例如Maesh或基金会支持的项目，例如Linkerd。
你是否关心开发人员的经验?
考虑运维工程师的可用性对于采用新工具至关重要。Linkerd在开发者有不错的口碑。
你的团队准备好服务网格了吗?评估企业是否具有资源和技能来实施服务网格技术，可能会影响你是使用Istio，还是Envoy，还是选择供应商实现抽象化，例如OpenShift。
虽然这些考虑并不完整，但算抛砖引玉吧。
