乐趣区

关于阿里云:阿里云-MSE-基于-Apache-APISIX-的全链路灰度方案实践

jiezi

Apache APISIX 是一个开源的云原生 API 网关，作为 API 网关，它兼具动静、实时、高性能等特点，提供了负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。你能够应用 Apache APISIX 来解决传统的南北向流量，以及服务间的东西向流量，也能够当做 K8s Ingress controller 来应用。得益于 APISIX 全动静的设计，能够随时进行配置更改并且均不须要重启服务。

阿里云微服务引擎 MSE 提供了十分易用的流量泳道能力，基于 Java Agent 字节码加强的技术实现，无缝反对市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本，通过极简的配置与无代码侵入的形式，来实现全链路灰度，开释基于 APISIX 的微服务架构的新价值。

全链路灰度计划简介

相干概念

  • 泳道：为雷同版本利用定义的一套隔离环境。只有满足了流控路由规定的申请流量才会路由到对应泳道里的打标利用。一个利用能够属于多个泳道，一个泳道能够蕴含多个利用，利用和泳道是多对多的关系。
  • 基线环境：未打标的利用属于基线稳固版本的利用，即稳固的线上环境。
  • 流量回退：泳道中所部署的服务数量并非要求与基线环境完全一致，当泳道中并不存在调用链中所依赖的其余服务时，流量须要回退至基线环境，进一步在必要的时候路由回对应标签的泳道。
  • 泳道组：泳道的汇合。泳道组的作用次要是为了辨别不同团队或不同场景。

业务场景

基于流量泳道的全链路灰度能力，实用于以下业务场景：

  • 日常开发 / 我的项目 / 测试环境隔离；
  • 全链路灰度公布；
  • 高可用同机房优先路由；
  • 全链路压测。

技术原理

如何在理论业务场景中去疾速落地全链路灰度呢？目前次要有两种解决方案，基于物理环境隔离和基于逻辑环境隔离。

物理环境隔离

物理环境隔离，其实就是通过减少机器的形式来搭建真正意义上的流量隔离。

该计划须要为灰度的服务搭建一套网络隔离、资源独立的环境，并在其中部署服务的灰度版本。因为与正式环境隔离，正式环境中的其余服务无法访问到须要灰度的服务，所以须要在灰度环境中冗余部署 这些线上服务，以便整个调用链路失常进行流量转发。此外，注册核心等一些其余依赖的中间件组件也须要冗余部署在灰度环境中，保障微服务之间的可见性问题，确保获取的节点 IP 地址只属于以后的网络环境。

该计划个别用于企业的测试、预开发环境的搭建，对于线上灰度公布引流的场景来说其灵活性不够。并且微服务多版本的存在在微服务架构中是十分常见的，须要为这些业务场景采纳堆机器的形式来保护多套灰度环境。如果利用数目很小，该形式是能够被受的；如果您的利用数目过多的状况下，会造成运维、机器老本过大，老本和代价远超收益。

逻辑环境隔离

另一种计划是构建逻辑上的环境隔离，咱们只需部署服务的灰度版本，流量在调用链路上流转时，由通过的网关、各个中间件以及各个微服务来辨认灰度流量，并动静转发至对应服务的灰度版本。如下图：

上图能够很好展现这种计划的成果，咱们用不同的色彩来示意不同版本的灰度流量，能够看出无论是微服务网关还是微服务自身都须要辨认流量，依据治理规定做出动静决策。当服务版本发生变化时，这个调用链路的转发也会实时扭转。相比于利用机器搭建的灰度环境，这种计划不仅能够节俭大量的机器成 本和运维人力，而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。

基于 Apache APISIX 全链路灰度产品实际

全链路灰度是微服务最外围的性能之一，也是云上用户在微服务化深刻过程中必须具备的性能。全链路灰度因为波及到的技术和场景泛滥，如果企业一一进行自我实现，须要破费大量人力老本对其进行扩大与运维。

