Apache APISIX 是一个开源的云原生 API 网关,作为 API 网关,它兼具动态、实时、高性能等特点,提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。你可以使用 Apache APISIX 来处理传统的南北向流量,以及服务间的东西向流量,也可以当做 K8s Ingress controller 来使用。得益于 APISIX 全动态的设计,可以随时进行配置更改并且均不需要重启服务。
阿里云微服务引擎 MSE 提供了非常易用的流量泳道能力,基于 Java Agent 字节码增强的技术实现,无缝支持市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本,通过极简的配置与无代码侵入的方式,来实现全链路灰度,释放基于 APISIX 的微服务架构的新价值。
全链路灰度方案简介
相关概念
- 泳道:为相同版本应用定义的一套隔离环境。只有满足了流控路由规则的请求流量才会路由到对应泳道里的打标应用。一个应用可以属于多个泳道,一个泳道可以包含多个应用,应用和泳道是多对多的关系。
- 基线环境:未打标的应用属于基线稳定版本的应用,即稳定的线上环境。
- 流量回退:泳道中所部署的服务数量并非要求与基线环境完全一致,当泳道中并不存在调用链中所依赖的其他服务时,流量需要回退至基线环境,进一步在必要的时候路由回对应标签的泳道。
- 泳道组:泳道的集合。泳道组的作用主要是为了区分不同团队或不同场景。
业务场景
基于流量泳道的全链路灰度能力,适用于以下业务场景:
- 日常开发/项目/测试环境隔离;
- 全链路灰度发布;
- 高可用同机房优先路由;
- 全链路压测。
技术原理
如何在实际业务场景中去快速落地全链路灰度呢?目前主要有两种解决方案,基于物理环境隔离和基于逻辑环境隔离。
物理环境隔离
物理环境隔离,其实就是通过增加机器的方式来搭建真正意义上的流量隔离。
该方案需要为灰度的服务搭建一套网络隔离、资源独立的环境,并在其中部署服务的灰度版本。由于与正式环境隔离,正式环境中的其他服务无法访问到需要灰度的服务,所以需要在灰度环境中冗余部署 这些线上服务,以便整个调用链路正常进行流量转发。此外,注册中心等一些其他依赖的中间件组件也需要冗余部署在灰度环境中,保证微服务之间的可见性问题,确保获取的节点 IP 地址只属于当前的网络环境。
该方案一般用于企业的测试、预开发环境的搭建,对于线上灰度发布引流的场景来说其灵活性不够。并且微服务多版本的存在在微服务架构中是非常常见的,需要为这些业务场景采用堆机器的方式来维护多套灰度环境。如果应用数目很小,该方式是可以被受的;如果您的应用数目过多的情况下,会造成运维、机器成本过大,成本和代价远超收益。
逻辑环境隔离
另一种方案是构建逻辑上的环境隔离,我们只需部署服务的灰度版本,流量在调用链路上流转时,由经过的网关、各个中间件以及各个微服务来识别灰度流量,并动态转发至对应服务的灰度版本。如下图:
上图可以很好展示这种方案的效果,我们用不同的颜色来表示不同版本的灰度流量,可以看出无论是微服务网关还是微服务本身都需要识别流量,根据治理规则做出动态决策。当服务版