企业网站哪家做得好/站长工具搜索

作者：聂子雄 华为云高级软件工程师

摘要：目前应用上云已成为趋势，用户也对应用在云上的高可靠方案有更高追求，目前同城双活场景作为应用高可靠方案中的一种常见实践方案，对微服务流量提出了数据中心亲和性的要求，目前通过Sermant的标签路由能力可以实现此要求并能快速助力同城双活方案的落地。

1.  背景

1.1 应用高可靠方案的演进

目前，应用上云已经成为了一种趋势，在这个过程中，用户对于云能够提供的高可靠能力要求也越来越高，目前云上的应用高可靠方案的演进可以分为以下几个阶段：

1. 同城灾备：同城灾备是指生产中心和灾备中心位于同一个城市。当生产中心发生灾难时，可以将业务迅速切换到灾备中心。数据同步是同城灾备方案的核心，备用数据中心必须同步主数据中心的数据，以确保在主数据中心发生灾害或故障时，备用数据中心可以快速接管业务。

   2. 同城双活：同城双活是指同城内两个数据中心都部署了相同业务，访问流量会按照一定比例分发往两个数据中心，当其中任意一个数据中心出现故障，另外一个数据中心仍然能够正常对外提供服务。

3. 两地三中心：两地三中心的容灾方案其实是同时结合了前两者方案的优点，也即同城双活+异地灾备。同城两个数据中心业务保持双活部署，异地一般以冷备的方式部署并同步主数据中心的数据。

4. 异地多活：异地多活实际上采用的是单元化容灾方案，单元化容灾方案是一种将系统分为多个单元，每个单元都可以独立运行和故障恢复的容灾方案。它可以提高系统的可用性和可靠性，减少系统故障对整个系统的影响。

可以观察到整个应用高可用方案演进的过程中，方案提供的可靠性是逐步提升的，但是相应的成本也会相对升高，因此不同的方案有其适用的场景，其中同城双活和两地三中心方案在可靠性以及成本两方面做到了相对均衡的程度，也是目前国内尤其是金融行业采用较多的方案。同时，两地三中心的容灾方案实际上更多是同城双活以及异地灾备方案的组合形态，因此本文将重点探讨同城双活的场景以及Sermant在这个场景中扮演的角色。

1.2 同城双活对微服务流量的要求

在同城双活场景下，业务应用会按照相同的方式部署在同城的两个数据中心，从接入层进来的访问流量会以一定比例的方式分别流水到两个数据中心的业务应用集群，具体比例的大小是根据两个数据中心规划的集群资源来评估的。此外，同城两个数据中心之间的访问时延一般会明显高于数据中心内部的访问时延。

正常情况下，虽然两个数据中心都部署了相同的微服务应用，但为了降低访问时延以及方便流量管理的需要，方案会要求每个数据中心的微服务应用之间的访问流量全都要在本数据中心闭环，不能随意进行跨数据中心的调用。

故障场景下，例如某个数据中心的部分微服务实例出现了故障，这时候微服务的流量允许进行跨数据中心自动容灾切换，流量可以自动流入可以正常对外提供的微服务应用实例上，以保持应用对外服务的连续性。

因此微服务流量在同城双活的场景下需要具有数据中心亲和性，保障流量优先在数据中心闭环同时在面对故障时也能自动切换。

2. 基于标签路由实现微服务流量的数据中心亲和方案

2.1 整体方案介绍

针对同城双活容灾场景对微服务流量的要求，基于Sermant的标签路由插件以及华为云CSE注册配置中心，我们给出了如下的解决方案：

DC1与DC2两个数据中心分别部署一套应用集群以及CSE注册配置中心，每个数据中心的微服务应用实例在启动时提前挂载好Sermant agent，由Sermant agent代替应用实例向所在数据中心的CSE注册配置中心注册微服务实例信息。此外，两边的注册配置中心会进行数据的双向同步，保证DC1和DC2中的微服务应用能够相互发现。

