【阅读原文】戳：阿里云服务网格ASM多集群实践（一）多集群管理概述
引言：在应用部署日趋复杂的业务场景中，多集群部署逐渐成为一个重要的部署实践。多集群可以带来显著地可用性优势或对多套部署环境形成天然隔离，带来稳定性和安全性收益。然而，正确地管理多集群是充满挑战的，在实践中，为了使得多集群可以形成互备，通常都会将多个集群部署在不同的机房、地域或公有云上，如何打通多集群的网络是第一个需要面对的挑战。其次，针对不同的多集群部署实践，往往需要按照特定的规则管理流量。本系列文章将以场景化的形式为读者展示几种典型的多集群实践，以及多集群部署可能遇到的挑战和解决方案，并在随后的内容中带来部分场景的实操流程。
多集群网络互通
阿里云在多个地域部署了云服务基础设施，每个地域包含多个可用区。地域是指物理的数据中心。资源创建成功后不能更换地域。而可用区（Availability Zone，简称AZ）是指在同一地域内，电力和网络互相独立的物理区域。同一可用区内实例之间的网络延时更小。
在一些多集群实践中，我们可能希望服务能够进行跨集群调用，例如多集群灾备场景中，当一个集群的应用发生故障时，我们希望能够调用另一集群的同一服务来完成无感的故障切换。由于阿里云容器服务集群的网络归属于其所属地域（Region）的某一虚拟私有网络（VPC）中，因此，为了实现集群之间互相调用，我们需要将集群所属的VPC网络打通。在接下来的章节，本文将介绍打通集群网络的三种方式，分别是：PrivateLink，CEN和ASM东西向网关。
通过阿里云PrivateLink打通跨可用区网络
PrivateLink是利用阿里云的私有网络进行服务交互的一种方式。利用PrivateLink，用户可以通过私有网络打通多个VPC的网络，无需创建NAT网关（NAT Gateway）、弹性公网IP（Elastic IP）等公网出口。交互数据不会经过互联网，有更高的安全性和更好的网络质量。
但是，PrivateLink无法打通跨地域VPC之间的网络，为此，阿里云还推出了打通跨地域网络的解决方案 -- 阿里云云企业网（CEN）用于跨地域的网络打通。
通过阿里云云企业网CEN打通跨地域网络
云企业网CEN（Cloud Enterprise Network）是运行在阿里云私有全球网络上的一张高可用网络。云企业网通过转发路由器TR（Transit Router）帮助您在跨地域专有网络之间，专有网络与本地数据中心间搭建私网通信通道，为您打造一张灵活、可靠、大规模的企业级云上网络。使用云企业网，您可以不受地域限制地打通任意地域的任意VPC之间网络通信。
通过ASM东西向网关打通跨地域网络
除PrivateLink和CEN外，ASM作为集群网络基础设施，提供了一种更经济灵活的网络打通方式 -- ASM东西向网关。通过部署ASM东西向网关并将其暴露于公网，可以实现通过公网链路将集群网络打通，实现跨集群应用调用。由于ASM东西向网关通过公网打通集群间网络，相比于CEN专线打通可能存在更高的网络延迟，但相比于CEN提供了更高的性价比。用户应当综合评估业务对网络质量的综合诉求，选择适用的方案。
多集群典型场景
针对不同的业务需求，多集群部署存在多种实践，在接下来的章节中，笔者将将介绍几种典型的多集群实践。由于多集群的网络环境、依赖关系都相比于单集群场景更为复杂，因此，熟悉这些经过验证的最佳实践是相当有必要的。
隔离模式
ASM控制平面默认假设一个服务（Service）的所有端点（Endpoints）都是可达的，然而在一些场景下我们或许不希望发生跨集群访问。例如某应用存在分区服务，每个区独立部署在一个集群中，每个集群有独立的存储（数据库等）供应用消费，但集群间的流量规则和应用拓扑完全一致，希望使用统一的控制平面管理，使用这种部署模式的典型业务例如游戏。针对这种场景，ASM提供了集群流量保持功能，您可以参考ASM官网文档[1]获取流量保持功能的更多信息，或持续关注本系列的后续文章中带来的最佳实践实操。
分布式应用
一些分布式应用可能因为权限隔离、资源依赖等原因，需要部署在多个集群里，多个集群中的应用又存在交叉调用，这是一种典型的多集群部署实践，它的拓扑大致像这样。在使用这种多集群部署时，由于多个集群被同一ASM实例管理，因此，用户需要确保多集群之间的服务不发生冲突（例如集群1的default/httpbin服务和集群2的default/httpbin服务将被控制平面视为同一个服务)。
多集群灾备
跨地域或者跨可用区的多集群部署是利用多地域带来的物理隔离构建灾备体系的常见部署形态，ASM提供了跨地域负载均衡能力，利用跨地域负载均衡的跨地域故障转移功能，可以在默认情况下将流量保持在本地集群内，而当本地服务服务发生故障不可用时，自动将针对该服务的调用切换至部署于其他地域、可用区的集群中的同名服务，实现跨地域容灾。您可以参考ASM官网文档[2]获取跨级群故障切换的更多信息，或持续关注本系列的后续文章中带来的最佳实践实操。
多集群多环境部署
在一些大规模微服务(如今部分微服务系统达到了1000+Services)的开发过程中，测试环境部署往往是充满挑战的，被广泛采用的部署方式主要是以下两种：
全量单一测试环境：最简单的部署模式，所有开发者共享一套测试环境，对于给定的应用，当前环境里只能是该应用的某一个测试版本，应用开发者将环境部署为自己的版本进行测试时，其他开发者只能等待。同时，一旦某一应用的开发者部署了无法正常工作的版本，则调用链上所有其他应用开发者的测试都受到影响。
全量多套测试环境：每一个开发者单独部署一套测试环境，对于规模稍大的应用来说，这种部署方式的成本可能是不可接受的（试想为一个上千服务规模的应用做一套独立部署是多么夸张的资源浪费）。
以上两种方式都存在较为非常显著的缺陷，理想情况下，应该可以做到将对应服务开发人员的测试流量路由到其自己版本，而其他开发者则应该路由到稳定的版本，这通常需要自行实现或是借助一些Framework能力，前者有着显著的开发成本和实施成本；后者则大多有存在语言限制，对语言应用不够友好。
通过使用ASM的泳道模式则可以轻松地在多语言应用环境下，在不对应用做任何入侵的情况下，为每个开发人员建立一条独立泳道，且通过引流规则匹配对请求特征（例如用户ID、类型等）进行引流，即可实现每个开发者只在自己的泳道中部署正在开发中的应用，而调用链上的其他应用则fallback回到基线环境，极大地提升了开发环境部署的灵活程度。您可以参考ASM官网文档[3]获取流量泳道功能的更多信息，或持续关注本系列的后续文章中带来的最佳实践实操。
相关链接：
[1] ASM官网文档
[2] ASM官网文档
[3] ASM官网文档
https://help.aliyun.com/zh/asm/user-guide/traffic-swimlane/?spm=a2c4g.11186623.0.i8
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
获取关于我们的更多信息~
