腾讯云微服务平台 TSF 异地多活单元化能力重磅升级

腾讯云中间件团队

发布于 2023-09-15 13:50:45

4160

发布于 2023-09-15 13:50:45

文章被收录于专栏：腾讯云中间件的专栏腾讯云中间件的专栏

导语

2023腾讯全球数字生态大会已于9月7-8日完美落幕，40+专场活动展示了腾讯最新的前沿技术、核心产品、解决方案。

微服务与消息队列专场，腾讯云微服务平台 TSF 产品经理张桢带来了《腾讯云微服务平台 TSF 异地多活单元化能力重磅升级》的精彩演讲。本篇文章详细回顾了腾讯云微服务单元化最佳实践。

单元化架构的概述

什么是单元化

从目前的服务化架构看起，传统的架构下服务是分层的，每一层使用不同的分区算法，每一层都有不同数量的节点，上层节点随机选择下层节点。这种不确定性，就会导致上层节点访问下层节点时有可能跨区或者跨地域。而跨区跨地域的调用代价是很高的，不仅要解决时延的问题，还要保证数据同步，这两点在技术实现上都具有很大的挑战性。

那换一个思路，事先设计好调用的路径，让请求沿着规划好的路径进行调用，这样的设计路径就可以解决以上的挑战。单元化架构的出现，就是遵循这样的设计，在单元化架构下，接入层、服务层、数据层使用相同的分区算法，实现计算资源与数据资源进行逻辑上的绑定，最终形成一个个标准化的处理单元。

单元的特征与类型

了解了什么是单元化，接下来再看下单元的特征与类型。

单元的特征

每个单元都包括一组计算资源和一组数据资源，并使用相同的规则进行逻辑关联，比如他们都使用相同的标签。
根据系统业务的规模不同，一个系统可能会规划多个单元，常见的可能会有 4-12 个，甚至更多。
原则上一个单元内部只会有一组数据资源。

单元的类型

单元的类型原则上是按照单元内承载业务的不同来分类的，比如用于承载入口流量的为网关或接入单元，处理业务的就叫做业务单元。这里面能进行单元化拆分，拥有自己的数据，能完成所有业务，而不需要依赖其他业务的叫做标准业务单元，不能进行拆分并且读多写少的业务就叫做本地技术单元。另外，在整个系统中，一般都会有一些配置型的业务，他们被很多单元依赖，也不能进行拆分，这种情况下，就把他们放在全局单元中。

由此可以看出，如果我们想要使用单元化架构，并不是一件特别轻松的事情，需要进行一系列的架构规划与业务改造。

那么，实现单元化能带来什么好处呢？这就要说到单元化的价值了。

单元化的价值

一般来说，当业务规模逐渐扩大，架构复杂性越来越高时，数据库连接数、标准化扩容、跨机房稳定性和性能问题就会逐渐凸显。

数据库连接数问题

先来看数据库连接数的问题。在云原生背景下，应用可以轻松实现横向扩容，但每个扩容出来的实例都会对数据库产生连接数，随着业务量的增大，数据库连接数上限往往成为集群扩容的瓶颈。在没有使用分布式数据库时，可以通过单元化来解决这个问题的。在数据资源与逻辑资源进行绑定后，每个单元的数据资源就是确定的，连带着计算资源也就确定下来。我们可以通过单元来控制数据库的连接数，并通过单元扩容的方式来实现分布式系统的整体扩容。

分布式运维与扩容问题

接下来看第二个问题——分布式运维与扩容。一般分布式系统都是通过监控告警配合人工干预的方式进行扩容，扩容的时机和容量需要依据经验判断，不一定能做到准确及时。如果采用单元化架构，那么以单元维度进行标准化扩容能够做到架构上整齐统一、运维动作标准化，也能够通过一个单元的业务量实现提前扩容的规划，真正做到操作前心里有数，操作时整齐划一。

跨机房性能问题

