相信大家对于分布式架构都很熟悉，但是可能对单元化不是很熟悉或者说没听说过单元化。本文将带你了解单元化架构的产生背景、相关架构方案等，应该会对你了解单元化有一定帮助。
概述
单元是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务和对应的数据，并以单元为基本部署单位，单元间实现逻辑或物理隔离，支持跨机房、跨地域方式部署，支持多地多活。
单元化和非单元化架构应用具有明显特点：
操作 | 非单元化 | 单元化 |
|---|---|---|
数据库连接 | 启动时连接所有数据库 | 启动时仅连接自身单元内的数据库 |
业务处理 | 随机选择一台服务器进行业务处理 | 根据用户访问不同单元下的服务器 |
数据处理 | 处理全部数据 | 每个单元只处理部分数据，所有单元组成完整的数据 |
产生背景
单元化通过灵活的模块化和自治的单元来处理大规模的数据和交易，这种架构不仅提高了系统的扩展性和灵活性，同时也增强了系统的容错能力和运维效率。目前，银行如：邮储、微众，大型互联网系统：比如淘宝、支付宝、网商银行等，都已经实现了单元化架构。下面从几个原因分析为什么选择单元化：
容量
业务使用量总是在不断增长，为了满足业务需求，业务服务系统、数据库都需要不断的扩容，以支持越来越多的业务数据。先来看传统的解决方案：基于分库分表的方案、基于分布式数据库的方案。
分库分表：实际上是 分布分表+主从，对应这个方案，单库容量有限，如果本身数据量就很大，并且考虑到日后的业务发展需求，可能需要十几二十套主从数据库（当然，要根据容量分析），这意味着所有的应用都需要与这些数据库建立连接，当业务服务数量随着业务量逐渐增多的时候，需要建立的连接数越来越多，而每个数据库可以承接的连接数是有限的，当超过数据库连接数上限的时候，再增加业务服务也无法实现扩容。
分布式数据库方案：分布式数据库如
TiDB等可以利用其分片扩容的特性来满足容量需求，但是可能存在逻辑单点问题，难于实现多地多活。跨片事务可能较多，性能较差。
如果采用单元化架构，每个单元内部署单套或多套主从模式的数据库，可以有效解决分库分表方案中数据库连接的问题，这种架构下，数据被划分到不同的单元，有助于分散数据库压力，提高吞吐量。
容灾
在非单元化架构的系统中，容灾通常是同城双中心的主从数据库部署和应用双活部署，依赖于主库的跨中心连接来实现的，对于网络性能和稳定性要求极高，并且可能显著影响整型的性能和稳定。由于所有数据都存储在单一数据库中，容灾备份的粒度较大，导致数据备份、恢复以及切换可能耗时较长。并且系统的隔离性较差。一旦数据库发生故障，整个系统可能无法提供服务。
在单元化架构下，不同类型的应用被分配到不同的单元，每种类型的单元设计有适合的容灾模型。由于某个单元服务或者数据库出现问题，只会影响该单元的请求，可以实现单元粒度的故障隔离，从而提高系统的可用性。
单元化下的容灾模型
在两地三中心或多地多中心部署模式下，不同的单元类型，将具有不同的容灾模型：
AAA：采用多中心多活部署，每个中心的服务均为可用，即Active-Active-Active，分别表示主中心、同城中心、异地中心。AAS：采用同城双中心双活部署，异地中心灾备部署，即Active-Active-StandBy，非主中心的流量比例较少。ASS：采用同城双中心主备模式部署，异地中心灾备部署，即Active-StandBy-StandBy。
多地多活
在非单元化架构的系统中，由于数据集中存储，核心系统难以实现多中心多活的容灾架构。即使借助分布式数据库的多节点部署能力，通常也不建议将不同数据节点主本部署在不同中心或异地中心，因为这可能带来一定的复杂性和风险。
相比之下，在单元化架构的分布式系统中，由于各单元的数据和应用相互独立，不同单元的数据库可以灵活部署，不仅可以部署在同城双中心，甚至可以扩展到异地多中心部署，有效提高系统对地域性故障的容忍度和业务连续性。
运维
在非单元化架构的系统中，由于所有应用和数据都集中在一个大型核心系统中，运维工作的复杂性较高。系统的集中性操作，如升级发布等，可能带来较大风险。一次升级发布可能影响到整个系统的稳定性，增加运维工作的难度。
而在单元化架构的分布式系统中，通过将大型核心系统按照不同单元类型拆分，特别是业务单元拆分，可以将其细分为更小、更易于管理的单元。这种拆分极大提高了系统维护和管理的灵活性和便利性，例如：日志、链路追踪及监控均可按照单元维度提供视图，使得监控更加精细、准确。此外，基于单元的自治性，能够实施更精细的治理措施。在灰度发布过程中，利用白名单机制，可以精确控制哪些单元进行更新，从而在应用和数据层面实现更为平滑的版本迭代，有效提高开发和运维效率，同时增强系统的稳定性和可靠性。
单元分类
那么核心系统的单元化的拆分标准是什么呢？下面提供一种实施方案。
数据分类
单元分类的前提是对数据按照可分区和不可分区的分类。核心系统中，对于客户维度的数据往往是可拆分的，而公共业务参数或者技术参数，一般需要集中管理，并不适合拆分为多个子集进行管理的使用，例如：机构参数、产品参数、定价参数等，又比如：批量调度、全局路由（用于单元定位）等，需要通过集中管理主本以及多副本共享方式进行使用。依照这个特性，可以将数据分为三类：可拆分数据（业务单元）、不可拆分数据（管理单元，被访问的频率较低） 和 不可拆分数据副本（公共单元，会被频繁访问）。
另外，除这些数据以外，核心系统及其平台，可能还涉及到一些公共的基础组件或服务，都会纳入单元的管理范畴，一般是归属到公共单元。
单元模型
根据数据可拆分和不可拆分的特性，可将单元分为 A、B、C 三种类型。
AZone-管理单元（Admin Zone）：不可拆分数据的管理。如：全局定位服务、参数管理、批量调度等。应用为无状态，数据为全局不可拆分数据。应用容灾策略为AAS，数据容灾策略为ASS。BZone- 业务单元（Busi Zone）：用于对客的应用，如：存款系统、贷款系统等。每个单元为自包含，客户账务相关的服务尽量全部部署进BZone，确保所有核心业务链路按客户维度封闭在各BZone中，并具备异地多活和水平扩容能力。单元容灾策略为AAS。CZone- 公共单元（Common Zone）：在BZone的业务处理中，若无法将链路封闭在同一个单元内，需要频繁访问一些公共的参数或者副本数据，且这些数据的时效性和一致性有一定的容忍度，可以部署到CZone，其一般为AZone的查询服务以副本数据，容灾策略为AAA。
灰度单元
一般来说，灰度发布有两个层级：
应用灰度：在同一份数据下，对应用集群进行分组，如：蓝绿，在发版时，先对蓝版本进行分流、升级、验证、滚动升级等处理。这样可以在一定程度上验证新版本的可靠性，前提是新旧版本要对数据库脚本兼容。
数据灰度：当应用灰度无法解决新旧版本兼容问题时，可以考虑通过数据灰度的方式（即 灰度单元）来缩短业务中断的时间。
考虑到灰度单元只是少量白名单客户，采用
N+1模式，节省灰度单元资源需求。即在常规N个单元基础上，增加 1 个灰度单元，且此单元双中心部署应用集群和数据库主从副本。
单元模式
单元模式一般包含 固定单元模式 和 非固定单元模式。
固定单元模式
基于数据规模，设定了固定的单元数量，所有的系统或业务模块都采用这一固定的单元数量，且无特殊情况时一般不进行增减，适合于拥有大量存量数据且未来数据增长可预见的系统，特性如下：
某一系统或多个系统采用相同的单元数量，且采用相同的路由算法；
各个业务模块可根据自身数据量采用是否分库分表；
有利于统一架构部署和运维管控。
非固定单元模式
根据系统当前数据量初始化单元数，后续通过增加单元数来实现系统扩容，可采用逐个或多个增加方式。适用于初始数据不多，未来可能出现爆发式增长、业务分布可能不均匀的系统。特性如下：
每个业务领域或微服务按自身数据量确定初始单元数，且按自身增长情况进行扩容，互不影响；
路由策略往往不需要算法，而是采用映射的方式；
由于单元数量不固定，运维无法按照固定的单元进行管控。
对于固定模式单元数一般不增加的原因，主要是固定单元模式下，系统是基于主要分片要素（如客户号）进行
HASH算法，从而得到分片号，并将该分片号映射到对应的单元。基于这一规则，如果想要增加单元，就必须将特定的分片数据迁移到新的单元中。这种数据迁移可能想当复杂和耗时，因此，为了避免这种复杂性，通常不会频繁的增加单元。此外，系统相关的配套组件、运维工具和监控页面也需要对新的单元进行适配和支持。
数据切分
单元化的核心思想是数据切分，单元自治和隔离。切分原则主要考虑如下：
粒度合适：粒度过大，会让流量适配的灵活性和精细度受到制约；粒度过小，会给数据的支撑资源、访问逻辑带来负担；
数据分布均匀：按指定维度划分后，每个分区的数据量应该几乎一致；
性能优先：拆分规则和算法要足够简单且和业务无关，有利于应用路由定位服务的落地实现；另外，不能因为 切分使得业务流程变得复杂。
切分维度 | 说明 | 优势 | 不足 |
|---|---|---|---|
客户维度 | 以客户号为主要素进行哈希求模得到分片或直接映射到分片，账号及卡号等作为辅助要素，与客户号建立映射关系。 | 分布均匀，大量交易在单元内完成，少量交易涉及跨客户；机构撤并不涉及单元变更。 | 非客户维度查询困难，客户合并处理复杂，但量不大。 |
机构维度 | 以开客户机构号为主要素映射到分片，任何一个客户归属于唯一机构。客户下的账户等都归属到该分片。 | 路由策略相对简单，若外围能提供开户机构号，路由策略非常简单，有利于客户维度的业务处理。 | 机构客户数据分布不均匀，增长可能不均。机构撤并涉及数据迁移量大，需要外围提供相关的机构号或者路由存储客户与机构关系。 |
流水号 | 按流水号 | 均匀，单元无状态，无限扩展。 | 适用性对系统类型局限性。 |
单元路由
单元化架构与传统架构最大的区别，就是数据的分区和路由。即当一笔交易请求进到网关服务时，如何才能路由到正确的业务单元。选择、获取和传递路由主要素和辅助要素对整个系统非常关键。
评论区