私有化输出的服务网格我们是这样做的

作者：古琦

介绍

微服务开发的问题

微服务架构下我们在开发中遇到的常见的问题有以下 4 个：

• 多语言问题：有多种编程语言，node.js, JAVA, GoLang…微服务需要为每种语言都维护一种中间件 SDK

• 升级推动难：SDK 升级需要推动业务应用进行代码修改和发布，对业务有打扰，业务压力下推动成本高

• 迭代速度慢：由于多语言多版本的存在，需要花费大量精力去维护历史版本，降低了迭代速度，升级速度慢 （在数据面选型上也考虑研发效能的问题

• 多版本问题：每种语言的 SDK 都面临版本升级，同时存在大量不同的版本互相访问，兼容性和测试维护成本巨大

为了解决这些问题，服务网格的 Sidecar + APP 模式是一个很好的方案

服务网格

Service Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。服务网格的概念被提出也有很多年了，服务网格的也出现了很多不同类型的实现，比如 Istio、Linkerd，Open Service Mesh 等等，还有出现类似 ebpf + envoy，proxylessMesh 等等其他方式的服务网格实现，其实都是在想如何解决当下生产、开发中的问题，我们熟知的关注度最多还是 Istio，架构如下：

通过 Sidecar 和业务应用分离，控制面 Istiod 实现对整个流量的管控，基于 Istio + Envoy 的能力实现了微服务的连接、安全、控制和可观测，服务网格在微服务架构下体现了与应用解耦的平台级服务治理能力，推出来统一的多协议多语言的微服务治理，同时保持了基础架构与应用解耦，降低升级和运维的成本，而且实现了微服务间的安全可靠通信，让不同类型的微服务的通信具备可观测。

阿里云专有云服务网格能力

服务网格的优势被大家广泛认可，直到今天已经有很多的用户将服务网格使用在自己的生产业务系统中，但是对于很多的常见的用户而言使用和运维这样的一套系统还是过于复杂，在通常的使用中，可能我们只需要做一次灰度发布，这时候就涉及不同规则的配置，非常容易出错，如何定义好应用的 VirtualService、DestinationRule 等规则对于大部分使用者而言都需要很高的学习成本，为了减少使用的成本和运维难度，阿里云专有云服务网格通过高度的产品化能力将服务网格的能力推出，只需要按照常见的思路去操作控制台，即可轻松的完成比如灰度发布、标签路由、鉴权、全链路等能力。

下面是一张阿里云专有云服务网格的能力大图，覆盖了协议、环境、服务治理、可观测、安全生产几个方面：

接下来来介绍下我们的产品能力：

服务治理

• 流量管理

流量管理的能力很多，包含了负载均衡、熔断、限流、超时、重试、流量镜像、连接池管理、故障注入、同 AZ 路由、服务 Mock。

限流的能力提供了单机的限流、基于 header 的限流、Path 的限流。

故障注入中除了开源社区的服务级别的故障外，还提供了针对服务单个 Pod 的故障注入，这样可以进行单个 Pod 的测试。

服务 Mock 的能力可以为开发人员 Mock 指定接口的返回，在接口还没有开发完成的时候，提高开发测试的效率，服务 Mock 的配置中可以选择请求的路径、端口号、方法、状态码、Header、返回 Json 数据。

• 标签路由

通过标签路由可以选择好基线的版本，然后选择对应的路由版本，配置路由策略，比如基于权重的策略、基于内容的策略，通过简单的配置轻松完成路由规则的配置。

• 服务注册

服务注册其实顾名思义就是将微服务注册到注册中心，这个能力主要是为了帮助一些非 Java 类型的服务实现跟已有 Java 类型服务的通信，比如 Spring Cloud 服务需要与非 Java 互通，为了方便代码编写，Spring Cloud 服务需要像调用其他 Spring Cloud 服务一样去调用非 Java 服务，因此就需要非 Java 的服务注册到对应的注册中心，这里我们支持了非 Java 服务注册到 Nacos、Eureka 注册中心。

• 运行监控

展示服务的运行监控数据，比如平均处理请求的次数、请求的成功率。

• 灰度发布

可以通过发布版本的方式发布一个灰度版本的镜像，填写对应的版本号、镜像，可以配置权重、内容路由规则，可以使用回滚、灰度成功能力。

• 零信任安全

可以配置双向身份认证、请求的 JWT 认证，还可以配置对应的授权策略。

全链路路由

全链路路由可以实现在整条调用链按照指定规则路由，比如在测试某个服务是否符合预期，但是测试服务需要依赖其他服务，这时候可以通过全链路的能力，拉出一个开发环境的泳道，将指定 tag 标记的流量打到测试服务中，而其他请求还在基线环境中，这时候如果还有其他服务需要测试，也可以加入到这个泳道中一起测试，全链路路由的好处就是可以任意路由到服务链路中间服务，在基线环境外研发/测试人员可以轻松部署一套独立环境，提升研发测试效率，降低运维成本。

• 创建泳道

创建一个属于对应服务网格的泳道，即为不同的环境（创建泳道前先确定号基线版本环境）。

• 发布服务/导入服务

创建好泳道后可以发布一个服务到泳道中，也可以导入部署的服务。

选择入口的应用，配置规则（什么样的流量特征的请求可以进入泳道中）。

入口网关

通过服务网格的 Istio Ingress Gateway 的能力可以将服务网格内服务暴露出去，协议上我们支持 HTTP、HTTPS、GRPC，除了暴露之外，我们还支持配置路由规则，这样可以对入口服务的流量进行管理。

外部服务

通过外部服务纳管将网格外的服务纳管进来管理，可以配置服务的协议、地址、EndPoint，还可以配置服务不同 EndPoint 的标签。

服务拓扑

结合 Prometheus + Kiali，可以展示整个调用链路的拓扑结构，其中包含了调用的服务、版本等信息。

网格管理

• 集群管理

可以通过简单的接入集群的能力，将已有的 K8s 集群加入进来，加入进来后，可以通过网格管理中创建网格的能力，在对应的集群中部署服务网格，创建网格时候可以配置网关、控制面 Istiod 的高可用能力、配置集群中服务的 Sidecar 资源（也可以单独配置）、是否打开 AccessLog 日志等能力。

• 网格配置管理

创建好服务网格后需要对网格进行管理、配置，在高级选项中可以看到常见的配置，比如网关高可用、控制面高可用、网关的资源、控制面资源、服务访问限制、可观测等。

除了这些外，还提供了服务网格对接注册中心的能力，这里我们支持了常见的 Nacos、Eureka、Zookeeper、Consul 注册中心对接到服务网格中。

• 多集群管理

单集群的可以满足大部分用户的要求，但是为了容灾，多集群的管理、互通也非常重要，服务网格的多集群能力在社区版本中也支持，但是配置复杂，我们的产品中提供了一键管理多集群的能力，通过多集群配置-纳管集群的能力，轻松的实现多个集群之间应用的互通、治理。

部署和输出

我们支持通过阿里云混合云企业版输出、CNStack 输出，同时我们也支持独立部署输出，只需要一个 K8s 集群，可以快速轻松拉起专有云服务网格的能力，体验产品化的服务网格能力。