第三个问题——跨机房性能问题。在微服务集群中，应用通常是无状态的，这就意味着流量会进行无差别分发，那么接入层网关往服务层分发流量时，就会产生跨中心的访问，这极大影响了系统的稳定性和性能，如果使用单元化架构，那么单元化的流量闭环特征就能很好的解决这个问题。

异地多活问题

最后一个问题——异地多活。当架构逐渐演进到异地多活时，上述的稳定性和性能问题在异地场景下会被无限放大，因此，单元化也是实现异地多活的一种重要方案。

接下来，看一下腾讯云针对单元化提供的整体解决方案。

单元化架构解决方案

腾讯云单元化设计理念

腾讯云通过广泛的实践经验，归纳提炼出了腾讯云单元化架构，自上而下分为接入层、应用层、数据层和设施层。

接入层负责接收流量、识别流量、转发流量。识别后的流量被转发到应用层对应单元进行处理，单元按照客户维度进行拆分，在大多数场景下，单客户交易实现单元内闭环处理，少量的跨客户交易会进行跨单元处理。

整个体系的单元化架构是一个复杂的系统工程，涵盖了各个层面的综合设计，腾讯各产品提供对单元化原子能力的支持，ISV 伙伴基于原子能力实现服务封装。因此，腾讯单元化的设计始终秉承开放、轻量、灵活交付的设计与交付理念。

腾讯云应用单元化架构

站在整体核心系统应用的视角，我们可以按照业务逻辑将应用分为不同单元，最上面是接入层的接入单元 ADU，负责接入接出能力。在应用层，按照业务可拆分性，分为 SDU、LDU 和 RDU。最底层为公共组件 GDU。在业务进行单元化改造的过程中，可按照此规则进行单元定义和拆分。

接入单元(ADU)：负责接入接出能力。

标准处理单元(SDU)：负责业务处理能力。

本地单元(LDU)：提供单AZ共享服务能力。

同城单元(RDU)：提供同城共享服务能力。

全局单元(GDU)：异地多活架构中的全局类型服务。

腾讯云微服务平台（TSF）介绍

有了单元化的整体概念，接下来看看单元化在微服务层面的最佳实践。

TSF：开箱即用的微服务平台

腾讯云微服务平台（ Tencent Service Framework，TSF）是一个兼容 Spring Cloud 和 Service Mesh 等多种微服务架构的商业化 PaaS 平台框架，提供一站式微服务全生命周期管理能力、数据化运营支持，提供多维度应用和服务治理。具有无代码改造迁移、业务快速部署、细粒度服务治理、快速问题定位排查、轻量化运维等功能。

TSF 核心特性与价值

使用标准化

TSF 提供标准化的服务接入规范、统一的标准操作体验、统一的注册和配置中心服务，标准化的部署管理，能够给客户带来接入、操作、配置一致体验。

技术多元化

TSF 兼容 SpringCloud, Dubbo、Service Mesh、GRPC、Spring Cloud 等主流框架。

能力全栈化

TSF 微服务平台拥有完备的权限管控体系，提供多样化的服务治理能力，技术体系自主可控，支持性能调优与运维排障，具有全方位服务治理和全周期管理能力，能够满足用户对微服务平台的诉求。

近年来，随着越来越多的客户进行架构升级，从单体应用改造为微服务应用，从云下迁移上云，能够覆盖开发、测试、发布、生产等各个阶段核心要求就成为了产品必不可少的能力，TSF 在上述各个阶段都提供了全面的管理能力，是众多客户采购一站式微服务平台的首要选择。

TSF 始终保持对高可用与单元化的探索，我们致力于不断优化底层架构以确保平台的稳定性和可靠性。同时，我们也在不断研究和实践高可用，提供标准化产品能力，带给客户更加稳定、可靠和愉悦的体验。

TSF 单元化产品能力

TSF 伴随客户一起成长，根据不同的客户诉求，从单中心、同城多活、两地三中心到异地多活演进的各个阶段，都提供了相应的解决方案。如今，在大型金融机构纷纷尝试异地多活单元化架构时，我们也发布了 TSF 异地多活单元化的产品能力，辅助用户进行单元化架构的探索与实践。

