单元化架构
为何需要：不断增长的海量用户的需求
所谓单元，是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据
- 根据用户单元化
核心问题
- 扩展性
- 数据库的瓶颈限制了应用的扩展
- 数据中心扩展性
- 物理因素所制约
- 容错性
演进
分层（根据技术以服务形式划分） ->
分段（根据业务能力隔离） ->
单元化架构（独立开发运行的一套套系统）
CRG架构
从单元化的角度，数据的分类：
- 可分区数据：按照选择好的维度进行分区的数据，真正能被单元化的数据
- 全局数据（不被关键链路业务共享）：不能被分区的数据，全局只能有一份，常见的如配置类数据
- 全局数据（被关键链路业务共享）：不能被分区的数据，全局只能有一份，常见的如配置类数据，如果希望通过单元化获得多地多活的能力，这种数据需要特殊处理
单元类型的划分：
- RZone（Region Zone）：最符合理论上单元定义的 Zone，每个 RZone 都是自包含的，拥有自己的数据，能完成所有业务。
- GZone（Global Zone）：部署了不可拆分的数据和服务，这些数据或服务可能会被RZone 依赖。GZone 在全局只有一组，数据仅有一份。
- CZone（City Zone）：同样部署了不可拆分的数据和服务，也会被 RZone 依赖。跟GZone 不同的是，CZone 中的数据或服务会被 RZone 频繁访问
CZone 基于数据写入跟数据读取是有一定时间差这个假设，通过异步的方式在写入时同步到其他机房
组件
- 单元化架构的最小原子单位
- 在一定域内 拥有一定业务功能的服务
- 组件间有依赖和约束关系
名称与版本
- 全局唯一的名称
- 以版本管理的形式来控制单元的演化
独立性
设计单元的最终目的就是单元独立开发部署
完备性
相关业务场景置于同一单元 逻辑完备
业务单元之间应减少交集
通信
单元间的通信都必须通过某种统一的网络接口进行
单元内的组件通过可被允许的通信协议进行通信
什么时候用
- 要异地多活
- 系统功能与地域强关联
- 高可用、容灾
- 要突破扩展上限
- 突破单点（机房、数据库）瓶颈
设计
设计原则
- 透明性：对开发者与基础设施来说 服务与哪个单元是不重要的
- 系统、数据可被切分
- 业务自包含、自治
要素
业务切分
- 系统根据功能、用户等进行切分拆散到不同单元
使用DDD或者其他什么方式来切分，很像微服务，但切分业务单元时不可避免的会出现一些交集，要保证跨单元操作尽量少，这种拆分与组织架构与业务流程强相关并且可能会反过来影响组织架构，拆分的粒度可参考微服务，需要不断迭代演进。
另外一种是根据用户的地域或者类型等维度根据不同的单元来服务不同的用户，但怎么说，系统中肯定会有一些共同需要有的数据，可以使用数据的复制机制来解决，这样子若数据需同步，则需要一个分布式的ID生成方案来保证不会冲突。这种方式可能会由于用户的不均出现热点单元与冷单元，需要二次拆分或者合并，并且当用户切分维度发生改变时要继续将用户数据同步到新的单元上去。
最后一种方式，是根据数据进行切分，可以参考分库分表
单元路由
- 考虑流量在各个云、中间件间的路由
单元间或者单元内的组件之间通信都是通过各种中间件、代理、网关等来进行，这主要是为了安全与解耦
对于外网的访问，可以使用不同的显式入口、或者在请求里携带标志位来进行路由。外网的请求来到单元网关，网关需进行判断是否接收该请求，以此是否继续路由到单元内部，应用层的处理方式将会进行网络过滤，业务逻辑不必关心，再来到中间件层 最后是数据层
而对于跨 zone 的请求，应用需要通过某种方式，向服务框架提供计算目标单元的信息，再通过 rpc 调用，携带单元信息进行调用。
弹性伸缩
可以在业务在出现热点后，进行拆分、扩容，以应对流量激增
单元规划
一个单元化架构系统，应尽可能提高 RZone 应用的比例，减少 GZone 应用，有限地使用 CZone
数据复制
- 数据复制的一些问题 一致性 延迟等等
当跨单元需要大量数据时，数据复制是比较好的方式
- 单元间直接复制
- 通过中台复制
根据业务场景选择强一致、最终一致、评估失败的业务的影响