异地多活的单元化设计

原创声明：本文系作者原创，谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。 

现在的互联网技术从业者或多或少知道阿里"单元化"技术这个词，阿里的很多业务线和系统，都已实现单元化架构，很多其他公司也在参考阿里单元化方案，实现自己的多活架构。单元技术是阿里巴巴异地多活实践中总结出来的基于核心业务的跨机房分流量技术，如之前提到,实际的软件系统技术上很难100%业务使用多活，只能尽量保证绝大部分用户的核心业务异地多活，单元化也是如此，那么我们在设计中，怎样评估哪些业务是否使用单元化改造、单元化怎样提升系统性能、实施成本又如何呢。本文结合实施中的经验及调研资料，描绘了单元化实施过程中的顶层架构和部分细节。

一、单元化是什么

单元化技术是阿里异地多活方案的内部代号，同城多活是它的第一步，主要解决双11购物的大流量问题，涉及到数据库垂直、水平分库、数据库复制、数据库一致性、应用层多活、接入层流量控制等一系列技术。是目前国内异地多活实施稳定、学习资料容易查阅的一个方案。核心设计思想是从C端用户角度考虑，将用户核心业务的闭环链(比如购物闭环)，内聚到一个单元，用户在C端操作的一个完整过程，相关数据都能在一个单元内完成，避免跨单元获取数据。这里的一个单元可以是一个机房，也可以是一个机房内的某一组子系统群。

单元化系统里面是一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的全部服务，以及分配给这个单元的数据、资源。单元化架构的外在形态是把一个单元作为系统部署的基本单位，在全站所有机房中部署数个单元，每个机房里的单元数目不定，任意一个单元都部署了系统所需的所有的应用，数据则是全量数据按照某种维度划分后的一部分。如下是单元化的部署形态:

二、哪些业务需要做单元化

原理上，带有user_id字段(除了用户中心业务)的C端核心业务都可使用单元化方案改造，具体如购物下单、抢购、秒杀等，理论上都支持单元化改造。

如阿里毕玄提到，决策整个架构的方案，对系统未来将产生深远影响，并且涉及到很多人力的投入，因此这种顶层决策应该是谨慎的、有依据的。所以对于业务单元化改造问题，千万要谨慎，切勿神话阿里的单元化技术。

三、怎样做单元化

实际中，单元化很难有实施到完美的模型，因为数据这里，就存在很多分类的数据，不能满足完美的单元化。而数据分类问题，也是影响单元化最后质量好坏的关键。

1.数据归类

在"多数据中心数据分类" 文章中，我们提到 "多数据中心系统数据需要解决3类数据的问题：业务层可分区数据、高频全局数据、低频全局数据。" ,数据分类是单元化的设计前提，因为各种类型的数据，在数据复制和垂直、水平设计时，同步方案不一样。每种数据的详细处理细节，可以参考“多数据中心数据分类” 文章。

2.数据复制

数据复制指不同机房间数据库复制， 数据复制基本会有如下几种方案:

• 基于mysql的原生复制,做主主架构,两边都开启写入。
• 基于PXC galera类似的数据库集群方案
• 基于otter+canal、Apache Pulsar的开源数据同步方案
• 自研数据复制方案

前两种合适在机房内的数据库复制，不合适地域级跨机房复制，而阿里开源的otter+canal方案是创业企业较常用的跨机房复制方案。

如果将单元化一系列难点作排名，数据库复制是排前3的，因为多活解决的最大难点就是数据复制带来的延迟。目前数据库复制的中间件很多，比如阿里otter+canal方案、Apache Pulsar等。一般的公司如果强调业务的快速迭代，支持用开源的中间件方案实施，当然，熟练使用中间件的成本和代价也很高。如果有研发能力，可以考虑自研实现。数据同步这里，总体上需要基于mysql等存储的私有协议，基于协议读取bin_log数据，然后再使用队列传输到另一个数据中心恢复数据。具体的复制细节方案我们在另外的文章里再作分享。

四、单元化调度规则

具有各个单元化系统后，就需要有一个支持全部单元的调度系统，调度所有单元系统。比如业务流量在单元之间怎样分配，单元之间是否能跨越访问业务，这些规则都需要一个全局性的调度中心实现并且能及时实时控制所有单元节点的运行。运营人员就在这个调度中心设置各种单元规则并实时性下发到各个子单元。

五、单元化中间件

单元化涉及到接入路由、数据队列、缓存、api路由、数据库复制、数据库事务等一些系列关键技术。从阿里资料上显示，单元化改造让本身的业务开发变得更复杂。而实际上现在看到的复杂性比起它的原本的程度来说降低了太多。这其中是由于中间件技术最大程度屏蔽了单元化的很多细节，让单元化架构尽量对业务层透明。阿里巴巴大牛些提供了一整套专门针对单元化而研制的中间件，即阿里原生 (Native) 单元化生态，如数据库中间件MyCAT，将数据库垂直和水平分库的细节隐藏在业务之下，上层业务使用起来跟单库单表没什么区别，同时数据访问层能实时动态感知单元化分流规则，根据规则变化决策是否连接某个数据分库，以及一笔业务是否允许访问某个数据分库。阿里单元化的本质是对数据的逻辑隔离，有这样一个数据访问中间件对单元化建设来说是必不可少，它解耦了业务层对数据层结构的依赖，大大降低了理解成本和业务开发成本。另外重要的有负责信息传递的中间件，正是它们让业务可以成为单元。这其中有dubbo微服务框架、消息中间件等，它们能够根据单元化规则把系统应用间的服务调用或消息流转约束在一个逻辑区域内，再配合上数据访问中间件对数据访问的约束，就让这一个个逻辑区域形成了一个个单元。如果有些调用必须跨单元发生，也由它们根据规则执行转发，不需要业务层关心。

总之，中间件的抽象降低了单元化的连接成本，同时也相对降低了实施成本，这是单元实施最关键的设计。

六、单元化的部署及运维监控

单元化让系统变成了粒度更可控的一个个单位，这也让单元的发布变得更难，所以就需要一套面向单元化的运维系统作支撑。这个运维系统以单元为管理单位，单元之间独立管理、互不影响。基于最基本的单元隔离机制，阿里设计了更为高级的统一编排和控制部署进度的蓝绿发布功能，目前实践中，我们也在使用实施蓝绿方案。除此，单元监控系统也要求能够细化到单元粒度展示监控信息和发送报警，以协助判断每个单元中的系统健康程度，为快速执行流量切换以隔离故障等操作提供依据。

七、结束语

总之，单元化的改造并非一日之功，每个环节都需要极其精细同时复杂的工程。希望本篇文章能帮助到你学习和实践单元化设计和实施。