接下来对几个关键的阶段简单介绍一下。

同城多活

TSF 很早就具备了同城多活的能力，这也是大多数微服务客户对于高可用的诉求。

什么是多活呢？

同城多活其实就是在云原生架构下的一个多活的解决方案，我们在同一个地域通常会有多个可用区，比如说有可用区 A 和 B，我们在两个可用区都部署了相同的服务，同城双活互为主备。

同城双活的架构实施起来较为容易，但是他只能应对机房故障，当整个地域都挂的时候，服务依旧是不可用的，这时候就需要两地三中心。

两地三中心（单元化）

一般来讲，两地三中心有两种方式可以做到，异地灾备和单元化，这两种架构目前都有客户在使用，区别是，单元化的模式能够获得单元化带来的一些优势，比如单元灰度，单元整体扩容等，但由于异地都用于灾备，因此资源闲置问题严重。

异地多活

异地多活的挑战就是为了让闲置异地资源也活起来，那么单元化就是解决异地场景下数据同步和访问时延的最好方式。在异地多活单元化下，多地的服务都能提供业务服务，同时由于单元流量闭环的特性，异地访问的概率大大降低，数据也无需实时全量同步，能够实现跨地域的高可用单元化多活容灾。

TSF 单元化产品能力矩阵

为了帮助我们的客户使用单元化架构，TSF 发布了对应的产品能力，涵盖单元化管理、高可用容灾、高效运维三大核心场景。

在实施单元化前，首先需要进行架构规划，设计好单元数量、添加好单元化产品，包括接入层的单元化网关、应用层的微服务平台、消息队列和数据层的数据库。在实施时，需要配置单元化规则，并将其推送给各个组件。如果需要进行单元灰度，还支持配置灰度单元与灰度规则。

除了基本的能力，单元化下的容灾与可观测也是单元化建设的重点。在容灾场景下，TSF 提供容灾单元配置，容灾一键切换、容灾仿真演练等多项容灾能力。在运维方面，支持统一的单元化监控与告警，监控并追踪跨单元或跨机房的请求。

下面，来看几个核心设计要点。

单元化路由

客户端请求携带标签路由到单元化网关，网关根据标签计算出目标单元。TSF会识别本次调用是单元内调用还是跨单元调用，再将请求转发到对应的单元。对于相同服务的调用顺序为：优先单元内调用，其次本中心调用，最后同城中心调用。

单元灰度

以上是单元化路由的主要过程，接下来再看单元灰度的实现方式。在标准微服务架构中，灰度发布主要依靠框架能力实现。通过应用之间版本隔离，流量能按照版本标记发送到指定的应用版本集群中，通过流量比例的控制，来实现生产流量中的一部分请求由灰度的应用集群处理。

在单元化场景下，可以首先设定1-2个灰度单元，然后明确灰度维度有哪些，比如常见的有按指定客户号或者客户标签灰度等等。在网关进行单元路由计算前，优先查询灰度表，如果请求特征命中灰度规则，那么直接按照表中定义好的单元进行路由，转发到对应的灰度单元，完成单元灰度。

单元化容灾

接下来看单元化容灾。

在异地多活场景下，当一个单元出现故障时，需要将该单元的流量尽快切换到其他单元以保证服务连续性。可以在架构规划时配置好互备单元表来建立单元间的互备关系。当其中一个单元出现故障时，通过更新状态，将流量指向互备单元从而进行路由调整。当发生切换时，数据库会将备单元下的副本调整为主本以提供服务。

比如这张图所展示的，当单元1发生故障时，停用单元1的流量，并获取单元1对应的互备单元信息（单元5），等待数据库主备切换完成，更新全局路由将流量转发至单元5。此时单元5除了承载自身业务流量还会承载单元1的业务流量。当单元1 故障恢复时，再通过回切调整网关层路由到单元 1。这样，就完成了灾备时的单元切换与回切。