站酷基于服务网格ASM的生产实践

作者：服务网格ASM

背景介绍

在这里插入图片描述

站酷（ZCOOL）2006 年 8 月创立于北京，深耕设计领域多年，聚集了 1500 万设计师、摄影师、插画师、艺术家、创意人，在设计创意群体中具有一定的影响力与号召力。站酷在创立之初，就以“让设计更有价值”为自身使命，多年来，一直致力于打造以原创设计为核心的“站酷原创版权生态体系”。

目前站酷旗下除拥有主站设计师互动平台「站酷网」之外，还重点打磨了一站式正版视觉内容交易平台——「站酷海洛」、一站式创意营销解决方案共创平台——「站酷共创」。值得一提的是，站酷近期发布了 AIGC 产品—— 「AI 创作实验室」。通过文字输入，可以在 1 分钟内生成高质量图像，自公测以来，已经生成图片数十万张。未来也会形成一个 AIGC 学习分享的专属社区。

站酷会在人工智能领域继续深耕，帮助设计师提升效率，更好专注在艺术作品创作的创意上，激发创作灵感。站酷的这一系列生态布局，为设计创意从业者在学习、展示、交流、就业、交易、创业各个环节提供了优质的专业服务，为设计师和企业的成长之路提供了高效的版权解决方案和立体的视觉服务。

技术挑战

在站酷的业务架构上，尽管使用 Kubernetes 平台解决了业务容器生产调度的问题，但在服务的治理、观测、安全等方面仍面临着诸多挑战。

1、多语言、多集群服务统一纳管

站酷面向互联网用户，提供站酷网、站酷海洛、站酷学习等各项服务，这些业务使用了 node.js、Java、php 等多种技术栈进行开发，并部署在多个 Kubernetes 集群中，如何通过统一的业务中台统一纳管这些业务是一个很大的技术挑战。

2、服务指标观测体系的构建

对于上述的业务架构而言，很难对于不同的应用服务实现统一的可观测体系、进行服务指标的统一实时监控。

3、服务治理的自动化集成

由于站酷建设了统一的业务中台，对于服务的部署、维护、治理等有着较强的自动化配置需求。对于多集群服务治理的场景需要一定的自动化集成能力。

基于服务网格 ASM 的生产实践

服务网格作为一种用来管理应用服务通信的基础核心技术, 为应用服务间的调用带来了安全、可靠、快速、应用无感知的服务治理、安全、可观测能力。为多语言应用服务的治理、观测等挑战提供了无侵入式的高效解决方案。

而阿里云服务网格产品 ASM 作为业内首个全托管 Istio 兼容的服务网格，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。

相比社区服务网格 Istio，服务网格 ASM 提供了更为强大实用的多项能力，包括多集群统一纳管、即插即用的插件中心、与阿里云云产品深度集成的可观测中心等，能够更好地帮助站酷解决业务建构中的各种技术挑战，显著降低运维成本。

目前，站酷所有的互联网用户业务都已经接入 ASM，包括站酷主站、站酷海洛等。

站酷的业务架构图如下：

在这里插入图片描述

1、多集群、多语言下的应用服务管理

在站酷的生产实践中，多集群、多语言的业务架构对统一管理带来了不小的挑战。对于服务网格来说，由于 Sidecar 模式的无侵入式特性，可以以统一的方式管理以不同技术栈开发的多语言应用，实现显著的运维成本降低。但对于社区服务网格 Istio 而言，多集群下的服务治理、以及对不同的 Kuberenets 集群形态的兼容仍然是一个极大的挑战。

通过使用服务网格 ASM，对多集群、多形态、多语言服务的统一纳管成为了非常简单的工作。托管式服务网格 ASM 在成为多种异构类型计算服务统一管理的基础设施中, 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及实现统一的代理可扩展能力, 以此构筑企业级能力。

在这里插入图片描述

服务网格 ASM 的托管式架构

如上图，对于阿里云容器服务提供的多种数据面集群形态，服务网格 ASM 都提供了统一的管控能力，使得集群形态不再是服务网格落地生产环境的制约。

同时，由于其托管式架构，服务网格 ASM 能够对多个数据面集群进行统一管控。借助 ASM 多集群管控的能力，站酷能够通过一个 ASM 实例对其下多个数据面集群中的服务进行统一管理，有效解决了多集群应用实现统一管理入口的挑战。

对于数据面的多个集群，ASM 采用全局命名空间的方式进行管理，将多个数据面集群中的不同命名空间汇总到一个 ASM 实例中，并可以在全局命名空间中统一进行 Sidecar 注入配置。同时，ASM 也支持在 ASM 实例与不同的数据面集群之间双向地一键式同步命名空间信息。

在这里插入图片描述

服务网格 ASM 的全局命名空间管理，支持配置多个集群的命名空间下的 Sidecar 注入管理

2、南北向与东西向流量治理的统一

作为站酷网、站酷海洛、站酷学习等一系列集群中服务的流量入口，站酷启用了多个 ASM 网关对集群中的服务进行流量的转发与控制。

站酷的服务主要使用 HTTP 与 gRPC 协议，ASM 网关对这些协议都有着很高的支持成熟度，能够原生地支持请求的负载均衡、以及基于多种丰富匹配条件的请求路由等网关能力。

而在社区 Istio 的网关之基础上，ASM 企业版提供了更多的企业级高级特性，包括指标伸缩（HPA）、基于 Intel MultiBuffer 技术的软硬结合性能优化、网关无损升级、SLB 优雅下线等，使网关真正达到了生产可用级别，可以很好地支持各种企业级服务。

在这里插入图片描述

ASM 网关还支持图形化地配置上游服务、域名证书等，显著提高运维效率

3、使用 ASM 可观测中心进行全业务的实时监控

在主要业务服务都迁移至服务网格平台上之后，利用服务网格 Sidecar 的日志与指标上报能力，可以自然地对网格中的不同服务以及 ASM 网关本身建设统一的可观测能力。

在网格可观测管理中心中，服务网格 ASM 提供了完善的网格可观测化方案。不仅提供日志中心、Prometheus 监控、网格拓扑等多种可观测形式，还与阿里云的其它可观测云产品（SLS 日志服务、ARMS 监测服务等）进行了深度集成（同时兼容开源可观测方案），能够一站式配置各项可观测指标的仪表盘。

在生产环境中，站酷主要利用了日志中心进行了网格可观测性的建设。ASM 通过与日志服务集成、提供网关与网格内 Sidecar 日志的自动采集，同时针对网关与网格内 Sidecar 访问日志分别提供了日志仪表盘，提供包括请求错误率、P95 延迟等实用指标监控，实现了对多集群异构应用的统一可观测性。

在这里插入图片描述

ASM 可观测管理中心与日志仪表盘

4、插件市场 - 使用 ASM 插件激活拓展能力

在迁移到服务网格 ASM 的过程中，站酷发现服务网格平台和自身的业务架构存在着一定的兼容问题。具体来说，服务网格的数据面 Sidecar 在默认情况下会将请求和响应中的 header 转化为小写。尽管这一行为对于大多数 http 服务来说没有问题，但仍会影响到对 header 大小写敏感的服务。

这一问题可以通过激活数据面 Sidecar 的插件拓展能力、让其保留 header 的大小写来进行解决。服务网格 ASM 在插件拓展中心中提供了即插即用的插件市场。针对各种实际业务场景，提供了多种即插即用式插件，经过简单几个参数的配置即可快速启用数据面 Sidecar 的各种拓展能力。通过对 ASM 插件市场的利用，站酷在很短时间内就解决了业务迁移中遇到的问题。

在这里插入图片描述

ASM 插件市场，提供一系列可以一键启用的插件拓展能力

5、自动化 API 集成

在提供企业级服务网格平台的各项特性的基础上，自动化集成也是网格平台的关键一环。在生产实践中，由于站酷自有业务中台，因此会对服务网格平台产生较强的自动化集成需求。

作为阿里云云产品, 服务网格 ASM 除了通用的 OpenAPI/SDK 集成方式之外，也提供了其它多样化的产品功能模块集成方式，包括 Kube API、Terraform 等，产品所提供的各大功能模块不仅能够通过 ASM 控制台进行访问，也能以API的形式集成进厂商的自有业务中台之中，助力网格运维自动化。

举例来说，在站酷的生产实践中，前述所提的全局命名空间管理功能就被站酷以 Open API 的形式集成进自家业务中台，实现了完备的网格内多集群自动化管理。针对网格配置, 使用 Kube API 实现了与原有 GitOps 平台的平滑对接。