MSE 服务治理提供了残缺的产品化的全链路灰度解决方案，笼罩 RPC、MQ、可观测性等绝大多数场 景。只有架构是基于 Spring Cloud 或者 Dubbo 框架，利用无需降级或代码改变，即可实现企业级全链路灰度性能。

应用前提

第一步：装置 APISIX 相干组件

  1. 装置 APISIX、apisix-ingress-controller、etcd 等组件。
helm repo add apisix https://charts.apiseven.com
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
kubectl create ns ingress-apisix
helm install apisix apisix/apisix \
  --set gateway.type=LoadBalancer \
  --set ingress-controller.enabled=true \
  --set etcd.persistence.storageClass="alicloud-disk-ssd" \
  --set etcd.persistence.size="20Gi" \
  --namespace ingress-apisix \
  --set ingress-controller.config.apisix.serviceNamespace=ingress-apisix
kubectl get service --namespace ingress-apisix

在 ingress-apisix 命名空间下能够看到无状态的 APISIX 和 apisix-ingress-controller 利用、以及有状态的 etcd 利用。

  1. 应用 Helm 装置 APISIX Dashboard。

    helm repo add apisix https://charts.apiseven.com
helm repo update
helm install apisix-dashboard apisix/apisix-dashboard --namespace
ingress-apisix
  2. 装置实现后，能够绑定一个 SLB。

  3. 通过 {slb-ip}:9000 拜访 APISIX Dashboard。

    第二步：开启微服务治理

    这一步骤中，须要开明 MSE 微服务治理、装置 MSE 服务治理组件（ack-onepilot）并为利用开启微服务治理。具体操作信息可参考阿里云官网教程。

    第三步：部署 Demo 应用程序

    在阿里云容器服务中部署 A、B、C 三个利用，每个利用别离部署⼀个base 版本和⼀个gray 版本；并部署⼀个 Nacos Server 利用，用于实现服务发现。具体可参考此教程实现利用部署：部署 Demo 应用程序。部署实现后，你能够通过 APISIX Dashboard 为利用配置 Service 进行上游配置。

    利用场景一：按域名进行路由

    在局部场景下，能够通过不同的域名来辨别线上基线环境和灰度环境。灰度环境有独自的域名能够配置，假如咱们通过拜访 www.gray.com 来申请灰度环境，拜访 www.base.com 走基线环境。

    调用链路 Ingress-nginx -> A -> B -> C，其中 A 能够是一个 spring-boot 的利用。

    配置 APISIX 路由规定

    在 APISIX Dashboard 抉择路由并单击创立。匹配条件中域名、申请门路抉择 /*，抉择对应的上游。别离配置如下路由：

  4. 当 host 为 www.base.com 时，路由到 id 为 401152455435354748 所对应的上游，即 spring-cloud-a-svc；

  5. 当 host为 www.gray.com 时，路由到 id 为 401163331936715388 所对应的上游，即 spring-cloud-a-gray-svc。
    而后进行 base 对应的路由配置：

    {
  "uri": "/*",
  "name": "spring-cloud-a",
  "methods": [
 "GET",
 "POST",
 "PUT",
 "DELETE",
 "PATCH",
 "HEAD",
 "OPTIONS",
 "CONNECT",
 "TRACE"
  ],
  "host": "www.base.com",
  "upstream_id": "401152455435354748",
  "labels": {"API_VERSION": "0.0.1"},
  "status": 1
}

    进行 gray 对应的路由配置：

    {
  "uri": "/*",
  "name": "spring-cloud-a-gray",
  "priority": 1,
  "methods": [
 "GET",
 "POST",
 "PUT",
 "DELETE",
 "PATCH",
 "HEAD",
 "OPTIONS",
 "CONNECT",
 "TRACE"
  ],
  "host": "www.gray.com",
  "upstream_id": "401163331936715388",
  "labels": {"API_VERSION": "0.0.1"},
  "status": 1
}

    配置 MSE 全链路灰度

    你须要配置实现 MSE 的全链路公布，具体操作细节可参考此教程：配置全链路灰度。

    后果验证

    拜访 www.base.com 路由到 A 利用的 base 版本：

    curl -H"Host:www.base.com" http://47.97.253.177/a
A[172.18.144.15] -> B[172.18.144.125] -> C[172.18.144.90]%

    拜访 www.gray.com 路由到 A 利用的 gray 版本：

    curl -H"Host:www.gray.com" http://47.97.253.177/a
Agray[172.18.144.16] -> Bgray[172.18.144.57] -> Cgray[172.18.144.157]%

    利用场景二：按指定申请参数进行路由

    有些客户端无奈改写域名，心愿能拜访 www.demo.com 通过传入不同的参数来路由到灰度环境。例如下图中，通过 env=gray 这个申请参数，来拜访灰度环境。

    调用链路 Ingress-APISIX -> A -> B -> C，其中 A 能够是一个 spring-boot 的利用。

    配置 APISIX 路由规定

    在 APISIX Dashboard 抉择路由并单击创立。匹配条件中新建高级匹配规定、申请门路抉择 /*，抉择对应的上游。别离配置如下路由：

  6. 当 host 为 www.demo.com，申请参数 env=gray 时，路由优先匹配 id 为 401163331936715388 所对应的上游，即 spring-cloud-a-gray-svc；

  7. 当 host 为 www.demo.com 时，路由经会匹配 id 为 401152455435354748 所对应的上游，即 spring-cloud-a-svc。
    而后进行 base 对应的路由配置：

    {
  "uri": "/*",
  "name": "spring-cloud-a",
  "methods": [
 "GET",
 "POST",
 "PUT",
 "DELETE",
 "PATCH",
 "HEAD",
 "OPTIONS",
 "CONNECT",
 "TRACE"
  ],
  "host": "www.demo.com",
  "upstream_id": "401152455435354748",
  "labels": {"API_VERSION": "0.0.1"},
  "status": 1
}

    进行 gray 对应的路由配置，如下图所示：

    {
  "uri": "/*",
  "name": "spring-cloud-a-gray",
  "priority": 1,
  "methods": [
 "GET",
 "POST",
 "PUT",
 "DELETE",
 "PATCH",
 "HEAD",
 "OPTIONS",
 "CONNECT",
 "TRACE"
  ],
  "host": "www.demo.com",
  "vars": [
 [
   "arg_env",
   "==",
   "gray"
 ]
  ],
  "upstream_id": "401163331936715388",
  "labels": {"API_VERSION": "0.0.1"},
  "status": 1
}

    配置 MSE 全链路灰度

    配置 MSE 全链路灰度步骤与 应用 场景 一的内容统一。

    后果验证

    此时，拜访 www.demo.com 路由到基线环境：

    curl -H"Host:www.demo.com" http://47.97.253.177/a
A[172.18.144.15] -> B[172.18.144.125] -> C[172.18.144.90]%

    此时，拜访 www.demo.com 同时 env=gray 时路由到灰度环境：

    curl -H"Host:www.demo.com" http://47.97.253.177/a?env=gray
Agray[172.18.144.16] -> Bgray[172.18.144.57] -> Cgray[172.18.144.157]%

    留神：其中 47.97.253.177 为 APISIX 的公网 IP。

    总结

    基于 Apache APISIX 灵便的路由能力，配合 MSE 全链路灰度能力，能够疾速实现企业级的全链路灰度的能力。
    APSIX 反对依照 Header、Cookie、Params、域名等多种形式进行路由，只须要在网关侧依据需要将流量路由至不同的“泳道”环境后，流量在对应标签的“泳道”中主动闭环，当泳道中并不存在调用链中所依赖的其余服务时，流量须要回退至基线环境，进一步在必要的时候路由回对应标签的泳道。

退出移动版