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

导语

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

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

单元化架构的概述

什么是单元化

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

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

图片

单元的特征与类型

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

单元的特征

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

单元的类型

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

图片

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

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

单元化的价值

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

数据库连接数问题

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

分布式运维与扩容问题

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

跨机房性能问题

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

异地多活问题

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

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

单元化架构解决方案

腾讯云单元化设计理念

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

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

图片

整个体系的单元化架构是一个复杂的系统工程,涵盖了各个层面的综合设计,腾讯各产品提供对单元化原子能力的支持,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。这样,就完成了灾备时的单元切换与回切。

图片

总结

本篇文章从单元化讲起,首先介绍了单元化的概念与价值,以及腾讯单元化的整体解决方案。然后聚焦在微服务领域,介绍了腾讯微服务平台 TSF 以及 TSF 对单元化支持的产品能力,并重点介绍了单元路由、单元灰度和容灾切换三种核心场景。

乘骐骥以驰骋兮,来吾道夫先路。腾讯云微服务平台 TSF  异地多活单元化能力升级只是产品发展的一小步,微服务团队希望未来能把产品打磨的更好,满足客户更多的需求。