はじめに:マイクロサービスアーキテクチャでは、サービス間の依存関係が複雑であり、機能のリリースが、アップグレードされて同時に起動される複数のサービスに依存する場合があります。これらのサービスの新しいバージョンが、少量のトラフィックで同時に検証できることを願っています。これは、マイクロサービスアーキテクチャのユニークなフルリンクグレースケールシーンです。ゲートウェイからバックエンドサービス全体への環境分離を構築することにより、複数の異なるバージョンを検証できます。グレースケール検証のサービス。
著者:テンスリープ
フルリンクグレースケールとは何ですか?
マイクロサービスアーキテクチャでは、サービス間の依存関係が複雑であり、機能のリリースが、アップグレードされて同時に起動される複数のサービスに依存する場合があります。これらのサービスの新しいバージョンが、少量のトラフィックで同時に検証できることを願っています。これは、マイクロサービスアーキテクチャのユニークなフルリンクグレースケールシーンです。ゲートウェイからバックエンドサービス全体への環境分離を構築することにより、複数の異なるバージョンを検証できます。グレースケール検証のサービス。
ライブチュートリアルを表示するには、以下のリンクをクリックしてください。
リリースプロセスでは、サービスのグレースケールバージョンをデプロイするだけで済みます。トラフィックがコールリンクを流れると、グレースケールトラフィックは、通過するゲートウェイ、ミドルウェア、マイクロサービスによって識別され、対応するサービスに動的に転送されます。グレースケールバージョン。以下に示すように:
上の図は、このスキームの効果をよく示しています。さまざまなバージョンのグレースケールトラフィックを表すためにさまざまな色を使用しています。マイクロサービスゲートウェイとマイクロサービス自体の両方がトラフィックを識別し、それに応じて動的な決定を行う必要があることがわかります。ガバナンスルールに。サービスバージョンが変更されると、この通話リンクの転送もリアルタイムで変更されます。マシンによって構築されたグレースケール環境と比較して、このソリューションは、マシンのコストとO&Mの人員を大幅に節約できるだけでなく、開発者がオンライントラフィックの洗練されたフルリンク制御をリアルタイムで迅速に実行するのにも役立ちます。
OpenSergo[1]トラフィックルーティング標準
Q:OpenSergoとは何ですか?
A:OpenSergoは、分散サービスアーキテクチャを対象とし、リンク全体の異種エコロジーをカバーする一連のオープンな汎用サービスガバナンス標準であり、業界のサービスガバナンスシナリオと実践に基づいた一般的なサービスガバナンス標準を形成します。OpenSergoの最大の機能は、構成/ DSL /プロトコルの統一されたセットを使用してサービスガバナンスルールを定義し、多言語の異種アーキテクチャを対象として、フルリンクのエコロジカルカバレッジを実現することです。マイクロサービスの言語がJava、Go、Node.js、その他の言語であるかどうか、標準のマイクロサービスまたはメッシュアクセスであるかどうか、ゲートウェイからマイクロサービス、データベースからキャッシュ、サービス登録の検出から構成まで、開発者は同じものを使用できますOpenSergo CRD標準構成のセットは、フレームワークと言語の違いに注意を払うことなく、各レイヤーに対して統一されたガバナンスと制御を実行し、異種のフルリンクサービスのガバナンスと制御の複雑さを軽減します
Q:フルリンクグレースケールについて学ぶ前に、なぜOpenSergoを紹介したのですか?
A:OpenSergoは、分散アーキテクチャのフルリンクサービスガバナンス仕様を実装するための統合YAML構成方法を定義しています。仕様と標準を導入する一方で、技術的な詳細の実装を理解でき、新しいコンポーネントを適用することもできます。 OpenSergo標準。
トラフィックルーティングは、その名前が示すように、特定の属性特性を持つトラフィックを指定された宛先にルーティングすることです。トラフィックルーティングは、トラフィックガバナンスの重要な部分です。開発者は、グレースケールパブリッシング、カナリアパブリッシング、ディザスタリカバリルーティング、ラベルルーティングなど、トラフィックルーティング標準に基づいてさまざまなシナリオを実装できます。
フルリンクのグレースケールの例:
トラフィックルーティングルール(v1alpha1)は、主に次の3つの部分に分かれています。
- ワークロードラベルルール(WorkloadLabelRule):ワークロードのグループに対応するラベルでラベルを付けます。このブロックは、アプリケーションまたは対応するストレージレイヤーのデータベースロード(データベース、テーブル)にラベルを付けることとして理解できます。
- トラフィックラベルルール(TrafficLabelRule):特定の属性特性を持つトラフィックに対応するラベルを付けます
- ワークロードラベルとトラフィックラベルに従って一致するルートを作成し、指定されたラベルのトラフィックを一致するワークロードにルーティングします
トラフィックをマークするには:
特定の属性特性を持つトラフィックは、対応するラベルでマークする必要があります。
假设现在需要将深圳地域的用户灰度到新版主页,测试用户 location=cn-shenzhen,cn-shenzhen 位于 location header 中:
apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficLabelRule
metadata:
name: my-traffic-label-rule
labels:
app: spring-cloud-zuul
spec:
selector:
app: spring-cloud-zuul
trafficLabel: gray
match:
- condition: "==" # 匹配表达式
type: header # 匹配属性类型
key: 'location' # 参数名
value: cn-shenzhen # 参数值
复制代码
通过上述配置,location header 为 cn-shenzhen 的 HTTP 流量,打上 gray 标,代表这个流量为灰度流量。
给 Workload 打标签:
在使用 Nacos 作为服务发现的业务系统中,一般是需要业务根据其使用的微服务框架来决定打标方式。如果 Java 应用使用的 Spring Cloud 微服务开发框架,我们可以为业务容器添加对应的环境变量来完成标签的添加操作。比如我们希望为节点添加版本灰度标,那么为业务容器添加 traffic.opensergo.io/label: gray ,这样框架向 Nacos 注册该节点时会为其添加一个 gray 标签。
对于一些复杂的 workload 打标场景(如数据库实例、缓存实例标签),我们可以利用 WorkloadLabelRule CRD 进行打标。示例:
apiVersion: traffic.opensergo.io/v1alpha1
kind: WorkloadLabelRule
metadata:
name: gray-sts-label-rule
spec:
workloadLabels: ['gray']
selector:
db: mse-demo
table: mse_demo_table_gray
复制代码
全链路灰度在数据库上的常见方案
方案一:影子库
每个单独维护一套独立的库,假设基线环境的库的名称为 mse-demo,那么 gray 环境的流量可以映射到 mse-demo-gray 的库中,我们在同一个实例上建立对应环境流量的影子库,我们在业务中维护着各个库连接的连接池,根据不同的流量标选择对应的影子库的连接去访问,以此达到数据和基线环境库隔离的效果,从而避免了灰度环境流量产生的数据对基线环境库造成污染。
方案二:影子表
类似影子库方案,针对影子表方案,是在同一个实例上的同一个数据库上建立对应的影子表。我们在执行 SQL 的过程中,对灰度流量的 SQL 进行解析与修改,实现不同环境流量的 SQL 分别访问对应的表,假设基线环境的表的名称为 mse_demo_table,那么 gray 环境的流量可以映射到 mse_demo_table_gray 的表中。从而实现灰度数据和基线环境数据表隔离的效果。
MSE[2] 数据库全链路灰度能力
MSE 提供了一种数据隔离的方案,您可以在不需要修改任何业务代码的情况下,实现数据库层面全链路灰度。下面介绍 MSE 基于 Mysql 数据存储通过影子表的方案实现全链路灰度的能力。
前提条件
- 应用接入 MSE
- 部署 Demo 应用
在阿里云容器服务中部署 A、B、C 三个应用,每个应用分别部署⼀个 base 版本和⼀个 gray 版本;并部署⼀个 Nacos Server 应用,用于实现服务发现。具体可参考教程完成应用部署:部署 Demo 应用程序[3]。
Demo 应用介绍,本 Demo 中的 C 应用会向数据库执行如下语句:
CREATE TABLE `mse_demo_table` (
`id` int NOT NULL AUTO_INCREMENT,
`location` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3
复制代码
其中涉及到的数据库建表语句:
CREATE TABLE `mse_demo_table` (
`id` int NOT NULL AUTO_INCREMENT,
`location` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3
复制代码
-
创建影子表,我们 Demo涉及到的数据库表有 mse_demo_table,因为我们需要创建灰度 gray 环境,因此我们需要提前创建 mse_demo_table_gray 表。
CREATE TABLE
mse_demo_table_gray
(id
int NOT NULL AUTO_INCREMENT,location
varchar(255) DEFAULT NULL, PRIMARY KEY (id
) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3 ;
第一步:配置全链路灰度规则
您需要配置完成 MSE 的全链路发布,具体操作细节可参考教程:配置全链路灰度[4]。
创建如下泳道规则:
第二步:配置数据库全链路灰度
- 我们需要配置以下环境变量来额外开启/配置数据库的全链路灰度能力
第三步:结果验证
我们发起灰度请求,发现流量请求均访问灰度环境:
curl -H "location: cn-shenzhen" http://106.14.XX.XX/a
Agray[172.18.XX.XX] -> Bgray[172.18.XX.XX] -> Cgray[172.18.XX.XX]%
复制代码
我们通过如下 SQL 查询影子表:
SELECT * FROM `mse_demo_table_gray`
复制代码
发现灰度环境的数据都插入至影子表。
不仅仅是全链路灰度
目前为止 MSE 服务治理全链路灰度能力已经支持了云原生网关、ALB、APISIX、Apache Dubbo、Spring Cloud、RocketMQ 以及数据库。在数据库层面我们通过影子表的方式实现了数据层面的流量隔离,下一步我们会将该能力进行进一步产品化,全链路灰度也会支持缓存层面的能力。
服务治理是微服务改造深入到一定阶段之后的必经之路,在这个过程中我们不断有新的问题出现。
- 除了全链路灰度,服务治理还有没其他能力?
- 服务治理能力有没一个标准的定义,服务治理能力包含哪些?
- 多语言场景下,有无全链路的最佳实践或者标准?
- 异构微服务如何可以统一治理?
当我们在探索服务治理的过程中,我们在对接其他微服务的时候,我们发现治理体系不同造成的困扰是巨大的,打通两套甚者是多套治理体系的成本也是巨大的。为此我们提出了 OpenSergo 项目。OpenSergo 要解决的是不同框架、不同语言在微服务治理上的概念碎片化、无法互通的问题。
OpenSergo 社区也在联合各个社区进行进一步的合作,社区来一起讨论与定义统一的服务治理标准。当前社区也在联合 bilibili、字节跳动等企业一起共建标准,也欢迎感兴趣的开发者、社区与企业一起加入到 OpenSergo 服务治理标准共建中。欢迎大家加入 OpenSergo 社区交流群(钉钉群)进行讨论:34826335
参考链接:
[1]
OpenSergo:
[2] MSE 微服务引擎:
[3] 部署Demo 应用程序:
[4] 配置全链路灰度:
MSE 注册配置中心专业版首购享 9 折优惠,MSE 云原生网关预付费全规格享 9 折优惠。点击此处,即享优惠!
原文链接:click.aliyun.com/m/100034974…
この記事はAlibabaCloudのオリジナルコンテンツであり、許可なく複製することはできません。