简介：服务网格是用于解决服务间通信的专用基础设施层。它负责通过蕴含古代云原生应用程序的简单服务拓扑来牢靠地传递申请。

微服务倒退的这几年，新的技术和概念层出不穷，这些技术的引入实质上都是在围绕服务稳定性和业务开发效率晋升，最近两年服务网格越来越被宽广的微服务用户所认知。

在 Kubernetes 曾经成为云原生时代的操作系统的明天，如何更好的拥抱 Kubernetes 生态，实现业务疾速上云，享受云计算带来的能力，其中服务网格是一个必须要提的关键技术，然而在服务网格应用过程中咱们会碰到很多的问题，比方：如何让现有的利用迁徙到服务网格，如何反对多种语言、框架的互通和治理，如何应用可观测产品排查问题，接下来我将从如何接入服务网格、异构服务框架、语言的互通和可观测三个方面答复这个问题。

迁徙利用到服务网格中

服务网格

服务网格是用于解决服务间通信的专用基础设施层，它负责通过蕴含古代云原生应用程序的简单服务拓扑来牢靠地传递申请。实际上，服务网格通常通过一组轻量级网络代理来实现，这些代理与利用程序代码一起部署，而不须要感知应用程序自身。

目前支流的服务网格开源软件是 Istio，其整体架构如下：

从图中能够看到服务网格与业务容器是在同一个 Pod 中的不同容器，带来的劣势有如下三点：

1. 微服务治理与业务逻辑的解耦。服务网格把 SDK 中的大部分能力从利用中剥离进去，拆解为独立过程，以 Sidecar 的模式进行部署，服务网格通过将服务通信及相干管控性能从业务程序中拆散并下沉到基础设施层，使其和业务零碎齐全解耦，使开发人员更加专一于业务自身。

2. 异构语言 / 框架的对立治理。随着新技术的倒退和人员更替，在同一家公司中往往会呈现不同语言、不同框架的利用和服务，为了可能对立管控这些服务，以往的做法是为每种语言、每种框架都开发一套残缺的 SDK，保护老本十分之高，而且给公司的中间件团队带来了很大的挑战，有了服务网格之后，通过将主体的服务治理能力下沉到基础设施，多语言的反对就轻松很多了。

3. 服务网格岂但能够承当流量代理，对于业务共用的、通用的场景和需要都能够成为服务网格的一部分，这样能无效进步业务开发效率。

利用接入服务网格

目前服务网格对 Kubernetes 反对最残缺，同时也反对了 VM 的利用接入，然而须要较多的配置，咱们举荐首先将 VM 上的服务容器化后在接入网格中，逐渐迁徙已有的利用，通过网关来买通服务网格中的利用和 VM 中没有接入服务网格的利用。

服务网格的接入首先是须要装置 Istiod，而后通过对 Namespace 打标来实现 Sidecar 的主动注入，能够选择性的对一些服务不进行 Sidecar 的注入，比方相似 MySQL、Redis 等中间件利用，次要是缩小 Envoy 带来的提早，在 EDAS 中能够针对每个利用进行打标，对须要退出服务网格的利用才进行 Sidecar 的注入。

异构微服务的互通、治理

因为业务的倒退，基于业务产品的抉择，业务开发语言越来越多种多样，这些语言之间的互通成为大家关注的问题，目前常见的场景如 Java 语言和非 Java 语言的互通，互通中最重要的问题就是服务发现和通信协议的反对。

服务发现

通常咱们在应用 Kubernetes 上部署服务如下，其中定义了 Kubernetes Service 用于服务间申请的域名：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: details-v1
  labels:
    app: details
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: details
      version: v1
  template:
    metadata:
      labels:
        app: details
        version: v1
    spec:
      containers:
      - name: details
        image: docker.io/istio/examples-bookinfo-details-v1:1.16.2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080

apiVersion: v1
kind: Service
metadata:
  name: details
  labels:
    app: details
    service: details
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: details

Istio 监听 Kubernetes Api Server，获取服务的 Service、Pod 等数据，通过 XDS 形式提供给 Envoy，Envoy 会通过获取的数据做负载平衡。

很多微服务框架都在应用如 Nacos、Consul、Zookeeper 等注册核心，这部分微服务如何在不进行大规模革新下应用服务网格呢，这就设计到 Istiod 跟注册核心的买通，目前社区提供了以下的几种形式实现注册核心数据买通：

1.MCP Server

编写自定义的 MCP Server 从第三方注册核心获取服务数据，转换为 ServiceEntry 和 WorkloadEntry 资源，通过 MCP 协定提供给 Istio 中的 MCP Config Controller，Istiod 须要配置 MCP Server 地址，目前在开源我的项目中蕴含 MCP Server 的注册核心的有很多，阿里云 MSE 提供托管的 Nacos 注册核心，间接提供 MCP Server 能力。

2.ServiceEntry 和 WorkloadEntry

编写独立的第三方组件，该组件从注册核心中获取服务数据，而后转换为 Istio 中 ServiceEntry 和 WorkloadEntry CRD，写入到 Kubernetes API Server 中。Pilot 的 Kube Controller 会监听 Kubernetes API Server 中和 Istio 相干资源的变动，并将 ServiceEntry 和 WorkloadEntry 转换为外部 Service 模型，通过 Xds 协定同步给 Sidecar。

3. 自定义适配器

编写自定义的 Adapter 来集成第三方注册核心，该适配器从注册核心中获取服务和服务实例，转换为 Pilot 外部的 Service 模型，集成到 Service Controller 中，相似现有的 Consul Service Registry 的适配形式，这种形式的长处就是不须要通过第三方进行转换，然而跟 Istio 耦合在一起，在 Istio 版本升级较快的时候，须要一直的适配对应的新版本。

