共计 4559 个字符，预计需要花费 12 分钟才能阅读完成。
导语
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 异地多活单元化能力降级只是产品倒退的一小步，微服务团队心愿将来能把产品打磨的更好，满足客户更多的需要。