正常情况下，如下图所示，流量以一定的比例分别经过网关留到了对应数据中心的业务集群，在业务集群内部，请求都是由每个微服务实例上面挂载的Sermant Agent进行接收与转发，Sermant Agent控制着所在业务集群的流量都在内部流动，跨数据中心的微服务访问会被发起者实例上面的Sermant Agent所禁止。

故障情况下，若某个数据中心的部分微服务实例存在异常的情况，Sermant agent会自动完成流量切换到另一个数据中心的正常实例上。如下图所示，例如DC1中的ServiceB实例出现故障，此时DC1中ServiceA的流量会经过Sermant agent自动切换到DC2的ServiceB'实例上，随后流量又会经过Sermant agent转发到DC1的正常的ServiceC实例上。

当然，还有另外一种故障场景，就是存在一整个数据中心都不可用，这时候其只需要把这种场景当成是单个数据中心对外服务的情况即可，正常数据中心的流量仍然在所在数据中心闭环，异常数据中心的流量可以通过自动或者手动的方式将流量全部切到正常的数据中心上。

2.2 Sermant的标签路由插件在方案中的具体机制

在整个方案中，可以看到Sermant在其中扮演着非常重要的角色，微服务实例的流量接收以及转发全都由Sermant agent来控制，在Sermant agent上，有着一个非常重要的插件——标签路由插件，通过在插件上定义相应的路由策略，Sermant agent即可让微服务实例的流量具备数据中心亲和的能力。

使用者可以在每个微服务实例启动的时候手动或者通过流水线自动给微服务实例打上和数据中心有关的标签，因此每个微服务实例在运行的时候会自动带有数据中心的属性。这时候标签路由插件可以通过服务提供者配置路由规则，将带有DC1属性的微服务提供者实例划分为一组，将带有DC2属性的微服务提供者实例划分为另外一组，约束流量只能在指定分组中流转，下图是标签路由插件工作的示意图：

路由插件会根据配置中心下发的动态路由规则去匹配入口流量，若标签符合规则要求，则顺利通过进行后续处理，否则由fallback路由规则进行流量的处理。

2.3 如何接入部署Sermant

Sermant 是基于Java字节码增强技术的云原生无代理服务网格，通过 JavaAgent 对宿主应用进行非侵入式增强，因此在使用的时候无需额外启动进程来运行Sermant agent，只需要在启动应用实例时加入agent的挂载命令即可。标签路由插件需要在Sermant agent中配置服务元数据（版本号、其它元数据），可参考Sermant-agent使用手册。微服务实例的标签信息在服务注册时会携带，路由筛选过程需利用已经配置好的标签。在同城高可用的情况下，标签里面需要携带数据中心的信息。

可以看到Semant agent存在以下特点：

1. 非侵入性，无需修改业务代码即可使用。
2. 适配主流的应用开发框架。
3. 路由规则可以动态调整，只需要通过配置中心统一下发规则即可。

3. 总结

目前，随着应用上云的趋势，业务人员对于故障的认知发生了变化，从被动响应到主动引入故障，到认为故障就是常态，系统架构需要适应故障，因此对云上的业务高可用方案要求也随之提升，同城双活方案是目前用户采用比较多的容灾方案。在这个方案中，也对微服务应用之间的访问流量提出了相应要求，为了保证业务的就近访问能力，微服务之间的流量需要能做到优先本中心访问，对于故障情况也要求能做到流量自动切换到正常实例上。为了解决这个问题，考虑到Sermant非侵入，易部署以及多场景兼容等特点，华为云基于Sermant的标签路由能力实现了微服务流量的数据中心亲和性，助力同城双活方案的实际落地。

---

Sermant作为专注于服务治理领域的字节码增强框架，致力于提供高性能、可扩展、易接入、功能丰富的服务治理体验，并会在每个版本中做好性能、功能、体验的看护，广泛欢迎大家的加入。

• Sermant 官网：https://sermant.io
• GitHub 仓库地址：GitHub - sermant-io/Sermant: A Cloud-Native Proxyless Service Mesh based on Java Bytecode Enhancement Technology
• 扫码加入Sermant 社区交流群