MSE 注册核心

第一种形式须要注册核心提供反对，第二种形式须要独立的三方组件进行同步，可用性、保护是一个累赘，第三种须要对 Istio 十分相熟，保护降级老本很高，目前 MSE 注册核心曾经反对 MCP Over XDS 的形式对接 Istio，可用性高，免保护。

咱们通过 Java Agent 反对 Xds 协定的形式对接 Istio，同时 Istio 也通过 MCP Over XDS 对接 Nacos 注册核心，这样服务发现的数据在 Java Agent 和 Sidecar 中都能拿到，Java 和非 Java 的服务能够相互发现，相互调用。

服务网格的服务治理

服务网格 Sidecar 通过容器的形式与业务容器共享网络，通过 Iptables 的形式将 inbound 和 outbound 流量都劫持到 Sidecar 上，Sidecar 解析数据包，获取申请后通过匹配服务发现数据找到对应的服务端，而后匹配对应的路由规定找到满足条件的服务端发送申请。

服务网格的服务治理中 Istio 的路由规定最要害的两个 CRD 是 VirtualService 和 DestinationRule，他们形容了申请匹配、路由的过程，如下所示：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

DestinationRule 中蕴含了 reviews 服务的三个版本，VirtualService 形容了对 reviews 服务的申请会发送到 subset 为 v1 的版本中。其余的服务治理能力还包含了故障注入、服务鉴权、服务超时、熔断等，能够通过写入对应的规定来实现，目前 Istio 也没有提供十分好应用的白屏化服务治理界面，在 EDAS/MSE 中提供白屏界面操作如服务鉴权、服务查问、离群摘除、金丝雀公布等，保障在操作过程中流量不失落，路由规定的操作须要遵循以下几个准则：

1、通常应用服务网格服务治理的最佳实际形式是从一开始就为每一个服务创立具备默认路由的 VirtualService，即当你只有一个版本的时候，就写入该版本的 VirtualService 规定，这样在你部署第二个版本中，不至于流量会打到第二个版本中，须要配置路由规定才能够，保障新版本验证过程中不会呈现因为新版本本身问题导致的大规模报错。

2、VirtualService 和 DestinationRule 在应用的过程中，Envoy 会首先查看 VirtualService 中的路由规定，以决定是否路由到特定的子集去，只有路由到对应的子集才会激活在 DestinationRule 中对应子集配置的如熔断、离群摘除等规定，同时能够看出 VirtualService 和 DestinationRule 的配置也是有程序的，首先配置 DestinationRule，而后在配置 VirtualService，否则会导致找不到对应的 Subset 报错。

3、更新 DestinationRule 增加一个新的 Subset 后，须要期待 DestinationRule 流传到 Envoy Sidecar，而后再更新对应的 VirtualService。

双模微服务治理

互通的问题通过对接注册核心的形式解决了，那异构框架的服务治理则通过 MSE 来反对，MSE 的服务治理核心能够对接 Java 服务，同时也能够反对服务网格的服务。

MSE 在管制面上反对双模微服务治理，即 Java 服务治理和非 Java 服务治理，管制面对外提供对立的治理模型，咱们参考 Istio 的路由规定设计模型，提出一个对立的服务治理规定模型，模型的设计次要思考到 Dubbo、Spring Cloud 和服务网格治理的通用性。

{"RegisterConfig":Object{...},
    "protocol":"springcloud",
    "rule_type":"fault_inject",
    "rule":{"hosts":Array[1],
        "rule_policy":[
            {"match":Array[1],
                "fault":Object{...},
                "route":Array[1],
                "Timeout":"10s",
                "retries":Object{...},
                "mirror":Object{...},
                "mirror_percent":100,
                "headers":Object{...},
                "tls":Object{...}
            },
            {
                "route":[
                    {"destination":Object{...},
                        "weight":"100",
                        "headers":Object{...}
                    }
                ]
            }
        ]
    }
}

上述模型中蕴含了注册核心、协定、规定类型、路由规定，路由规定中蕴含了匹配的规定和路由的目的地，MSE 通过生成对应这样的 CRD 来定义不同类型的路由规定，Java Agent 的和服务网格都能够通过监听这样的 CRD 来治理本人的流量，后续咱们也会在 OAM 中推出这一套微服务治理规定，用于对立服务治理模型。

MSE 微服务治理

服务查问：

标签路由：

离群实例摘除：

可观测

社区开源计划

可观测是微服务能力的重要组成部分，服务网格能够跟目前开源的可观测产品联合，可观测性上次要围绕 Metrics、Tracing 和 Logging 来开展，在 Metrics 上提供数据供 Prometheus 采集，在 Tracing 上，Istio 反对 Apache SKyWalking、Zipkin、Jaeger 的链路追踪，这三个中间件都反对 OpenTracing 协定，在 Logging 上，对于日志采集组件的要求也越来越高，目前比拟风行的计划是应用 Fluentd 或者 Filebeat 代替 Logstash。

阿里云 EDAS 计划

阿里云 Xtrace 为服务网格提供可观测能力，蕴含链路追踪、利用概览、拓扑、Metrics 统计，在利用公布后间接能够通过利用详情查看，如下图所示：

拓扑图如下：

能够通过链路追踪查看每个申请过程中的问题，帮助问题定位，同时 Xtrace 也提供了不同语言的 SDK，接入 SDK 后能够查看更细粒度的数据。

作者：中间件小哥
原文链接
本文为阿里云原创内容，未经容许不得转载