共计 3378 个字符，预计需要花费 9 分钟才能阅读完成。
简介：微服务场景下，全链路灰度作为一种低成本的新性能验证形式，失去了越来越宽泛的利用。除了微服务实例和流量的灰度，微服务利用中的配置项也应该具备相应的灰度能力，以应答灰度利用对非凡配置的诉求。为什么须要配置标签推送从全链路灰度谈起在微服务场景中，利用的灰度公布迎来了新的挑战。不同于单体架构中将利用整体打包即可公布测试版本，微服务利用往往由多个服务组合而成。这些服务通常由不同的团队负责，独立进行开发。一个新性能通常只波及到局部服务，在测试新个性时，咱们只须要对这部分服务进行公布即可。为了让微服务利用失常运行，还须要设计一种计划，让灰度流量也能失常通过其余不须要公布的服务。这一性能通常有物理环境隔离和逻辑环境隔离两种解决方案。前者须要为每套灰度环境都搭建一套网络隔离、资源独立的环境，为了利用能失常运行，还须要在环境中为未被灰度到的服务、各种中间件等做冗余公布，如图所示：
物理环境隔离这一计划存在着大量的机器资源节约。因而业界广泛采纳后者，即逻辑环境隔离的形式做为全链路灰度的解决方案。只需部署灰度服务，通过调用链路上的流量管制使得灰度流量能在灰度环境和正式环境间流转，实现灰度微服务利用的失常运行，帮忙业务方进行新性能验证。如图所示：
配置灰度的利用场景在许多业务场景中都可能波及到配置灰度能力的利用，上面是几个典型场景。金丝雀公布金丝雀公布曾经在业界宽泛落地，是新版本公布的罕用伎俩。金丝雀发布会对流量进行比例分隔，一开始为新版本的实例调配较小比例的流量，通过一段时间的运行，确认新版本运行失常后再逐步提高所调配流量的比例，直到最终全量切流。通过这种形式做公布能够在新版本呈现问题时管制影响面，进步零碎的稳定性。金丝雀公布通常通过流量染色和机器打标来实现。新版本的机器被打上金丝雀版本标记，同时让局部流量携带上金丝雀版本标记，最终还是演变成全链路灰度的解决方案。金丝雀版本的利用中的配置项可能须要应用和旧版本中不同的配置值，这就须要配置灰度的能力。新性能上线在改变波及较大的性能上线时，往往会通过逐渐放量的形式来验证性能的稳定性。一种典型的放量形式就是白名单，即配置在白名单中的用户 / 设施能够应用新性能，未在白名单中的用户依然应用旧版本。在线上运行一段时间后收集白名单用户的反馈，对性能做优化的同时逐渐减少白名单中的用户 / 设施数，等性能达到最终的稳固状态后再全量公布。来自于白名单中的用户 / 设施会被打上非凡的标记，被路由到灰度环境中。如果新性能中的配置须要应用不同于旧版本中的配置值，就须要同步用到配置灰度。数据库迁徙数据库迁徙也是业务倒退中的常见问题。随着业务的快速增长，原有的数据库可能在容量 / 性能上都不再能满足将来的业务须要，这时就须要做数据库迁徙。为了保障迁徙过程的稳定性，迁徙通常是渐进式的，这个过程中会存在局部流量写新库，局部流量写老库，待迁徙齐全实现后再将所有流量切到新库上。迁徙过程中咱们能够通过流量染色配合配置灰度来实现对不同数据库的操作。问题及解决方案微服务利用通常会引入配置核心做配置管理，其提供动静的配置推送能力使得利用无需重启就能够动静地扭转运行逻辑。然而配置核心的治理维度仅仅是配置项自身，并不能感知到前来获取配置的服务实例的环境信息，即无奈辨别申请配置的是正式环境的实例还是灰度环境的实例。在这种背景下，如果某项配置在正式环境和灰度环境中须要应用不同值，它们在配置核心中必须作为不同的配置项，咱们可能须要写出这样的代码：…
if (env == “gray”) {
cfg = getConfig('cfg1');} else {
cfg = getConfig('cfg2');}
… 如果有多个配置项在灰度环境中存在不同的配置值，这样的代码还须要反复屡次。更极其的场景下，如果在测试的灰度环境还有多套，每套环境中的配置值都不同，负责获取配置项的代码还会更简单。此外，一套灰度环境中往往存在多个服务，每个服务都须要独立保护一套相似的代码。最终的解决方案如图所示，同一配置项在不同环境中应用的配置值须要在用户利用中被动进行辨别。
究其原因，还是来自于配置核心无奈感知服务实例的环境信息，使得咱们必须在代码中代替配置核心行使这一工作，从而导致了环境信息对业务代码产生了侵入。只管咱们能够通过对获取配置的代码做一些封装来升高业务代码的应用复杂度，但只有配置核心无奈感知服务实例的环境信息这一事实存在，这种环境信息对业务代码的侵入性就无奈防止。性能介绍 MSE 的新上线的配置标签推送性能将配置管理场景下的环境信息的感知下沉到平台侧，由 Agent 负责。用户只需接入 MSE，就可轻松在全链路灰度场景中应用配置推送能力，免去业务代码中繁琐的环境信息检测逻辑。如图所示：
配置标签推送提供的性能包含：标签维度的配置管理在配置列表页中能够查看利用中的各种配置项。目前 MSE 反对对三类配置进行采集：应用 SDK 提供的注解 @Switch 标记的配置类应用 Spring 的注解 @Value 标记的配置项应用 SpringBoot 的注解 @ConfigurationProperties 标记的配置类每个配置项下会展现所有服务实例的配置值，用户能够通过标签名直观地看到不同实例所处的灰度环境，还能够查看不同灰度环境下的配置值散布标签维度的利用配置推送能力通过“按标签推送”，用户能够便捷地为指定灰度环境中的所有服务实例推送长久化的新配置值。长久化意味着即便利用重启，针对该环境的配置项也不会失落。配置场景下的实例动静打标除了在利用启动时通过 MSE 的打标形式为服务实例设置标签，用户能够在 MSE 控制台动静地为服务实例新增 / 删除标签，以适配不同灰度环境下的配置项治理。围绕整个配置标签推送流程的溯源能力 MSE 为标签推送提供了全流程的溯源能力，包含实例标签变动记录，标签推送记录，帮忙用户便捷地排查标签推送流程中的问题。配置标签推送实际接下来，咱们通过实际来演示配置标签推送的应用流程，只需简略的三步即可实现。筹备工作将利用接入 MSE 微服务治理进入 MSE 控制台，抉择地区进入 治理核心 > 利用治理，进入刚刚接入的利用 Step 1：新增标签配置标签推送的第一步是为服务实例设置标签。服务实例的标签能够在启动时通过 -Dalicloud.service.tag 设置，同时也能够在 MSE 控制台动静设置。接下来咱们演示为服务实例动静打标的过程。抉择 利用配置 > 标签列表，这里会展现以后利用下所有的服务实例。点击左上角的“新增标签”按钮，在弹出的节点打标窗口中咱们能够抉择一批服务实例进行打标。用户能够通过节点 IP 来筛选须要打标的实例。除了按节点 IP 筛选，MSE 提供了按主机名称筛选服务实例的能力。选中须要打标的机器后，输出标签的名称，点击“新增标签”即可实现机器打标。
Step 2：按标签推送实现机器打标后，咱们能够为指定的标签推送配置值。回到 利用配置 > 配置列表，抉择“customName”配置项，点击“按标签推送”。在弹出的推送窗口中，咱们抉择须要推送的标签，并设置待推送的配置值，点击“下一步：值比照”，能够看到新老配置项的差别。之后点击“标签推送”，实现配置下发。
能够看到配置项曾经被胜利推送到了两个带有“gray”标签的机器实例上。之后，咱们对“gray2”标签也执行同样的操作，推送“testGray2”配置值。针对标签的配置值推送都是长久化的。用户只须要在管制台上操作一次，之后指定标签的服务实例重启时 MSE 会通过 Agent 将长久化的配置值下发到利用。Step 3：查看配置值散布回到 利用配置 > 配置列表，抉择“customName”配置项，咱们能够看到刚刚为标签“gray”和“gray2”推送的两个配置值都曾经失效。点击“值散布”。在弹出的窗口中能够看到该配置项的配置值在所有机器实例上的散布，也能看到其在不同标签下的长久化值。
结束语本文介绍了全链路灰度场景给配置管理带来的问题，介绍了 MSE 针对这一场景的解决方案，并通过实际的形式展现了配置标签推送的应用流程。后续，MSE 还会针对配置治理做更多的摸索，帮忙用户更好地解决微服务配置管理中的难题，进步微服务利用的稳定性。原文链接：https://click.aliyun.com/m/10… 本文为阿里云原创内容，未经容许不得转载。
