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