你是否需要服务网格？看看这十个问题

1.什么是服务网格？

服务网格( Service Mesh )是指用于微服务应用的可配置基础架构层( configurable infrastructure layer )。它使每个service实例之间的通信更加流畅、可靠和迅速。服务网格提供了诸如服务发现、负载均衡、加密、身份鉴定、授权、支持熔断器模式( Circuit Breaker Pattern )以及其他一系列功能。

2.如何理解服务网格中的Sidecar?

服务网格的实现通常是提供一个代理实例，我们称之为"sidecar"。sidecar 包含在每一个service 之中。sidecar 主要处理 service 间的通信、监控、以及一些安全相关的考量 —— 任何可以从服务本体中抽象出来的安全方面的部分。通过这种方式，开发者可以在服务中专注于开发、支持以及维护；运维人员可以维护服务网格并运行app。

3.Envoy 是一个服务网格吗？

Envoy 是一个云原生代理，是众多开箱即用的代理之一，最初是由 Lyft 团队设计和构建的。Envoy 经常被用作服务网格的数据平面。然而，为了被认为是一个服务网格，Envoy 必须与控制平面一起使用，这样才能使这些技术集合成为一个服务网格。控制平面可以是简单的集中式配置文件库和指标收集器，也可以是全面 / 复杂的 Istio。

4.如果你正在部署微服务，是否需要服务网格？

不一定。服务网格增加了技术栈的操作复杂性，因此通常只有在组织在扩展服务与服务之间的通信方面遇到困难，或者有特定的用例需要解决时才会部署。

5.何时添加服务网格？

如果你正在部署第一个或第二个微服务，那么没有服务网格也行。你应该首先专注于学习Kubernetes并将无状态容器从应用程序中分解出来。你会很自然地慢慢熟悉服务网格可以解决的问题，这将使你在时机成熟时更好地规划服务网格的使用。

如果你现有的应用程序架构提供了所需的可观察性、安全性和弹性，那么你已经有了一个很好的起点。对于你来说，问题是何时添加服务网格。我们通常看到组织关注与实用程序代码相关联的工作，以集成每个新的微服务。一旦这项工作变得痛苦，他们就会评估如何使这种集成更加有效。我们提倡使用服务网格来简化这项工作。

6.如何实施、部署或推广服务网格？

最好的方法是分析各种服务网格产品（见上文），并遵循所选网格特有的实施准则。一般来说，最好是与所有利益相关者合作，逐步将任何新技术部署到生产中。

7.你是否需要服务网格来实现微服务的服务发现？

不，服务网格提供了实现服务发现的一种方式。其他解决方案包括特定语言的库（如 Ribbon 和 Eureka或 Finagle）。

8.可以在 Kubernetes 之外使用服务网格吗？

是的。许多服务网格允许在各种基础设施上安装和管理数据平面代理和相关控制平面。HashiCorp 的 Consul[106] 是最知名的例子，Istio 也被实验性地用于 Cloud Foundry。

9.服务网格与 API 网关的区别？

微服务和 API 服务解决了两个不同的问题，前者是技术性问题，后者是业务问题。

微服务应在有界上下文（bounded context）中进行通信。它们的设计是由连接组成有界上下文的组件需求所驱动的，就像远程过程调用（RPC）一样。
API（通常是 REST，但也包括事件流和其他协议，例如 SOAP、gRPC 和 GraphQL）应提供接口，将有界上下文暴露给外界。理想情况下，它们的接口设计是由业务价值驱动的，而不仅仅是 RPC。
换句话说，API 是在外部将一个有界上下文的业务暴露给另一个有界上下文，而微服务是构成有界上下文内部的几个组件。在传统体系结构中，这些组件可能是通过进程调用栈进行通信的类或 DLL。在微服务架构中，它们可能是跨网络通信的独立服务。

10.目前服务网格的实现和产品有哪些？

•Linkerd

•Istio

•Consul

•Kuma

•AWS App Mesh

•NGINX Service Mesh

•SolarMesh

•Kong

•Open Service MEsh

SolarMesh是基于Istio构建的高效可视化微服务治理平台，为集群服务提供非入侵式的服务治理能力，涵盖流量可视化、流量控制、链路追踪和通信加密认证等治理功能，开箱即用。

点击了解更多Solarmesh

有问题欢迎扫码加微信咨询

资料来源：https://mp.weixin.qq.com/s/0KPD9UqUUu6Xien4To0-IA