没有 Kubernetes，Service Mesh 还能玩得转吗？传统微服务治理新思路

Service Mesh，这几年在云原生领域可是火得一塌糊涂。提到它，大家脑子里冒出来的肯定是 Kubernetes（K8s）。毕竟，这俩就像一对连体婴，形影不离。但问题来了，如果离开了 K8s 的怀抱，Service Mesh 还能发挥它的价值吗？今天咱们就来聊聊这个话题，看看在没有 K8s 的环境下，Service Mesh 到底还能怎么玩。

为什么 Service Mesh 总和 Kubernetes 绑定在一起？

要搞清楚这个问题，咱们得先了解一下 Service Mesh 的核心作用。简单来说，Service Mesh 就是一个专门处理服务间通信的基础设施层。它把服务间的那些“脏活累活”，比如服务发现、流量管理、安全认证、可观测性等等，都给接管了。这样，开发人员就可以专注于业务逻辑，不用再去操心这些非业务相关的技术细节了。

而 K8s 呢，它是一个容器编排平台。它可以帮助我们自动化地部署、管理和扩展容器化的应用程序。在 K8s 中，服务通常是以 Pod 的形式运行的，Service Mesh 可以很好地集成到 K8s 的 Pod 网络中，为这些 Pod 提供服务治理能力。

所以，Service Mesh 和 K8s 的结合，简直就是天作之合。K8s 提供了容器化的运行环境，Service Mesh 提供了服务治理的能力，两者相互配合，可以大大简化微服务架构的开发和运维。

离开 Kubernetes，Service Mesh 还有什么用？

虽然 Service Mesh 和 K8s 配合得很好，但这并不意味着 Service Mesh 只能在 K8s 环境下才能发挥作用。事实上，在很多传统的微服务架构中，Service Mesh 同样可以大显身手。

1. 解决传统微服务架构的痛点

在没有 K8s 的环境下，传统的微服务架构通常会面临以下几个痛点：

• 服务发现困难：服务实例的 IP 地址和端口经常变化，需要一个中心化的服务注册中心来管理。
• 流量管理复杂：需要手动实现负载均衡、熔断、限流等功能，代码散落在各个服务中，难以维护。
• 安全认证不足：服务间的认证和授权通常依赖于简单的 Token 机制，容易被攻击。
• 可观测性差：缺乏统一的监控和日志收集方案，难以排查问题。

而 Service Mesh 可以很好地解决这些问题。它可以提供统一的服务发现、流量管理、安全认证和可观测性方案，让开发人员可以专注于业务逻辑，不用再去操心这些非业务相关的技术细节了。

2. 逐步迁移到云原生架构

对于一些传统的企业来说，他们可能还没有完全拥抱云原生架构，但是他们又想享受到 Service Mesh 带来的好处。这时候，他们就可以先在现有的微服务架构中引入 Service Mesh，逐步地将服务迁移到 K8s 中。这样，他们就可以平滑地过渡到云原生架构，避免了一次性迁移带来的风险。

3. 异构环境下的服务治理

在一些复杂的环境中，可能同时存在 K8s 和非 K8s 的服务。这时候，Service Mesh 可以作为一个统一的服务治理平台，将这些异构的服务连接起来。它可以提供统一的服务发现、流量管理、安全认证和可观测性方案，让这些异构的服务可以像在同一个环境中一样协同工作。

如何在没有 Kubernetes 的环境下部署 Service Mesh？

既然 Service Mesh 在没有 K8s 的环境下也能发挥作用，那么我们该如何在这样的环境下部署 Service Mesh 呢？

1. 选择合适的 Service Mesh 产品

目前市面上有很多 Service Mesh 产品，比如 Istio、Linkerd、Consul Connect 等等。在选择 Service Mesh 产品时，我们需要考虑以下几个因素：

• 是否支持非 K8s 环境：有些 Service Mesh 产品是专门为 K8s 设计的，不支持非 K8s 环境。在选择 Service Mesh 产品时，我们需要确保它支持我们的运行环境。
• 性能：Service Mesh 会增加一定的延迟，我们需要选择一个性能较好的 Service Mesh 产品，以减少对应用程序的影响。
• 易用性：Service Mesh 的配置和管理可能会比较复杂，我们需要选择一个易于使用的 Service Mesh 产品，以降低我们的学习成本。
• 社区支持：Service Mesh 的发展非常迅速，我们需要选择一个社区活跃的 Service Mesh 产品，以便及时获取技术支持。

2. 部署 Service Mesh 控制平面

Service Mesh 的控制平面是整个 Service Mesh 的大脑。它负责管理和配置 Service Mesh 的各个组件。在没有 K8s 的环境下，我们可以将 Service Mesh 的控制平面部署在虚拟机或者物理机上。具体部署方式可以参考 Service Mesh 产品的官方文档。

3. 部署 Service Mesh 数据平面

Service Mesh 的数据平面是负责实际流量转发的组件。它通常是以 Sidecar 的形式运行在应用程序旁边。在没有 K8s 的环境下，我们可以将 Sidecar 部署在虚拟机或者物理机上。具体部署方式可以参考 Service Mesh 产品的官方文档。

