近期在小组的群里面看到同事在和leader讨论 “分账/补差入分区”的方案。 虽然当前负责的业务还没有接触到分区的具体事项，但是资料都是共享的，依然可以从中学习在整体方案设计中思考 同时先写本文记录自己的一些理解，同时期望后续随着理解不断加深，得以不断完善。
以下内容主要参考:
内部叫做分区，外部一般称之为Set化，本文后面也就用Set化这个名词来表达分区这个事情，不管叫什么，其本质是 将业务系统分为多个可独立扩展部署的逻辑分区，以期达到业务目标
一般来说，有两种目标
对于我们的业务来说，使用Set化的核心目标是通过分区冗余，达到5个9的可用性。（降低了全局的单点情况，控制了部分风险）
在上一个业务团队，其实已经接触到了分区的概念，当时的RPC框架和运维体系已经能够支持部分分区能力。（目前已经开源，https://github.com/TarsCloud/Tars ）
在业务实现时我们也应用过这种能力，我们将功能类通知/营销类通知完全隔离到不同的Set，在功能类通知中，又将最核心的业务（例如微信注册触达，王者注册触达等触达类业务）放在独立的Set，再变更时，优先变更 营销，功能，功能（核心业务）
这里也介绍一下Tars的Set能力，以下内容主要参考:
当你的集群上了规模之后, 服务器可能部署在不同机房或网段, 为了能够减少跨网调用, 保证同一个分组的服务调用时优先, Tars设计了分组机制.
目前Tars设计了两种分组: IDC分组和SET分组
IDC分组简单的说, 通过IP网段自动将服务器分组. SET分组可以根据你的设置, 将服务器设置分组.
具体调用策略可以参考上面的文档，还是挺有意思的。
主要几个思路：
这里还有很多设计点和思考点，因为自己了解程度有限和涉及到业务敏感，暂时先只列一个提纲，等到合适的时机，放在附录中。
以下内容主要来自于，建议阅读原文：
单元化的好处：
怎么做单元化：
支付宝的单元化架构中，把单元称之为 “zone”，并且为上面所说的3类数据分别设计了三种不同类型的 zone：
RZone（Region Zone）：最符合理论上单元定义的 zone，每个 RZone 都是自包含的，拥有自己的数据，能完成所有业务。 GZone（Global Zone）：部署了不可拆分的数据和服务，这些数据或服务可能会被RZone依赖。GZone 在全局只有一组，数据仅有一份。 CZone（City Zone）：同样部署了不可拆分的数据和服务，也会被 RZone 依赖。跟 GZone 不同的是，CZone 中的数据或服务会被 RZone 频繁访问，每一笔业务至少会访问一次；而 GZone 被 RZone 访问的频率则低的多。
RZone 是成组部署的，组内 A/B 集群互为备份，可随时调整 A/B 之间的流量比例。可以把一组 RZone 部署的任意机房中，包括异地机房，数据随着 zone 一起走。 GZone 也是成组部署的，A/B 互备，同样可以调整流量。GZone 只有一组，必须部署在同一个城市中。 CZone 是一种很特殊的 zone，它是为了解决最让人头疼的异地延时问题而诞生的，可以说是支付宝单元化架构的一个创新。 CZone 解决这个问题的核心思想是：把数据搬到本地，并基于一个假设：大部分数据被创建（写入）和被使用（读取）之间是有时间差的
把数据搬到本地：在某个机房创建或更新的公共数据，以增量的方式同步给异地所有机房，并且同步是双向的，也就是说在大多数时间，所有机房里的公共数据库，内容都是一样的。这就使得部署在任何城市的 RZone，都可以在本地访问公共数据，消除了跨地访问的影响。整个过程中唯一受到异地延时影响的，就只有数据同步，而这影响，也会被下面所说的时间差抹掉。
时间差假设：举例说明，2 个用户分属两个不同的 RZone，分别部署在两地，用户 A 要给用户 B 做一笔转账，系统处理时必须同时拿到 A 和 B 的会员信息；而 B 是一个刚刚新建的用户，它创建后，其会员信息会进入它所在机房的公共数据库，然后再同步给 A 所在的机房。如果 A 发起转账的时候，B 的信息还没有同步给 A 的机房，这笔业务就会失败。时间差假设就是，对于 80% 以上的公共数据，这种情况不会发生，也就是说 B 的会员信息创建后，过了足够长的时间后，A 才会发起对 B 的转账。
需要哪些支持？
其他资料参考: