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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 在站酷的生产实践中,多集群、多语言的业务架构对统一管理带来了不小的挑战。对于服务网格来说,由于Sidecar模式的无侵入式特性,可以以统一的方式管理以不同技术栈开发的多语言应用,实现显著的运维成本降低。但对于社区服务网格Istio而言,多集群下的服务治理、以及对不同的Kuberenets集群形态的兼容仍然是一个极大的挑战。通过使用服务网格ASM,对多集群、多形态、多语言服务的统一纳管成为了非常简单的工作。托管式服务网格 ASM 在成为多种异构类型计算服务统一管理的基础设施中, 提供了统一的流量管理能力、服务安全能力、服务可观测性能力、以及实现统一的代理可扩展能力, 以此构筑企业级服务网格平台。

背景介绍


站酷(ZCOOL20068月创立于北京,深耕设计领域年,聚集了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平台的平滑对接。

展望

随着站酷业务服务的持续改造,将持续基于阿里云服务网格ASM产品,获得更加丰富便捷的企业级特性,助力降本增效,包括但不限于:

1、提供便捷的网格内服务安全与鉴权方案:ASM现已提供ASM安全策略中心,可帮助快速配置网关与网格内服务安全鉴权方案

2、更加精细化的流量治理能力:随着站酷微服务化改造的不断加深,将会持续挖掘ASM提供的多项企业级流量治理特性,如全链路灰度发布、本地限流、接口级熔断。

相关文章
|
3月前
|
运维 负载均衡 监控
探索微服务架构下的服务网格(Service Mesh)实践之路
【8月更文挑战第30天】 在当今日益复杂的分布式系统中,微服务架构已成为众多企业解决系统扩展与维护难题的利器。然而,随着服务的不断增多和网络交互的复杂性提升,传统的微服务管理方式开始显得力不从心。服务网格(Service Mesh)作为一种新兴的解决方案,旨在通过提供应用层的网络基础设施来简化服务间通讯,并增强系统的可观察性和安全性。本文将分享我在采用服务网格技术过程中的经验与思考,探讨如何在现代云原生环境中有效地实施服务网格,以及它给开发和运维带来的变革。
|
5月前
|
负载均衡 测试技术 网络安全
阿里云服务网格ASM多集群实践(一)多集群管理概述
服务网格多集群管理网络打通和部署模式的多种最佳实践
|
4月前
|
Cloud Native 测试技术 开发者
阿里云服务网格ASM多集群实践(二):高效按需的应用多环境部署与全链路灰度发布
介绍服务网格ASM提出的一种多集群部署下的多环境部署与全链路灰度发布解决方案。
|
6月前
|
监控 负载均衡 数据安全/隐私保护
探索微服务架构下的服务网格(Service Mesh)实践
【5月更文挑战第6天】 在现代软件工程的复杂多变的开发环境中,微服务架构已成为构建、部署和扩展应用的一种流行方式。随着微服务架构的普及,服务网格(Service Mesh)作为一种新兴技术范式,旨在提供一种透明且高效的方式来管理微服务间的通讯。本文将深入探讨服务网格的核心概念、它在微服务架构中的作用以及如何在实际项目中落地实施服务网格。通过剖析服务网格的关键组件及其与现有系统的协同工作方式,我们揭示了服务网格提高系统可观察性、安全性和可操作性的内在机制。此外,文章还将分享一些实践中的挑战和应对策略,为开发者和企业决策者提供实用的参考。
|
6月前
|
运维 监控 负载均衡
探索微服务架构下的服务网格(Service Mesh)实践之路
【4月更文挑战第30天】 在现代云计算的大背景下,微服务架构以其灵活性和可扩展性成为众多企业转型的首选。然而,随着服务的激增和网络交互的复杂化,传统的服务通信模式已无法满足需求,服务网格(Service Mesh)应运而生。本文通过分析服务网格的核心组件、运作机制以及在企业中的实际应用案例,探讨了服务网格在微服务架构中的关键作用及其带来的变革,同时提出了实施过程中面临的挑战和解决策略。
|
6月前
|
运维 监控 Cloud Native
云原生架构下的服务网格演进与实践
【5月更文挑战第23天】 随着云计算技术的不断成熟,云原生架构已成为推动企业数字化转型的关键动力。本文将深入探讨服务网格在云原生环境中的重要性,分析其在微服务管理、流量控制和安全性方面的创新应用。通过对服务网格的技术和实践案例的剖析,揭示其如何优化云原生应用的部署、运行和管理,为企业构建更加动态、可靠和高效的分布式系统提供策略指导。
|
6月前
|
运维 监控 负载均衡
探索微服务架构下的服务网格(Service Mesh)实践
【4月更文挑战第28天】 在现代云原生应用的后端开发领域,微服务架构已成为一种广泛采用的设计模式。随着分布式系统的复杂性增加,服务之间的通信变得愈加关键。本文将深入探讨服务网格这一创新技术,它旨在提供一种透明且高效的方式来管理、监控和保护微服务间的交互。我们将从服务网格的基本概念出发,分析其在实际应用中的优势与挑战,并通过一个案例研究来展示如何在现有的后端系统中集成服务网格。
|
6月前
|
Kubernetes Cloud Native 测试技术
使用ASM流量泳道的全链路灰度发布实践
服务网格ASM实现全链路灰度发布:通过流量泳道隔离不同版本环境,配置虚拟服务实现灰度比例控制。从创建泳道、打标签、部署新版本到灰度切流、最终上线及下线旧版。
|
运维 Kubernetes Cloud Native
服务网格实施周期缩短 50%,丽迅物流基于阿里云 ACK 和 ASM 的云原生应用管理实践
通过本文介绍丽迅物流关于基于阿里云服务网格 ASM 如何加速企业业务云原生化进程的实践经验。
|
人工智能 自然语言处理 运维
站酷基于服务网格 ASM 的生产实践
随着站酷业务服务的持续改造,将持续基于阿里云服务网格 ASM 产品,获得更加丰富便捷的企业级特性,助力降本增效。
181 2
站酷基于服务网格 ASM 的生产实践
下一篇
无影云桌面