一般来说，有两种部署 Sidecar 的方式：

• 手动部署：手动将 Sidecar 部署到每个应用程序所在的虚拟机或者物理机上。这种方式比较繁琐，但是它可以更好地控制 Sidecar 的部署位置和资源占用。
• 自动注入：使用一些工具，比如 Envoy 的 auto-inject 功能，自动将 Sidecar 注入到应用程序中。这种方式比较方便，但是它可能会增加应用程序的启动时间。

4. 配置 Service Mesh

部署好 Service Mesh 的控制平面和数据平面之后，我们需要配置 Service Mesh，让它可以正确地管理我们的服务。具体的配置方式可以参考 Service Mesh 产品的官方文档。

一般来说，我们需要配置以下几个方面：

• 服务发现：配置 Service Mesh 如何发现我们的服务。我们可以使用 Service Mesh 自带的服务发现机制，也可以集成第三方的服务注册中心，比如 Consul、etcd 等。
• 流量管理：配置 Service Mesh 如何管理我们的流量。我们可以配置负载均衡策略、熔断策略、限流策略等。
• 安全认证：配置 Service Mesh 如何进行安全认证。我们可以使用 Service Mesh 自带的认证机制，也可以集成第三方的认证服务，比如 OAuth2、JWT 等。
• 可观测性：配置 Service Mesh 如何收集监控和日志数据。我们可以使用 Service Mesh 自带的监控和日志收集工具，也可以集成第三方的监控和日志收集系统，比如 Prometheus、Grafana、ELK Stack 等。

案例分析：Consul Connect 在非 Kubernetes 环境下的应用

为了更好地理解 Service Mesh 在非 K8s 环境下的应用，我们来看一个具体的案例：Consul Connect。Consul Connect 是 HashiCorp 公司推出的 Service Mesh 产品，它可以很好地支持非 K8s 环境。

假设我们有一个传统的微服务架构，其中包含以下几个服务：

• user-service：用户服务，负责处理用户相关的业务逻辑。
• order-service：订单服务，负责处理订单相关的业务逻辑。
• product-service：商品服务，负责处理商品相关的业务逻辑。

这些服务都运行在虚拟机上，并且使用 Consul 作为服务注册中心。

现在，我们想使用 Consul Connect 来管理这些服务。我们可以按照以下步骤进行操作：

1. 部署 Consul Connect 控制平面：在虚拟机上部署 Consul Connect 的控制平面。具体部署方式可以参考 Consul Connect 的官方文档。
2. 部署 Consul Connect 数据平面：在每个服务所在的虚拟机上部署 Consul Connect 的 Sidecar。具体部署方式可以参考 Consul Connect 的官方文档。
3. 配置 Consul Connect：配置 Consul Connect，让它可以正确地管理我们的服务。我们可以使用 Consul Connect 的 CLI 工具或者 API 来进行配置。

配置 Consul Connect 的服务发现：

consul connect envoy -sidecar-for user-service -address=127.0.0.1:8500

这个命令会将 Envoy Sidecar 注册到 Consul 中，并且将其与 user-service 关联起来。这样，Envoy Sidecar 就可以拦截所有进出 user-service 的流量，并且将其转发到 Consul Connect 控制平面进行处理。

配置 Consul Connect 的流量管理：

consul config write service-defaults/user-service <<EOF
{
  "protocol": "http",
  "upstream": [
    {
      "destination": {
        "service": "order-service"
      },
      "config": {
        "比例": 50
      }
    },
    {
      "destination": {
        "service": "product-service"
      },
      "config": {
        "比例": 50
      }
    }
  ]
}
EOF

这个命令会创建一个 Consul Connect 的服务默认配置，将 user-service 的流量按照 50% 的比例分发到 order-service 和 product-service。这样，我们就可以实现简单的流量管理功能。

配置 Consul Connect 的安全认证：

consul config write service-intentions <<EOF
{
  "sources": [
    {
      "type": "consul",
      "name": "user-service"
    }
  ],
  "destination": {
    "service": "order-service"
  },
  "action": "allow"
}
EOF

这个命令会创建一个 Consul Connect 的服务意图，允许 user-service 访问 order-service。这样，我们就可以实现简单的安全认证功能。

通过以上步骤，我们就可以在没有 K8s 的环境下使用 Consul Connect 来管理我们的服务了。当然，这只是一个简单的示例，实际应用中可能需要更复杂的配置。

总结

虽然 Service Mesh 和 K8s 配合得很好，但这并不意味着 Service Mesh 只能在 K8s 环境下才能发挥作用。事实上，在很多传统的微服务架构中，Service Mesh 同样可以大显身手。它可以解决传统微服务架构的痛点，帮助企业逐步迁移到云原生架构，以及在异构环境下提供统一的服务治理能力。

当然，在没有 K8s 的环境下部署 Service Mesh 可能会比较复杂，需要我们选择合适的 Service Mesh 产品，并且仔细配置 Service Mesh 的各个组件。但是，只要我们掌握了正确的方法，就可以在非 K8s 环境下享受到 Service Mesh 带来的好处。