选择service mesh时的注意事项
时间：2022-03-06 04:32:02 | 来源：行业动态
时间：2022-03-06 04:32:02 来源：行业动态
本份榜单列出了多种Service Mesh选项，而且各个项目的发展态势也在不断变化。当然，每种Service Mesh的实现方式互不相同，也在具体功能上有所体现。在实际选择中，大家需要考虑到Service Mesh的侵入度、默认安全水平、平台成熟度以及其他问题。
DevOps团队也应参考以下因素，判断哪种service mesh最适合当前需求：
能否脱离Envoy？Envoy拥有充满活力的社区生态系统，属于开源项目而且作为多种Service Mesh的实现基础。其丰富的功能几乎找不到真正全面的替代方案。
用例提出哪些现实需求？Service mesh面向微服务架构。如果需要构建单体式应用，大家显然无需使用Service Mesh。另外，如果您的某些应用程序并不使用Kubernetes，最好选择具有良好平台中立性的方案。
您的现有容器管理工具中存在哪些依赖关系？已经在容器编排体系中引入某些供应商生态要素（例如AWS EKS、Red Hat OpenShift以及Consul）的用户不妨直接选择原生工具，借此将功能扩展至开源软件包之外。
您身处哪个行业？大多数Service Mesh并非针对特定行业进行设计与构建。但是，Kuma拥有强大的网格分区能力，因此特别适合需要遵循严格监管的金融平台。而底层网络电信企业与互联网服务供应商则更适合选择Network Service Mesh。
您需要怎样的可观察性？可观察性是Service Mesh中的一项核心指标。需要这类深层定制化功能的用户，可以优先考虑Istio与Consul。
您是否关心开放标准？使用开放标准，可以保证您的技术随时跟进时代发展，并通过其他工具完成持续扩展。如果您有这类诉求，不妨选择支持SMI的工具（例如Maesh）或者由基金会支持的项目（例如Linkerd）。
您是否关心开发者体验？在选择新工具时，很多企业都会关注运维工程师的实际体验。Linkerd在开发者群体中享有良好声誉，可能符合您的需求。
您的团队是否为Service Mesh做好了准备？评估组织内是否具有资源及技能，用以实施Service Mesh技术。这个问题的答案将直接决定您选择基于Envoy的Istio，或者使用OpenShift等经由供应商层进行抽象化的解决方案。
当然，以上事项并不完全，只是为大家提供一点讨论思路。希望您在审视以上列出的各项要点之后能够得到一点启发，探索出微服务网络开发的更多实现途径。
在线咨询
